From nobody Mon Sep 3 00:49:33 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90B0130E0C for ; Mon, 3 Sep 2018 00:49:30 -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 autolearn_force=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 mZL6yDDep693 for ; Mon, 3 Sep 2018 00:49:28 -0700 (PDT) Received: from visuela.unizar.es (visuela.unizar.es [155.210.1.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC31212DD85 for ; Mon, 3 Sep 2018 00:49:27 -0700 (PDT) Received: from gtc1pc12.cps.unizar.es ([155.210.158.17] helo=usuarioPC) by visuela.unizar.es with esmtpa (Exim 4.89) (envelope-from ) id 1fwjbx-0005H3-OE for lisp@ietf.org; Mon, 03 Sep 2018 09:49:25 +0200 From: "Jose Saldana" To: References: <153596015362.13308.4526227836350132395.idtracker@ietfa.amsl.com> In-Reply-To: <153596015362.13308.4526227836350132395.idtracker@ietfa.amsl.com> Date: Mon, 3 Sep 2018 09:49:27 +0200 Message-ID: <008401d4435a$a3d54e10$eb7fea30$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG6pQ2JfKqwAajalaLruW1Rw/rpVqURawxQ Content-Language: es Archived-At: Subject: [lisp] RV: New Version Notification for draft-saldana-lisp-compress-mux-05.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 07:49:31 -0000 > De: internet-drafts@ietf.org > Enviado el: lunes, 3 de septiembre de 2018 9:36 > Para: Jose Mas ; Julian Navajas ; = Julian > Fernandez Navajas ; Jose Ruiz Mas = ; Jose > Saldana > Asunto: New Version Notification for = draft-saldana-lisp-compress-mux-05.txt >=20 >=20 > A new version of I-D, draft-saldana-lisp-compress-mux-05.txt > has been successfully submitted by Jose Saldana and posted to the IETF > repository. >=20 > Name: draft-saldana-lisp-compress-mux > Revision: 05 > Title: Header compression and multiplexing in LISP > Document date: 2018-09-03 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-saldana-lisp-compress-mux- > 05.txt > Status: = https://datatracker.ietf.org/doc/draft-saldana-lisp-compress-mux/ > Htmlized: = https://tools.ietf.org/html/draft-saldana-lisp-compress-mux-05 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-saldana-lisp-compress-mux > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-saldana-lisp-compress-mux-05 >=20 > Abstract: > When small payloads are transmitted through a packet-switched > network, the resulting overhead may result significant. This is > stressed in the case of LISP, where a number of headers have to be > added to each packet. >=20 > This document proposes a way to send together, into a single = packet, > a number of small packets, which are in the buffer of a ITR, having > the same ETR as destination. This way, they can share a single = LISP > header, and therefore bandwidth savings can be obtained, and a > reduction in the overall number of packets sent to the network can = be > achieved. >=20 >=20 >=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 > The IETF Secretariat From nobody Mon Sep 3 05:55:05 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 023B4130E23; Mon, 3 Sep 2018 05:54:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Colin Perkins To: Cc: draft-ietf-lisp-rfc6833bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153597929696.13392.8265627120055145654@ietfa.amsl.com> Date: Mon, 03 Sep 2018 05:54:57 -0700 Archived-At: Subject: [lisp] Tsvart last call review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.27 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 12:54:57 -0000 Reviewer: Colin Perkins Review result: On the Right Track I've reviewed this document as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. I have several concerns with the transport aspects of this draft. Many of these appear to be present in RFC 6833 also, but I note that while RFC 6833 is an Experimental, this draft is targeted at the Standards Track. Some of these issues may not be of practical concern, depending on the way LISP is used, and might just need clarifications in the draft to make it clear they do not occur in practice. The draft defines the LISP control plane. It updates and greatly extends RFC 6833. The control plane runs over UDP, and this draft defines the format of LISP control plane messages and rules for processing such messages. The packet formats generally contain lists of records, the length of which is indicated by an 8-bit Record Count field located in a common sub-header. The format allows packets that are larger than the typical path MTUs seen in the Internet, but the draft doesn’t mention Path MTU discovery to determine the largest packet that can be sent, or how large packets are fragmented. Perhaps the messages are small enough that this is not a practical issue? In which case the draft should explain and justify this for each message type (and perhaps put limits on the Record Count to ensure it). Alternatively, then the draft should specify how path MTU discovery is to be performed, and how protocol messages should be fragmented (or subdivided) to fit the path MTU. Section 3.2 of RFC 8085 has some further discussion and suggestions for how to address this issue. The draft does not mention congestion control, but many of the messages are rate limited. If the intent of the rate limits is that no further congestion control is needed, then it needs to be made explicit that this is the case, and some justification needs to be added to explain why it is safe. This could, perhaps, take the form of an appendix that analyses the expected control plane traffic that will flow over a particular path when the protocol is in use, and demonstrates that this will be low enough rate not to be problematic. In any case, the draft needs some discussion of how congestion control is addressed. It’s unclear what messages need to be retransmitted if they’re lost, and how to determine if a message is lost (e.g., what is the timeout) and what is the retransmission schedule. This may be clear to a reader with an in-depth understanding of LISP, but it would be helpful to provide more explicit statements about loss detection and retransmission. Many of these issues could perhaps be addressed by running the control plane over TCP rather than UDP, as is beginning to happen with the DNS. I understand that this would be a significant late change to the protocol. The control plane messages contain embedded IP addresses. Does this cause any issues in the presence of NAT boxes, either by leaking information about private addressing or by distributing addresses that are unreachable outside their realm? I noticed there is a mention of an individual draft on LISP NAT Traversal in Section 5.6, but the embedded addresses are included in more places. Regards, Colin From nobody Tue Sep 4 09:33:20 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2C7130DDA; Tue, 4 Sep 2018 09:33: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lVKcQfg9lqwy; Tue, 4 Sep 2018 09:33:17 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 68345130F50; Tue, 4 Sep 2018 09:33:17 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id 7-v6so1936683pgf.2; Tue, 04 Sep 2018 09:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H24QGL3UlxROriSpXSueXkPCKTix6Zo4ASbnbZVDBwQ=; b=YzdwCgZM8V8PcH2hNJOMy1PuQsGjAbeGf9cGVXzcg7gFVfhHKPJCfSj+sLVjfIUp0q X3gqV8Ea3auwstnPidI//HTkTbQz7Q6VQvy9f0kSPoTcyZJvdd3ktQqH3HGGyexN7reQ JCbrHtbV5t1pkQkRNZyMxP52MRqmrcHWOfPYGytleqm/6f33HR35XZCuIUJq6WkIiLW+ Z3cLQPAdmQ1A4iWDDlMM7K8rUpveL4BAg1GRzYqMBEnW8CgHm+U5RBSVn9xLmpKIvM9N E+Vi3ymuG0a3I6Zjj6CFARlOoBlAuY0CgLTcdeC472quQd2BqVofj1rZDsWd6ljl2N6h aaIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H24QGL3UlxROriSpXSueXkPCKTix6Zo4ASbnbZVDBwQ=; b=OvszVFD1mRfp8BDkigDDODQJWuDb4n77c6cKGmrm60v7ny38K8MflrBOfMinZ4hzQh Z2vG9CZ4K7giqt0F49jgJbAQWxJHWCgoAGwI2FFnoOIjy25P+exVzKX+6ksgNgmc60Qy r8hsdKLY5wABlc7M/4dtxdhJ2leSQw/E187cGoWxCBhMRxN1Wouin1Nvi5OSWrnnGi4o DaEO+A+zuXcK5hOiZyQCYxQikx/xn1JEZO9w47IhITtTk3p4wWmzZ9WlSKx+iT62FEA2 FTnuINxw1fMcCy1mssrHwq9pUGs/CUnmsQ5Xow8yh06IZl1aCHIyOHULAQoVNoy+ra+m d4Pg== X-Gm-Message-State: APzg51DJ9lOgM5TfijSLketAaAk0mX4Cj3UbHEUV0e5qhgtVtsQGUs1z NILNOu2IEA0w5WNrOobEo/E= X-Google-Smtp-Source: ANB0VdZwqS2h4sqXiec9jdLh9zYI6Zvf8gZ/I5dNevHwttQm3msU+G9CW8biuuPkRLls5dfeKMwDAQ== X-Received: by 2002:a63:d343:: with SMTP id u3-v6mr27482862pgi.420.1536078796935; Tue, 04 Sep 2018 09:33:16 -0700 (PDT) Received: from [10.31.79.156] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id q85-v6sm35090858pfa.151.2018.09.04.09.33.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 09:33:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153597929696.13392.8265627120055145654@ietfa.amsl.com> Date: Tue, 4 Sep 2018 09:33:15 -0700 Cc: tsv-art@ietf.org, draft-ietf-lisp-rfc6833bis.all@ietf.org, IETF Discussion Mailing List , Dino Farinacci , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: References: <153597929696.13392.8265627120055145654@ietfa.amsl.com> To: Colin Perkins X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 16:33:19 -0000 > Reviewer: Colin Perkins > Review result: On the Right Track >=20 > I've reviewed this document as part of the transport area review = team's ongoing > effort to review key IETF documents. These comments were written = primarily for > the transport area directors, but are copied to the document's authors = for > their information and to allow them to address any issues raised. When = done at > the time of IETF Last Call, the authors should consider this review = together > with any other last-call comments they receive. Please always CC > tsv-art@ietf.org if you reply to or forward this review. Thanks a lot for the review Colin. > I have several concerns with the transport aspects of this draft. Many = of these > appear to be present in RFC 6833 also, but I note that while RFC 6833 = is an > Experimental, this draft is targeted at the Standards Track. Some of = these > issues may not be of practical concern, depending on the way LISP is = used, and > might just need clarifications in the draft to make it clear they do = not occur > in practice. Let me try helping with the clarification and if we need to add = clarification text, by all means, we will do so. > The draft defines the LISP control plane. It updates and greatly = extends RFC > 6833. The control plane runs over UDP, and this draft defines the = format of I hope you understand why it greatly updates RFC6833. It was due to the = working group=E2=80=99s decision to move the control-plane elements out = of RFC 6830 into RFC 6833bis. So the procedures and protocols are not = new just re-located. > LISP control plane messages and rules for processing such messages. = The packet > formats generally contain lists of records, the length of which is = indicated by > an 8-bit Record Count field located in a common sub-header. The format = allows > packets that are larger than the typical path MTUs seen in the = Internet, but > the draft doesn=E2=80=99t mention Path MTU discovery to determine the = largest packet > that can be sent, or how large packets are fragmented. Perhaps the = messages are > small enough that this is not a practical issue? In which case the = draft should > explain and justify this for each message type (and perhaps put limits = on the > Record Count to ensure it). Alternatively, then the draft should = specify how > path MTU discovery is to be performed, and how protocol messages = should be > fragmented (or subdivided) to fit the path MTU. Section 3.2 of RFC = 8085 has > some further discussion and suggestions for how to address this issue. The control-plane does=E2=80=99t try to send MTU size packets. It = depends on IP fragmentation/reassembly. But an implementation should = know it cannot build a LISP message larger than 65535 bytes. > The draft does not mention congestion control, but many of the = messages are > rate limited. If the intent of the rate limits is that no further = congestion > control is needed, then it needs to be made explicit that this is the = case, and Yes, that is the intent. > some justification needs to be added to explain why it is safe. This = could, > perhaps, take the form of an appendix that analyses the expected = control plane > traffic that will flow over a particular path when the protocol is in = use, and > demonstrates that this will be low enough rate not to be problematic. = In any > case, the draft needs some discussion of how congestion control is = addressed. The flow-control is coupled with protecting caches as well as request = and register load on map-resolvers and map-servers. > It=E2=80=99s unclear what messages need to be retransmitted if = they=E2=80=99re lost, and how to > determine if a message is lost (e.g., what is the timeout) and what is = the > retransmission schedule. This may be clear to a reader with an = in-depth > understanding of LISP, but it would be helpful to provide more = explicit > statements about loss detection and retransmission. Map-Registers are sent periodically but the text says that if Map-Notify = messages are desired for acknowledgement, the Map-Registers can be = transmitted more quickly in the case of loss. Map-Notify messages are obviously acknowledgement by Map-Notify-Ack. = That was an added message to RFC6833bis. Map-Requests and Map-Replies are reliability sent for cache population. = And the nonce is used for both security purproses and to associated a = Map-Reply to a previous sent Map-Request, which is rate-limited. That is pretty much it and I think is explained in pretty much detail. = So if you have any specific comments, please provide them. Thanks. > Many of these issues could perhaps be addressed by running the control = plane > over TCP rather than UDP, as is beginning to happen with the DNS. I = understand > that this would be a significant late change to the protocol. We have a draft that is considering running the LISP control-plane over = TCP/QUIC with the addition of encryped security TLS/QUIC. But not as a = replacement to UDP but so an LISP control-plane implementation cam be = simplfied. > The control plane messages contain embedded IP addresses. Does this = cause any > issues in the presence of NAT boxes, either by leaking information = about > private addressing or by distributing addresses that are unreachable = outside > their realm? I noticed there is a mention of an individual draft on = LISP NAT > Traversal in Section 5.6, but the embedded addresses are included in = more > places. We want private addresses to be inside of LISP control-plane packet = payload because there are cases where two xTRs want to determine if they = are behind the same NAT, so they can encapsulate directly to each other = with those private addresses. For xTRs that are not behind this common = NAT, RLOC-probing will tell them they cannot reach the private address. Yes, there is a NAT-traversal draft that has been a alive for quite a = long time. Many of us are trying to simplify the operation of LISP = NAT-traversal with implementation and deployment experience. Thanks again, Dino >=20 > Regards, > Colin >=20 From nobody Tue Sep 4 12:05:30 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2008A130F93 for ; Tue, 4 Sep 2018 12:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 b3tCPND3k19v for ; Tue, 4 Sep 2018 12:05:25 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 0164A130DCF for ; Tue, 4 Sep 2018 12:05:25 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id u11-v6so2066827plq.5 for ; Tue, 04 Sep 2018 12:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=dpEs/gvGY5/UKSanjwnuzOh7xZBqKkeO+w0JukYCDQE=; b=ZXC5fLURccyxMwFq43ZRz0j+Oe8uVgSlPIwH4CTEE0CqF9izrnohIj4F7OWyiFYsqg wlXwGV87P07TdKGiWbYwZcJnYprlezFq8+B+sRLSv0NJWlUb3MXZk+ZZE3btM1S5mL3n Z3gPmYMOQ4TEB1sx6ySyzFLOiUABMncuqVDTDxTS5RISV+tHVYB8OdK60BSV7iYYJc4K rArRkKL8DLQ6HHlISR6YlobDrE4+Y/RnNyjv8xxwlEeJ4T2+hwofxK8kbhKwhatIP53n 5ObpHJNOSH+SYn2kD8nQuFFAOk4DgtCWGiQg4lheoM6z+i2EAYrQi2K3U+BZbW/6wErN d4FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=dpEs/gvGY5/UKSanjwnuzOh7xZBqKkeO+w0JukYCDQE=; b=rDWsaUQnA2qXsNKBoklJp0KiCvot3mcxetWH2KPH69kRtLCoIPkIYjnbk6fawT56sa 5QCAezc5GC39prBGDElSc4sTj5ufSqvVsqgKd/3Jo3PrfZOXQuiHOr849ZuJWKhNi3Sr 4o3FRYzGOkBcxi96bQ5C5TgfrT1KMQE626bhn+7Nb2BmFM6SKhK4vF4CTb8zbSfpcMOn LWvtsdMAmyYhwCVwmiVySN80kHeswf3Y+H41pLDxYz5SMFowovgi4RRxeyc+0EW4OBlo JduX/TkZrB0sX8qlSmUMGuaYSDcfeJph58s0OElM7QOn4Hzdeun3VRQWihFrzi2LWr5c jC0Q== X-Gm-Message-State: APzg51CqoCKj6nGmrSWNTC4zHWsk28gsXhIM6WrKVqBbEp6hcLgco9ja Ii6GShm95YfvYsgMA81Y7hQYrxA9 X-Google-Smtp-Source: ANB0VdaYRIvk5ZTig7iy8vcy8ZzG/31NCbScYjrp5x2PzlghlUAHRKcZqpeIe4WnCgjAfKc2VpwT/w== X-Received: by 2002:a17:902:8506:: with SMTP id bj6-v6mr34459883plb.210.1536087924344; Tue, 04 Sep 2018 12:05:24 -0700 (PDT) Received: from [10.31.79.156] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id f75-v6sm37656571pfk.85.2018.09.04.12.05.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 12:05:23 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/alternative; boundary="Apple-Mail=_B3B0C1C2-E4EA-49B5-A4AB-81460C454B2D" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 4 Sep 2018 12:05:21 -0700 References: <153608761426.14137.783984991533026116@ietfa.amsl.com> Cc: Dino Farinacci , Erik Nordmark To: "lisp@ietf.org list" Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [lisp] Fwd: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 19:05:29 -0000 --Apple-Mail=_B3B0C1C2-E4EA-49B5-A4AB-81460C454B2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, here is an update that reflects comments we received at the = Montreal presentation: A diff file is included for your convenience.=20 At this time, I would like to request this document for working group = adoption. Thanks, Dino/Erik > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt > Date: September 4, 2018 at 12:00:14 PM PDT > To: > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : LISP Control-Plane ECDSA Authentication and = Authorization > Authors : Dino Farinacci > Erik Nordmark > Filename : draft-farinacci-lisp-ecdsa-auth-03.txt > Pages : 17 > Date : 2018-09-04 >=20 > Abstract: > This draft describes how LISP control-plane messages can be > individually authenticated and authorized without a a priori shared- > key configuration. Public-key cryptography is used with no new PKI > infrastructure required. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03 > = https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecdsa-auth-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-ecdsa-auth-03 >=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 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_B3B0C1C2-E4EA-49B5-A4AB-81460C454B2D Content-Type: multipart/mixed; boundary="Apple-Mail=_FDC9A972-FA97-4A0B-B8D3-B38879D71A8C" --Apple-Mail=_FDC9A972-FA97-4A0B-B8D3-B38879D71A8C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Folks, here is an update that reflects comments we received at the Montreal presentation:

--Apple-Mail=_FDC9A972-FA97-4A0B-B8D3-B38879D71A8C Content-Disposition: inline; filename=PastedGraphic-1.png Content-Type: image/png; x-unix-mode=0666; name="PastedGraphic-1.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABF4AAAF0CAYAAAAaS/0IAAAMK2lDQ1BJQ0MgUHJvZmlsZQAASImV VwdYU8kWnltSSWiBUKSE3kQp0gUCoUUQkCrYCEkgocSYEFTsqKjAWlCxYEVXRRRdCyCLDQsWFsXe HxZUlHVxFRsqb5IAuvq99753vm/u/e+ZM+f859yZ+WYA0IrlSaU5qDYAuZI8WVx4MGtsSiqL9AiQ AQZ0gDXw4fHl0qDY2CgAZeD9T3l3AyDK91Vnpa+f+/+r6AiEcj4ASCzE6QI5PxfiQwDgnnypLA8A QhfUW03Nk0JMhCyBngwShNhaiTPV2FuJ09U4SmWTEMeBOA0AMo3Hk2UCoKnkxcrnZ0I/mqUQu0gE YgnEjRAH8EU8AcSfIR6amzsZYi17iO3Tv/OT+Q+f6YM+ebzMQazORSXkELFcmsOb/n+W439Lbo5i IIYVbDSRLCJOmbOybtmTI5WYBvE5SXp0DMS6EF8TC1T2SvxUpIhI7Lf/wJdzYM0AEwCUJuCFREJs ArGlJCc6ql8fkCEO40IMa48miPO4CeqxqEA2Oa7fPzpNKA+NH8A8mSqW0qZYkZ0Y1O9zk0jIHfDZ UCBKSFbzRC/ni5OiIdaE+J48Oz6y3+ZFgYgTPWAjU8QpOcN/joEMWVic2gazzpUP5IX5isTc6H4c lSdKiFCPxSbyeSpuhhBnCeVjowZ4CoQhoeq8sEKhJLGfP1YmzQuO67ffLs2J7bfHGoU54Uq9JcSt 8vz4gbHdeXCyqfPFgTQvNkHNDdfL4o2KVXPAHUEU4IAQwAIK2NLBZJAFxK1ddV3wS90TBnhABjKB EDj3awZGJKt6JPAZDwrAnxAJgXxwXLCqVwjyof7LoFb9dAYZqt581Yhs8BTiXBAJcuC3QjVKMhgt CTyBGvFP0fmQaw5syr6fdCytAR0xlBhCjCCGER1wYzwA98Oj4JMNmxvujfsM8PpmT3hKaCM8Ilwn tBNuTxIXyn5gzgKjQTvkGNafXfr32eG20KsHHoz7Q//QN87EjYEzPgJGCsIDYWwPqP2eq2Iw42+1 7PdFcaGgFAMKm2L/IwNNR02PQS/KSn1fCzWv9MFqcQZ7fsyD8139BPAd+aMlthg7iDVjJ7HzWCNW B1jYcawea8GOKvHg3HiimhsD0eJUfLKhH/FP8Xj9MZVVk7tUu3S6fO7vA3nCaXnKxcKZLJ0uE2eK 8lhBcLcWsrgS/rChLDcXV7iLKvd+9dbyhqna0xHmhW+6wrcA+Av6+voav+mi4Jo8tBAA6tNvOrtj cDkbAHCuhK+Q5at1uPJBAFSgBVeKETCDe5c9zMgNeAI/wAahYBSIAQkgBUyEdRbBeSoDU8FMMA8U gRKwHKwG68FmsA3sAnvBAVAHGsFJcBZcBJfBdXAXzpUO8BJ0g3egF0EQEkJHGIgRYo7YIE6IG+KN BCChSBQSh6QgaUgmIkEUyExkPlKClCHrka1IFfIbcgQ5iZxH2pDbyEOkE/kb+YRiKA3VQ01RW3Q4 6o0GoZFoAjoBzUSnoAXoAnQpuhatRPegtehJ9CJ6HW1HX6I9GMA0MCZmgTlj3hgHi8FSsQxMhs3G irFyrBKrwRrgn76KtWNd2EeciDNwFu4M52sEnojz8Sn4bLwUX4/vwmvx0/hV/CHejX8l0AkmBCeC L4FLGEvIJEwlFBHKCTsIhwln4NrpILwjEolMoh3RC669FGIWcQaxlLiRuI94gthGfEzsIZFIRiQn kj8phsQj5ZGKSOtIe0jHSVdIHaQPZA2yOdmNHEZOJUvIheRy8m7yMfIV8jNyL0WbYkPxpcRQBJTp lGWU7ZQGyiVKB6WXqkO1o/pTE6hZ1HnUtdQa6hnqPeobDQ0NSw0fjTEaYo25Gms19muc03io8ZGm S3OkcWjjaQraUtpO2gnabdobOp1uS2fTU+l59KX0Kvop+gP6B02G5jBNrqZAc45mhWat5hXNV1oU LRutIK2JWgVa5VoHtS5pdWlTtG21Odo87dnaFdpHtG9q9+gwdFx1YnRydUp1duuc13muS9K11Q3V Fegu0N2me0r3MQNjWDE4DD5jPmM74wyjQ4+oZ6fH1cvSK9Hbq9eq162vqz9CP0l/mn6F/lH9dibG tGVymTnMZcwDzBvMTwamBkEGQoMlBjUGVwzeGw4xZBsKDYsN9xleN/xkxDIKNco2WmFUZ3TfGDd2 NB5jPNV4k/EZ464hekP8hvCHFA85MOSOCWriaBJnMsNkm0mLSY+pmWm4qdR0nekp0y4zphnbLMts ldkxs05zhnmAudh8lflx8xcsfVYQK4e1lnWa1W1hYhFhobDYatFq0WtpZ5loWWi5z/K+FdXK2yrD apVVk1W3tbn1aOuZ1tXWd2woNt42Ips1Ns02723tbJNtF9nW2T63M7Tj2hXYVdvds6fbB9pPsa+0 v+ZAdPB2yHbY6HDZEXX0cBQ5VjheckKdPJ3EThud2oYShvoMlQytHHrTmeYc5JzvXO38cBhzWNSw wmF1w14Ntx6eOnzF8ObhX108XHJctrvcddV1HeVa6Nrg+reboxvfrcLtmjvdPcx9jnu9++sRTiOE IzaNuOXB8BjtscijyeOLp5enzLPGs9PL2ivNa4PXTW8971jvUu9zPgSfYJ85Po0+H309ffN8D/j+ 5efsl+232+/5SLuRwpHbRz72t/Tn+W/1bw9gBaQFbAloD7QI5AVWBj5iW7EF7B3sZ0EOQVlBe4Je BbsEy4IPB7/n+HJmcU6EYCHhIcUhraG6oYmh60MfhFmGZYZVh3WHe4TPCD8RQYiIjFgRcZNryuVz q7jdo7xGzRp1OpIWGR+5PvJRlGOULKphNDp61OiVo+9F20RLoutiQAw3ZmXM/Vi72Cmxv48hjokd UzHmaZxr3My45nhG/KT43fHvEoITliXcTbRPVCQ2JWkljU+qSnqfHJJcltw+dvjYWWMvphiniFPq U0mpSak7UnvGhY5bPa5jvMf4ovE3JthNmDbh/ETjiTkTj07SmsSbdDCNkJactjvtMy+GV8nrSeem b0jv5nP4a/gvBWzBKkGn0F9YJnyW4Z9RlvE80z9zZWanKFBULuoSc8Trxa+zIrI2Z73Pjsnemd2X k5yzL5ecm5Z7RKIryZacnmw2edrkNqmTtEjaPsV3yuop3bJI2Q45Ip8gr8/Tg4fsFoW9YqHiYX5A fkX+h6lJUw9O05kmmdYy3XH6kunPCsIKfp2Bz+DPaJppMXPezIezgmZtnY3MTp/dNMdqzoI5HXPD 5+6aR52XPe+PQpfCssK385PnNywwXTB3weOF4QurizSLZEU3F/kt2rwYXyxe3LrEfcm6JV+LBcUX SlxKyks+l/JLL/zi+svaX/qWZixtXea5bNNy4nLJ8hsrAlfsKtMpKyh7vHL0ytpVrFXFq96unrT6 fPmI8s1rqGsUa9rXRq2tX2e9bvm6z+tF669XBFfs22CyYcmG9xsFG69sYm+q2Wy6uWTzpy3iLbe2 hm+trbStLN9G3Ja/7en2pO3Nv3r/WrXDeEfJji87JTvbd8XtOl3lVVW122T3smq0WlHduWf8nst7 Q/bW1zjXbN3H3FeyH+xX7H/xW9pvNw5EHmg66H2w5pDNoQ2HGYeLa5Ha6bXddaK69vqU+rYjo440 Nfg1HP592O87Gy0aK47qH112jHpswbG+4wXHe05IT3SdzDz5uGlS091TY09dOz3mdOuZyDPnzoad PdUc1Hz8nP+5xvO+549c8L5Qd9HzYm2LR8vhPzz+ONzq2Vp7yetS/WWfyw1tI9uOXQm8cvJqyNWz 17jXLl6Pvt52I/HGrZvjb7bfEtx6fjvn9us7+Xd67869R7hXfF/7fvkDkweV/3L41752z/ajD0Me tjyKf3T3Mf/xyyfyJ587FjylPy1/Zv6s6rnb88bOsM7LL8a96HgpfdnbVfSnzp8bXtm/OvQX+6+W 7rHdHa9lr/v+Ln1j9Gbn2xFvm3piex68y33X+774g9GHXR+9PzZ/Sv70rHfqZ9LntV8cvjR8jfx6 ry+3r0/Kk/FURwEMNjQjA4C/dwJATwGAcRmeH8ap72YqQdT3SRUC/wmr728q8QSgBr6Ux3DOCQD2 w2Y7F/pmA6A8giewAeruPtj6RZ7h7qb2RYM3FsKHvr43pgCQGgD4Iuvr693Y1/dlOyR7G4ATU9R3 QqUo76Bb2Ep03VAwF/wg/wYEKXFozC1U3QAAAAlwSFlzAAAWJQAAFiUBSVIk8AAAAZ5pVFh0WE1M OmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6 eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3 LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlv biByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNv bS9leGlmLzEuMC8iPgogICAgICAgICA8ZXhpZjpQaXhlbFhEaW1lbnNpb24+MTExODwvZXhpZjpQ aXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj4zNzI8L2V4aWY6 UGl4ZWxZRGltZW5zaW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8 L3g6eG1wbWV0YT4KYL1sYQAAABxpRE9UAAAAAgAAAAAAAAC6AAAAKAAAALoAAAC6AACHHRqmMMAA AEAASURBVHgB7L0LcFzHee/5sUxKoizSJilTMuWITmQ7dhyM1pIVP9aPGcmpKE/A17bqJoBzr71V gGJn7eHW7uaCuRsXsLtJDe7WBpPaFEe2g5FjDbM2kESAbIM3ISRdMAngG4xjDLMcJYRiQCboABJB e6AL0BgIvd1npvv0Oad75pzBkBhS/6kC5kyffnz9+/r5ne4+uxj/ED4gAAIgAAIgAAIgAAIgAAIg AAIgAAIgcB0Q2I4ZI2pYm3+Tu8lN4NzFb8Dwch0ULIgIAiAAAiAAAiAAAiAAAiAAAiAAAiBAtB0z RtSwNv8md5Ob0BcMLyi1IAACIAACIAACIAACIAACIAACIAAC1w0Bm4EjTAaihrX5N7mb3IRMMLyE 0Qz8gAAIgAAIgAAIgAAIgAAIgAAIgAAItAQBm4EjjHBRw9r8m9xNbkImGF7CaAZ+QAAEQAAEQAAE QAAEQAAEQAAEQAAEWoKAzcARRrioYW3+Te4mNyETDC9hNAM/IAACIAACIAACIAACIAACIAACIAAC LUHAZuAII1zUsDb/JneTm5AJhpcwmoEfEAABEAABEAABEAABEAABEAABEACBliBgM3CEES5qWJt/ k7vJTcgEw0sYzcAPCIAACIAACIAACIAACIAACIAACIBASxCwGTjCCBc1rM2/yd3kJmSC4SWMZuAH BEAABEAABEAABEAABEAABEAABECgJQjYDBxhhIsa1ubf5G5yEzLB8BJGM/ADAiAAAiAAAiAAAiAA AiAAAiAAAiDQEgRsBo4wwkUNa/Nvcje5CZlgeAmjGfgBARAAARAAARAAARAAARAAARAAARBoCQI2 A0cY4aKGtfk3uZvchEwwvITRDPyAAAiAAAiAAAiAAAiAAAiAAAiAAAi0BAGbgSOMcFHD2vyb3E1u QiYYXsJoBn5AAARAAARAAARAAARAAARAAARAAARagoDNwBFGuKhhbf5N7iY3IRMML2E0Az8gAAIg AAIgAAIgAAIgAAIgAAIgAAItQcBm4AgjXNSwNv8md5ObkAmGlzCagR8QAAEQAAEQAAEQAAEQAAEQ AAEQAIGWIGAzcIQRLmpYm3+Tu8lNyATDSxjNwA8IgAAIgAAIgAAIgAAIgAAIgAAIgEBLELAZOMII FzWszb/J3eQmZILhJYxm4AcEQAAEQAAEQAAEQAAEQAAEQAAEQKAlCNgMHGGEixrW5t/kbnITMsHw EkYz8AMCIAACIAACIAACIAACIAACIAACINASBGwGjjDCRQ1r829yN7kJmWB4CaMZ+AEBEAABEAAB EAABEAABEAABEAABEGgJAjYDRxjhooa1+Te5m9yETDC8hNEM/IAACOwggXV68eJlWiuXac+ePbR7 7z46eGAf7d5BicxJX6HlxUt05ZVXaPfu3bRn7346cOC2lpFzdfkiXd61n+5+w21m8V+lrqsvXqQV to+OHt7X0gSgv5ZWD4QDARAAARAAARC4xgRsBo4wYkQNa/Nvcje5CZmiGV42V+ni4gptiskPD1zm EyFngnHrftq/bx/d0uSZkBB6165dLjuZ/q49dODIEdrH0wv4cX1fF1e6/KsXz9Izf/UMTc9+jy6t ER266430tp95N733/Q/Q24+4k4Ln//x/ord8/A+prTtHf5v5ddqnM9JyrcetOeMSBBQBUUae//Pf pbd+4g8oxsvT3zz2G+SWNOVtRy4YW6e/+bP/RL/d+QUq+CRIpPP09Ofu87le+5+VOnaF/ubk/0Wf 7fy9lpJTr/8vfvuP6PB7P+8AOn5qgf7PX7jbudb9XHt6O5/i8nSa7nhf0hGkd3yefv/ho00WapVO 9nyAOqeJYjxmybtAD9LsNG/Db/H1cVrq0q9wgv40ME281Bk/P3Kc3tKC7WATs9sSUe3c+OUK5cf+ jHLf+jbdcuQgXfrnS3TPQx+lrk8+TEcMY1fGyvTSvzxH+X+YobPF83RxZZ1o7146cudR+smffYB+ 4cH76Db/GLUlCEMIEAABEHj1EBD9eKOfqGFt/k3uJjdHTn4j9KeUT4vcWf86e3NsMXRs0TxuLM2w 3pibdiq/Ei2CVvZdXmS53nYrV4ql2SVN/kKm6jeRYTqFra0tzRcurxmB8grLT06yyckptrh2zVJt WkKFTEel7MVPeMpT0xIIGZG3/JbZRF/CWidiqelArFsbl9iMo4dptrgeuH2VHLic/TXkHAjKeZUE qRnt/GhSsYynpmr6fTXdvPpcVlha67fc/rOdTa96SXvLv/fe1ZfTm96r8dfsCXO/+mpkESnPEfu/ HRm/bMyzdLs7fnTroXDrYpOLZeavf6VCRrWZXv8ynh42pQ/AIkELelbpC55nzlTGE9eiH4uov6Dk cAEBEACBnSMg2s5G/1555RUW5W9zc5OZ/vhCFOb/29jYYKY/8QQu9Kc0W68j4h1Szwhr7tyzxPIj A4EOcHCmiT1eaAJXw+Myy3gGBDGWTA+x0dFhNtiXZG3C0MUNL3puZ090Vnhww4tv7H41BESc9QiU pliiapAcmNY1VS/gztxXA7xq8rOZ1itP68WcW+cT/WxqfoVtcHnL6yU2PzvFps4bOK9OKz2krqIe dH5+OacXVli5npw7oPb1uVHW7pTRBMvN6mbcHRBmh5P06G9uzOVSMJSpJsi6PFdghUKBzZ47zyZz 0gDWzvIRGm/orwmKqEah61+PtZDpqrQ58Qwr6TdwXZtAxP7v2o9fVrxjrM4+Njo+ygZ6dIN5Dyv4 6mNpZrBSHmIdrDeVYcOjo2w4m2Jx/eFjh/fhV21QIe9qPFMGy46t/IaMPehNS+96GL8EMwAXEACB VzMB0SY2+hfF6CL8mowuws1vdBG/TUYX4RbJ8LKqPQFQHUJ5nc0XRlmn6oz4k7xmjVrWiuyYilc+ Zah8p2+QFS/FXLc7wYz1ssDYv7zMB+3zzmROVix3gHgCA0QJZSe/1/Kq/F+P5bKgGV6aVXW3qw5V xqmHzYQVav3a68GVs5vlw8q5XTgIf90SWCsOVdv79vDl+rrN7fUluKrLeKARTXER+z/Fma+wvBZN 5uJErzvG6hzyPMTKp92VxrG+SW++S/MsX1jwjL0qHha11TPtbKrZmeD9WFd13HtNxhMR9eeFhF8g AAIgsLMEGjW6iHAtb3jRl176O4SV6ZTq3LKFUmDZZkNqKeXVE+x4MsfmF6dZ97XskBoSOkIgnr/K U2hhTEqwiSU3rCgQ+kf/rQYufIBo6/N1/3o8uL4KBAwDJT9//++rIEXNKGulX8y6T3p9D/1qxnn1 bq6z0WRbpT1pr5TxWvIrOdZm1IB1cMa7qiNUeBVR2AshZ8wjpwx5ddKTsUf/bjV5oufg2oZoNi8Z n7tqtCOSoU6Gv7YUbpzUwvArDrkr/0q+/vfGIXEVchKx/7u245cSy3bKh3bcSOJb1Dbp2c7azYpi uaLh4y8/qs+kaCvXDFEHnThP+SBTjrP96QcDbcMlov62kRKCggAIgEDTCYj2sdG/nTC8RDpc9+Wz j9G+2KN8uysR3+pDn7//gHPNKdKP//GLtNe5F6fxxb+mh02nlTm+I/zbfIGyfzxB93Z8nO47yo/8 vPId6th7P40a0vccwhshiZ30evHUcbrrF//AESGRnuaHhb4nlDhnH/skxR59giieodVneui1K3P0 F3+Spa+OT9G/vMTo3od+ibqTj9IHBTPLZ325SH/9zafomcIPHB+33nqQ7rj7J2jfTVfo5jf+9/TI w23qbSyXz56ir//dAt185AHq+tX7aPfl52nkS39CT/D0vreyi9oefJgePfYZ+sDd9relbL78Ak2O jdPpv3+O+BF1/JC6A/TGO++gw/u5Je3gu+nXf+1+usUg60J+jL7yxWF6drpAl/j9Qz/5IH229xh9 7D2Vw0ENQegKP6T4L574Mxo+9U16nvPYdfvtdOh1d9G974jRAx/5VXrkwbervJnCR3Vj5QL95k33 EtcInTi3Ro++Y2+4KC7P0ckv/zF96asTtOIckHyIs2ynR3/7f6AP3GNnGS5ys6/N1QWafOqU0sPe gwdp6vd+j54V3hMZKj3d4zlc93KB636K6/52rvuPcd3z8E+d/FP62v/7NJ1dWaFDhw7RW9t/l9Kf f8ioP6ecfesperbwr87Bonu53u88erexnLkSb1K2Yw99WlT0zmEqP/HxmvoS7Y9T/zfPUteeGOV4 sAzXQ09YPbgJR7zapMc/uoc+9SQP1jVC5a9+rKaceuRR6p8Id/nsf+Z1cJ5uOvQAffLjFT2MnfwK DX/tWZp96SW6nZfxt3b8Rxr83IMkS9/l556mrz27QLfc4h5Q/uMf30Tvf+QRajtgOE2yKqBe3zt5 fd/D6/uff3nIqe//with7MFfDNW+nP7WN+jp2YtOrG778mPevryfPsHblz3V9JT+xO/yMj2d+woN PfktOvu9FTrIy+fr3vQ2uj92Hz3woY/Qh99zj8pfNXjlwNpXXqKnn8jycOMq3Ovf9NP0rrb/jn7u wz9PcR5Oti+Sy80389Pleb0T6W9s3FyXi0xvO9+rvA/d7/ST7ZQvPUn38Sbak38tcilnVP3JKGQ7 +HXeDn7PaTwP0aH9R+jed95LDzz4K/TIQ+/wlNfnnx6hv/7nl2j/m+P0Gw+/nTYvP0df/9Jj9PVT T/Pwh+h9v/yb9D/3/nt6C5e5mR+R/+//wzfo8ce+Rs9MFZy28CBv53+7TjvvyLD5Ik18NUuPj52i Ai+corxU9P4ues+HP0IfMpQXEa7M27EzWjt4a7UdfEbcNLSDwlnyVP0Kb/sOvf5NvF9p4/3Kr9Xs V668+JzT38r6UGkHf4L237xBN935Pt7fxjy6EOlt5yPal7D1b3F6jL4x+wPad/TDvF6+XdVLmf7F b4/RU9+t3H+E3/e3HFH7v2aMX6Rsdb8vn6EHD36IhF5jyXGa/cOHVZDVs1leFz+tfouLodkSfSpW v4Dzc73oI194lofooKnSX9B797ltrIhnWx+tH6s7nnj5OTr5xLO0cQtv3W66hz72Gx/09N+8pNPZ sWH6u5UNLtKd9NGuh+mwT4FR9betvCEwCIAACDSZgBhDNPqJGtbm3+RucnPk5DdCf+wrXsruE2p+ UFmhuYe8uPIZngS4N6+3qzIb760+LeerXSZ9T2Jq5UY9MerKsfPnhhl/W0blqbvnO8bG+YFxwc8G m87IcwZM4bib70yZfLq6F7o9WyO9Nkt6jBVH3dVQvNAFZfWlV5F5heXkagJDmPb0pGEJMGOLE3XS ahv0LDUO8gnpwg9EHstm2NBQjmUzvZWzeLicsZ4Uy+WGWDab5ff4dybDRvPaUqZq9Ev5rEVvFT7J XCGkIOG91dWDYQWVq/shNl8c9e5vl3pJeM8gqkhUZlMRy1l5Mc95ZVluKKVWusW6+jnPXIWlYHpi iE3rJ+dyPYxqepB1Idbt6sHRhaOH5fCwavhUcmYHFI82fm6AkNPVe5ZNGU9ajl7/hCgzg/FKvWmv 6EGeKeSpTz49zKRk++Ktc/XOv8mn3bTmiiOWcmprX6LrXaJeLcrzVrzyunlMGJf1l3i5dFcOmsJ6 w+UtXK7F+Qal2RPV9q/+k/JG9Sd41m0HA21uiaUTVXZ8lVlhOhtsp5363smae3xS7Xa+I33G2M6L PNYvL/HAAcYiXN120HDGS12e1n6l8fogZI3+iZ6eauMDZaKSun5frSPcRv+3vfFLNCKr2gshesf1 Vz/Ms17Zf2nfXZn6/e7cuDbGiDd3PJHN8r6OjydUP9YzwPuV6ljC6f9O8PGE1o+Vz3vy0ZX1yr98 RjsfsSvrvqRhG/qLpgH4BgEQAIGrS6DR1S4i3E6seBFP20J/dMPLiVlpXVlnk5keNUhrz+RDxxfZ I9+LKve++rcSRI5rhwNsbZW0A9962ZzJRmKRUQ1ctAGD2KrUzyet6aR7YFzCv2eZx1c86epKTGi6 jqfZyNgYy2VSrEsNvE94Du1Vh6960ouzPpHeMTc9OjYWGCQvT2qDFB4+cWyADYv0hgZZt0zPMOGf TneoMkVtSTY2zQ+onBxW+heyZ/iWNu9nmaXUG0T4IcWpHJsWh1rOTLHxsRzrE2y6ss72LFHhtvPZ 4gfSycGROzE0TfqItfV53yJTnh9z88bz0ZMeY4W5IjszkvbE2TuhDxS3Iy1jy5PaAIynGU+mnMMC c9k066mhB1tZS3GDU6q7qnuD/oo5XznrTTvpncwMaOXMezj0at4ro42rMBwo/fEDdcPqIebTQ6NE S3lvmbbK6V/XzhNspP4JOW16GOADdXVIpE8PS/lh1t/fz1KpFBvod/Uhlq8rfgYI6vBLXk7cvCV4 fR/y1vfkaKC+e86s4uG7qnrPcb13ynLGD6T0b+Uoz4969NiRTLOJqTwr5CfZaG6Q9XQIWRKBiXR5 YcwTrp2HOz01Uw3Hy7YTzjsBX+Zc+vr6jFwMOJrq5J6Txg0v/ubLl1Kj+mNsiQ0Y2sFCfoqdGjvJ +kU7yM+68CbPt2Q4rHSdi+sO1jeYYh16WUiOsY3ttp/V8J52PnaMjU7x9trfzs96JRWYNnzlReh9 Yrp+efFMRHmeRH/k9H96O8jPHvFuuQzynJqd5WVM8MxVeHZlfWEqygy0g7y/dfq/E1p/K+pDxfu2 /zdS/1TbYpFD9f/cICe5bKf/U+npZSrk+CUqILe+EUtrFW5mUJ7tkmBjhWnGXyjvtHXtaf/4tcxm RodYRhhEhrS+UviPJdn0coSBWy3hSxH6sf5pb/u9PKEeVIj2+oR88cSS7p70bKPajv5qZQP3QAAE QOBaExDj2Ub/rivDC8W6WG9vkrWrAR6fzPWNN20AIRQXmBwY9qJeawU3L71VNiTfZlQ9x8IfdyD/ VQ/qMFQ5cGlPs/PSDsY1kO2qDp79T2N4B+1OUjvY6DnvcM+zx10TJjBQ4unNqdccltiQ3EPNnxTq C3e21mZZj5SR2lhm2mtIOKfvqdfSW58bcSd8HWnvK8pXptyn2/6JHzeGqCffnePB8qOlse3L8gIb 4pO3fj6pTfVpByS3J9nAwIAzqRMTXjHxzU7q+V5nw91V/XA2Kc89/taexQltktPLFrYtKI9gvaDO RuILrllmSpeHGwOkHgxPek26n6+WNaU/f/n1l7OipZz50lubn2Sp3j7O75ir/0SPYil49vH7E1IA waY87+ihz6AHx+BQ1YWYaHv10DhYIedArzBoaCvH4t1KTqF/IedpXU6RnJ9LyPonggaMIbxeyOiV /nx68LQfG7PKaJmWA3MRseFj0rnevtjqO+MDfbd9aQ+2L9azhHgbIttCXif6Jyql3iM/l3NlxVuO mGjrtHB9E/Oe3MjwwXCat3LBPU+hDhctVMOX7sOLjrqH60r5ncQi6I9xY6RqB7tOhZTVqwMxgWvr zjE1r+TtrnzoQU0612Lt/LBbz9sHa7bz4o1m7sdrJPLrXfq7dMlXXsK2gz4DJuOTYpfnuIy+7vfW 0mlvffC1g6r99KdXN2aLhwbrnxpP+NpjWf5Ue6DL2XD/J4zI1bN05Ngg7PjFku1azqt5+SbOuFqR W553y117usD7kILSr254qeTf8Dr46pi3PTdbK+lo9/jrrsV4QvRjupGcOo6pfsXp/7ifId+YQSS0 5HnA1cWmls6zwbg7zsi5DXhFrm3oL1rG4BsEQAAEri4B0VY3+tfyhhf96YH7JNRt3GP9Y/xZm8Fg 0izmN9RWI22gywc08kmSQCUHPDZsaiAkBi6JAe+AlQdSAzrtCZWIa3rAXZ2S0Z7+yHRUvL4nfp6B UjwVSK+Y1Q4llJHx77lh1yDROxY0Iah4ffnXJ5k5w1KgvFwNE/dtceEDa3konXhSm50oMmUf0uRq +iUfuMlJCT9bpLb++AGw6ulxZ84on9If1688XG87Mp/X9TDqnZyKeHU9+KYq3pUWsX6mhy7ILSm+ JepTqbiaUGUM78x1y5m33Ms8bm1tqKfvHSGWfstwYgAt9Z8phtN8eX2FT+i9f5cuXdLcasVTNspp q7+N1r+KjqoHIIs6H9BDtV779KC4iIsIRmu9/pnaF3WwJJ+o6e2WN3/6nYokSu/6BE6INue+OryN G1PDrqZYO++Gi/FVGPLZs41/RQrff0OfUit8ec1bVvxlZ2Wldv13D9etv+LFI2kE/QmDt2yPRDs4 FKodXFVl2enbu7IeI7qQxdVv8GBgvR5564/kFaxHqt3hZVpv5yV/9cYZXzuvl5eYYZWlDO/hx3/M jbirvnqN7aA8ZNy34mXNbd+F0SlsvzKV0vtbU31w+039rpBf5xksY4JpkKerH74atFa766t/Sg9V dz8//30/V9HuyvJWt//jgVU7EHH8ItKNWv/m1MrLLpZ3kC25W+qIrzQWka5MqP6qfXBGuGgfvqKb b30dGEhzg8hx1hl3x7tOPfE/GNJCNnq5pRlZw/ZjIi3P6jHBtvqXHD5fW5SI+qsdGe6CAAiAwLUl IPqsRv9a3vDi7k/nq1t6h5xltun+pDrnwGno+TkD3ufpzVPAFp+0yokVP9y3eRHvSEzaU7v2aK9V dAcuCfUUR8+Cuu8ZYPE9zW3Vzrijst1GDyOubQMsFR+5T430sGqi5kmvxHJy5U11gBMc0LkDXXfC r599w+XtTLLeZJIl5R9fZaUMF3xS4bUfldlY0h1wVAYecdabHmaF+drbK/T8RL7W3qZTz1Cib6no t2wlWi+6E8rtl3OvHkxDMLP+KhRUmeArZYZ9T83Kq4usyLdynTuvn2HDy5lcBcfPBHL16hoUVXny lBedumuU1AfC/vKjh3CuPVsRg+1DMPwqy8jtL9pAVQ5YK9+1Jsh8slpdcaE/KQ3I5Tg0Xv9EcMWM 62HEXW7mxLxRuuDooejRg3PL/WcwMLg3vVduWt72RfJT9z36s+tdxm4rZ2vq3BPvdgAZTn7L9OXv 9YJ8ml07nPRv/I7Axdkeuo3yIuR3V7zUP+PFI28EOfn0lJ+55m8HE6x3sNIOeuJVP/TVQ+Yzxy6c 7qtO5vyrdfi22RBcZkr69s4Nduq4dgZRV7CdV6tMxAobrSFpTO+8HZQrM3l/ZGoHVVvnKdcCkLlf OZ4ecfoVhdBzEawP/vKr6lHgtcqcp3+CH2if/OUnmJ5HHP7DVv9s7jK8Xc6qjwj9nwih4uPbi0zn 0Kn7Pj00Uv/WCvL17fxMqqUtNj/srlJUfbVmqKzVjkv9rcxNsl5NP/GUdyux5Nbwt1bX9f5fpm+P d4Vl1JirUv/jvaPq4Y41fET92dPHHRAAARC49gRE29boX+sbXrSBbqagP3FZYaO9cWVh78oVrw55 3iHJJyuq07w6KV2DWPUzXnqYOjInRMpqYOLbWiCDqvv6wEV7dXW7ZRWBepLNw+lP4FR8vhU0NdNj y+6TpZ4RpnZCyUD8u2BcKcO5GM8a8E8kxG/voZmVqFfYqbS2VUUfsLb3sok5PWeaMNu51AZK9cql u/RZPJXUZhN6+nzljizn8cATON1jmGvtCV/3sBqE6SELcguIXl6qHtSg3FLW9Hica17OpGEsTDkz E3CfvuuGl0BafocIeqgEdQ08XmOLXtY6q09K/YmJ3274unJuo/6JlNSk0HIOg/BT86MZpeqVUb2+ m/Sj7uvlpeSu5LKtUtLbFz3euRE5GeLGPbl/qmZmKjfn1CQqWjhP1JEmHZqxXG9XPNe1ygs/EFb1 oV5jgkcm048I+qsEX2HjaclVL8/82mkHdQ2IEFrefO2/FMc9P8Qvu7Zt1sNCT9fPRe//dH+ma287 35jeo7WDwV6iBs+OXnb6vI/nal5tX7HXB3fFize02/7Z2yW5gqOqnW3UP2N9lkrn33r/EOTCPURs d1V6lj5F3dfbF0cerYyGLGf6w8L0qHZGnL5NeeWM0lUtw4uGxJNnig04K70997fzQxvn6oaXMFGu +c4f6zutPxSxxBBRf5ZY4AwCIAACO0KgUaOLCNf6hhfPk0n/CoI5dUAZ8QmeaaK9bY34BskC2vX8 mVRbMmJsbL6yUD5MntQkLPCkrLKqQN3XB9CcnVwt1J6uLKf1pqWdPeIb8KiBkG8Lkgyv7otwUifa eSu2gee4fCqrySmeaslVBETd7ExxjhWLRXbu3DnnT1zLv9lz84FyJmXaKC2yiVyadcjVF9pALefb a99oGZJp6ds46h367E68iA3OeIfbQg4nTr5XP16Vt3c8uEUrkrz8vAdlCDnh3ZMu5df1oPRXTUTp 1rf/X8nqE0ZflWYexGrlzFJ+dYNGR+CwQ1+C+k9tABlmwOrkv1xm6+vr6m9tbc25Ft/ONb9v+4iy Ks8mkXJKpoEw26h/Ii69TstSY0rL5ObIoqUvz3ix+dXTMk201H1df9pkwaz3NfdsI98WpRXtzSMn DAepBlhWHS7NDCpjf6ZQkdSWJ1Mcjl+fQaNueF4eAmVELz8b3tNI/Om69V+sGonQf0XQn56mWJUm 2kH9LDY5mc95zhhyV2+RZULsHkjaHjjkmFXrkY3NWqAe6caabjaptfOyvZftfKHobedXZtKa3mVt qOTaqj+tP5IGYb9fTzuoQ9SuJU9bv6Li1PQl2wYtGn6ptYNa/6f88HIkWYr2SVzL384356nSEoG2 Uf9UG6/330oQsdqnujLJ0v/radfr/0S0xvajmp7Ik7pv4hKx/rn1rWrQc8YD3AjImwvJb2XaLU/d 9bblKC6MTakDeg31QfMX5dKRSevH6hnJvXHPs76433CZYBPaS5B0/zL/UfWnx4FrEAABENhpAqIt a/Sv5Q0veicWnNisq0kI+V5rul2l6B2ENB4E099uKtc+vN7hU3fwDSFSIpX/qoM+UDJPjKpbeMRA SkaiDcxMA8HFCbmMnHfcejgeXq168LnLqNVASZ9QrRfVwbptvePq/AUZZu2cu52GfJN6dYYL9Tgn 8fvzL+MI911mF86dZn1d2rJ2vgLHPp0OF6vHFx9kyxUqacPeeo/82oqQRGraE438sXymX00sog28 ZAzaN9dDd9WIEzt+KpDv9eJJlZbQg7881StrWkqVS0M50/PvL2f+9CqRuJNAMYnXwwfS0x08elAl P3x4Pa5Q1+4TWLOxQYvEwEW7y1//a69/wl9kPWiRO/y09OuVKT0tQdHPX7+v9Mfjl22zv30R4Wvl z91+w98y0z+pSV659KcvPXjCGd7gJv3Zwjv3NbmvVp+ip+/K7F81IqUNfjvhI+jPH0Ml/TJbLE6w vk69HRzW2gPXiOhv/53wZbc9F/eDG/n8qdb/rc5w4Qb2Yo0GWecnYtXHIYn+M/UTEj60/ih2PNgf 6ds7jfkPpFLh2a/3K/yBk8qGpi/TarhFtW2L97e+/i+QVBgHrRxHrX+q/zasaF2Zco0Sfi5KLE+7 q1oEdduvP2P7oXx72zq3Fdc8RLn0nPtWMUoc9503p59JNrKgNKhS8csvb0yn5JuRuCFn24LKWPm3 VnbEm5hs6Wsh+GWZne6Lu3259qCJ2vo8Z7N5w/FfEfUXCA8HEAABENhBAqKNbPSv5Q0v7qAx+Cpf MXCRb7SI6cs4fcoQcJYLE2wok2HD/NC/YDfnC6D/1DrR4KuEdY/eaz29sAc3emO4Wr/4vmytg7Ru PfElH3rgog/otK0OFOvznMNTmnV15zwN9RlY9PT8KyKEaGbDjL6UvIsVqkughP7Fm3vc/fti4Ok9 zHBxvFcNIDp9rycX4eVnfd1XevhBqUvWAVDJ3frUZMMg05Z5pwyvEJbyiu+tLW0vPlWevOn3+Ul/ 2mvG42xiyZdHr+cQv/StW118S5vLz/sGJa4Hn95F5GpQXi1LOn9j4no54wM+/bynUiHH2rTyLtIL DtNFrO4k0G/QqJm+lrZNDzXDGzNUy9E1vPgnO4FQmmxR65+Iy9VDtPOglBzayo56baeq73r7UY1I 8FP3df3xrRVyZVUgf1zvsm8wtS9s45wy0oq3btVakebRn24MqBNOcfBfaBPWelz8QRv57W594IYX fbduvcgi6I/VaAfFKq20PI/F0w5q21sCK174uVvapC5pOJi2nvim+3o73+Vr53X/gXae610ak53y 4lm5o4fUr839kfCxceG0W3ZF++RvBzWenvLnRL/qvj1G58n7BNXH8cOwZTsowot20FMffP2fLnXo 623UP9V/x1Ieg9ra+VHPa4odLlr/q2SL0P+JMMb2Q0Wm3Te0P5q3kJfaih2h2/Yh73ZbbUxJ5OrJ FrnSP6+P0tDsH7/4w0Yef2p9hb8fU+n7ElmccB/WiId4whCjvz0xVn34ZQwfUX++pPETBEAABHaU gGjXGv27rgwvyZE8W15eZIuLc3wpc8ozkEj6nijoGikvaK8K5h1hr+WA0UqYdbY4P8/mF0U6y/yJ nTsQ6B0pOOnPL/L784usZJmfluejpKdLem2uVzyvAUyw3NQFT8LL/CC3zNBpz2BBDZT8A8RqSPPA ZlU77JY/We4dYQtcf5M518ghl6BTR9ZdKcPjnJWvf9QnWpqUenqu3aPMJjyHJ6ZZcWmJFcbT3sm3 aaDLh6kpbYtQcmiSyZc4lNdX2fzsJEuL5c/8LS5uevxJaHXLQn92jBXnl5lrlymzhemsGkSaVuBo 2Yl+6ZkI8GXzC1VzQnmdzefH+CsiRz0GhguaYYkSvSy/XJ2BrS+yXDKujE6x/onosgRC8CdhvW0q TupKs3NVPXgG/0Y9aINgS1kLJMc14h6qXCln80uL7EzuuCuDSEv8+cqZG5e74qWuQcMNxMea+oSs h51RelhjCwY96EEbu3bl9BuIgvE1Xv9EXOY6FkzF6qI9RU0Ozzpt58LCAjdUBhtOPS2TYczc/vj1 PmxvX/jkxx/veXVeS6VspEbzvM6LbWCrbGnxPJsYSbPu7jTzP5B2z/uQ4Waq4UpsWfRNTrjBQDjF SefC+5SlpQtMcFk2cFFhtnHhrtZIsJHCIs/bIu+/5tmi3WJcSU2Xs47+/O3gmlJxpR2MV+ufdwWc a0QUb80qLpfY6uoqW57Ps8Furf1o6nkWvnY+e4Zdqhroy+sltlA4U2nn2wYD5cU9F0jqvVJe1taq eh9Os54e/sp1Le8TvdpqH94OFpeXnf6oXjtYqm5p68uOsuLCMltTu8nKbF7rV8TkVt3yt4PHR5ho B439re8Q8saKV+P1z115xMdjOV5/VpbZ9LA2kZfttaX/97a79fs/c/vh5rpe++P6DHflvkmMl5VE P3PtdMu8v3XLhP9swmI2ybr6c2yWH8yvihFPcm1phvVL4yVnkxx23o1kFKah8afHoNzDJueroxw+ njD2Y4vj2vg76a4e46u8klJ3/Nv0Ji9HaE+/WV9/xozCEQRAAAR2iECjRhcR7royvKhJutawO258 tUut813kIEaGr3Ui/Bbfl53wx2/5PTBtXvxc0s4PEGnWSm8nyoxQ/KRasloZRFK8k7/Fp5vF5VuI fK+JVQMT8UTI8ATK9nRcX7Ek+avvHr4CKV097E8s/daUqOIzTL6F/Lb7Gxf0AUE1b1J/3OCQ6aum x/Phn4iV+WDCszpChtO/+YD8kpZ/v65V3vQw/DpbPQ+iGfoW+ReffKYjaFiQ6fr0x01E/K0j7oDP KCdflXReW52yHVkFy8DkQsoW1/Rg0K8qa4Z7QiaZf12+muWsO8NG0vLVyN3snDGP7tPpegYNf/r5 jFz+7StvIr8BPehSN3JdYieqbzUyGYj8stXkUqP+CcmUHnx1xZ+GngvPPW1lh17e2gxv5FD1WT/D RYtYl0Vvf8Lnj28hDKz2WOcHtNepE4bDtLe21kKFm/Y3MNX86GcS6VxiBi4agoYvrYwMZbNR/fn7 WD1f+vUQP0/HTcM1Iup+vNedbDLEWZ1R4NTsI2QbZWAjzkgZ1Q3K0q/nO86mNct8zT4lcdzTH2nB WPh+RQ/F1+1pZ+J5OfK2iLeDw4NafxuoD1EoVvxay5Zg4mlfvPWvpL1FLyAnN1CpcQHvA/yjLFl+ ovR/tvZD5rhe+yP9Rfk+M6D3zzHWJcZXelnhh5b7i/bsCa0viSVYZ3eSdXfGvf18d87z8Mcvk7/s hB1/hu3Htjb4uS7aQ6qc1rAK3azPDWvyxtio782EjejPn0f8BgEQAIGdJCDasUb/rgPDS1ZrxHln rjquGGvv7mVD47M1jS5CMWLw44Yjlqo1ktOe8ulhTNfZgnfQIwtBefGUJ72BM5aTxmSAHfoujmfc pcmKa5Wx74mYertEh3dliuxEi7meSp55OP98Y2EiHZiE96THnQGVO2Dv8ByeqNIzxCdwuekNBQYh K4WRgPGsvTfnLL2e096m4x/QiXjXF6eYZw+9xiXR1cvG8nIBt/DNjQCXZlmmtzuQP1VeEt0sN73N w2orSRn+l9j4YLenrMl0u1IThnpRZtM5w1NFnseO/hG2rD9iM6QW1enS7HBADx1VPcyPyPIS1F/x pP1eLRlM5axbljNlDO1gU1q1leVXTKpyPZVJeEeNLQj+9CvhuR7SVZm18iJ0IfTQhPmNliyXs7si ZzuX05Vf8+K7NHGpV/9EFOdy1bLlq/N69DXT1/bxy3IpvjuzBT0K59qtz8H2Q3hQ7YFPFpH+/OnB QP0Ter/Ew7mTEH4YpaZ3J1H+b2trg82MDnq3fWg6jLWnmO9N2tWgZZYf5QfIan71PIpwvvmGTJI/ vnbflKeH6TJwcQM1frVetPShoo2vGnGNsUfQH1spsMzxnoAeVP7ioh2c9yXjbu9T/hTPGOtODbP5 5lYelf764rT3DC6VLl8x13WcjfraeRWQr0MQeldb3LRwIg+m8iL6o7jPn2oHh9065uk3Oc8TNfuV Hr5Sdd5Y/031XbaDcmUSkbcddPMX7Wo79a84qp0xVeXT1TfsjAvU28i6coHxhCth+P6vVvsh4qvX /rhpRrnaYJNpc/8c68k64xF/++lfTeetFzHWz1d9a8+njMJEGX9601/l/ZhZ3k6tH9NlTObOGWWY G9VWNfM22yxzeP0ZE4EjCIAACOwQAdF2Nvq3E4aXXYIT71Cu6WdlLk/ffeFHdNPr30IfuO/uq572 5ee/Q/+w8EPa87p76IP3H73q6TWewBV64blzNDd/gV7eILrpwGE6evdP0VuPHqbdjUcaCMnWl+n5 hRXapD106E1H6Q23NTP2QHJEm5fp+bkL9N/YXnrjm95Mt9/2Gtq16xX680fvp48/ViC+75pKT36K 9hmCCqeXX3yBLlwq097djDb33EqHD7+B9u3dY/EtnDfp8ovLdOlHP6JyeZM2N4luPfQmuufIASeM KPK7du2qEX4bt65cpoULS7TO09y9dx/dcfguLqs3Pk/63P/c975Pu259HZVL67Sf8zly4BZvgGb9 Kq/S88/PO3q4k6dzeN9V1jsvZ3Pzl2hz10108K6jKj1P/puVN388jh7+ldbKvB699nW8zByhfVcJ qz/per+vef2rJ1Cz71fblw22m7cvwXJWX/+b9OLFBXrpR7wR5J/XvvZ2OnD4ANdfvfJaCXepxJXO P3v3HqSDhw/y+lcvnOP9BvxXpsvLL9LKaom3g2XiL8qh197+E/RTb3y9of1bpcc/up8+9STHEEvR /Lc/RwfLfGiweYX27DtAOvr6+msMZdh2Ppi+Qe93cL3rQmsisWo7uE630p2R+j/O88UXnX5lk3cq HKmnX9GS8F5eeZGe5+2gqA+3q/7vKvU/IuVG6x9vM5+fX6IyH20cuuvN9IZG+ocQ/Z8XzrX9tbpw lp75+3+ijZuIdr28i+5oex99oO2IVYjNVd6Hnf8evfjDy3SZD8rEuOH1R95CP3vvO+hAyGZlW+PP 9cv0wsUlpx/bvXc/3XHHEbrt5p0dv1hh4QYIgAAI7AABMSZo9BM1rM2/yd3kJuTcEcNLo4AQ7noi cIXOnPwLev3P/xtqe0Nwxnt5+jE6+L5HnQzx13vSkz18YxE+IAACIAACO0CAG146uOFllCfdkaHV v+yh23ZACiQJAiAAAiAAAiAAAmEJ2AwcYcJHDWvzb3I3uQmZYHgJoxn4iUyAn2NCX3xoPz36DF/Q kkzRp//NQ/TOu28n9qMf0H89laXO3/liNc4ETSw/TQ++IXISCAACIAACINAUAquU5YaXTwvDS3uG Sn/ZTfu0VYFiAHHVVgk2RX5EAgIgAAIgAAIg8GojYDNwhOEQNazNv8nd5CZkguEljGbgpwECq/TY gxXDS63A6clF+h8/8EYM6mtBwj0QAAEQuKoEXubt9T7HUM4PoaaV2c9RZWPmVU0UkYMACIAACIAA CIBAwwRsBo4wEUYNa/Nvcje5CZlgeAmjGfhpiMAm32ueP/0tGv3GaZqaPkvPFvh5LvwTS3TRx37z E9TZ/kt0T9iN0g1JgEAgAAIgAAL1CWzS2af+hJ787jK97h2/TJ/5+H1NPVesfvrwAQIgAAIgAAIg AALRCNgMHGFiiRrW5t/kbnITMsHwEkYz8AMCIAACIAACIAACIAACIAACIAACINASBGwGjjDCRQ1r 829yN7kJmWB4CaMZ+AEBEAABEAABEAABEAABEAABEAABEGgJAjYDRxjhooa1+Te5m9yETDC8hNEM /IAACIAACIAACIAACIAACIAACIAACLQEAZuBI4xwUcPa/JvcTW5CJhhewmgGfkAABEAABEAABEAA BEAABEAABEAABFqCgM3AEUa4qGFt/k3uJjchEwwvYTQDPyAAAiAAAiAAAiAAAiAAAiAAAiAAAi1B wGbgCCNc1LA2/yZ3k5uQCYaXMJqBHxAAARAAARAAARAAARAAARAAARAAgZYgYDNwhBEualibf5O7 yU3IBMNLGM3ADwiAAAiAAAiAAAiAAAiAAAiAAAiAQEsQsBk4wggXNazNv8nd5CZkguEljGbgBwRA AARAAARAAARAAARAAARAAARAoCUI2AwcYYSLGtbm3+RuchMywfASRjPwAwIgAAIgAAIgAAIgAAIg AAIgAAIg0BIEbAaOMMJFDWvzb3I3uQmZYHgJoxn4AQEQAAEQAAEQAAEQAAEQAAEQAAEQaAkCNgNH GOGihrX5N7mb3IRMMLyE0Qz8gAAIgAAIgAAIgAAIgAAIgAAIgAAItAQBm4EjjHBRw9r8m9xNbkIm GF7CaAZ+QAAEQAAEQAAEQAAEQAAEQAAEQAAEWoKAzcARRrioYW3+Te4mNyETDC9hNAM/IAACIAAC IAACIAACIAACIAACIAACLUHAZuAII1zUsDb/JneTm5AJhpcwmoEfEAABEAABEAABEAABEAABEAAB EACBliBgM3CEES5qWJt/k7vJTcgEw0sYzcAPCIAACIAACIAACIAACIAACIAACIBASxCwGTjCCBc1 rM2/yd3kJmSC4SWMZuAHBEAABEAABEAABEAABEAABEAABECgJQjYDBxhhIsa1ubf5G5yEzLB8BJG M/ADAiAAAiAAAiAAAiAAAiAAAiAAAiDQEgRsBo4wwkUNa/Nvcje5CZlgeAmjGfgBARAAARAAARAA ARAAARAAARAAARBoCQI2A0cY4aKGtfk3uZvchEwwvITRDPyAAAiAAAiAAAiAAAiAAAiAAAiAAAi0 BAGbgSOMcFHD2vyb3E1uQiYYXsJoBn5AAARAAARAAARAAARAAARAAARAAARagoDNwBFGuKhhbf5N 7iY3IRMML2E0Az8gAAIgAAIgAAIgAAIgAAIgAAIgAAItQcBm4AgjXNSwNv8md5ObkAmGlzCagR8Q AAEQAAEQAAEQAAEQAAEQAAEQAIGWIGAzcIQRLmpYm3+Tu8lNyATDSxjNwA8IgAAIgAAIgAAIgAAI gAAIgAAIgEBLELAZOMIIFzWszb/J3eQmZILhJYxm4AcEQAAEQAAEQAAEQAAEQAAEQAAEQKAlCNgM HGGEixrW5t/kbnITMsHwEkYz8AMCIAACIAACIAACIAACIAACIAACINASBGwGjjDCRQ1r829yN7kJ mWB4CaMZ+AEBEAABEAABEAABEAABEAABEAABEGgJAjYDRxjhooa1+Te5m9yETDC8hNEM/IAACIAA CIAACIAACIAACIAACIAACLQEAZuBI4xwUcPa/JvcTW5CJhhewmgGfkAABEAABEAABEAABEAABEAA BEAABFqCgM3AEUa4qGFt/k3uJjchEwwvYTQDPyAAAiAAAiAAAiAAAiAAAiAAAiAAAi1BwGbgCCNc 1LA2/yZ3k5uQCYaXMJqBHxAAARAAARAAARAAARAAARAAARAAgZYgYDNwhBEualibf5O7yU3IBMNL GM3ADwiAAAiAAAiAAAiAAAiAAAiAAAiAQEsQsBk4wggXNazNv8nd5CZkguEljGbgBwRAAARAAARA AARAAARAAARAAARAoCUI2AwcYYSLGtbm3+RuchMywfASRjPwAwIgAAIgAAIgAAIgAAIgAAIgAAIg 0BIEbAaOMMJFDWvzb3I3uQmZYHgJoxn4AQEQAAEQAAEQAAEQAAEQAAEQAAEQaAkCNgNHGOGihrX5 N7mb3IRMMLyE0Qz8gAAIgAAIgAAIgAAIgAAIgAAIgAAItAQBm4EjjHBRw9r8m9xNbkImGF7CaAZ+ QAAEQAAEQAAEQAAEQAAEQAAEQAAEWoKAzcARRrioYW3+Te4mNyETDC9hNAM/IAACIAACIAACIAAC IAACIAACIAACLUHAZuAII1zUsDb/JneTm5AJhpcwmrlKflh5lX5wcYXKe/bQHpFGuUxs927axX/v 27eP9u3de5VSbt1oRUHdtWtXTQHnRo7TWz/xB9TWnaO/few3aF9N31FubtJC/jSNfnOS/r/FS3Tr rbfS3r0H6c63/Qy96/730QfbjkSJ7FXpl7F1eup3f53a/2CUEslh+tYffpxusZAIo2tL0BZw3qTF uVk6+90C/fO/fJ++94PLXKa99MY3/yy978F4nbKyTt956mv01W9M0d67DtGl85foLQ99lDq7HqY3 vqZ++afNVbp48TKV2Wvo4F130b7dLg4b09WFaRr52l9RoSrnkZ/8WfrgLz1M733LQTcwrkAABEAA BEAABEAABEDgOiFgM3CEET9qWJt/k7vJTcgEw0sYzVwlP6vf+SPaf//n7bEnuijb93/Qv/vA3XWN EfZItn9HFB7HGLJ5mb4z9Y+0tusm+qn730NHrpFdSKVfzcrZxz5KsUefJEpkaOXpHjqw/SwSrT5H /Z98B31h1BJZLE0rs59rTlqWJEI7cz3khR7oJrrnAa4Hm2UjdITN9PgyPfbRfSTUI/Xzell+mpnM DsZ15YVT9G+P/iLZiooQLdY7Sn/7+79Gt/nl3FygP/rEm+nzgk/g00mTi4/TB49olhTuRy//m8vf oS/8/P30+4VK4IH8Cv0v99WqAZt0JvNZ+tBvfTGQmnDoOVmgzK+3Ge/BEQRAAARAAARAAARAAARa lYDNwBFG3qhhbf5N7iY3IRMML2E0c5X8rJ59jPbHHnVjj8WICtUZletK/RPz9L89eFRz2aHL1W9T Yv976VmefGpqhf7X99aa8F0dGUVB/scv/iY3vDzhTOxXueElMLmNnPQqnfzkfurkUVY+7ZTOddGb ecQ/eO4c/c2pL9ATl9JU4oaX23bYiCDyv+vl/0oPcj08w4UdmOYT7/dcez1IUsHvVXq8Yz99Slgl 4hkqPdPjWZHkyF9nRVMwztZy0Q2msY4e+lj8PfTON+2n5//mCfqdQdei0nd6iX7vocOa8Jcp03GQ fkuwEZ/OPhrrehcV//L/pt/54rOOE1E3FUqPUVtgGdcqfWfkBN3/id+p+qt8pbnh5XM1DC8Xn+6n ux76QsVzrJuG/vdfpl3f/SZ96guuIWb4/Bp9/C3XyIrqkR4/QAAEQAAEQAAEQAAEQKAxAjYDR5jY ooa1+Te5m9wcmfgNfHaIwGohw7gSnD9uyKhIsbHBVhYKLNffpe4RtbP8+g4JqSe7nmddVXn5hE+/ c02vZ090VtgkMqzUhJTLc8Mu6/YTbNEQ5/p62eC6Q05rMy2hB3PuSyzbUSnTfMULWzV7uq5dNy5M sXR6jM2tBCvlhclBVZYS6bwnn4sTveoedWWZXoPy6XZ1L9Y/6QnH1s6xY9V6J9sL+V27Hq5quhjw lOvl6bRKr3/CVOK9IuAXCIAACIAACIAACIAACLQSga2tLdbo3yuvvMKi/G1ubjLTX7lcZv6/DT6f N/2JZez47BCB0qxreDFNoKZS7mQsU2iBKSw3vHT6DC+isF+tjy3uYrZqlIpzw0sT0i/NuHrIFNzJ tC39q5Xf0PFqBrDBmUuhg10bjyU21F41vMRPeIwLpvRblrFJWINbQP7ShDJotA/OaCG4EaSzyoU6 mLSzyvBn+hMqHF/1woq6na+UZ4lqvYsnc2xhcZp1V3/X0v/WVollqrroyBQ0WfhluajqcntGl9Pr Db9AAARAAARAAARAAARAoBUJiHF0o39RjC7Cr8noItz8Rhfx22R0EW43tuFlZY6dHDjGErEYa2tr Y7FYgnUl02zyfDPWSWy/+OkrXoThRU7CZMzrxayajBknWDx/uVTSyV/MyWOcdSYH2eRcbSPN2iJf UZPqZR2JGGfC/xIJlmjvYsneFMudPsf0OZ+UxfkuF9RKi0zRNVBIP375pbv4np8ZZX3dXUrWRHuS jUzP616M1+XVBTaRy7DeZJIl+d/x/n4Wl0//m7TiZTXvPv1PDteXySTofF7kr5PFnXIWY4mOY2x4 yhzX+YlhlslkWG686ERVXik6emyPt/FyGmc9vVlWU4UePawpcWrxl54W8mOOnKJOCN3retDDr85N ODKenJjjQZfZUG+n478jmWWLooCU51km2eF1cxLxrngRpUTlzylvCdbdO8TmDFVQT78ip1te4ry8 DNcoLyuFcXbixAk2NDxTKb+83Ixm+lgXL9sin/F4nHWnJ1iw1DpCN+WfkH/tXE7V2e6cYFf9XJpU xpNYcly6Ot+rBbeey5UsWd3QylkPDQ6x/HwV2lqetVfrgG6w1flVEuC66Koae9p6mV5lV7QVL+l8 7fbCIyx+gAAIgAAIgAAIgAAIgEALEBBj30b/YHhpogKX81nGj4xUkyA5oZHfyZzvCXAT0w4bld/w 4g+3NntCye+fYC3NDDF+Ioy6L/Mlv235W5xIWcM4YWNp7yqF8iIby2ZYNptjQ5lelWasmxtpclnu nmVDQ0Msyw0JY/llfxb47xWWS8asaXakz1gNPedG68jarK0sS6dVvvixqCwzGWXrhchfmzV/7YOT vvyV2GC8qreODCtMByfdFR12qVURDlSuh9Ghqh5OaHroGeB64Py5Hpw/rofR/JJFDzXkTHvlzKer KzDae9mAT3/J3GmWUas3KnnpGZZGhlV3xUvnECtMDVnYdLJpfa+Nkrh2eWnncm4YVjkpeTuybL44 qowcsj443/FBb9lWaUa7CBo4quH5KhJ3S1CMjV/YUBGXNONe7/gF5c7YAus11OMu/woVLcQW32rm X3mm3fZcnhuqbssTaXDjS4HbbrYunHaNl9TLzOZBTzT4AQIgAAIgAAIgAAIgAAItRaBRo4sIB8NL k1RZnh/zTPa606OsMFdkZ0bS2gSbWO9pfQLUpMQjRFPSDCuDM8FZ6KS21Sg35z6rLy8E8zd7/hyb HPblL3B2wzJLxaSxJsaSqRybLhRYIT/FxkdzrC/JJ9udWe+5KavTHmaeiaxvwhjrmw7kfjrd4eoi doyNTvH0JkfUxFHElxGzQd9neXLADcf9JJIDbGRsjOWG0qwnUc0D38oSDOmLKNTPNTbqM5509OZY mIVR09rZHBRLqvzJs3CC+dNWhHj4tbO+dEqtZHA4J0ddo00UPfTX00NFztnJYbWCyS9nIaOfMcR5 89ViAUOfWN1TzUNcbaux5a+D9acH7Pmr6mnKx3NsWpQXv5zBFRrq3B8P0wQb4AbDVHe8UpaatELK XKSW1LYewTI5Jg1RFd9eI6srv3u2S5yNFqZZsip/h+/T25apAABAAElEQVR8GE+ahi1/nvueH4ss FZd13v/dxka1dsUTDD9AAARAAARAAARAAARAoIUJwPCy48pZZ8Pd7gQjVV29IJ9SlxdPa5O/nX3a W9IO1/UbH/RDOimRZpfUU/41Y/4k9vLihD1/pWn3XtcpGcT4LXmJLSXZvj7Wl0qxVF+3awzhW2lS wo3/DQwMsH6+BWhIWykiwq97Dq0d9BzuyVY0WY6NuQYGIc16QZ1h4axAmVr0bMNSZ7w0dSK9yAar 52E4Rg9nAhxjqbE8E5t5FA+Nljd/aU/+ti5Nuay5AcVdpcENE750Yj05tiz3d3EurtGGH6pctSxt bVj0wLfgCP5SF0IPWa4HXd618/rhwX49TLGO6mSfNEOP15DRzc5xfRZ1Yww3ognTQjFTOYeoXRkK +Fkm/vx159jSRvUsoJUpY/4E1lpy+nlKXFIdAUNR+yCbr9oqi9nqqo/25hzGLNN0v1fZsLYqKNY3 rum74qs0I1evxdm4s1dL7NZy9dKeLnCHgtKF93wYX/nTzvjRV8K58vj883jdMu22jRnPQTJ6aFyD AAiAAAiAAAiAAAiAQGsTEPOdRv+w4qUZuuXL8NVEsivnTJr90aqJO59w2iYu/jBX47dueOnJnmHz fFXO1OlhvrVDWyVCbWxYfyrNz3dQ+evMOWdW6JNsIaeeP89KGm7QkFsUxJuShiaKxvDWvPIJnAx/ 4lz9s0X0yXBuzj9VZkw97fdtAZkb6VETxd7R4EYIFS8/XNddO2CVuu4Nl986m8r1qbTVZJWvZJlW lhE3ukLG3cZhzl9Vj9xw5q5n8q0I6cpqRrVK3NMD8qDVDjZjWtKj6UGctePK78qmXylevLznzgf1 MDNYPcRZGPiqAWe1vPWOV7Ze6fH0TVa2M0k3d4WGL398u5Gbd3/+uGFJU6CHp0HOvFw95eFZiVPK 4egs1u/ZPlOQ26b82+h0SA1fr7PR3rgqM23JYWOZnMvJMt1ZfUPZEkvHpRGk1zFisRXbwbw+4Xwr Xmrrf42N97mHdKsyzctCrDPNRNNSO7wvbfwEARAAARAAARAAARAAgRYgIMawjf7B8NIEBYptRnL7 Q19gq00lgfWiewCmxzDRhPSjRKFvP9AnRO51nOV8r23emB9V+bO9BnZNy5/XsFTmW2rkZE9+x1lv epjNzvunx4ac+CZ8Bh+aU5mN92pnu3Qm1QG54pDcZG/SNSBxI5BrYCixnDo/pDoh1WIVl2qS3dQV L1oipfMs1+ufrPIJs8cIUj9/8gBUYeTS8+euCEmwSQP2xQlp/PEaJpSEmh7ql98ocnaoPCrG2hkg ZreK8cldoaG91Yji7EzN/OmGJZ+cXcHyovP06oIx11AUY8PnXaOgYFYuLbIi31JXnDOdQaSoNnBR ZhN9rtEl1jtmPbx3rSDPumlj41yM+eGkMtaoOsoNo3K1k7uCyCBWBP0XlcFH1PceNjyec1diceML tfV5jFSG1OAEAiAAAiAAAiAAAiAAAi1HoFGjiwgHw0sT1FnKa68G9s/OZPzayo+E2iIhb167b33F izC2JMTbhRLtrDvZx0Ym8mzFPdZFCbUaJn9rs2oCF8zfChtPu5M+18jDJ2Edx9mE6XUzMnW+2kZO DI1vWZL+nO9Vz5kXnnTEhM/zl2DTyqix5B4+2z1snMgW5Oukm3W4rkdu98cKP6RVrS4S8na68uiv 6vXmxZ838TvOptXKDr4Vp6PqxyL/uZzc0lXf8KIm7a7Yvqtoepiq6kEZWfgBwFI1ckVKIjWtVklI f66hQDO8WPLnGgP0/PFXH0sunrJh4plgUyXva8ylHHTVthN5sYoGO5+VeuJ1t3fUWFZlKN3Imh4b VivHSN9mt3JGGUXcFUQyBu1bM7zU0n95cVwZaYm6WHWREisvTrrpC9ZJ31Y/LSlcggAIgAAIgAAI gAAIgEArEoDhZYe1ohszBt1lBl6plibUW096x4NbWbyer96v0qxrJDLJKgqT/xMqf8tu/o6fWvBH 4fwury6y07lB1q4O23UnuLmishJ4w/IJnzS81JrwVQJpE3DqZpPnzrNisej5O3funPO7UJx3t4Tx c2iksaP9xKw3/eqv8WRVVr7VSBoFjB636ejwXz6j8kyUZO6OKe3tPVHyxyUekmegWIwEaksNXynj Gmy0zPDtdOH1oJ+5wvVQnFM6kPyFXsS10IO09UkjC2mriqRxoz09o4RRbqbDddtPGLfdzKgDdHn+ lAI1LnxlxmTxvCOTLDO6rLqcUhB1Jo1m7DHVH+l/u9+L4/3KeBjjZ+N419hUYtfT1w/Sdgx1Tr3z rqJamXJfa949fN4uYkj9T6XiSsahWQW6Ei83ysSVgauTzZoyYJcAd0AABEAABEAABEAABEBgRwmI sXajf1jx0gzVlWbUU+NEasoY4/IZd9JU34BgjKIpjroRRZdDn7AFEuL5k4aJuCV/S5Nyq0qYM2zK bLE4wfq7tG1BfKVJ8CQQLonnSbtvIhcQVDvDhRsmQp/juXZOHawb6x0PyLF2zt0mRk0648Uvup+/ OouGOvhKC9e36+7Nnz+8G0JcaWegmOQvu/kXRg/DTh1HD67hJWgk86fvytnDzhkV65VQ/JIGFZPh RV+NIf25bpoBRTOCqBR4/nrkhJ/nX8+fa3Dy8lRha1xIOUSZKBkMljWCRr+lbQmixIDnUGURmZ+/ k4Aeppp///lF7tk+xEYWaigqlAFUW+kU6wvIKGRyy4XFwOcIjn8gAAIgAAIgAAIgAAIg0HoExJi7 0T8YXpqiz3nWq1ZxdGlna8gJ0Yq2pSHBJgyHpjZFjBCReLYf+M5ysQf35i+4m4rnT66oIJ6/JXcC t7V2iS1phgNvGiWWlq9pNhxeKvxuaUat1JQ+ZfbGJH8tjveqJ+5dmbx5Qso9r61tyCD8m285UfJ3 sYL2JH7jgv5GKr7qRVuNoUXQ9Ev3rJpOjzyLp4578mdLeH3d1YHH8KJt46mE5eec9MuDdfkriX0H C6sJ/WpeGRdT09H00Mn1YPusrblyqjNThCGjGkCuKnGNLK6BRt9qlJX6863o2dra4Ae9uvk7NuZd jaWXl86Mu6pGyivz7+VZuasMLzXKhAwv42v02z38OcZGK+cOh4hKnK/UpsoLtQ+p1UVOYG37I5HZ UKLk1/z634bmCqK/PYuflcRVq8JXPU0PyEO89ZVHbgzyaqkwwbKZDBs+fS5gCJV+8A0CIAACIAAC IAACIAAC15KAGNs2+gfDS5M0pU+IKd7L8svVDRTriyx3zJ34xfommpRiY9HoK17qH5LqpqFPUAP5 S7rbC/z5K+UrWxn6sqOsOL/MXHtAmc1PDantV7Hjp8wTrHLRXa0gttfMV6fk5XU2PzPK+gfG1CS9 Iu0iS7VVtwXxp/zJ7KQ6t6a8XmLzhUk2KCaj/G0zcnLPj0JlE8e11Tedg6y4vMwK42ntvIpqnDUm 2S6t+ldzI70s3j3IzhQXmGZ74AHLbHbYNR5RYCWQN3/H+JupVqqGovL6qiV/2tYfvhLhHLeEra6u sqX5GZbu0fIdG2DWo2C5HrrlqhGuhzML1VUvQg/5ih6862C4nMoY6dPDWoktFM4E9KAMGXF3u5B0 c40swvASPFxXnWHjyV+epbv1/KVY5b1Iun4MckqeXE5RXtLHeBye8lIJrxuKvHnX42/OdaH6Cm2x ZSg1Osmmz5xhk5OT7IzvezI/zzwmRe318ZToY0VV6JdZTjPKdOWKPkHX2eL8PJtfXGSLi8t8hdqo qqu9wwW2vLzI782zhYVFVnJtZ1w37gHRse6ser22iHxuwt3WRNoByr6E2Yb2ymuR3+OWA8v94fAb BEAABEAABEAABEAABK4mgUaNLiIcDC9N0IwAKVYVeJ4uq0mqawQg/srZ82vBM1SaIELoKPRzH+RW o4r89aIosbGkNok15Y+/rcT3chdWmhl0n7ibwlTdsgU1IwwIks/Ip+QaSxkXnxBfcvi7wbwHfBrC iLDaa35F/kWYNhmn/zvRyzJ91dc4c6OAXVJXhnpX7paLinyJ9nYWj7ezhGasIOKrG+b1aXRlBUHU /DF+6ok648WfN/W7Ux2EapO9nh7862BqMpXpavqbPSFfMe1uB5Ju8owXoStpeJGrYMIdOszzx61K prK+cUE/ELZ+eZF8pFGImlQmZLymb5ln56wWyc70rZVrGc9kSq8/bawz2a2MKE58/FycgEFqdVo7 j8XCpJp+akq+EJynuDKltiVWZG1zDvCOx71xpIQyLJ/VqrFW5lUcrIwPCIAACIAACIAACIAACOw0 ATGXaPQPhpemaq/MpnPuWS5y4iC+O/pHmLYDp6mpRolsvZhVhpBaxg7TBFWsxqiVP+MOqpUCy/R2 B1eOyEljvJvlpr3bP0R+vOmX+FuRepTcOtfO1Gnv9okqjLULU6xPP0NGpse/E13H2ehMcL/GSmHY OyEVejuec86qWBippt+eNR7eGkUHwu/SpHvIsZ4fdd3e667uMUS+tlgrf708fxe0UNoZLxqHSlpt rGdghC3IE261UMFLux66BiY8epD6W1+cZn2dZoNdokvI6ephTr7uuCvH1qrGtLmRY47exbYx+Sme rOjCdVtnI/rKHU8eY6w7NVw3f0JOz5lDWhyJzl42lnflVHLIN0F1BMuEzL/0u91v9VYtTS5VVnQ3 LkvQMFhmZyz1p617yHgWy5Z2mK4xHS3NbMG73md9foIl415DixtHgmUm5mriEAY71z9f4SNfjVQz FG6CAAiAAAiAAAiAAAiAwNUlIMb4jf7thOFll8DBB9Y37mf9Mj2/cIHY3v20WVqnfXcdpbsO7r1u 8yvUtWvXLlf+K5dp7nvfp12vfT2Vf7RG+990lI4csOevEv4Vury8TCurJSqXy7Sxwei1t/8E3XPk gBuv5Uqlz7kuXFyi9TLR7r376M477qLbbrEEqjqvvrhAF14q06037aLy7r10xx2Had8tu+2Byqs0 9/w8rdOtdAfX2+F9u0mlbw/V4J0r9OLCPH3/By/SD394mVZe3iC66QD99L1t1Hb0sIqzVvoif4uX yrR3TzV/h99A+/buUWHFBV/xQl/56H761Cj/EUvRwrc/RwfKXKebV2j3vgNUC0clfFD/Cxf+ldY3 d9EeXsYPHz7C0xQ+zR8h/8svvaDk3Nyzlw6/ISinOXREV1621q9coU3iDDbXaQ/P382v8clfI8rV Zc5zRePJy8ttN7/GW/5rhG/FW7L8rC6cpWf+/p+ofPMu4tZDurPt/fSBtiNXSeRNuvhcgQr/fIF4 qeb1fYMOvuln6V3vfjsdqFH9pDCXn/8O/cPCD2nP6++hD7zr7uuav8wTvkEABEAABEAABEAABK5v AmJc3egnalibf5O7yU3IeeMbXhrVBsKBwFUh8DJlO/bRp4XhpSNDpb/soX1XJR1ECgIgAAIgAAIg AAIgAAIgAAI3JgGbgSNMbqOGtfk3uZvchEwwvITRDPyAQNMIrNLjYsXLkzzCdmF46aZ9+gomLR1R aT2rm7R7uAQBEAABEAABEAABEAABEACBVysBm4EjDI+oYW3+Te4mNyETDC9hNAM/INA0Ai/TY4l9 9OizPMJYmlZm+VajatyiksLQ0jTQiAgEQAAEQAAEQAAEQAAEQOAGJWAzcITJbtSwNv8md5ObkAmG lzCagR8QaBqBTSqMfZme/O4yvf6dv0Kf+dh9FOKYjaaljohAAARAAARAAARAAARAAARA4HonYDNw hMlX1LA2/yZ3k5uQCYaXMJqBHxAAARAAARAAARAAARAAARAAARAAgZYgYDNwhBEualibf5O7yU3I BMNLGM3ADwiAAAiAAAiAAAiAAAiAAAiAAAiAQEsQsBk4wggXNazNv8nd5CZkguEljGbgBwRAAARA AARAAARAAARAAARAAARAoCUI2AwcYYSLGtbm3+RuchMywfASRjPwAwIgAAIgAAIgAAIgAAIgAAIg AAIg0BIEbAaOMMJFDWvzb3I3uQmZYHgJoxn4AQEQAAEQAAEQAAEQAAEQAAEQAAEQaAkCNgNHGOGi hrX5N7mb3IRMMLyE0Qz8gAAIgAAIgAAIgAAIgAAIgAAIgAAItAQBm4EjjHBRw9r8m9xNbkImGF7C aAZ+QAAEQAAEQAAEQAAEQAAEQAAEQAAEWoKAzcARRrioYW3+Te4mNyETDC9hNAM/IAACIAACIAAC IAACIAACIAACIAACLUHAZuAII1zUsDb/JneTm5AJhpcwmoEfEAABEAABEAABEAABEAABEAABEACB liBgM3CEES5qWJt/k7vJTcgEw0sYzcAPCIAACIAACIAACIAACIAACIAACIBASxCwGTjCCBc1rM2/ yd3kJmSC4SWMZuAHBEAABEAABEAABEAABEAABEAABECgJQjYDBxhhIsa1ubf5G5yEzLB8BJGM/AD AiAAAiAAAiAAAiAAAiAAAiAAAiDQEgRsBo4wwkUNa/Nvcje5CZlgeAmjGfgBARAAARAAARAAARAA ARAAARAAARBoCQI2A0cY4aKGtfk3uZvchEwwvITRDPyAAAiAAAiAAAiAAAiAAAiAAAiAAAi0BAGb gSOMcFHD2vyb3E1uQiYYXsJoBn5AAARAAARAAARAAARAAARAAARAAARagoDNwBFGuKhhbf5N7iY3 IRMML2E0Az8gAAIgAAIgAAIgAAIgAAIgAAIgAAItQcBm4AgjXNSwNv8md5ObkAmGlzCagR8QAAEQ AAEQAAEQAAEQAAEQAAEQAIGWIGAzcIQRLmpYm3+Tu8lNyATDSxjNwA8IgAAIgAAIgAAIgAAIgAAI gAAIgEBLELAZOMIIFzWszb/J3eQmZILhJYxm4AcEQAAEQAAEQAAEQAAEQAAEQAAEQKAlCNgMHGGE ixrW5t/kbnITMsHwEkYz8AMCIAACIAACIAACIAACIAACIAACINASBGwGjjDCRQ1r829yN7kJmWB4 CaMZ+AEBEAABEAABEAABEAABEAABEAABEGgJAjYDRxjhooa1+Te5m9yETDC8hNEM/IAACIAACIAA CIAACIAACIAACIAACLQEAZuBI4xwUcPa/JvcTW5CJhhewmgGfkAABEAABEAABEAABEAABEAABEAA BFqCgM3AEUa4qGFt/k3uJjchEwwvYTQDPyAAAiAAAiAAAiAAAiAAAiAAAiAAAi1BwGbgCCNc1LA2 /yZ3k5uQCYaXMJqBHxAAARAAARAAARAAARAAARAAARAAgZYgYDNwhBEualibf5O7yU3IBMNLGM3A DwiAAAiAAAiAAAiAAAiAAAiAAAiAQEsQsBk4wggXNazNv8nd5CZkguEljGbgBwRAAARAAARAAARA AARAAARAAARAoCUI2AwcYYSLGtbm3+RuchMywfASRjPwAwIgAAIgAAIgAAIgAAIgAAIgAAIg0BIE bAaOMMJFDWvzb3I3uQmZYHgJoxn4AQEQAAEQAAEQAAEQAAEQAAEQAAEQaAkCNgNHGOGihrX5N7mb 3IRMMLyE0Qz8gAAIgAAIgAAIgAAIgAAIgAAIgAAItAQBm4EjjHBRw9r8m9xNbkImGF7CaAZ+QAAE QAAEQAAEQAAEQAAEQAAEQAAEWoKAzcARRrioYW3+Te4mNyETDC9hNAM/IAACIAACIAACIAACIAAC IAACIAACLUHAZuAII1zUsDb/JneTm5AJhpcwmoEfEAABEAABEAABEAABEAABEAABEACBliBgM3CE ES5qWJt/k7vJTcgEw0sYzcAPCIAACIAACIAACIAACIAACIAACIBASxCwGTjCCBc1rM2/yd3kJmSC 4SWMZuAHBEAABEAABEAABEAABEAABEAABECgJQjYDBxhhIsa1ubf5G5yEzLB8BJGM/ADAiAAAiAA AiAAAiAAAiAAAiAAAiDQEgRsBo4wwkUNa/Nvcje5CZlgeAmjGfgBARAAARC4Tgis04sXL9NauUx7 9uyh3Xv30cED+2h3i0i/+uJFWmH76OjhfS0iEcQAARCoR2B1+SJd3rWf7n7DbSQG1Lt27aoXBPdB AARAAASuMgGbgSNMslHD2vyb3E1uQiYYXsJo5hr5Wb14lp75q2fo24V5eum/MTp01xvpbe98N733 fQ/Q24+4g/S5kWP01k8MUlt3jv72sd8g945XUKF0DA68TJr362U62fN+6pzeRTEeqWRdoAep8O0/ pLZbXDdvmqs83Ad4OKI2TT8FVg231/Ut43RdcAUCIGAnsE5nTv4n+u3OL1DB5yk+OEPPfP5+n+u1 /7k8/Ud0x/s+7yTcOz5Pv//w0WsvBFK8JgQYK9MPf/ADKpV3cwOgKckylct76PDRI6Q1+0SbL9PF xUtU3s3DWSb3m5ubdMuBI3R4n2tO3Fy/TIvLJcfYKFIrVw2Pe7nh8TZueDSKYBILbg4Bvf9dnk7z ept03FFvb/ACgvp3gysY2bvRCIi2utFP1LA2/yZ3k5sjJ7+Bz04TKC+yXG+HKDnmv1iarWgyFjJV v/GMx1162drakpf4vmoEVlg6ZtJXO5sq1eJvC9fBplcrwkJ/V01piPiGJVBmE/0Jc/vJ29XYwHRL 5Hx+NKlkjKemWkKmpglRXmEzk5NscnKKLa43LdbrN6L1PEvY+nTNPZ3Xe3fGSjODqoxYxwSiTKfy Hjb5tL38EyVYf+4MK3lCNOkH13ue6/3MmWm2uMbYjdh/LYy59TbRIm1Jk7TH7YM3vv6isLru6l+U zMEvCNyABESf0+jfK6+8wqL88YcezPTHH3Qw/9/GxgYz/Ykn9fjsKIFldqJdn8DHWDKdZaOjwyzd n2R8NQWjgOGlqzIwS2SuzkBqR3lcP4kvzxVYoVBgs+fOs8mcHJi1s3yd0a0INzs7ywrFuUjhrh8y kBQEri2B9WLOnawm+tjU/AorcxHKayU2X5hi03Peye21la6SmhgYrJ0fZR3OpDvOcoWdl6mpHEpT ytCQmgrm7UackNfkxw0vnZqBxWZEGTrn7TBKhaxblmuE78oWPMkXMp31w3XnWNW+7wm7rR+63qeD et9W3C0SeH1ujLU7ukjc2PX2BtVflGJ03dW/KJmDXxC4AQk0anQR4aIYXYRfk9FFuPmNLuK3yegi 3GB42eFCeC7X7Q6WYsdZYCy+scQn9wvOJEKKWsjA8CJZtMr32rmhqh654SXCyLbRcK2Sb8gBAq1A YFZNOrsj1b9WkP2GkUEzNPhXcdwweYySEY1HouHVTXyFZKL6YCbhXfnqF0WNC4ivnqzaPzY2Smxu esRjAOqbXPIH3d5vLZ/Q+/ZQ7kho6K8G9uug/tWQHrdA4NVAAIaXV4OWm5THrdJM9SmKGFgl2MRy uGW66slW/ERgxcur7qlik3TRSDQ669VCxjW8eB9gWqMW4UsqXIezUkaP0xoQN0AABLQtDetsLBmr 1L/2YJvYqqhuuLquTeAGZ27MlQ+RytJannVVV6y0D84EgobT/yrLdlQNL7xs6zZ9f3jX8NLOZvx9 0Moki8vVM/E040ONbX9U+lzvMp+DM5e2He/1EoHK//UisE9OJf+rVH8+HJafrVv/LALDGQRedQRE W9bo306seLmxD9e9/Dyd/NL/Q196YoJWnEPqDlHbgx306G9/mj5wz2185e/Ofi6eOk53/eIfOEIk 0lP09OfeaxSI1yLPIblnH/skxR59gttqMrT6dA/ddnmORr40RE+MT9H3Vvhhrw/9InV//lH64FHb sbtE68tFOv2tp+iZwr86B8Pu3XuA7jj6E/S6mzfo5je+nz7xC23qLSArhVM0PLVANx95gLp+9T7a zbmOfOlP6IlT0/S9S/yQ2Acfpp7kb1nTE/K/8vILNPnUKTr998/RusglT++Nd95Bh/fz0eDBd9Ov /9r9xM+jDXwWvjNGX3ns6/Ts9FniSdGhn3yQPtt7jD72nrsDfpvhcOXF5+ivv/kUPT170WF+yy2v pzvu5lxu2aCbOJdHNC56eqtnH6P9sUe5UwflV/+S7tOKl19/eriXebh9Trh2mik9SffbVaYHi3St 0q/Why/nnqaXnDJ1Oy8rHdT9mU/RB99iT9gJ/8qL9PQTX6GhJ8fpLFf6wYMH6XVv+mm6P/YueuCD D1H8vW8x6o82l2niq4/T46OnqMDDHTp0iF5319voXW3vop/78Eco/p57VLiL02P01OwPaP+bP8zL 39tV+ZPyX/z2U/TUdy/SvqMfpkcedu8LGJfPnqKv/x0vo7fzMvoxXkZXF+ipk39KX//aMzT70kt0 ++2309s6/iP94ece9Bxkefnsf+bh5unmQzzcx3k4Xk6fyn3FCVe4VJH3re2/S+nPP6Tk1OG/8J2n 6PHHvuaUT8H09nseos/+B3P5VGlp9ejPvzxEX/3W3zn11qlHxz5DH7xbKzw8MZl/J13Os6KHb3E9 rDg89x95K90Xu49+7kNmPYjwL/zDU/SnXxymZ6YKTj066NSjJH38PUf17Hiur/DDvv/iiT+jr49/ w5GPJ0aH9h+he995Lz3w4K/QIw+9Q+nIE7DRH7wdO/nlP6YvP/G0IyOv7RTj7XX3Z2uXT34aKT3e sYc+NcoT7hqh8lc/5pHLw69R2bRwisupbzrtH68MdOh1b6J7f6aNHvjIr9EjD3rL5kpxgoYnv083 3+xG8uMf30Tvf+QRajvgHo7q3vVeCfmjtJ/+cvaalTkS5SzH2+t/4Y1o7EHePyRr9w96OyikEf3D nUfvpv03/5huupO3gw+7/YOSdrNAn9xzL/GeiTLFdep5e6VFt/GvVZ9FnO79D/H0vGXtMu+Tvi76 JK2+j538Cg1/7VmS9VbU90Fe3439Sn6M/vRLbn0Q/cpn/gOvD++11weVz7AXV75Dn9x7v8OjPZ2n Jz93X9iQmr9Vynbsp0+Lss37+xLv720tdeGxLrr30Rz3yPugEu+Dqh4l/+dOPkrv6HxMRESnl/6K Hjpcv+xpgtgvN89yvccCepcBZPryt/rm/dGf8fr+RTE+446MHaR7H/oo9TR5fCbTl/V2mNfb51/i YyreJxx63V107zvM9fbyc0/T1//LC3TTTe74K0q9Ffnc5P3Qf3lqnCb+/p/oCh+DMj6eOMLHPbdz 3eziZfff8vGULJ+qTGv9gzPOijCu0+uteLFCqPFLRP259TLYD4s8q/u8H39E68fFPdlP33To3fTJ j9/v9Ldjucedeqv303q9lfoT4cV4UPRjT//drDOmP/RTD9Fnfufzza23IiH1uQ7qn5IVFyDw6iQg 2ohGP1HD2vyb3E1ujpz8xg35WZoZYm3yCY/hO5nz7o++9hDKbLy3+pSW4uxMhAeE6slWZ47NFUcs +Yyx8cWNQLa2tjbYdEaeR1J9kubn4ztTRh3a155l588NV86d8YchkZ44VSH4KY6lKk+jA2Gq6bcN Gg4JXmG5ZJs1XHt60rP9KphqVJdyKC6XuGXV9Am74kU9ZapG4oarrHgxxd0Mt6X8kEVvFR0cq1Ef SkW5v91SXnj5lQcD67KWzo1qK7pMYROecKqc+cqfjLPWfXWvfYjNF0fdp7t6meNL9f36U+E6sjzc mDqjgjeObtnTlvi7+hPlU9ZfzW81nCif/tqn0hL1qBi9HpV4virnDATTq8ib4Ac7S1ryu7acHQY5 RcjFiTp11qIjmWrU7+V8tmb5lO21y5+f37KYZ9lMluWGUkpvsc4+lsvl2NDQkPMn7k838aTXC6ej c8mnzOXEdA6KiVvU9tMtZ0MNlLNw7aDqrvjB8KNDJ1g2m+O66FU6jHWnuB6GuHvW+RvKZNhofllb pcSYktPY/jM2Mxiv1EFDWVNhRb3l7YzxENt4sF/Z2rpUt96aezGTZuq4rc2oLT7c8OJ41stvndDV 2yV3xYs4083S/wjPalxAhhUv/P66Wl1JLG04g6eaYLgvofdsxtH70Am/3rNa/cuwMa53+ZH5r9cf yfouw233u5H2bCZlHn+k5D6uOkKdG43WVqgyXe0fzOPXNss4K1y9Vf1fg/oTWVZyGuql576hXqs6 Xe2njfVW629dxPX6sTNNHg/KlFu0/knx8A0CINDwahfRH+3Eipcb8oyX8sKYO2niE6HuwVFWmCuy yeG0GhiKicrxicUdLLKrLCOXEFMvOx9htDd7wnSIHn9rAZ9kDCarg1Wev0T/mUD+irkeD5uu3jQb Hh1luUyKdcm95B3eQ3vd8xP0CV8lvXRSe5NCciww2VyeHPCkl0gOVNLLplmPTM9wSPB0ut0N15Zk Y9P8INvJYbWkWegvU9AXXgeyGsmhqJ+1w+MWXEbGxjiXAdYZr+a7PeNZ6q0n4G4ZinbGS6Ph9LTr XZfnR12WPG+yPpwZ8daHXkN9KM+PeQx7Hck0Oz01wwr5STaWS7Nu52Do4IRfpOkcDM3TE7rqOJZm E1N5J9xobpD1OGWfG140Q4GaOPjKn8yfuu9bci/uq+131fSkIWKATwhT3dU6wcuZv8SoOH3hUjzc QE+1bPO3h/nDTac7XKaxJBud4uXzjPcsBX/5tKUl6q2/HvmbA9GmeXhyPUxMS552PfjlFPVoNlCP NCU4sJdZSr2xix/2ncqxaX6IdCE/xcbHcqxPtDFd2QATJ2gD//zlsyc95rTX9crnat7btlR0Xq2r mj7DGjjqi77EBjQuxwYkl2k2Pppj/aIt7BwKcFmaGWb9/f0slUqxgX63/Q1zHkYj7aetnPX5y9mx scBkxXPmGGfo9g8Dbv+g17/StKdc2nQg3GN93rc4KTl5u+ovgUIX+n1//VP3ND2L7bqpIa3eGuq7 tz4cY6PVfkU/BNdfb+uXC4sPbQtHR9XwYvFZw3mVDcnD9w350QO6TCxGfH4IbuVgZ94eZ7xvRNLj CXW9Gl7vbT69b/j7ozQfn50vMlHfdWND88Zn3nrrtme16+1yfsRYb8Nso1ue9BpdEsfccU93vNpG +cY9rv70NizB+jJDLH1MH2eNBupt5PHLNvSnxp/1+ml+v9F6628PPPVWjgd5fyu3uIn2pWn11lMB WrT+eWTEDxB4dRMQBpRG/2B4aUrZWWfD3W7HlZr0GlfKi6fV4IO4wWO+xhOkpohjjaTkDqgsE3r5 dMgfRaCDbk+zOfX6Th5vZzX//id+SxPawKadjfK3KehpFLNVgw6faOodX2BS2+Gmt7WlpccHEupJ KBd6a22WdauBcYxlpry6ODfkpqd30Gvnh91JLc+bJ9SKO3ik5Cjb2Kb+nPxzLu6ktsJFMJdsilJO 30BJ9+OuXHGfNsrwwp/tU5o9Uc1rcLAcJrwtXte9dn3YuHBaW0XB64MbkOefP+2Rg36ux74J/W7F o5BxZUUvLcK9fjjhS4TT86jKWbX86feEf3XfoAdTnZhfq6xOUvozTPDUIFKWU17e5vkrUcVHlU9f /VyfG9HK56CvfE67PHn51A0oSn6V1iA7X5WR8SFqVtVbbz1yeCojLbH+iYWKgPy/zsivB0894nXW X4/U6hmfnIxP0NS9rnGVlulCT990v57b1taatb0WcZcXJ1xZRHutRbg2P8lSvX3coKGt4Et0OwYO YeQQf338/oRUqBa2oUsDl8j5LxfUZEFM4GqFb7T9DJYzt712ylKX7B8y3hVglnZQslL9g1b/tjbm 2VBfH+sfGGCpPu2g+PakRw/C8JT19cXKoG8wbIo0Vd3k6en9g7gXqO+8fM9X+0C33nrP+1mfC/Yr iv+Kvd6K9Br5/P/sXU1sXcd1HqG2G/knrvwjB24cu4hXAcRF20UXDSAm6aYbsUm7Igs0KEB61VKr gtpRO2pFrsxkIa7oDdkmJJDQaMWmoAqQKcQAegX4CohByUZMwieLTh5dPoOP9fTMfXdmzsyduT+P T9YT9RF4vPfOnTNz5ps5c86c+bmf0YoXPjAcGByUly5dkgMDA/Sje+oHxue3okl3eGN2AsM9RGTr vfNlPVM2HZkcQdrBpFfg6FeVr+1OvU8qOcup90lqGzedej+Si2PcPrvvZJ0n707EKg/M4SSG3f4s gxFL13lHcqux4w5TJ46mParl2j31ufTjCErPMfvF1l+Kz5VpZtcx/UDtQNtZSf4RudW8Gf3H20/X 9cdkz+NfF9+UI3AGoXnHdKDunk3/4ulpR48RJlyPffaQ6Spfj2mGurx28OtT+euyTCADAmcRASWr 3f7geOlFiyBjR8/qiJF5afwRLG2jiKjz50qURfkcbr0ljJSjVpRFmTvKa3DKKCJNbxS7N2DcmLKz JrOBbx7HDF3HyB28YfLTfJr8PEW7vWAN8YklPmTqUJp0uUFAr0w41c8H23zo2qHb1KthgktSNVfl rxs3GC6ZUwkZP8SnPwDQuXS7coXT3WmGtzHpPLq6krFtB9ERedCGIOHNZ/Na2/YTvZcqGDWcbiAw qx4rR6z96fimXaSOGR2uruadMugGrkvrmqB3M2n9BpZGO7J0adIZ2HM6fmQkp5ln7VPL36ZeDeO1 T4dHJre6HGbA6LUzB09aVZaViE4KOn+dHs9v/p6/8UktGU9X7Xh80p4ENmAcknOrdZn6onTSvbvS AaSmv6atk6F8TP8S7a/bxkF4ZfZu73jzU3JwuZLBxcffJ0+e2eC3SPf0ov8Uof464khen7psHIqz gU+zmfYUkD9Vts+O75rBKZ3xEiw+DzTppf2/j5//PkibyrvSLpqey60eoCpakx7RcLnV6d6ZTldZ +vJAEY6PHpKj+CDn1zL56/Qk1TV3vIRWAw0Ufu2IBtza+e31Cyaf9Mb0n/RVo0D10V4jy8+pHS88 c+ZMnN0KSTCLTDxwfcRj6/orlneWXplbklvtNKHzb+RN6s9CrVPnH0ySOdEK5XbRrmq7tsw1USdl oz/Sdq/zs/VHOiwkt1pPe/J3avulSv0RszH+NX5GzgLt1bxjcmvKH9layGlCcmv0mD/RSAm3Wx2Z ffgwJr+8BWpO+PUJkD/OLu6BwFOIgOp7uv3B8dKDBsOX5E/ecmdTdPJHW3ZAWaRENU3vr8zx4nn4 i/KyCnowuN/XKEbHEbIjJy7pmZSbzooWnZ9RcJ5iN+F0loc6x0UrWE1nZi4dRduU83oGn2aqt3Vk ump6k66THz/7hvgdHpcT4+NyXP8mxq3hFjMwWV7Ft7sWl6Hw9okwn27K1oGSXbnixrTlV+F8pUzQ WPaJKz7zLT+TtzpzRRp/nVRMHo7MahzloLSrWnx6nY6+HrGzBKYDjqwYfRHOpp057bqTq6Gls4YW 7rnGVPtwT9Zpq8zWvexnVDndol02liR63Lwvt4iuvm3PKCBTjs5mYnv/R9z2efXaVdY+7eonlaDh P5WjDuf2v+HFkQfvbAaqhxh+NiV15/EZkCPj8KAzIVj1JrRL42lfoQzk5DcoJ6YXZG0nf5WGy0Px k+qv9faC64GtbiqFVr2ov7YrrLrf0lHMKw2/6etJGg99tbiUSUENfvUgMF/3dNt/soFRpJ0Z/eH0 16Qf9DYqOn/BSrstlWm/AflLYrGBfX7ZOmnG2rvOkfPp82N0XEjemyF5z8rDtatXHb0SlwfaFqy3 xRp50PWvr4EtpuyMl4HReep/7sl6vS63traSq+qTdg9CLgCNgLoyOyHtF2Lyb/DMyHOaHq1A1Y6g 0FeWeK6V7is4JfjW1Zi8HzF55xMBlXhyIrdltj+7LK/NLMraLnfNOUTuA5Pb/C83HTp2zz03leSJ t2s+kWPrr2Nn+aRh+euB/VKh/hRPMf41v0Y2A/2ELeOA9PWt1tN1R0979iDTt1eV/Obag005e1nL Z+w6lP0CmC5Icn0C5M/hFw9A4OlDQOnEbn9wvPSgvTQ39Wd9ac+nO5qwqbMZkMGu917b5Lq7a8r3 9UyWGJV33bFibpJGeUU+nWrec8P60M4sD83WgumbmSZORzGNIo3u6U23DBGdNZAbckYbq6MLwRmm u8GZV1KWbFtFaJbQhtGhrjbDYJkKA5t2Bu5KDJcgn27KdsuQP4h14/lP1mFTjc5PJ/Z86MgDN/MY BS2N1oNBLg/3FvQWDjKS9Dp+Rha73V5kdLtFAwubSrDd2teypmf8nHbWiWCMwYpOTJNnRJZY9ult lfbpHh5s8orKUboE3ZM/Xg8Lel12ljEvhAaLpn+JGZ06PHtGD20Ekyszuh51vPQ6NCFXt08reB12 S/XX1D71gJG3T1tguxy8pzP5NgN2l4PLFcLlXgEu7BPD+YPKbvtPtrLDW/GoC2HaIR8YNe8Yh2EZ /RAsJRuclnG8GJkNyLPitab7XXI4+D2X0Uml5Z2fqea154wzxZVbx/mRiavTGpabflfH6jqGqa6T +NU9YyKIe0ps6jUyIcEnpUYX6vEsq76hcmr9UVTvXN7fDzjlk6zZyrKwvFdlUMU/kB/OXDUruqwN QfVHcnurSG5LOxX3C+0eo8e4/BGHpv4CZ6OoEpj3XF56Yb9UqD+HD49/9U79mfJ5eix5N5vailXk tms9xpwmUbkdkZu5tvcTIH8J6vgHBJ5eBLp1uig6OF560G7sCoKcWfrGqvkKwsRKdgtMD9golcSa 2fozIJd23A0EqkHwP/4cVMAscug9328eHpyws0CUYmf5GyOXK/xQfsxA/oydh6AcGpx/TbqiZ4+d dNnSTnJIrdW3nVlCM1tIM4e1+k7QoaPTL3VlBhWfBbT8erhEErUOlM6KF0sfIUiDLZ27OqIsfX7q NGRgq0/4qhWHjsnDtQ/t0uiDzRljqL5/N8/kd1KTnG621qErUx6nnbH2p1JXX+Na0l8RChp01mmh cvTz8581xyFZ6eQXkz+7ukKIMdM+1Uw2/6l26rdPnpc/kFR5xsrv4FmyHtzzeUiOtrzZdsZvrb6b kSONV5tWD6zSIcpX9Go5ZsDO18u3CY23f+Xtk6+O0vkn8ekMg8tpvuH+2vYZesWLQ0+J+M8+H1Wf 1exsgoteJeLh4udnnkvOLnfff4YHaCZ/Kihvh6YGmdNE6QceX2HjnMUTkL8EP1Y2f1WAn56KH+Qj SSgr71wf+bQhWfLz8+XhdqpXuMzqeyW3R37/c3wsW62WPDo6Sq7q3vm1Xf2dFCOiW9Ii5l4s/6y/ cfRkltz0H8lXjbL91/7qpOnPe3oQKSundrxY/jt86ufmXTsxFtVHhfKeLXtRiM5f92dDEbmNpcPt J13GYFw6tFZvpeITOTp/RRO2e+L9v6JR9FxeTJtn2Hdtv7A0dNk4vzp/dVV/nA/Tf3Re0X+1uij9 ilugvZpVO4F3Jgm6sfmz9q/swVSPaVnlV1/fJumRXCqZ1XKrr0Z2Q3Iby7+A58cmfxw43AOBpxAB 1V90+4PjpRcNhmbu9JLhwRsbwRQbt68bA0QrmmDERxx4sG4HtmIsfnaDz4ZRfKmjwyqpTkzznisK plz14ESnq+j3Vi0mgtNRpGB6mpiuwZnLoy05lg5GBiZWMudS8O0tgmZOjCFB6Zk9uzSw3coeTcFy 7sEt4aJn60IOqfu3rLHq46JzV/hZh19gybmOGLhauuItSgHy4iA2kx2Th/01W0Y+YLK8hb+QpTP3 2x+nuzy5pqMVXo3hElgRcrDBZMVrnyph00a9tlSUqaELpBmjte1zVNZpvOWXP0YXy0vTm/J7vHDn xGAAT03v5+vz6b/XzzF6/b5zbcu9+qqcHGafRqaVbIHhpktW9EQr8fRAZTBy3kWDtc9Qf50Mqoc6 Kw/44KMo6968b8v7W7fk9RGGy9hiHBe2CkKXJYj/KfrPWDvT5TXvmaOcb4Hy9YOiy9MPhn/Wl3In ms7Xv5r2zr+SlEY6WJ82Olr1u1w/qCiOzqH+t8yflQdXrxj+yyRSJQ7DI4SpTio/fzbw9PoFTa+v Bk9a8ZJdTELOyVRGhBiptMJWpx+7cqdEYb3TCg1tn11O5d0vP7fP8leFxTgqE36c9GeO3FJ/FjU3 mP2k5TaYC5fbax9m0uPbqASXP0rM1F+kno3c8vesjXVtvzgO06wrxS+n4SNdUcfr76Ent35qpoxs tQyn9/NSz+ZMP7IHlb71/4ro/fjVnvtf/qqVB7GBwNlDQPUB3f7geOlJe2B71QUt//UtNvmQLcEf lKv7gZ68J3yUSYT257KZ0tCBhqFUjOLjCphFtMqNGaxsAC4GJp0Dcpu1eXPOQrIElwwCrjBNekX5 Oe9pS4ZZIjosa2w5p/vlAhowOXRk5K9MGKN7JOezl61WD+rOweV6Bhf7taMsnwxyaWfyyPHCysrj hO7toJro/KXqIYLKYdTGzOzeSMAgP2D1RPLQYJi268Z5JugshdIrHIiOf82qLJ1p1wNT5qsNqrit 7SWz4iFpn157UXHKzqSpuPzPtG3PCOZx/HvePodn7/ivzfPREcOSQk35AvwrIvPekz/p4HmpdD10 y6c8OpAN3gGYEqmbpl1KHziE1Ila6oH317TsO5Ov2z5v7YeGRp/TViM6qHE/w58uJMPl8ozTfnWM 5MoGOfmrDrrvP4vatGlnvB2yCYuQfijVDzIn2tRG8dkZhg9P3o/uLZkVqTF552WMVokDvKtXhnP0 ii+3XjLlH1ld89UP5RNQMe1qLlGwPcPgSXZPzdMl9SWrUwcmVquxUBSbbXcprndX3rMOIi7vl119 VMRH7H1Zuc3rz1hd6lWc4ew8uWX1UGT3mPrz+/80I/Pek1vtuFaHyvMv/ii7rpTcVqo/pqcGbjj9 XGt72ZXbgE7lDtOMaR4G1LEHh9+P69ue2IMZHj5/+duvrcq52Vm5QIdAuxZEhjkEAAEgQAh063RR dHC89KgJ8QGHGJyQd/bTkfDRnvzgavqFE3J4DEz22ACpwL+qcPV3cPuGcTIIMSjnvU8uN7bX5OzN W85WAK6AQ8orrNz4oW9CXp5YkDv7e/L2/DWWf2fWWNDhijxdPqjV4Zp/VQbOjzWC23J1gs0Cj8zI +v6+rH044xoDyvHEDQmVIJkPN4yzgD65eXNN6jMI261DuVNbk9PjdMApfaVG85OQdfWPcNGfVyVe BlNc1uatoZoY/4pPhgsvv8rWOlAG5cLdPdnY25M7OztyrxHmUNPb1SGDcrG2J/cL6LopoisP1+Rm I/0CR2tPznN5uJ6VB3teS6dt3FjepLpQy3ebxOu2XF2ckWNj9ClXz0II0pEjokX11yC6WwvTcnR0 Ru4yOjsjLeTEPOVzsC83FtlKLFUHur14s9zhNliMFqcL11QojT05xbbejM/x9tmUO3fX5Ixabu21 TzNYVO3d41/lYngJrNrx8ZxaupPUg8ZzdSFUD8RnRI6Oqf6UHM1c7fBp5Zba8p3OaoPJuSVZ32lI 6z9qy92NOWNch1ayhdAqCnPbJ+uvVfscL9NfW+M4NOtblH/Z98106931uWW5tbMvrd+3LXcYLpcC K/xMHmzmfHyhJhuNTj/RaDJBSCJ333+G+3/DgW1n1A5tm2/KD5x+cDHRD8F+cGgu2H5dByFtw9tJ W1X7SO5uLsvJqSWWH5/J1vLekOsLdvWd6Xd7NIDL6BVPbndrtztye2na4dMiV/GO1bUg/be2uS5v 374t19bWzE897xx4dX/clHukO3Z2lB6p2ckZmjCp7TXoXafN7HttxvQf1EfOLK/JzfV1ubo8J8ev sMPAycZYpbPCtf6pWCIT3aF3HMO0HcTUe0vuBOrdlfeOPkoSLi3vho1SN6Y/u0n92W4jkdsO/15/ RitUvJqw6bOVJUpu9/fvJ/q9cehTtOUt5/D1Gbml7J6VsN1j5S+//1eMhPVHD+yXivXH9fS1RE83 5EZIbp3+pQOlaaNsxYsFOXbn2YMktw+POvaztge1vuV6LJZaYfhjlL/2DvvkPcnxROTA+cIyIAIQ eIoQUP15tz84XnrWUA7tPlM9WPOvNDvgffykZ7lXTWhtKv2MpeZxcIS+tjAqL+vBnfcZXKOAi2ZG vAGcdQ6kA1idn7qOvi8XZtKDz9SSTrZqwyjLjIOkU9IYP8f3V7JOFp0nOcRmJ0OH8nbSbO+tuKtw NB2/koFcPK9aXBu5uIzRzMNMen4I7TGOfSXVHq7rYevVnc9NNG+iexgYnPv05Z6bJA/c+PZ4VJjS p5R9eegYpy25xB1oHH9zHzqc9YjoCvKkr67ww5Gb7GsWZtCl8xietvVA7d6v99Bgs8N/PkKmbQcM wTz6btqnzYsPeC1/Ro6CcqbwZI5MjYtzdfFU/Lf3PozLoKZVbc2yIQ/Z2T6ZetA0dL1Z8rwZlnTk tlz79D46xdKyB5Vzx0te/THi0rfa8ZKHiXo3V+PDKS95NoDj6VwKbLPqtv+07czdwqk5Me3M0x/R vkjVeaIfivvBzVlPl7H2ohyRXG6b7OuCHIvkfnhGLkxb/cDpVDlMGYOy0ilpqP6V3DqrADh/+t7j U+NW9foZX0Wk0w5cp9bd0pWVv0tT7uy/qddAHhrfqdVHc6bdnffL17taNbeszwGJ8UpOpnvp4Loq 7n78snJ7Mz2PTNM77YeteNFYquvAVHY7e26fy+0eT/5M/aVt2smfmDJtnuh4D5MrtyXtlyr1l6un ycG4qO0l0qluy2ZlyJFbjT+/Hn+Ocvs45c9vq7Ht4Rwb3AOBpx0B1Vd2+4PjpUetp6Ow2nJ9PjB7 Rspy6PqifKw7jALlrK/Mmr3PXLEn92ylhSKtz491Zv69cJ3s1vxo+j77eeSdW9MZw3N0ZiVRkFbh XJEbTLPXdXpDNNOpM2HXvPcHtUV3m4jC/9p8siT2nv5qBSlhrqC1wdHaW3fPTmBG2uDIhFza5Atr GUNd3O6sZmekNC5WGQ7J9RAAlF+rPpddOaT4jWCmWeyWTtOXv7blxnxg9QjxeGVyQfIdRtk023Jz eSbaPgeuTEk+KNb1pw7aU3RmKTSrv8Ro9ehUvltLWZkdJv5U+zBf3RqZz7RDLhOh1STZMnVCDB3V k27ylv8YVSf8qGL75HmFmpF5H5Frheedpel4PQzdyDjPFKf5fF7LyNFnD+/K2YmxTD9h+qXBMTm/ 0esB3GnaZ0vOj3WcUldo61fZ+suv3cDbgxrhMpqPy/pOfv6RAdzIXC2QIa2I7KL/zOv/VSZ57Uzp B/15b13fuh+0+mHIcZi6jDflynSqfzx5H7mxKpk/PyGrL2f7JCvvqeNleN7Ips4rT+cU1X9rb0NO 8jN5GJ+Xh0mv3Lmvszndlb7Oo88501iGrv7Wlebdm2FdwvhU6QzfdNuMqVcvnhi4LMdvzMsarXR8 dH+H9BW01C7x8h+eWnVW7HZ4iNtnxfqoYikSuc3rz0aL+zO+eomVLyS3qv0puR1k8VR9abtnW3+d z5tAMPUX6f/N+4BNcVr7RW1pq1J/9YCeHiG7WunpLW3XBeSW900hHahqNia/idwOhydzlD243CN7 8HHKn3IM8z7ixm1anoY/IAAEchFQfUa3v8fheDmnSkOCfnb/Wh+Ln+/eF+L8F8Xxb4/Ey2+9I968 cL5Py9sSu/9VFz/fuS8+ORbiuQtviHe+8gfi3bcvimd6wLGq6nPnzgnx6QOx/d8fiZNzz4lXf/9t 8fpLvUg9h8ETqoPt++J/5XnxpS+/Iy4m+bXFP773x+Ivv1cTtIVHNH/4XfFSJInDxq7YOzgR55+R ov3s8+JLb1wUL37hEfDcalBbORBt8ax4hXDp8GmZMvjZoCfqLuH/098k8iBJHk6aLfFFqo83L3yh VDlo4C8e/GpXHDRPhErrhRdeExcuXhAvFdbFiXjwy13x0W+Pk/Z3/vyr4pWLvydeOv9sON9PP6b2 +eukffJ66Ff8efs8ofZ5kdpnMSbhoueF2vKfiMbejjg4PEminz//injljVcK8+zw2Rbnnz0n2s98 geTojQI5OhEfNxqUT1O0221BH3YRz7/2lnj3zQt5bJ7uHdW96v9s+3zb9Ne2/KfLoltqm7/CZZ9w OTS4vEC4fPVR4XLK/rNyeT9tkPw9PJ38kd7d/eW+aLWFeJb6motvvCle/N1U//gMtQ6oT2pQv/sM 6aN3Hpk+svXXYeCT+gXNyQAABtFJREFUB/8j7j8keSC9ksjtRZLb849Ar/jlPcvPJL+7e/viiPqK 555/WVy8+CZhmlPgpK//hThHcdsV9VFOqsFXSn/95sGDpD87Pj4WJyfnxPOvfvmRyu022T0tQTYL 2ROvvfg7pP/+j+yeP+rYPUNzovmDv4naPcFC5AX2wn6pUn9JX70vjiXJrbHr8hg83Tstv5882BW/ +KgtXnhO6bHz1MZej9sSp8vysVB//POfiZ/tfEz2/7vi63/49mPhAZkCgScJAdU3dPtXlTYWPxQe ClN8nn3HS7e1AbpTIvCpuP3BP4mXv/UXYuBi1vL6+KffE6/8yXtJHkOzNfGDMZpnxR8QAAJAAAgQ Aug/0QyAwJOHQEv8+wc/EC//2bfFpdezExrc7qEDl8UPYfc8eVUMjoEAEOgrBGIOjjJMVqWNxQ+F h8IUT3C8lKkZxOkCgUPxvW98Ubz3EyGGxm+I7377G+JrX3lNnGv+Wvx05aYY/ofvp2kOitXGv4pv vN5FFiABAkAACJxJBNB/nslqRaHONAK0ZUd8/5sdu+fK+JT42+98S3ztrVeFbP5K/MfKnGP33Npf Fd+8SCuQ8QcEgAAQAAJdIxBzcJRJsCptLH4oPBSmeILjpUzNIE4XCNiBQx7xzO098Xd/+mZeFLwD AkAACDxlCKD/fMoqHMU9Ewh8QhNOLyUTTnnFmV7bE3//ddg9eRjhHRAAAkCgDAIxB8ejoI3lFQoP hSme4HgpUzOI0xUCbdpzvPkvPxbLP14V6+s18W81Os+F/gYGR8R3/vqvxPDQn4uvXsCe+q7ABREQ AAJnGgH0n2e6elG4M4rACZ2RdOeffySWf7QqNjb+U/wEds8ZrWkUCwgAgX5AIObgKMNbVdpY/FB4 KEzxBMdLmZpBHCAABIAAEAACQAAIAAEgAASAABAAAkCgLxCIOTjKMFeVNhY/FB4KUzzB8VKmZhAH CAABIAAEgAAQAAJAAAgAASAABIAAEOgLBGIOjjLMVaWNxQ+Fh8IUT3C8lKkZxAECQAAIAAEgAASA ABAAAkAACAABIAAE+gKBmIOjDHNVaWPxQ+GhMMUTHC9lagZxgAAQAAJAAAgAASAABIAAEAACQAAI AIG+QCDm4CjDXFXaWPxQeChM8QTHS5maQRwgAASAABAAAkAACAABIAAEgAAQAAJAoC8QiDk4yjBX lTYWPxQeClM8wfFSpmYQBwgAASAABIAAEAACQAAIAAEgAASAABDoCwRiDo4yzFWljcUPhYfCFE9w vJSpGcQBAkAACAABIAAEgAAQAAJAAAgAASAABPoCgZiDowxzVWlj8UPhoTDFExwvZWoGcYAAEAAC QAAIAAEgAASAABAAAkAACACBvkAg5uAow1xV2lj8UHgoTPEEx0uZmkEcIAAEgAAQAAJAAAgAASAA BIAAEAACQKAvEIg5OMowV5U2Fj8UHgpTPMHxUqZmEAcIAAEgAASAABAAAkAACAABIAAEgAAQ6AsE Yg6OMsxVpY3FD4WHwhRPcLyUqRnEAQJAAAgAASAABIAAEAACQAAIAAEgAAT6AoGYg6MMc1VpY/FD 4aEwxRMcL2VqBnGAABAAAkAACAABIAAEgAAQAAJAAAgAgb5AIObgKMNcVdpY/FB4KEzxBMdLmZpB HCAABIAAEAACQAAIAAEgAASAABAAAkCgLxCIOTjKMFeVNhY/FB4KUzzB8VKmZhAHCAABIAAEgAAQ AAJAAAgAASAABIAAEOgLBGIOjjLMVaWNxQ+Fh8IUT3C8lKkZxAECQAAIAAEgAASAABAAAkAACAAB IAAE+gKBmIOjDHNVaWPxQ+GhMMUTHC9lagZxgAAQAAJAAAgAASAABIAAEAACQAAIAIG+QCDm4CjD XFXaWPxQeChM8QTHS5maQRwgAASAABAAAkAACAABIAAEgAAQAAJAoC8QiDk4yjBXlTYWPxQeClM8 wfFSpmYQBwgAASAABIAAEAACQAAIAAEgAASAABDoCwRiDo4yzFWljcUPhYfCFE9wvJSpGcQBAkAA CAABIAAEgAAQAAJAAAgAASAABPoCgZiDowxzVWlj8UPhoTDFExwvZWoGcYAAEAACQAAIAAEgAASA ABAAAkAACACBvkAg5uAow1xV2lj8UHgoTPEEx0uZmkEcIAAEgAAQAAJAAAgAASAABIAAEAACQKAv EIg5OMowV5U2Fj8UHgpTPMHxUqZmEAcIAAEgAASAABAAAkAACAABIAAEgAAQ6AsEYg6OMsxVpY3F D4WHwhRPcLyUqRnEAQJAAAgAASAABIAAEAACQAAIAAEgAAT6AoGYg6MMc1VpY/FD4aEwxdP/AwAA //8T9+ixAABAAElEQVTsvQ90HMd54PnxLf+IikibpETJkiM6keSzvMEolqJIdqwshvKelUvsgSJZ sQUosbx3gNZOrGFyTjLcXfkBeUneIPtijF/OHMoORj5rlDUB2wJoGdyEoGwwMaALoDOGG4wSQDEg E3QAiuAF4GJoDMS6r7q7/nRP9Uz34N+Q/IYPnJ7q+vPVr6q+qvq6qnoTww/QhwgQASJABIgAESAC RIAIEAEiQASIABEgApcBgZWYMcKG9fNvcje5cZyb8AYZXi6DikUiEgEiQASIABEgAkSACBABIkAE iAARIAIAKzFjhA3r59/kbnLj5UWGF6q1RIAIEAEiQASIABEgAkSACBABIkAEiMBlQ8DPwBEkA2HD +vk3uZvcuExkeAlSMuSHCBABIkAEiAARIAJEgAgQASJABIgAEagJAn4GjiDChQ3r59/kbnLjMpHh JUjJkB8iQASIABEgAkSACBABIkAEiAARIAJEoCYI+Bk4gggXNqyff5O7yY3LRIaXICVDfogAESAC RIAIEAEiQASIABEgAkSACBCBmiDgZ+AIIlzYsH7+Te4mNy4TGV6ClAz5IQJEgAgQASJABIgAESAC RIAIEAEiQARqgoCfgSOIcGHD+vk3uZvcuExkeAlSMuSHCBABIkAEiAARIAJEgAgQASJABIgAEagJ An4GjiDChQ3r59/kbnLjMpHhJUjJkB8iQASIABEgAkSACBABIkAEiAARIAJEoCYI+Bk4gggXNqyf f5O7yY3LRIaXICVDfogAESACRIAIEAEiQASIABEgAkSACBCBmiDgZ+AIIlzYsH7+Te4mNy4TGV6C lAz5IQJEgAgQASJABIgAESACRIAIEAEiQARqgoCfgSOIcGHD+vk3uZvcuExkeAlSMuSHCBABIkAE iAARIAJEgAgQASJABIgAEagJAn4GjiDChQ3r59/kbnLjMpHhJUjJkB8iQASIABEgAkSACBABIkAE iAARIAJEoCYI+Bk4gggXNqyff5O7yY3LRIaXICVDfogAESACRIAIaAQWZqdhbtNO2HfDDs2VLonA 6hJYmD3j1LPrqoy4AGfPnIfC8jJs3rwZtmzfCbt2XQebq4yNghEBIkAEiAARqBUCfgaOIPKFDevn 3+RucuMykeElSMmskZ/li+dhemYetmzZYqVQLBat6+3bd8B1b78OtmzaJFPmBbhJ+y1v0MVlR+D1 7gNw+8c6INKShb9NPw6madvlWt7LF87C9LlFLJPtcOO+vXCNUzre/Fw4ewbOLWJ9374bbt5rInA5 FOsyTL16HHpeOgn/cPpNuPbaa/FvN9x4x53wvrvfDw9EbrkcMkEyVkHg7CtfhL33P22FPHhsCv74 w7dWEUvtBFlewHY7t4h9zLWw99YbYJunvxHt1zICFLDdXrsHbr6hWkPA+ueby3/h7I9hjsu+8xa4 eZfB7LC8AGfQQFHcfA3c/I4bXP3veksseOv1LNE3CX/y0L5AotjhfwInX/gz+O3GZyDnCRVNjcCJ z97tcaWfRIAIVEtgAsd1d/BxXTMf130CdmjjddGeq42bwq01gYvQe/DjEPvTHojGu+ClP38EtlP5 rTX0VYuft69qP2HD+vk3uZvcLDnxBn02iMBIqp7XFp+/etaWPcnmN0i2qynZS5cu2dktzrHhgQF2 8uQQm15cOwK5dINd5vVpNofJyPTXLsl1i3m4Q9XpTL5gTreYZ82i3kdS7Jzgb/Zdm67zY6w15td2 0b2uwyrb2hSepFopgcmeuNTb9cnBlUa34eFHUlGZn0Dt9rKr3wssFRHt9SCb1ogL/Ts/knIYRNng ana82K+MnDzJBgbM/YpIXxNJXur1LNo+JN0rXxRZf5sqU+84o+4KqLOVGZAPIrACAs540Gq3PkMZ PfZcOmbrj6g9rtPv0XWtE1hgaTGeo/Kr9cIqkY/3odX+vfXWWyzM3/LyMjP94cIJ5v1bWlpipj8o yQE5rBuBXLpJDna9AyP5uyVLxpf1KpGFIRZ1DALJIW4SWZuPLHdU8Ks5vl8bacPFKvOGHP0mpHND YoKDE6HY5chgnmUbxSSOf8dYR7aL9fZ2s3SyjTXWoxsalK60sg1XE65s34WJHtZg6Yp6ls2tna5Y L4qj6UbZFwVttwvrJdyqpDPPMmJgjeUW75ksiXUhl3YYxNjIajbe+UFWb9UVYMnBcyXplnMoTPSy WBX1rJDPyvKEaCsbnJxjRUxoaXGeTeaG2ODE5V9ny3Gje0RgxQSw3crx4GDl9iLHPvhAbTXVx4rz QREEIID9Q4MzpqPyC8CrtrxUa3Th4cIYXbhfk9GFu3mNLvy3yejC3cjwsoH1RypqaGBinl8szrPx wS7W5AzUuAGmdWBmA6W8ipIujEjuqZHKHW21ZGS5o+Hl8pq8VM6xzJtVf+Nsgo/2XZ8i64tHtEnB 5cegONGl5G9Iu56ei6wWCiUZF7fo+wogwDvsK+kTut3WH7rMJhcLrFMzvADEWd7TRF2Gl9VUzIvD Jf3KSutPpfCqPFvYsGEWWCn8lVS3KS9EoCoCZcaDpvYj2xzqxkrqwxS+Khkp0CoR0A0vVH6rBHXd ouHtqdo/MrysWzHVRkLqKWOsdHA0NyCfkkE0xcj0sg5l5hkgr1XnmBNPlytY1tcq/bUkKQcfjuEw PeIZghRyrFEzKsJluOpnflg8GQeWzvmvQb4cy28t6wbFXbsERg+pFS/c2J/GJR+u+rs4Ko0H1mrM y67dule88Dw0do65CmRernhpWJUVL5IfTuCEzgtj0JfhXVIG+VFgPcK4jYZhg90lSCTkhwhc1QQu aePBjuHKD+LkuM7RjdW336sa+wZlfl4Z5rH8eGlT+W1QUVSRLC+rav82wvByRR6ui+VmH0R7/nV4 4St/AV9+/gTM4UgLYA/U7Y/BU7/9H+CDt238wYCnDjdB5KksyhWDkYUX4W5HJCH/ay+0wJ2Nz+L9 euif/RvYf4PnQMDzE5i/L8FXnu+Hczx7Tv5aPvMpeOD2CgeWLs/Cia89B5neY5D753OwZ88eeNst 74b31b0PfvGXH4T6+2+XB6OeGeqFo6M/hh3v+nfw2IffU/I2BHl/H95/yL5/4fUTkD0+Djvu+BA8 vn8HPHfw9+ALL+XgZ/bH4Ut/9iTcDFNw+HNPw5dO/BDdDqDbJ+FmJ3si/zxHb7x6FJ47/HX47tAp K4+7f2Y//HbiADxyX+lhludPHYMj35+Cre/4BXjio/fAZiz/b3ylE772ne/DD+c2QeTBX4Hmp5+C B/b5sFk+BU1bIsBLJJ0vQMt7xNGwXJLV+5w6/ASW+/NYrGlYeLkFrrPk/Et4vm8IXn8Td6mgnC0H Pg0P3OpTR3m9/jLW66yq15H9DdDy25+y6rXitwB/+41vwD9gnD//kU/AfTfb+TnzylE4+oMzsHXP XfCJR+93ynkZXv3G83Dyzd3w6Kc+ArdsUQc7h8m5qtN2qMjBfhj94/0yitmTbXDjL39e/kbDC8yf aHEdMMzl/8mb/wh//VIvvIz1jn+24yG8N+37adix9Sew7R0fwHpWJ+vh6ye64fj4OdiB9e9xrH/F uTx0/eWzcKTvBPzw3B64/1efgN8/+CSsVpO/8OoXYcc99sGqB7qn4M8fcddFxV9l03s19WovfPXw EVmv9/zsfvjMH9r12hRe1u09WLcfxbq9MAW9L3wVur7+Xcids9vvuxv+M3zhs/vxWGOAU8degO// ywJs2/pv4Tce/6Dl5pWB/z7/2gk48r1xwIYKjz2+H3ahm55+mPZnxYdt8Ot/NwnX3PCL0PTI3bD5 whvQm31Oyrl79274Xx7+L9CBcnpb18Uzp+Cbz/8Vltu3rfaKSgn2vO0WuOvOOrj3Qx+Fx/aX6h6e ZrWfAqb3rex/s9PjChTT273zZvj590aM6dmspmDbNrttcE5LS9vgA489BnWmw1oNgi1juQ0cPQbH //41KOD9TXgY80037oW9O3n698JvfORuWVayzN9xL+ozZIntvvvLfwnZY0OAKhv7sofgKdQTH/TT E4b0/ZykTnI8RBLYbv9EtduzJ/8I9v7yMyq4od3ym4XZPPzNS0fh5Zzdbq3Dpm99J+zctoR6Gdvt h1W7ncB226+12+Xzr8GRLx/G8ujH8r8e2+1vYrv95Cq12wvw3MM74MkXRQbxO9cII4Xn4W6nIl44 dRh2RJ7CG+7+2AmBjcXWu19BvcurC8Bu1NUPQ/NnnoQHbvPpU7g37FeewH4FNT6kxxah5U7eQv0/ c/l+6Br4EdYz20/YesZYEb7661vtvDZ1Q/Frj0hd6U3V7gt4bnbAr/zWI3ArstDbv/Cv9MTtqCce tPSEuBfme2GiH17on1Djgv+E44Jv5+BncQzwf/0ZjgFwXJDGccEhw7hATyes/uRhhX7pOvaS1X4A ddGet7+zon6x9cRfQVffS1b/vOn662EPHtB813vNeknnd/Hsa/DX38Z+DNsDfznCNde8HfuxW7E9 /AS23uTux0T+ePi3/uePYKC3D/pRT/Cj6oEfQn/TXrgeq9mm6++Fj6OecKqtCGZ9T41gv/Ksu1/5 9B/E4dH797n86T8sLlmVP64Hrw/ARY8jzLUohyPI84d8YC70PNe7+38NPoZ6Xn+xhIy72vYnIwh2 IctPb7cBxoNSh9YfwnHdU864LsT4E8ULWn5nXsEx+Q94u90JD2G73adVBik/3lXtVvXvwShU8BVi /qDHxPuH49/5NpwYPWM52/3DTxvbw3r2fwBa/4DlV8Dy28z7o69gf/QdHEfO7YH3/9pvwv/5h5+E clOroOWnM6HrlRPgdb7aT9iwfv5N7iY3S068cUV+ZoY7WQTHEJhJ4188O7rh+VarA8x7ygvyCRyw lNiL5EhdTf6EBXchL/aNm9kAuA8XlAcv+hyoKA9UxXMtxHMB6RZLsKR4+uaURTzbzw65zsgA1tw1 4SmPOZb1hNPLMtYxYO1Z1wNJOWMZNj7W5VP+EdY3ra0xL06zns5DLJPJskw6IcPUNSdZNpthnZ2d eC+D99KsZ3h11h3Jcm/Ksol8F6sz1tE6t5yYUV5+MyOV6nVOQzLNWp24W5CvXf6LLCv2suIWtxG5 YGOSJSy/UTa0gkekMm88Luswy2Ymzti9dGmRdTV76lzJk/MiG0qrg0v1MpfXWj1j+Dy3o96JE8+L yQ1ljO0doIkNnlul7SGz/VqZRdihgdMac/9Lm3+Fep0qrdc8RlW3O9kktt96p1wlE/4bV8aJ9teX qJMcshN2IYv2ryTEA+WiojxaPVumKshpaH+lcvZUlFPIMt2flPK68iTyucqHMJ8+XiE9g64bTiqm uoxBz+0Y66mQpqte62WeKaMnUJ+dXhIYq/4u124ZK7CuFlFPnO+S5fRFNlip3bqYzrOUqHuxQ2Xa bSMLcLxCgHxrTzRFncLvWGpEhlUrXkpXoM6OZLQ272GB8cSzut7FKHm/kklj/+HuVyIB+pWRpLYV U5O1Uj0rTo9gP5Vh2UxStrtIYyv2YygD9mG8L+tMd7Khaan0mX54b3PXuGThvtBXC3n1hNtnpV9K jyVY+wF3Pvm4IN3kZqvLtBL9GUS/CN2p5yFIOPOpPWH7MZVqPqSesENW0NfYrywZtkdWzt/qHRLP y69yeqoPU0QYC93+9MBhrv3abQsfD2L7ccaDnYcOsd6RWVfMcsULjusCjz9lDOHKL2i7Vdsr29hp Q/nL5ANciPFD2PmDHTX2D4fCjOvWt//j40h5BlhTho0OdvqMRxrlsRBuZOHKzx2Wfq2UAK+b1f5t xIqXK/KMl+JUr6vRtKR6WW4izwa6UnJizQfOiX793QYrLfrw4aWixgmwaR82mx9yDtbDAWJaDRCL kz0l+RsdH2Mnuyvnj7PRDVKxeAfrHxpho8MDrDebYs3WPnicfGs7ROSgHCe2mrPMsLyvLWuWbmLg GIm60rUmLpGIHMzWdwzL+PjFUMp58w8PHznAegZzLDfgPvsmnXNbCErStNLGt0PhYDQV197wEO9R Rhs8QE3noU+ovNeR1jBvlXBlx/WjvJz1smyjrQOucN5yb071sJxT7rrx5qCs1wV5CKycYOBWH/38 oA4xq8FltfZhoQnDuSwuMcr+UHVaDaDbTzoDFKzPdhrqHq76cdWpfLZZ5p/zb0x0sO7eXpZNJ1mT nKjpy+e1vbmirlnfDaw1lZTtxypLvdzL5qLSTW0pv5NmLIFGNFPj8ETlrtdxu16f7JZbEbic6Vxp RCau3ECaxIlde4tTtzUjVnFS6UBcdeSRwv6pH8CZ6HPrQrecwdofj9VXTjRsJptL5bQlmWXJOlEn IuxAe5YN5bC9jwyxvp4sazuA4Rozq7hlYoYl5Rtu6lgc0xscHXWn11Sa3uxIF2tra2PJZJIlW1U9 DbJ9ZGbAbXSJxpOsq6eHZTs7WIuo11r52SxNh69HWWuJPutlKzW9qG2vohzwINgBp93ioeP2Aa/q nneL4Jin3TYlUnb+DrnbrarZ2kDX1W5jrC3V7tYTB3qVvrYrTBX/q/Sa0z0sJSf49eykM+NWZ7yg QVoJyrzjCUvvOuMJs95F8ZBZ4H6lzd2vzI50V1XPFkbaXbrT23+J30mh8y2KwuDOy/YAGy+WotXz f6B3qtRDCJeSvq+uvpQTjgsEu/LjgqD6E/WLbO8RFk8K/TJo6xc+NmjsdPVDdpbceskbrtU3HGP5 bIurLBpFe0i3+/RjdopePVGPesLq/zI4NvPREzzkYIfzRh3elnC81Dtkj5fEFje7X3GPlxhuYFd6 t87Su4NC7/ZmWbn82dKG/X+WtXvKQaYn9XxpOej1j+cjUPsLK5rwH2o86H6bXUndtvRa6fjTO67j SYcvP73dxtm4oQPQx4umw8RFlsN8VzN/4PF7x3Wyf9DHddr8gYcx81yb/s8yvMgHklo/hy9O4P2R q/8zjCPDlx/PIX1Wi0C1Rhcejgwvq1AK3qfq7SfdE4ridL/WiBJschXSrDYKta8eV7w4Az1eEeRn UR32GpOGCXz6qK0aSA6487d0+rgrf+5hknuS2nq8NPc8/bk5dwctFaDnKaeQVd7nEwdHfpU3rsRa GN9NP6afIxDBzgL95p1X8DU4Tx55nAXX4aUp95P4OW0S4FGAUg4xkI+lmPOwH1PHJ55ilQ1O9uXT reIky7S2srb2dtdkCmJxa4LVju78rxX9dHpYy3IKeVEyOdXkvHQJy0jIqa1gYMy9WqQdZRH8efJ+ 9Vq+ujrWaU1cCzn3ihAxCCjkHXd8+uwu/XCZE+Xe2NrBmsUgq6XXimS6J2EPRusTLJtyBqb6ZNO1 kiTGevJuScY6nXMoXMYaNaESE4tIc5bNiIEI1hdlaFLtLFyuTL6nWYfrsE5ezyMs2TOM6wPMn8Vx /VDelPsJlKdeC/FFTCV1piHFJhdtXZHPOBN0/oYop/3x+qLevNRgWDVQxHMgxAoOdQjyStofl1WU vygL4HI6QGT5eQ24ukGusU9kee2+cXAtDYCe9PQ2VVaAojqrSDe8GMOjsVO+Ph3rSHrQ1tnCryw/ TX/ytEvKPNah6TM8LFbqCU2flRXa/6bQna5229xjBZju9Wm3oq5huxUTZf6GL2+7lflz9R/ew26B 2e3W6f/mBjVjpM+DCf/sGO6oFS+xzjxTRhZMt9U2TJpXvBRYt7baR+9vefmV6F3BZGmSdTr9Snub NglvUP0KN+DxfiVTrl/Beib0V6VzJgqTAyyZaMV+S3uyHG2x+i/LWIjptSXaWP/kosVH1D/96Xnc sOplqN0xmEIjK3OklYF5qZOoZ7Z+wNWQ6CWvv92xDnURuo0dsg0JYlzAY6paf+qGwyalX0T+edzi 43Iroye4f5dfJwLLbUZfEdnAevOaFQ/95WU/5ulrXXqiTuoJJ2om9aer/8P1aPp4CXWEa0SI/YrU dZ7x0iXMn5xQOlxMeRLpr/hb54npmdIqdauy/VUp7CVst3w82OoxrovxoGxHaIDv9Kx0dddtHA9o 4zr3+NO9qqfa8nO12257xbjObzAp2m0Ty9lNvkoqIlh18wfm6h8aZP8gZJX9wwb2f2gpVytenPkD 749mhSHa1R+5x5HVlp+gSt8rJ8DrUrV/ZHhZOX/shUZUR4NL/viYXzRwEb1s6NjA9EGzuL9e30pR m7ca8byIQZdcsYDGGNmROvnzyuuXv8KEesVknacT9sah/5aTKX2SrHmQEwRtQKDyhiuL+uytGLqb eFOTcJP5w3iFGx+cZfG1ON7yGxGrYVyGCZz0iUNrueKMJuUARISXXHzywYrqAEk840XmUISXDiu8 0PMH0XYpp4hWyqk/AfDUa1M/KgdmWr2e7m+1jR2RVsafX+d1RpwTHLTSn3OeyEdT7qevQqag3yJv TZkh1q8N2PP4tq6s85S5IYMrrMQTcq0sBpP1tqwoFz/cU3wEfxG3+2m7ZwLXlFFGNScCFW/poZnF whwaGsv9FUrqn5CLb8EYeqFNyiyNDfjEcUj22Mq3lB/zlzU8Wh4WTy099ZrHoIeFSJvLYJxLOdxc WzlwKDGiXtvdlMkpQfjVzHE5WW5Mu+/paYVpfzxaPayQU5ZfyhkIerbUsEU1uQRc/Zfpz7uMVyI8 j39VPq4DnhtYpye9QGloBy+mKhy8ON6lVsckDK8xNulPLoOLpabPhHxST6DeVa1F3A33LdJyt9sm fPOPenU6b7c50W61NFX74u3WPcnkUpj7D4/BtKm03aoJf2n/WFws12b5PaW/bRJq0tCQ4vV9nqWl 4RS3a+Eu0uKYODRb0xOod9XkNIvmzNKPnEhrelf3dWlJ71dMMei+PdeYvli1EHysUpSTiBi27Yrt pzjO4lZfwPsDXPGoi6C1lWj7Sf1OVdeyrmN6YpWd7tbmrLIS9dF3XBBCf15yHQwds/RLoFLAvIvx Fzcocr0UJJyqt4ZDqpGayBvvx/TW4qcnRPnp4fT2rvPj+tr78e1XPPnrPD7m0rsiHpG++F31t1aX BE9vKy2JexXaX0mcQR00o6c+HvQLHnj8qY/rMLKqy684wQ5o7XZcF0wr2/qke+W07i3MdbXzB3f/ oNdcO3WZf23+wO/I+s7zuMb9n2UYk/0Bptek+iNR/1W7dj8IkPKjnKHan519+n8VCPAyqvaPDC+r UAB8eZ14+tZ63GX7t2LnhaMvsQ8+mFkF4TxRqAbrtqBKbzhgEIMuMQBZ0vMnt5TIENaFX/5cZ8Zo E1t36NJfUgHySbJ4oqd5Mw2sVd7UqiIZDw7uxFob4aaebOHrhhPa3u/GOEvE4ywu/hJxNRDGwZA+ zhdx8S0YrnNcHFnlfW2yr2XDMtoJ3n6TKaGEXeFC/pByVJJTm9y46nWQcncmg4tiJQuyyhVwEmV1 LhGWwm1lop304PKQCWfVhOmJZ5jsiXLnT5UXx9U+2UQ6JcutC8/YGRdP/WRZTLGEWCGDZ/SUds9a RyzDcMl0w0uUDcilTErq6X5hHOFnN2gryvjkSyzflgMYPvnQ/0onfSpm52p+nGUPalvjrPCNnu2D 5ev1gYMHlEEVy8q79VBwxSNVWZdaxmUJsDR/muVxiXh+wr3nnKFJrVUwxdfn8jG5qL8jKbE0vcHD rLyc8TLtjwuj5IywrnH3NKU4P83GcEtPqZxLrPeAzpxf17NERxfLTboLVMjvkK/yi6/28aYXZYlU aXreBGT6aAAXuqL8SgRlcOSTWr7Kz/sx6U/uRw3klT6T6eN9ydq1ksQbe7DfQifxdluYUKvieLsV hn7fdiu2iTUEaLcy/7rhRW330aWdPu4YjflZVC6FEKzdutuQSk/0pfPa6j++HW9OPphQ7U/Xu22o d3X+QtbFMfVAwzie0IwnHcPmE0FEXCXf2qpXHrcp/ZIwqNfE2Q4ir8KPX/gJbWuMvi1hus9Z7YQr tXomSx+CiHiDfsu6ro0BTG6ibiv5y+ul8vqzTHufcusXdz6WDHoC9VJZPTGp9WP2KlM9Ts5ftDW3 4WVBPpiw9IQeyLnWw6nmwLmIlYuo0wzjJdF+ubHD3f8VWW+VetAgXgAnn3Lget6nHFal/QWQzOgF jetCx4t27dd+eHhZPpXGda7xy0rKjzFXu+0Vo2rs+bV224vtdjU+1c0f9PaA/YPU/0oi2f5dXNa3 /7NWvMitRpXHkao/Wln5KQp0tRICvF1W+0eGl5WQd8LODx+SEyfT0zfLm/YEJKodrrcKyYeKQilq 8+RO30/Z0p234l4YEU/lzE8XLU+atVvP30SXWIJcx7rF+v8AEssJACpG/QmNCJoTWx00xSnzpln3 hVt9Uu2NFW5qgIWDaqkAvZMj72/3QbAiLtDSFDLyb3nfb6KiDZBFR6uHX61r2dFUklPjrZf7IfeM QomlPVGS5b4gnthGWHagj7VYRgGchC9MsoOOgSHeNcR6HGNXh1/cKpWyVyJvMeup8rR9YK+YmPH0 Iu3WihRZFqLOzKuVXA2eFRgiQfWE/5BWD9WEyr0SRoTCZeviKb3HUGdaXuo2uvD61sSG3fYDFbHn as57aHVTt/YEEQ+y1Z+oOOxL0+Npuus1T0by8qkzHlHkz8le0eaBtfY7h0Nr+g/fXiP92hfVtz8e XpQ/eLcTeVIp/TnH+lJKVhcXPKC7P8gBOqWRlnGZY8dSB2Rf4UqvgaenpjbGSFBXiKfh5XXFrDr8 ublLqw8qVpP+5HdlmfuwlPdFG1JRhr6SE90Ofui8026l0c7cbq2+ANutWBHi127lSjxNn7kGuj7y q3My3AZ2/nQyU7GPaNIODuc41FJyfduuWIXH21wq0+6cOaYMPbre1VfhuQBretd7JonlT18dhcaT UJ+q+iSVV/VAo0KquOrM7hu4/hEPRubUAcg+q2srxFpyW9ZZ1GNiLCHcou1qtaVwU/KvTH8y7HXK 6pdxv/aO4Tp89FLDwVI9MS/OSgMWpD2oVGcU6xa931AIpZ5wjV9QX4fpVwR0GW0ZLlb+SgLIkNVd lOOZYMc95bAq7a86Qa0HccF0vJ2AqLPhxp8rLD/UPWobq7ndBhy+VKRU1fxBjj/5OZU5YxpyXOfp ByTPdej/XH2KRw4htDqnRu+PVlh+InL6XhGBao0uPBwZXlaE3g6s9mkD851E4p7DqDPxSfQpK/Eq JB8qCmnQKJkQ2tHMyCd+aGRxDtz05o9XnJIP7jE25W9O23ogDqY1hvdEKAblpontpUv8qZCzQkVT WKYwwk0NptRETbmpp3UAzWwgP8Hy+bz8Gxsbk9ejY5NsUcu/iJ8f2MoHNN68yfuanC4/nsmU656H yUp+yg6Fy6nJL+KUcuIASwzM9DMJUtoyH5eMnnK3703KVQ/NCWfLAxoE+Oe486Qs0phgB61tQDHP 6gchUfBvkTduSOPpD8mVFXxAj4fldtqdr/AHIo/aBENMjFx5wymrPNvIVX5afcEOWvDiEovwanVH jA3qHrifpSW2uLjICoWC/OO/xV+hWP5pkUhDEpodkE/JwFllYt9TkyF+5hGv17wu6/VZ1PMcr9cy QvtC8VITFn6nJH0tnHVPmxSK9jvVrQwO3lUpfAAinpaHbX88aSknLyND3dbEM17yVTH92Q4W0yf9 jq7Oes78MUYQ0pGvFurH1V8NpvTGPJVFj1urr36r4yzvrgPS7bqvR8PLqC9utw1RPuK+NGIhS9P0 R/YfniXaInyYb1FuwgA+6Gm3Tc5WNambnDZ4SXsqLMKKdO26aW63rnrmM7CWWySwf9QPe7fix3Yp 2qix/eJ9d9tQ7U/1NYwtjavVKsr4ph6E6P1tSj3mFFm00/DoXXFTpq+tWvGujpJ+RCDt27qn17PA RhtljPaWiRa9damnn8s4Z2hhe0ugkfbSpGIjD0j3RhDyd0n9wfov3HRZS91U+VWjP4WYtn7B1Zem 9u7RLzqb4gLXSxhOf4hg0ktaeYl+TKRtfy+qM4P0/l87h0ZMUPX0eViTnuBnwnn1tehTxLfsV/Kl /YpIQ+YvABd3fqr7xcvhONfzJp6a3l1J+6tOMhWK67ZKhhfBj4cSdTbc+HPl5ZcTq4etdourXrV2 Kw9IV9mq+qqq+YPeHgwPuV1ncmrjOi7kevZ/umGePzTiPb9etlweNY7EM/OcocFK2x+Plz4rJ8DL qto/MrysnD+O59QTh6i2skKPemZALGGulTNe7Cds7oauDzSa2KiYiWkW5GhSPSHi+RPhZwfE1gp3 /vROTByqqnMR4XU3fi0G5aan2HOD6hwJOYnWw2jKVMRTfoDFFVyD8yQaD98rP+91iVpJUYv0Rcfo Cow/9EmEbtzw+lvpb9lBa2x4nIK/lBPvywkX1mvxZFlfMaTLYq7Xej2yJ3jN2XEr2KznTSvcUDAm 6pkecYhrMRkUk5vixAuuVQW9zqu8S/KoddAirJ7sac0I6S4/7em3MOLoAYt59UQIeYZ83qzHVPFa lJ+qv+4Jo+q4zfVahDclpNdtP3OAX3iVLrBuNGKm6p2JfkPGx1BVXfvjcovy9xoRTHnyurnlL7Lp fD9ra9K2HeKKkRDqwBt9hd9FdnrsOGtt1Jbtl0sP66t3UO6W30muoOpfJNFXIv9iXk1udf3JQ+tt xFTmle5XyLDrtohLTBaLctuNXVd6nFdWC3+8fC3dpBkVRFg9YrXND+MRYSwPWrtF95KBrqfdhtyg o4vgXPsZI0zbLbA/Foq3TH8rEtH7W69hxfKj6bbQ/Yqhnol0vd+q/qHOd1YEmXSpN5z4rfd/ED1g v9XGMi6IJ+nCZ/XfJfUHoxJuev0Rbrr8So+F15+lEtv6pbUxrH5xwul6CVeoSL2kTdb1cY5I39se ZLuupCe07Wzu/s89XhqTgogUg3/b9cesd72HvQePtZLPCjxXo/1VEsHvvtb2fB/iamH1PlqoD+22 rOerXn6anFAfZ23yDZ4J5n65hi5N+Ouq5g+abOb2oOZiG9n/uR4EuPoph9PSmBpHosFUH0eq8V4z W0n7C18iFEIQ4Lqr2j8yvAiKK/rWzorAU/hLd07MsUNyaWaU9RsOwVxR8iECi8EFGN4WkBdvgMGB j3s7AO6ZlE8JcDl1iYaf05ae1rPjM1pPjMpDLSfGrSee0/b9RJdy1iUthSMGeIWJXrmyxnpaqCks GUZ7GismZaYBlq6U1f5UXCGRdr9mmsso0y9oeUN3PU05oNEyJdL3KnjpBTt5sR86OaSrVuljVS4q d9Di7T1qxQs+xtDK3Vyv1Ratele9Vh2DPYnKirM38CmbyK9Vftry72ozKspAlecc6021WW/vaO3o kxOsEuOTttUI8CBg/XSmhVxWnkdjyekysGhnvJTIv8T6Wuul4Uc/u6Da/PFwov75xaHOKMK3gGiG rEr1WsS3uOiu19zdxQs7mVCf2T43P2syBazdp45XklPkv+Bpf7aczhuWnMm0SU4RXt7Dg1JnTQ3W 8jCvluDXd7gGPDJ8yItLi+fYjG96C8ow5ZOeJb82wUqP+kaGkulbt+y3woj88zfiuNqfpj95lnQ9 oacgwou25h3Ih8RheRdxqYnuHOvpwLd78DfzpOx2yz0KfzxNq+vRJkb8MGW93c6PZp2tO7beccup GV48K9XwmFtst85BzFhX4yt8hbHNQz1Z1vsffq84rc6Fs1e9qBUvlt6VqwAarbNmBH87Xr2/9RlP aIx4v+IOb8fi+7+hnlUOrxmZ5NsQVQrlwo+khdHVKTPk3+Q5mLtceJWK+aqk/qA30S+ruqfqmV5W lfSSSLFEf+IB6np7d8u/oLYCeg81R72khxPx2+F99JJW1lDn7sd4exDnqnnHSyY9IdJzvzkLy8XV /+nneWBZpUdEsJLvxUWP+QS5zJaMH0WweX8uwkvYb0fPu/mLSHSe+lt/tDNCcJzMF525wwdofyKJ sN/awy79Fezu9FWket3W9bXwIer5SsvPlP6I83ZQW3/Zbbexk28bXcVPNfMH7UG4aA9C/pJx3Qb2 f7z9CWO1WPGiyHn6I88B+bpeCtX+VAJ0tUICvE5V+0eGlxXCF8H1hgDRg2x4xpn9FKZZVlqDgdW1 HhdBNuRbDqxxcNPRM8BGhvBNMD0ZFm/QnsLg3nNxNIMQ0p2/BBvxyZ94TaYIx7/H5TkvtnJO9oyw OZzoLS7Os5npCdbflWItLSk2pc39hrVl54ks+p+bZYNdmqXamcjpT7llJ6RNwIRbpQEWP2OgXQ52 ceDdOcDESyqKKOdUboCl4sgI3+Kid3AifveTVZV7/b4eTvrQn7Ly7SCTjq/iIpsc6cVXTve60pPh Ql5IOTwDKBGNvO/piKaPHZRGBIgmVL1e5PW6Xt6LtLnP7ZiUB63xMrcPWbXTws7GedMQ77Cjq3D6 vTAQ6GUs8qV/C3+qzuiHkKIsiW42OTPNTma1PIt61pDRykFNqLjBJo8j5fn5eTY7NcJSzVo7wrNl vEfP6vKEuZ7oTrBoc4oN4JYgt+2hyHJd4jBKZF2yYmKaJX3q9RLW60lRr/GtP97xsF+dCCY3PtXX XolrD85amf2uMVMM1bU/HlNpuZrid7vNO1sgWzM9LD85ozEtsqmhDKt3yj1y8Jh6suyOItQv8ban 1k6e3ixTdq4imxzMSGOyaYWKTAif5ImDF+NdOTaDdXVychInapritDwXWX9Cq4eNKZafnWW5vpTb KMHzqOlKHlSyFEYOmbh9IfsPTziPt0A/RVzKYGoOJmWSaaq3Hlk6JNHFJmen2UBWawcB2u2Y025n JrHdtmi8sN06JxOZBQrsWn4ViNh2abcNbcULxl/S384672JZPO0aT5j6W0s87FfUAw/cPjvltO4l 3q/04KtrezR95smQVs8OdNv1bGpqylDP9HBqElFJD+uhrGv9lb9WuZkPmiwJF9ChtP6oeq7XPaHv 3PJXpz/nh+1VuW2ZXo9+WWKTqF/Etmxve5d6ydETStfbekLqJVzJpkwann7soN2PGdtDTD98d8mt J5pQT8zMWHrCZawx6Ak+XkrKh3E4Xspo46XCgqtf0cc988Md1piB68Exg9714xKwqEu8Cb0rykHZ gTjPTt9yWHH7K5EkoIOr3bawk6LdFgvGdivqbPjxZ3Xl58qF/mrwNWi3Iq3w8wc8NLqRjzvtvyj2 D1N+/YPnpQpSV6xD/2cZXsQDeXyAkEeLpHkcmTSMI1eh/ARg+q6KQLVGFx6ODC9VITcFmsdzR7Ql 406jF43f+sbG5Xk5iCmiNXWTitokn+OW7LfPoOEVRH3m8S0g2uDUFB6ftpjztygPUnXxcMURxT2M Kr15fTm8yx8qUxwgdKecp9yoIMU6kdFDzltTcIDO3bj8Occqbxpg6W48n0unzU/pXTJ7XksrFTWf FLh4ifTV03jvxFawNT3xk2l60hNhwn7LcpeTF3cMpvt2+Qev13p9WcypA5nB8xrxCe1Vt434RpOV foTs+pNKHqcuD/8t/PFBiqgz+lJWyVzUt+ZDrEvUMzz7R73tW00ySsKIsPikbGBG1Wee/ko+asm7 M5hoaGDRaIzVa0YV/vYh/hYQ8RH5L04Hq9fnPPVXTIzdqwZE7KXfIj1xZ3FUvWGKc2rpdr00VniT 39W0Px5YlqvHqOiVRyaEF2JA7l9+NudMTp826DGEuxYTqhWlhxNisdVIjyeiHRAqpOJlXifrop0X GQYNqOk2pT91vSRZGvQZj9t1XyRW5beIS0x0veUlfsuntlq71c+fkvkS+W1JY7sVZ4fgUmy5Aqx0 C2RJWDzY2nm7cIn+CJtNvhdfHELq7WusuPDct3ohM54po/d/fFAeZDwhFhLy+AQvIeew6A9lGlo9 MPQrMrxmeNH5mOqZSIvLK1b1irzK+JQn3yvX+T5xe3tcmPC+EeONUfFkXqs/OWeVjd5nCH3nlb8a /Rm0vXd69EvQcBnn/D2R7/L9GG8PTnvHhzuqH+Mrr8r0DfWoJ1r9xy9lw4o656lnwfM3X1KfRV7D fFefXvj2F0Yuk19R300rSWQ79PBcyfizmvLzyj3YId5UiLrFabfCj8iP+F39dxXzB338Keqi+G5O q/mDa1zn6d884yEuv+izvA8sqsub6h9k+QoZ5Tf2Rz5PAVaj/KqTm0JxArx+V/tHhpdVrUNFNpRV Z53ojamhrZvhG3Q3/KNOydYGYbyRR6IsnsyynHiyZpR0iQ1mDatOMLyVPzXnM4QusuEePNhMKhR3 +pGGdqYPInkE+d5Slo2tXdakWb61ojErn9xJyzi6Oc8H2UR33LJ868vxxJsrdDchcGF6yH3mgiZv PR4I2zOiL2xHGcXbaxr0FREiNn6/xba8e+67O6V5fPuB409Lj9efpvb+kkNPVezBr6Qc+MSLT7Tc 6fvLaafgX69jWB7Geo3beMQkMeFZJomPc+WEQxy4HDwnpT5HnYPeKi1zFf6gCctK61Qnj3e4l2Mj 92bc6sCNM2qCrg4344eiqcMF3fUY8BWozUl8Ai8qYKm4VbnMntQMWZ46YukZfCuOXC1lSKFSve71 1GsehbfO6NF6649+T13jG0qccx/44ZTyzCj04Be+kpze9sfTkm+Qcuq2St//6tK5UZY+2FJS7lJn R5tZdmgVd6vP5dghPGi65EmyKMtoC8sOVjh0HbeAiBUvUk4M71fv53Ld8omu8B9LZK2tOfqr1fWz TFSZZ0pWQHGaUt+FYO1XCuKNKX7yi3DyIMdG9bSe15+pfvV6epG/ltQxq92qCZfebrWVaoK7/Lbb 7dSqtls09Dir+5p8ts4og4O7fdh5L693K+9YXvDtVxqTx2UfKTjLb22rkeDKv8uXU4Flm+0HT7FD pVt1ZdzOhbf9z/ar1Uqd2kGn3nDV/NbHBcIGJ9watW0yQo80GuSvpJdK9Ce297L6pd5Hv1TSE1a4 SaP+NPVjLSX9mPsMMM7z3GiXr56Y0N4eKR5W8DCi/ArTg77jpWjTQWbkkmgpYxQOoAe5AEE/vBzK 6l0sh0E/vbvS9hdUSK8/Ph50Xkog9ZM9zmhM9rvardTHnvGliFHqc8/9qsvPiViEn1nDdivyYH+H nz+Y+gcxrhMrr/jrzsWhtTwdyQtXwvBxsvcjea9C/4evsMKXN/g9zI6wlnZcuebTHwn+odufN0P0 u2oCvAyq/dsIw8smnlPsyK/cz8Xz8PrkaWDbd8LyfAF23LIPbtm9/crJb+E8TEydBnDyt/Od74Kb d10TMH/LMHtmEubml4FXg5/6qeth195dsOOazebwyHLih/8Cy5u2wm7kuHeHjz9z6KpdF2anYHqu CNu3bILi5mvgxhtv9Jex6lQ8ATGvU6dnoLAMsAXZ7t17M+yopWrjqdc737kPy72WBPTwDPOzMAuv T81BETbDHqzPN1xXrp4twHMNO+HJHkwg0g6Tr/wO7C6iSlu+CJt37ILt5YKGkanE70U4+8YkvHHm LPzr/3ce5i4swaZtu+HdkTqo23dDiW+Tw4Wzb8CP3lyCa7cAFLdcCzfduBeu82t7pgjWyW392t8y nD87C+f+dR6Wl4tQLAJcu+edcNvNu9Yop5jeLKY3P49pLWGam9Y2vWXUn+M/gsKmn4Ibpf5chu6W e+Bjz+YAGjIw/61Pwo41yu2aR3vxLPa15+x2ewu227L9A7bbh7HdvohSRZIwOfQ7sOetTcCKhTVu tyukUJhD3TRt9bdFHE+E1rsYfurMLBSwbm+5FvuVG2qsX4Hz8MWG3fA016f1aZh7uQXWqvWtsCQg vP5chrnZGTi/sIDt3dYv21G/3F5Rv9h6Ym5hHpaWQugJ2Y9tCTdeQj3x+sRpWITtcJPs/1BPPIV6 4jDqiRjqiRf99YStr5ex72OwvPVaHLvsrTBeUvkTXNZD79o8i6h3sTkFKgesMSttf9VWOhxnT52Z AdweBVuvfRvsvRHbbdBhdsg0w5cfTwDb7cPYbrk+Xbd2G3b+cBbnD2+u+/whJH4cOy7DxULB6sc2 OePIMMOy6sovtJQUQCOwEjNG2LB+/k3uJjcu9pVveNEKhy6JABG40ghcwAncDnsC15DGiWvL5Ttx vdKKhvKDBC7CyRe+CW//978OdTeokTrvkDdt2gTnXzkMu+9/yiLVkM7Bt1pwU9JV8MGVavBVbnjh E3xqtzVT4qeea4HIk89a8qRG5uCzd9eq2aVmkK2SIBfhb//qW/C2Bx+Gur1KT4jIvXrim80/Z+kP cZ++ry4Cov8QudbbLb5ZDZ6+h9qtYEPfVz4BPwNHkJyHDevn3+RucuMykeElSMmQHyJABGqUwAJk cMXLp/gELoaGlxeV4YUrPT65pQ8R2DgCF+Dw/h3w1MtYPeNJ+NSvfwjee+se2DT/L/BKXyc0/oE9 ycXHlNA/8zLs37txkq5vyhew3e4wtlshB7VfQWLtvqdefQXO7bwJ9hTfhBNdX4BPfT5rJ9bcBYvp R2A76c+1g++KeQEOR3fCU99FO+SBdnjy4Qd99EQU9cSJq0hPuCDRD4fAG9huz2K7vX75HJw48ueu dls4/Chw0x3pT6ouVwsBPwNHkPyHDevn3+RucuMykeElSMmQHyJABGqUgJrYQiQFc6OfhbeTwaVG y+pqFAvrZxQNL98tn/fUwDR89oGby3u6ou6qiaZot+IZLR+skMF0PQobtyfchdsTcPeK61PXChP/ zzNwW+nCC5c3+rGaBLR+rEy0Hagnnr6q9EQZGFftLZ92G2mD8aH/gu2W9OdVWzWu0oz7GTiC4Agb 1s+/yd3kxmUiw0uQkiE/RIAI1CiBZcj1fgVe/MEsvP29vwaffvRuPBnG/OFKkCZ0ZjbkunYEli/O wsjffAd6vn0choZOwcs5e6YbiTbBo7/5MfjER38Fbt+NB/1cVZ8inDraabXbnXf+b/CZR+/xbbdX FZZ1zewFeOGpX4JGfm4IfiKRGK7A+j34Px5/wHiuC+nPtS2cZTwTZuQ41xP9MDg4Ct89dcouF0tP PIZ64qGrUE+sLfPLM3Zsty0fgMZn7fpRVxeDpj/0b7cij9R+BQn6vtII+Bk4guQzbFg//yZ3kxuX iQwvQUqG/BABIkAEiAARIAJEgAgQASJABIgAESACNUHAz8ARRLiwYf38m9xNblwmMrwEKRnyQwSI ABEgAkSACBABIkAEiAARIAJEgAjUBAE/A0cQ4cKG9fNvcje5cZnI8BKkZMgPESACRIAIEAEiQASI ABEgAkSACBABIlATBPwMHEGECxvWz7/J3eTGZSLDS5CSIT9EgAgQASJABIgAESACRIAIEAEiQASI QE0Q8DNwBBEubFg//yZ3kxuXiQwvQUqG/BABIkAEiAARIAJEgAgQASJABIgAESACNUHAz8ARRLiw Yf38m9xNblwmMrwEKRnyQwSIABEgAkSACBABIkAEiAARIAJEgAjUBAE/A0cQ4cKG9fNvcje5cZnI 8BKkZMiPi8DC7BmY27QD9t2ww+Ue/EcBzp45D4vFImzZsgW2bN8Ju3Zd5/s60YWzmB7D9PZWm15w ycgnESACRIAIEAEiQASIABEgAkSACNQ2AT8DRxCpw4b1829yN7lxmcjwEqRkyI8kcPaVL8Le+5+2 fh88NgV//OFb5b3KFwU4+cJ/hc80PgOnPJ6jqRE48dm7Pa4As0MpuPH9ccs90TcJf/LQPuCVedOm TSV+18rh9W8chNsf/VOoa87C3x1+HFZm/rkIvQc/DrE/7YHogW74zp8/AtesleAbEO/F82dhZn7R Mqj5lZNwX15ehs3bd8PNN1xnSbp84SycmSvA5s2brd8MDXOb0DCHkcGOHbtgxzWO+zqX/wZgpCSJ ABEgAkSACBABIkAEiAARKEPAz8BRJoi8FTasn3+Tu8mNJ0yGF4mfLoIQmOo9AO+KdVhe65OD8PLv 3x8kGPpZhhN/9L/Cg8+8bPRfh3HlDHG9cfR3Yd9Hv2CFibYPwYnP3WcMv5aOpw43QOSpHoBoGuZO tMCuFSW2AIcf3glPvYiR1B+CuZefWmF8KxJmlQNj3vZj3sxFbE4rkoK50c9aDF794n6452n/wJGm g3A42Qr332wbYMwRkisRIAJEgAgQASJABIgAESACVzoBPwNHkHyHDevn3+RucuMykeElSMmQH7nK pDDRC5+4Iwa4XgOyuW/A43XBzBCF/Atw7XsbbZLRVhh67nfgnlsx7MUFODM+Bj++9t1w320qLl5h +aqWi68fhY/f/lFMrx7T+2bg9FZaZCJ9Hs+pw01oeMlahpd5NLysbMXLAjzXsBOe7MGI0ZDjF5+e /krzsn7hMW9oVHqSG5WCfjTDi+RcNmwjDM09D/epqlLWN90kAkSACBABIkAEiAARIAJE4Moj4Gfg CJLTsGH9/JvcTW5cJjK8BCkZ8lOWAK9clbb+nDr8BBovnsd4mmFk4TDcbe8useINEr6sACu8WSl9 KXsZQ0lwETTjRH0aFl5ugZ8KwC94/Bvrs1hYgAsXl6UQmzefgy988A74fA6dou0w3vMU7MEtRvKz ZTu8/ae2WfVHGV4aYGDuW/AAN64UCzD12iA8+/SD8CfOYpimTB6+9sn3yCjogggQASJABIgAESAC RIAIEIGri4CfgSMIhbBh/fyb3E1uXCYyvAQpGfKzQgJ4rsmB+yDWgbPv2CGYf/GpFa4aWaE4IYO/ 9lwT3Pnk2qx4WfnWpZCZWXfvF3CFzw57hU8MV/i86L9iSBq4IAYj8y/C3frSooUhaNj5flz5hFUI zwN60XAe0LpnjRIkAkSACBABIkAEiAARIAJEYEMI+Bk4gggTNqyff5O7yY3LRIaXICWzBn5yx16A wX9ZgG1b/y18/PEP+h6wev61E3Dke+MAO+6Axx7fL88D4QXKV5m88epR+OqzR+DlwRycQzn3/Mx+ +PQfxuHR+/cZpT5/6r/Dke9PwtY9vwBPPHoPbL7wBhzNfhWOfP1lyJ07B3v27IE7Yv8JUrjCQBz6 ej7fD0cGfgRbt6qVLRcvboVf+o3HoG5XkPM2lnELyhZ7C0pTNxS/9gj8mzKrPER627bZWeB5XVra Bh94TKUn8m/MJDpOcS6Hj8B3h3LwJoa//rYH4dN/oLj4hV9emILvHe2D/r//RyhgPNt374bBZ56B 7/KEcMXLAm410hbrcNeQHzREPIyGCL4dB+MrYHybz78GR758GLqOnYB/PrcH7v/VJ+D3Dz4Jt2kJ nXnlKBz9wZsYaCc89FuPwK3bVFnoAvD68vXv/hNs2vluV33R/QS6vvAavJD9HixhIbCtt8HHHn/A lW/GivA/jnbB9+eWMLqb4NebHoIbjFXhAmTQ8PIpZ2uV4Gfi7zK8LKDhRcs/wFn44v69wI+AaUDD yzd/530lq6wunjkF33z+r+BI37fhh3N4+DLW5T1vuwXuurMO7v3QR+Gx/e/xfXNWICbkiQgQASJA BIgAESACRIAIEIGaIMDnE9V+wob1829yN7lZcuIN+mwAgb5EhNcU6y87vmiU4NKleZaO2n4AWtm0 y9ccy8brZBwiLvEdSw2wpUuXXCH4j5FU1A7TkGGTYz0s6sggwlnf0RSb00KOJJWsur/koO5LC+Bc Lp0eZpl0hmUzSVbvpBNpamXZbJZlMhnW2dlp3R+cdud/pN0nvaHy6dnJIpcD5vBcds6lWCqq5ZLv SfrytLmk2bxP2ODO86wz5pRpYyfLDWV80mxkg+dU+U32xKW/5q5xn+TmWUbEjfXltKH8fQKWOhfH WUKrG42doy4/swPtUh7AfJxz3bV/XLLSX1AyRcvzy6UbnTgb2AiCtsPbcS1Ndsn0TPk/fbxC2dV1 uOq0QVxyIgJEgAgQASJABIgAESACROAyIcDnCtX+vfXWWyzMH76NlZn+isUivojV/be0tMRMf/zQ VPpsAIHiZI+cSEYS/S4JxISzkM9KP4k+t9llKBWT9yASZ71DOZY72c3w+Frpns6VmglG5eRW+cOl F6w9k2XtLY5Rpv4QW9AkmhnpYm1tbay9vZ0lW5tl/KmR8oaQ+ZEKA/1h2AAAQABJREFUk2FHVq8B Z2bYTi+ZTLL2tpbA6XGRBzsMXAa6WJOLi547O6MuQwL6jcbbWVdPDxqNUqy53mFVwXCgIStzicaR Bp29uG5gbal2FtPkhHiPZiSaYgflvTibMFiPilO9klW8d6qMDAFvzfS7DHNpUd6zuvsBlvfIIuqv ncqCMjRV4JdLNznyN7KRgi7jNEtJZt573N8Ma48IjnUsnsyyoRy2h5FB1tebZa3xegZNGVed1mOn ayJABIgAESACRIAIEAEiQAQuLwLVGl14uDBGF+7XZHThbl6jC/9tMrpwNzK8bFj9WmTZJjFZjLHS xRxF1hMXKzfsibaY0BYmuuUEGw+8YKf1PMwNqcm7a+Jue1KrCpy0Mfyks+Akn3FWHMTMKxOs9Is5 acSoZHgpTA6wZKKVJZNqtQZEm20DDjeqoCGnLdHGjgsB9HyIay29jmHTugrhkbHFcbUqAg+Uca8Q cnHpZUsqGAYcZc3SqBFh6SG3kSufcQwCaJAqNWXpEQW5LjW81DVn2YwwXqCcykgUY8Nagvqql7hh 1ctg0jGcQRMbdS8iCiKY0c/MgG48w1U4M+MsJVdhActOuCwkhji0VTgV+Ol1Mz0wyvL5PMsP97G4 ll6ib7I0jflBVeeb+krvOy6i/fh6oBtEgAgQASJABIgAESACRIAIXBYE+Ni+2j8yvFwWRbx6Qs6P pKQBxbuVg+GqgohjDGhK51yJqpUBOPEdFzN25WUk1WDH69kyxH3oYSHSyvRpbE5sQ4q4txqpmPGq MCINA5UMLypcUW43afDkRfnxuVocDpyenresYUnIiFgl5OEy0a1W1SR6dCK2TDJeXLFRulbGR25f Z23rDS9f3KbjXTc01C4MKG7DCytOsAPSQJRgE3oaaDwSBpto+0n9zoqvh0R9kmnbRrt4l0sCn3Q0 Q1MFfpKzJx2xvS3Z55NeIaet9IqxTH+eVTIH+QhLzkSACBABIkAEiAARIAJEgAhcBgSqNbrwcGR4 uQwKeDVFvHTpNGuVWyTcq1qG5ZaZBjbgmpkXmX4+DDTGWSIeZ3Hxl4irp/8QYyMeS4Ga3EZYl+ds meL8NBsbxZUGEzP+2UTDi9jOVGkFiopEbTfBg1GlM6/0FT+aoadj2AXCE7RaLvPayqMEGzfIJJl5 tmB5BAj4U7EAqPeUrX2uyXR/q2OQKy2/iawyEsU1I9F0X8IJU8d6JkuNcQGF8/E2x9KNYnWW/R1N 9LJFA6vSMkVDk9gm5OHn9Ss5W4aXOhaRbQPTjCRLDFQqfJH1xt3ycbaJVBfLTZWrMz7ZJWciQASI ABEgAkSACBABIkAEapoAnwtU+0eGl5ou2rURbqr3gFz10nrcMXjgE3yxeoGf/6ImmFwGPHBXTGR9 VgaIFQL87JZBbasKDy23c/hsJ+J+vB9X+ovhV7zwQ4IzzqGv+Cpgb/Tlf2uGnvIrbJCLPFjWOwn3 /ta5zLJUvXO/ucu4UmK009mCVeGMkvIZEXcrrwDJvyCMK6WHzLLFHGuR5Z5g9kkuc2r7T1PWmAeR ejXfvPwLnvN6ZF2tGKF2mHAFfur8ITvfDDeLKcMksJasz4oXS4Y51tehbWmTjLBsYwnWP+FpCBXl Jg9EgAgQASJABIgAESACRIAI1CqBao0uPBwZXmq1VNdSLn2bhDMxnexSE0jvqhTdiAHQzAbyE2xs bMw+D4OfiaH9jY5NMu9RH6OHVmZEuBRi64/CpibfsY5h5RzkymPocRmBXOG1lRUWl3EjF84ql9e4 LKgzcfy2QfWJ1RS8fAyrPFxiVPjhKj80fnkWJFmh5ZYoXLHkNZzx/OfEmTNoXEj0zzI2qQ5hTg6U Wa1UQTb/25OsVRinpEEjyvoDJeU2NJXjp1a8qHwv5vW3PsXYgPamJ5O8fNVWfzbFYvpqGUfmbH7e Y8Q0xUBuRIAIEAEiQASIABEgAkSACNQ6ATK81HoJ1aB8aqINrAsNA/Lw0gbzm1jUNqSWkjfKVMqe nNyiEcE06a8Unp/xIrYalV+BosekJt/6ViPdh+91iPTk2TYQgkshLw/WjST63IfuolD6m6WgWmau zGlbjRxDm+v20pha0YL3jRtlNOMXROOsLS7OhEm4zuxxxVv1jyI73lovV2Wp1VS4kiTSFiA9d37L 1TlZN0GseLGFdqXf0l1SRuasFdl0vp+1NYkDqlFeXNG02puwzGmTKxEgAkSACBABIkAEiAARIAJr SYAML2tJ9wqM21rBMdMnD9LVJ7bJQfNbfKaPHZQT4cZD/itIFhdd7+6x6MmtRs6k30o/DFdt0p8e Lb+CQMWtDC/eFS/KT6kQ1j3N8GJ6PbYeSp1zAqwxPeK7uqFQUNNvvgJFbVFqZDntVNal08e183Jw 4m4ylOgCBLpWLIBv93KtoMFzalqFEQWYfoaLN+qRtPbabGdFR2PGfQhzObbe+Ey/eXh13gw3XPSg tyLrbsFrJ806NFYpmu5Y7PTVaicTP11GWTf52US4M0jew+1VYusdTzflfQXY4hybNVh0RPrSkOk5 VNktLb6UOtfPMuk06+of882TNwz9JgJEgAgQASJABIgAESACRGD9CfCxfrV/tNVo/curRlLEV0c3 q8msPaltc78O2SXpNEtqWynimQE2hwYDXvGKi/NsMjfAUgfwST++ncg7H5WrCtCI4L1nT1RdCZX+ 0Awh8e4cm5mZZpOTk2xm3m/6zaNQk+9qVryISXe8K8dmZ+30Zg3p8cOKk3WKo+DCJVgSXPgrupGL OvGjyPoT2qqIxg6Wn51luWOpUmOYgRmPO9xHWwGCK0byM/NsYWGBzUyOsI7mOmnQgEg7K7uTZ36I NTjGD7u+RCtuwwknJ/qe1g2CcbW6ajHP4lraiV77TVDm+qO9xakCP7kNjq948VTO08fFgcO8fO2D qEV+Fpy3g7V29rCxyRmm7GpFNjWUYVFHVr6iya+WFie1V5Gj/4P97leKi7TomwgQASJABIgAESAC RIAIEIGNJ1Ct0YWHI8PLxpffhklQyOlnWQBrLvOqXl5Ziq5JsTI2iJUI1nddR8lWFWl4qS81vATK vGZ40dOKJIfKBF+Qq0r44brmCbpPcG2FjTu9QWOA4vSxUoOJZiQwcSnLsj7B0m1NtkEEmSmDjTH5 AI7z7FDFQ4Ab2QAe3eL3Efxcr3mO+xsV/OIp617Ec100I1Y2r5YC8fQXx3VDBb5JaULdd8erHQbt 8BPyu/3przqPsaES0Gi8096sFOtQ5T8/3KEMVt6y1n534gotv4/+andeR6Jl67NfLOROBIgAESAC RIAIEAEiQASIwHoQ4HOKav/I8LIeJVSzaeCbaeSEvMW15cVP5MXTg6xVP8NCm2RGmxKsZ6T0qX0+ 22xPUmOZ6owI2mG3uiGksXPUT0x0X2TZFntVSQy3AIX6+Bh6vNtq9DgL00Pusz10Lo0J1mvgMjfa JVdGiHzFEllr1dFkl8OsoUpmunDIotthIdJR3xHWnOxik342DFc8uDXmuHiFNLDOMX+jgidYoJ8T 3eqA53g2bwwz3qPSh1inz9uUCqyr2VlRVIGfOjTYp/7P9mtl1MhGxcnRczl2KNHsb3Crb2bZIXtV jjEj6LiEhkxVDsDay1m+/CIhdyJABIgAESACRIAIEAEiQATWhUC1RhcebiMML5s4FZxw0OcyJnDh 7Btw+lwRtm9msLz1Wti7dy9ct+3fwKZNmy7jXK1MdF6tOZfpuWWLS3HLdrjxxhthxzWb/SNeXoDX JyZhEa6FG2+5Ffbu2CL98vhWnefyMlwsFGB50xZgxQJs3rELZbWT9Kbn/Q1wHr7YsBue7kH/0TTM nWiBXVJatDSthbxa/LV5uQznz87C3Pw8LC0twfLyJrh2zzvhtpt3BeJxfmIE/t83/hW2vP02+OD7 bl398q5NaCQVESACRIAIEAEiQASIABG47Ajw+U61n7Bh/fyb3E1uXE4yvFRbWhSOCGwggVymBe76 1LOWBB3D5+Dpe3ZvoDSUNBEgAkSACBABIkAEiAARIAJEYP0I+Bk4gkgQNqyff5O7yY3LRIaXICVD fojABhOYGhmCc29/B+xZehNe7uqAJz//vC1RcxcsHn4Utm+wfJQ8ESACRIAIEAEiQASIABEgAkRg vQj4GTiCpB82rJ9/k7vJjctEhpcgJUN+iMCGEsBtRXfhtqKcR4hIK0y88gzcdo3HnX4SASJABIgA ESACRIAIEAEiQASuYAJ+Bo4gWQ4b1s+/yd3kxmUiw0uQkiE/RGBDCSzACy2/BI3PnrKkiERi0PQH vwf/++MPuM518YrIG/2qn0vjTYR+EwEiQASIABEgAkSACBABIkAE1pmAn4EjiBhhw/r5N7mb3LhM ZHgJUjLkhwgQASJABIgAESACRIAIEAEiQASIABGoCQJ+Bo4gwoUN6+ff5G5y4zKR4SVIyZAfIkAE iAARIAJEgAgQASJABIgAESACRKAmCPgZOIIIFzasn3+Tu8mNy0SGlyAlQ36IABEgAkSACBABIkAE iAARIAJEgAgQgZog4GfgCCJc2LB+/k3uJjcuExlegpQM+SECRIAIEAEiQASIABEgAkSACBABIkAE aoKAn4EjiHBhw/r5N7mb3LhMZHgJUjLkhwgQASJABIgAESACRIAIEAEiQASIABGoCQJ+Bo4gwoUN 6+ff5G5y4zKR4SVIyZAfIkAEiAARIAJEgAgQASJABIgAESACRKAmCPgZOIIIFzasn3+Tu8mNy0SG lyAlQ36IABEgAkSACBABIkAEiAARIAJEgAgQgZog4GfgCCJc2LB+/k3uJjcuExlegpQM+SECRIAI EAEiQASIABEgAkSACBABIkAEaoKAn4EjiHBhw/r5N7mb3LhMZHgJUjLkhwgQASJABIgAESACRIAI EAEiQASIABGoCQJ+Bo4gwoUN6+ff5G5y4zKR4SVIyZAfIkAEiAARIAJEgAgQASJABIgAESACRKAm CPgZOIIIFzasn3+Tu8mNy0SGlyAlQ36IABEgAkSACBABIkAEiAARIAJEgAgQgZog4GfgCCJc2LB+ /k3uJjcuExlegpQM+SECRIAIEAEiQASIABEgAkSACBABIkAEaoKAn4EjiHBhw/r5N7mb3LhMZHgJ UjLkhwgQASJABIgAESACRIAIEAEiQASIABGoCQJ+Bo4gwoUN6+ff5G5y4zKR4SVIyZAfIkAEiAAR IAJEgAgQASJABIgAESACRKAmCPgZOIIIFzasn3+Tu8mNy0SGlyAlQ36IABEgAkSACBABIkAEiAAR IAJEgAgQgZog4GfgCCJc2LB+/k3uJjcuExlegpQM+SECRIAIEAEiQASIABEgAkSACBABIkAEaoKA n4EjiHBhw/r5N7mb3LhMZHgJUjLkhwgQASJABIgAESACRIAIEAEiQASIABGoCQJ+Bo4gwoUN6+ff 5G5y4zKR4SVIyZAfIkAEiAARIAJEgAgQASJABIgAESACRKAmCPgZOIIIFzasn3+Tu8mNy0SGlyAl Q36IABEgAkSACBABIkAEiAARIAJEgAgQgZog4GfgCCJc2LB+/k3uJjcuExlegpQM+SECRIAIEAEi QASIABEgAkSACBABIkAEaoKAn4EjiHBhw/r5N7mb3LhMZHgJUjLkhwgQASJABIgAESACRIAIEAEi QASIABGoCQJ+Bo4gwoUN6+ff5G5y4zKR4SVIyZAfIkAEiAARIAJEgAgQASJABIgAESACRKAmCPgZ OIIIFzasn3+Tu8mNy0SGlyAlQ36IABEgAkSACBABIkAEiAARIAJEgAgQgZog4GfgCCJc2LB+/k3u JjcuExlegpQM+SECRIAIEAEiQASIABEgAkSACBABIkAEaoKAn4EjiHBhw/r5N7mb3LhMZHgJUjLk hwgQASJABIgAESACRIAIEAEiQASIABGoCQJ+Bo4gwoUN6+ff5G5y4zKR4SVIyZAfIkAEiAARIAJE gAgQASJABIgAESACRKAmCPgZOIIIFzasn3+Tu8mNy0SGlyAlQ36IABEgAkSACBABIkAEiAARIAJE gAgQgZog4GfgCCJc2LB+/k3uJjcuExlegpQM+SECRIAIEAEiQASIABEgAkSACBABIkAEaoKAn4Ej iHBhw/r5N7mb3LhMZHgJUjLkhwgQASJABIgAESACRIAIEAEiQASIABGoCQJ+Bo4gwoUN6+ff5G5y 4zKR4SVIyZAfIkAEiAARIAJEgAgQASJABIgAESACRKAmCPgZOIIIFzasn3+Tu8mNy0SGlyAlQ36I ABEgAkSACBABIkAEiAARIAJEgAgQgZog4GfgCCJc2LB+/k3uJjcuExlegpQM+SECRIAIEAEiQASI ABEgAkSACBABIkAEaoKAn4EjiHBhw/r5N7mb3LhMZHgJUjLkhwgQASJABIgAESACRIAIEAEiQASI ABGoCQJ+Bo4gwoUN6+ff5G5y4zKR4SVIyZAfIkAEiAARIAJEgAgQASJABIgAESACRKAmCPgZOIII Fzasn3+Tu8mNy0SGlyAlQ36IABEgAkSACBABIkAEiAARIAJEgAgQgZog4GfgCCJc2LB+/k3uJjcu ExlegpQM+SECRIAIEAEiQASIABEgAkSACBABIkAEaoKAn4EjiHBhw/r5N7mb3LhMZHgJUjLkhwgE ILAwewbOb9oJt95wXQDf6+eFN/5NmzbJBC+cPQPn2A7Yt3eHdKMLIkAEapOAaL/UbmuzfEgqIkAE iAARIAJEYGMI+Bk4gkgTNqyff5O7yY3LRIaXICWzTn4WcEI8t1gE2LIdbrl5L2w2pMsLUp9EG7zA 690H4faP/SnUNWfh7w4/Dvr0ulx4ES6C4f7WE86UTm25XYAXnvolaBwEiDiC8bye2vQg5F75AtRd YzuWy/9K8nP2lS/C3vuftqJI9E3Cnzy0byXRrVnY2aEU3Pj+eM3LuWYAKGIicBkSmB36Irbb2tcv lyHaK0jkZZidyMOrPxiB3Ng/wY/PFwC2b4d33LQPfvbn7oUP778brgswflgtIBM4DrkDxyGRFhxP pN3jkNVKg+IhAqtLYAFeaPkgNA4B1GltJQf7rXHkz23zG39v7PhzdRlQbETg8iLA53XVfsKG9fNv cje5cTnJ8FJtaa16uCk4sOld0GHFG4H+2VHYf0N1iZw6/DBEnnoRIJqGuRMtsCtgNNWGCxj9Gns7 D1+8azc8nfMm0wCD89+C+3Xrk9eL+L18HkYG/wcswla47d774GbHWCNul/ue6j0A74rZpRdtH4IT n7uvnPcNu/fG0QOw76O1L2dVgFZQflWld6UHQp6vYnv4n7AF28P9odrDlY5mvfP3xtHfxXb7BSvZ +uQgvPz796+3CJRejRO4cOow7Ig8VUbKZhiaOwz3BR0QlIkpyC05nqjHccjLwcchQeK+LPyQ/rws iskt5ByOI/dUMY5chfGnWxD6RQSIQEACfgaOIMHDhvXzb3I3uVky4Q36bCCBS5cuWakXJrLcZCf/ 4j2TTNwrJ57JTy7daMdTf4jNlwuM9/TwKly6YrgK0W7I7ZmJHMvl8G9snA1k4w7LGBspA0HPP5sf ZFGnDJKDcy42fhkS4QsTvSxmhY2ybG7O8i7u+YXdCPfF8R7WIOQcDZbHjZAzaJouxlWUX9B0rkZ/ lzSe7UN2nfZycPH33qTfKyKgs1X6pV7qFx657mdFiVHgy57A/EjK7vMiMZZIpllXTw/ryiRln2aN L2JpZm7J1WW/XP0bPeSMQ6JptlBd9Jd1KNKfl2fxzYzb48hR1ziyoew4kue0mvHn5UmIpCYCtUWA 90PV/r311lsszN/y8jIz/RWLReb9W1paYqY/WvESxCS2Dn5OHX4CV6k8r1JqykLha49DiEUXgE3B 2oYk48IVLwu44iXoiSO5dBPc9R+z1kqZMOGU0Bt7JfLPpbj42nOw/c4n8aoBRnDFy90BVrywwgg8 ce0vABKA1MgcfPbucI8G9fS5DPRZXwIrLb/1lfYySO3iq/DE9nuAa6WO4XPw9D27LwOhSUQicHUS YAtT8OoPAe6K7PNsUz4DqYZbIN7DuYRYARoSo7f/08ch8zgOCdAFh0yxxr2T/qzxAqosnhpHxnAc +WLZcaRe/1W44OPPytKQDyJABEwEeNur9hM2rJ9/k7vJjctJhpdqS2sF4XhhuM9pmYX2/TfCH7ys RxrDLTIvGrfIlIbXwwG8lmmCOz+F5oP6QzD/8lMlAx6/8K899wTc+SROs3Bp8DwuDb6cB0oLuOx6 p7XsGjvMBewwNeuTX/5BGyhVY3hxl0Lt/vLNf+2KHEyyq6T8gsFYBV9oiGwyGCKv2PqzCsjWIwri vx6Ur6w0XnsOxwRP8kcKMRjGBxH37FCHra9VTvM4DnkvH4fgA6Cr0vBC+nOtqta6xauPI4dxPH4P DoqD6F89XODx57rlihIiAlcWAd4mq/2EDevn3+RucuNyXtmGl/MT8MJXvgRffr4f5qxS2QN1+xug 5bc/BQ/cps3Eqy2x1Qp35hhEbvkVOOWJr3VgBp55YK/H1f1zGZ9yDRw9Bsf//jXAo/Rg+65dMPT5 z4Nlwymz4oWH+97RPuj/+38MFc6duv+vC6+fgOzxcdhxx4fg8f074LmDvwdfeCkHP7M/Dl/6syfh ZpiC9OeehkMnfmi7taPbFju+M68chaM/OAM79v07eOyh93ie3gGo+7+M9+8suc9jUfvdG5yBpr+s 8s7yKWjaErFWvKTzBWh5T/n1Rufz/XBk4Eewdavd6Lkx7Sc/2QofeOwxqNtlOhpZprSii4tnTsE3 n/8rONL3bfjhHA6g9+yB3Ttvhp9/bwTu/dBH4bH9bmbnXzsBR773BmzbpgYNXM73P/YxiOxyoFeQ aPkC1rNeVc+wosE7btwLe9+2Cdjue+HjH70btjtxnD91DI58fwq2vuNeeALdN2M7/MZXOuH5viH4 53N4+PH+X4Hm+FPwwD5/097Fs6/BX3+7F7576l+sgc727bvhpn0/DTu2/gS2veMDWO51peUesvym h3rh26M/turZx7CeeUmcwftHnfveesjz+PW/m4Rrrv9FaHoU84jtqfeFr8KRr38XTp07h0WyB+5o +M+Q+ux+46q1qVd74auHj8B3h04BIoHdP7MfPpOIw6P37fMtCVHuXcdesjiy3bvh+re9E+56bx3c ++BH4LEHzW3BN8JKN5DnE9ge+IqXIO1BRnf+ddS7fwFfef6ElTfMHZb5w5be/eAq6d0Frl/+5p9g 57v/vaVfMgd/FzpeOoW65ADql0+ifnkDDn/us/AloV+4zjE0SVHPXs792BJ/O9brm/bdCju3/QS2 3uSuZ6+f+AYcH3/Tqi+PY30pns9D15efhSPHTsA/v7kb3v9rvwWfS3wSbvdU64kT3dA/fg52vOvf weMffg8sn38Njnz5MLbffmy/18P9v/oEhnuyJJxot1y/CEN9EP2yGu1v+cIb2N6xfxj+R1jkgxps fzfftBeux7xtuh7b+0fuLqnX3vrJ9dKet90Cd92J9dOgl2R9qfKiMJ2Db2X/G/LH9vAmMrr+etiD evAuHz0ok+H188t/YY8LrLe98XFBzBkXeApPBlrZBa9nf/PSUTgxesaKiNezG2/9aXjbNUtWPfsY 6jOv/llZiu7QJ/5oPzz4DB8VxGAIH0Tc5xn+nM+hzh6cgm177rX1GZZ/b/Y56EJ9lnP02btRn30B 9ZnQ83oKRdR/J/VxCOqmoWeescch+CBnAR/keJLUgwe6rrb96ZEXZl+D499xl4PqV36ppF8RbWkb 1vmmR2w9f/SF/xu+/vWXIffmm3A91jmu5ztMXELoT7uv4aPU6+Ch33oU9vkMPWydMA44sILHHt8f +Pw+nYHxujgLJ7LPQeeLx+DUD+3+a+fNd8A9d90N9z7wINTff3tJe+fxhNGf50/9dxwXTMK2m5El 6g8+Luj+Mo4LjuG4ANvvXQ/yccF/LDsuMMoewLHa9qePI0cWcOV0wEqsh7MNnQGEdPTSV7Ki39wD kQcboPnTT8IDrk7lApzs7oZ/QGbv++gn4D7nMMIzr+B45Qc/hm3X/zx8/JH7nPJahpHur8Hfnbse Hv0PHzH2gQEkK/FyEdvRX7/UC0H6TdmGZLm/juX+lzgeHLTGr3X7H4KWNSr3EsHJ4Yok4GfgCJLZ sGH9/JvcTW6WTHjjivzMDHcyfLsNnxEb/w5kczWT74nuA46MuH//WFbuyY7E+1jRkdK0lzrfkzTm TeYZ91aL40308IHCOWfPVAtpuKPeli2WYMl4xCVnPNvPcFeTy625a0ImNZKK2vciKbkfXZffdF8G di7mRw858dtnvOjhXX6L06w3k2aZTJZ1phOyztQ1J1k2m0F3+6/z0CHWMzLjCjqSdOdLcA96Powr soA/po9XKHOHmZ5fXzl9zu3goujhK9YXrZx4WFk+sQybyHdJpoKP/R1hfdOidvNQ4lNkg2lxPo+7 jsjwenorKT9DPRNS8PzLfGB65zztQd7DPE7le2WblTJyvRM11d85lvW0Bz1MQ+qk1eZ1/lym0wHL Xchf9Tfy7MH20NmZZRlDe+js7LTbRDqN7WG2JJnZkYxPedtlGc+OloSpxkHxT7D2A+52yPXLoUZ3 3WnuGvckU2RDIerZpUvzLBV14sRzMnJDGZf+UmXYxPB4KK39uMONDnaWDacLWU275eEVm2raH2Nh 2ztPc7q/gl6q65C6nPtf6We6v92Ho1NGnvREewo6LhD+q5VThQ+pz6pN0BNOpc/YeJ9WNvXmcpB1 piHDJvM9rN40btL0mZ5cvrdCWfBxiEd/6uGDXFff/uzYL11aCtDeS9lILrHOYFyq1J+TParP42Mh vfx4Duzf86wzJvRaG5sOAi6AnwXsv+zz6UTc3u8oG5y3zyJU0YXTnzycYsn1UrdPP2GPC7z5V+kG u1Lhq2t/Ivx8Lu0aRwZLnbHA408nwnD95jRrc9qnGjcXWFbWjRgbXhTlNckSlt96NiQmA0EzofkT PBiOToL0m/p4SS/38bGw40FNCLokAj4EeP2s9i/M+S7cr+l8F+7mPd+F/zad78Ld+NPkK+5TnOp1 DcqaUz0sN5FnA90pl7JP9K9W17UShAuqM40k2Tn81x4RHV8LG1syxz0zoA2mULFG4+3WYXrZzg7W IiYImuFFxOIbLpNizWXCifBBv0fFAb9iABeJuthbE5VIRLpFUyMyajxrxi6/BmU4kjfxQt7HCZDf oX3zowE7zIUhVidkrPAdaRvSxWAzI12sra2NJZNJ1t7WIuscblNy+Vu9H7MsKetGHYsns2wIDxMe HR5kfb1Z1hpHg1VjZwmTWUfO9vZ2lmxtLpFTdaqlkpbWlyTr7u1lvJ411zv1FA9x1stBlo+LZ5S1 pTMsxWUU7vEeaVgUKY9llXzcX2Oiw67X6XbWJOqnXi9WUH7yMOmYW34hi8yHoZ7JgyNFXqzvKEui waK9xcmjof0NpmIq/5E46x3C8hvoYk1aPOmcTpNLM6vphAiLt2fZ4Ogoy42Icq9n0JSRRlYhf1Xf eKBuOYO1LDuUN9I66EqiONmj8ob3W1K9bHR8jA10ufXuwVXQuyX8ffSLaNu6fuFCe+tZ08GUXc8O Jc31DGt4pkHoZf27gbV2JJ0Dqx33eK9Wr+dZRg6I9XAx1pryhuthurqfHelmra2tofWLrLdancL9 HoHan7e918eTNhfsH/z6lUuXZrT6iXpJ1s8h1tfj6KWmjEtHuCpO6B+oB+sES2wPjh602gOm1+aj B4uTPuOCrg5XnV/NcYG3njUmUrb+xHrWWO/kwUf/hMZiBVhiI70ZluaGU96nizR4XUB9MzhjMnZr faqnznB9lmz212ezA26jC68von/Q64tXo4XPW7Xtz04pn1X9s7dfUeVQOt4o0TMWH1vPJ5vrbX2n 939V6E+7/51yJsi8TsTZuKGY9PrLX76wGh8ep9CRnEss3sH6h0ZwTDHAerNYfyzdFWVDngL01uvK +tO/jrUe6vSMC3T9ubJceuUM2/6UAQUP1/UwKCdZ4PEnRrLk02+exPmKXjZKL6GRxXmw0IDjZqv+ FHKsUWu7Hdz6zz+Lw45R7SCbMNQp21Pw//Oe8VkT6jN+iHcWx2eNpvEZRm3uj+pZa9pb7u7+L7hU 5PNqJ1Ct0YWHI8PLqtSeAutqdgY0qIjaT7qNK0unj2vW/QRbne5rBYLPDUp5oil7Yj+iTc7SJm2P SrZZKtk6lh505zHfKd5q5DFMuMJFWHrIEy7jGDzqSwcgYXPoVrbNLI8R5IVBhcuOg0C+xmUsbU9E Yx3DMgk5IUY5TH2djNswsRWRqCcVFU6jL06yDE5uWj3GE4jF7QkPN1bgPT4Bygy4eYm0rO/iqJw8 r5nhZX5I1hVo7HMlH/jHUgg5F3OsRdazMvXFUw6y/ETYWIqN434F+4MTUbHaCcO5TFSz/doEKMZ6 8u5HNHhmgD3Q1dNbQflVqkcyH3p6Ti7kPZnHDjZVsG/K9ucx2BQmupRhApm4ahPqAfttU9g2vAYp HMzLJ5LVlrsjd8Uv5NnptAfdSCfaA28Lsj24dOsi625RejfpaSvF6X6VB1i53nXzb2ZjmDGvfhm3 3Bos5rp+YZXqmVF/lhpQIi1ZJuexWH7KeKa/SQ0njB7DS6TZHU4NmMvoqmJOxl9Jv7jZYJkEbX/Y P7jau7dfMbU/XqH0+tlUpV7i8QT9VKUHF1lX2fp5XLW/VaifVlZmqtBnQRn4+ptjKWmcd9qj8ztW ZpVvyYMSrDOTjs7OZ5zxBOozl0Z2jSdwHOIdT4h2ZNCfvuL73qi2/WGEFctBvX3JlT8MKvsITc9P Cj0v2oPOpWr9ydhUr1r1EtdWAAskQ0nx0KKJ5RwZxL3qvrWHfpi/tv4pYzRzcx4qVelPA8sGn3EB jvtc4wKjVAEcK5a7YTzhiXah2hUvMlwZnW6lhXpJm68E7TdzzrgZcCUWL53FUfdKymjrgBV7Ie+s zNTrqCePgX9iuStDUIz15t2jczk+88wfTP3RhKy/2K7F6lTveDCwYOTxaidAhpeNrgGFETXAb8oy 2b41uaSCwM6m0iBWC7aql5aVGmOc7m+Tk7GM86R7cUy9WjqatBWonvhEl3p6c7C3tLOUT2lQkemq cbxLrSZIGJ6YyEGG/gRHTzjEtYwLGSf67CmmroDx/BorNuEvpq148ZNfJC/C4KF9rvyJ+/xbdZgN bNgzbtD9ua61yQ2eaeG6VfEH1jsx8eoYrjxsWFo8x+bm5sr8GdJHQ4hIA/fqs0x/3li/y8qqyVmp 7k/o9cVTz3j91ctBRyzLjw9Wo0m3gQGFk+3PU35D7WJgCcxkcJT1B8MZl66HLD8/+QU/ed9gAHTl MdLmMuCOim12+pYojFTKj1yy4/raBjvFkZRtJADvdoBFZSzDt5JY5b64wqX7Io9lv8vwFPpLhsd6 JQ1HjT56V0zEMP/4liQZtJoLnb/SL85AGuNvG7C3QYky5E8GxUdNYMz1TMbtqp/uSQpfWeZt5ar+ ouFFKl5PuKaMFU7np8KVGaQjX2Gg4e1WDy/yJb6l/CHb30S36lcSvaWPJGT99bY/nIDreqnz+Fh4 vSSED/KN6QkWoj0YtKU7JuQnjZc4LjC1H6mXkFsl3eiO3PxrUE6US+tZOf1pji2oa4ENdOIKzPYU rm5MqNVbvC7wP5zs8t7YW39EO7H81LVW1Gc8vKt/KDueKO2nw/d/nnYUuP0xNpisl2Ms0a/o+Zd5 5/Xag1ne4+wirUyMtqzyK7NV1YomjP7kAYoTLC7KCY1/avM13tPqPB8T6vJbaVXxX2FCjTMjXmN/ mfiq05/u/g/qy4wLVmH8ycVfjfanjyNHtMpRib8eruz4U+83m14w6s0xrd8Ueun08Va7TuPYg/d0 rocOVh1KWO18zlkZLx7qlinWird0nocMmZJtxVN+LqNutL1E/0i9a2h/FYUiD0QACfD2WO0frXhZ hSrEl7uLpfKtx08bY1zMqw5HKDKjxzV3LLIeed6DvrxUX3Z60DUIwseLcpkheDtnR16zAsRwYqWB bzj/Jz9hUchBOij5pVyYvhjACDf9ibRww7cyGQ0rMm6PZV2XMfCKFz0QLssUE4hKkxs9mHWNYcVk QNQp/855nqXFskw50HIGxvI37tM17KvuiXv9RVki1cVGJwNOZLUJXHkDkbue8dUD3o/sUD0dpiw/ qGfHDOe4mMsP9yKLJ7UN9rYZLz8Zr8EQYskWsvz85Bf5lBNYT/74fSkLRFiXWs5jBS0uTLM8bgEb G9fPBFpifQntLJKmOEvE4ywu/hJxNTFE44o+yOP7qo3l3tHFcpPe6b+QfuXflzSe5euKvVxa6N02 ZyuRt/wKq6h3FX+1ekbWK0fn8PSFP6VftHrmPC30khJh3PpHf+JezwYM2Kf7ncGwq/z0FS/RCuH0 lTKeybFWFqkKhl0pf6j2p7f3g4y3d2/5yXhL2l+Z+jllAOUFHvp3kfWW6MH6/7+98w2O47gO/GOZ lEVFpEzSomTaMZPIuTi+YH0nxWUlse6wslPlc/kCyFaUiwAnlq4CyPZFgi4VJ2Bd4gI+XBXwIYd1 XRWXdgIoiVe5CIglQLlAlRCSDrwKoByghMuEcB2haOEQsgGJoL2rAxguzL7Xs9Pdb2a6d2cGILSk 3lYBO9vTf978Xveb7jfdPZ4dpO2Byi+n86v62edY6ra9/QKsZ2o5FO4DRcZs+mob2R8dMeWBuv61 xWnR22ruG60DwSWCMntt69CejfmPo1X6anlZnMWljQuLdE+nSqAfYr0/HHf1J9Lc/9K2P+xLqfuK Qw/ablj6E7rOQ4sYNY/pPY1ILtLOLwTsvFFWEvupUi2SpRx0OdHyZK/vPMqI8VJVRd/S97peji0d 4dEaqvQfLCSt/aT3zFbr/m5aD5b7bVCGOL+23v7k9RsHStA2N5Igbv8zMF4J2SXF33bf1DNZ8AFc cR1ttzerMiNyuDxM2bnxlcti0Z+V1RPZ46zRFYTPB/WunyuQaC79mTaUra93S/sj2fMhE3ASkG0l 7R87XpxY458oz6m9PeRTpujNxMuJPKELr/2PX9I2xCQzGDK9UzpDWYHMU1D5dFyv08A4K2aTx65R q4f8tPKQ4w3MGMhVk657zJquqKbOOhweWsAYB9rYkv04VFh20OyVosLoE2ndCQzIbwo1ctLrM+cl P3PDDA9iTbzIEXFKKOdJJI4rANMqp03jp/l0MGY6xN7TRu146RTz1se4a2IyZ6YkB9K0HxMnz5Uj A6aAyHQAV3cvGlJfHPWsaK1npBMfWmqj5FA6x9eWm/pZMTMm2o7bN2Bt+GQkof5oR8G0EzPgLKop 9lRO/yL0NZD6ra5P1r/opyLy1j1CbPrHjfCoQF5ma+K5nNqEO5QGN7CeWowkiIoQM0TLT+p0o/ZQ mTd21/Y0zCuaPrUlM1BiihWIZuOvwujAUoVp+1Ke0zNz2vLFQJ7qh37CGLA/ZI8Jx8DA7CPhmPHi TKdmItaZnZdAF9p+Jml/+NxUbx7sau/q/mC9jjp2aZvrZ01Pycqj9VPNelD61t/bWD8F2jM1w8ZV z/SSxEA909KkPtDtl+ZA6g9kBrEXEfyodgJySYLVfgXje/0Q5cwJ1RdVvtt+prn/pWx/RA/tjvau l1JZ6rXmgnY+roVV1y8I80b2U9PFPqFZRq4eUOHyMfWgxjGbUKdPcHBuVPUj0Nmm1k9hei2/La/U 9pM4Xiz3TFmUZr0N/c+ttD96/YF+ZMwKINMH0jmGIfKabXaJli/jCDJOaFVL8svKvmREYXrSXyKK D2/L6CDx+5A9ozNi4ljtYU/OTMH0skz8j/TP3O1IbVUQfGCq+1lOvbsctIml5ARvUwKyzaT9Y8fL NlQa42mW04WDFk8bNFyr2Oobp97J6JTqbRAjVhaV+ZyeAisH0NlsVv/RAbXquHny43p6NaXfZQAn 1dNA2pEg6+ITpYt1JdFI+mke8WKrAYEeBGEydbOlS41UmFxKRDVY05982unPHAidp1LYNjfT+qcR 6fE6dZ5En9TWTY+drPCMF5p15Bh3tt7Y2PD+1tfXA98yfL0afapFy79cPi+m8OlGm3qa59dnWW8K C5SaKdlLT66xbmeQ7NsQqH8mO/Hc474DADtKtMT6+jM6D+iX8KN1wRRH9m5y6Z1cm22GBuUn89Vy huSvlUlmo1nKU3U5cA1GWMsRfSNFt5g+e04sLCx4f2fPntXHMqy4UBLU1aoyk/LLp6ye3tXT9Bh6 V+kTfxOdyLoS5kfzq2d3VbwrKyf125+2andt/FUHj9afSBipI9QOKRlxTr9Zcx/QO9GfowNp9uZq w7eAqBzJk3rcRFUHq9P4PTekNlxuc795IqQLkjxyqOt1QH4zoLKeJ/cH1d7DGVvvK6FIdevnWdvV hzJI+FOWd7Iw1NAOBuunYwSFe0Jk/fa01fopN7VUjnhVH4Pth+yJZLU/CUHEiD6j61k7qZ+1hNY6 EcozID/ph7gc5XXrS+L7X8r2R/WgBq2B63K1d8WFDApjOaRI5qE2G+BHooUP9YMlrIu9U+giK5kZ 2gP+Eu1wmjS/10j/M1+M2TZT20/yQCZkl5TsylbHv6eqlJZvqnffyR/kH6/9Gbthm4FsKdcPitv/ NPlHxys6d6tdKol+v+/X1es77jtGvSRT/szaTGev6PX2T2nzZloGr1/nHu+A1OVk981G/azG9SKe gBzr7UxA1u20f+x42Y6ag55g5ZjIDpiZFTTrlWk1JVxOsYwOsGncq3k83Wf2tKCOlshxNmeeUG0s 6CcimV7zumklJ50uHbiBrTdIR/aVkekcXVNVTMNv3ZEjTy9UmOqIykzUzdYsBSCG2rIh2NoscVY5 buAyX/PEgT59lmfqfMjNJfETAnKjr+vQqFN8ulNVsbwwJfo6WowTD2c0Rd02fu54jWpAUFdOWs+O PRfJj05/DdQzLEbpORyurs96nvCz3djNMg509rj0nlB/qu6BZSDdqJ7pa7DMhlHXGf42A3PcbNqp oHAq1++EendlUy88wLNBx5w8CaUz2mj2q8Tu1q17NJHj2MZfhdH6oxw02uaQ+q/DSBnuekYcKLb6 d/ms2ZgWz5u7CqZTM50wPGJXq650RCh5SAY8jdgpDq52Yj2/buTIWNq7874SEtP8tNRPnBmx5Wpv CggdXfbtIFnOh+XpnZT0E2J8wGFZaiMzWz1l9ltrxDhUePQnqWe0PqqI7nqmYmz/9+yAcvDhbMpQ c6YPSiJ11CYKvT9gP0Rz9uPWuz/YsmsclrL9kfuKtb2rvTKkw83SrpX9sJ1rKHMS+0kzI3UHWntE /+Oqn6hmwNDI6Y/poL/V34y1YW5ENitPvdwyytNqd0iB9HysOkjSRg6JnFtpf+atRsmWGsXuf8a5 b1rtEmkPvrO4u1DbFWj1VPBNYwCPiwXbk5wItDoB5P5j1XuoHVH9NdIrPR8yS3UE4lNMwBBI63SR 6djxYjimPrpyhaxFhA6yyaHKck3k9VsmWsWUfi2FOr9T32Qfl86cmJdPuuWrgeVrYuX+EGfnRL5D dSIzZG0kLlnQ8nfg+k4jb/DNIbUbnzGAZXGcpsNlLLLSyY9Mp5xVntPH0gExpcQ7oh0WJYMKa8vV 3mAky1eDX3pzVGGAr9c2Axgce5wb108kPTktTwrVNZkbJi41si7ZsVwH6ZwPqNfxWaKpIFWW95vc 6GM/PVIZxf1eXxOrCiamCZSPQzo9HRkddZRbIHuUU83MOX663m0O1+Hr+oJvUQjVs3B9IWJpncrO Kg1Xcmj9Uv2RKeFyE0P6xp9KsaDXLdf0bs9XJNSfqo+0nkmmG4vjekacqz24OgtBnagrrn2bdfog OvP+ayCDUTydbmyEhqcba2LFoqpaWeWA3i/4bTqUbeyfAfmJE9vWHgJxcScqvZcC2t3olgFrxP6g 3V0NXWNsCWsRbfxVGO0Y6jD1tJvWM9xElNazMtYz89aGqP0cVu3BX8Jjrr8qJvvV4AgE3ZsBXcDG 8RJ6bfCVK7jvD3G+y3QmzxAQHECqdqvsiyuubl9J2h/Kadp7hzgdau9q2Yy1/WH9VHYpKhOxS+FN o0OXGPunbwejZUmbGGwPxg5i/dSzxGr9gmB62i/IipO4P8KWPjig0sxwA8xwPVP7MCj7YrOTacoP XhPJgdSfwBJPP4pqJ3JfI4upIRmpwwppz+YtO7J8Wz8kXp4qb9s3mfGSpP2RJRIQbu+nQ/cV2e8J 2U/DJTj7VkpoYx0IS2Q/a9es0s8dV04ytEP+wLpjOLgEV8W10YoTdgWdxWZZEy5ZwZmyDfNMbT/J zAb/YUW4LM16G/qfImX7C8tEHShzxCZKvuG4NCx+/5PeNzst+/qhXVKOe9yzi943zUzJWh0p4B5E nkxktrJXdywPluLUj0CcAM/afVNdv7xvhu0Zbe9ar+QhLGWlz1vaX0AG/sEEHARkXUz7x44XB9Sk wcvPHdM3K8j2irkV32JuLItCj+kgZ/rNvipJy9hqfPrmIvVWjnCeq+SNR1369YJVMeWv2/SMKjpt FlZWRHEyFxw0RJ7ghNJ1DImF1VVRfM5sxqVu8Kme7oSEtxlTFRZ0stTWhdLBkn67C15Db2FeXLiw ImZH+4xO/Y6Ia2AvRTFPc7Ji9PR5sbK8LJaWlsSybQSrZKdPn6FLnFqqdYevXF4Xpflx0T844e6U EofG42NFsbpaK2+lvLUBphJNfqulaf0jE+JsaUWY8XlVlGZGtLMg/MRa3SC9vMiTi57RmpylUgkH 9mE5Q/VF1jNZX7CeBW6yUhdkOZksQ+lZ1aNA+aHzZsBBN/fEp9K9o2IJGU4X1KaCpgMK7fbNKkVC /ZkZKLV6traG9WzMPPXW7cEyGNFPiBN1EpfFAFka1jMyLdZ8p2B1oyxKp6dFTi6jw7ch0Y5LeW7I q/tS7wshvS/NGr23WGbAeTpP+69qZskBaQ+iuiFKc9geBiYCjjXqWJJ2d361dnFX1s9vu9218Vdh 9e0L1jO9yTjWs2NjorQSp56RmSs4kD6LdqRcLovVpXmR61IOcqyjuH8G3YIULZHQDhtMt4DpKpWK WCnNiVw3TTdgZjWG9OW1H+LY7UH7soIyy3a7Wgm327TtrypO9pJZc6S9B5xRkfsKXuFcbRZi3/C4 WFhajW2XQpcZ+ye1g7K8dY2gKmR7UMuFwnYw0C9oNfVTrF+NfkGontWzZ45NnmMD8SOeHe4Rnf0F UcQNjTUSPLe+Mif61B4hqL+escD7crzU1GYbm1zLOGy/a6F4f/CXNKh+yFm/HxK9P8R15tRytv9P 3/4K6nW1eO117yuoh/C11+Nil5OEJrSfJCU2qtngwzDIilPGixiIupUfi2PBfcMGJ+bxnlTFpc9o 25YXxdRoTnR1DQmzn2+oXse2n1G7FJZb2W/VbwifT/Y7JGfK9kf7kWPF5Xj9SBSUpmvU/3TdN0WD 8UpJb7gs+0b05Rzo7Cf3uFbLm1GTsZSxgzxbkWcJ+2enniRjLXlvkH+h/pl+wOXoK+kHBQlmDyeX n1NczwTkPSrtHztetq1mlMnbgnxjoIyC+san6qFN6ret9DgZzefVEw37my68PKjn2u+cycpVXZ6M Dn7VdeGAJ9+nNrkKPqWR6SKdaJ3umMj3++kcBjLOdak4RXV9mJfqL6gw6mRRHRs6WCqTt5/owa+S Ex1Gozkjp8pblau+zY0vpP+WIS2Piku/jV5C6WT5OCB2ziggAyMqc8YxrZ2WGfe4TNZk0zLCxyN1 1mvTNy3QdBmy4bGS53LDeuavfw89yVA6DTtkZL6y/urzWDdoR9epM8m+K2/0jk4A19TZJPqrX89y YnTIrO8P1zPdWUjYVi6fr9N2VR0PvYZ6O/SudJr0uxHPIJcYdhefOm+H3VW2RHbSlQzFfO113EH7 UtOhCpP1L109i07tpu2ndtwpolswkAGj0m/ku0OcCnpromoiDlNarq3d6vYVcojKTOu1v7r3FXRU uO4PyjFI5bIdS7sky9/qJ257GI7M6JP1kziXInqQNn576qe8RrPPg+Ve4tkz375IexZ3VmYdeKr+ e+wzraKjq0d0dZgHTV54VyHg1FXZ6TrTwJ5R/TWsL33GflJHsioz2Xfa9kcHwRY9dON9Rdl56I7c V7Sd99sSvf448iezn8EczZ48KHdPbVl50vKDOdp+bYhx6nC1tQl0+qg9q2T56exnY8dL3Dpouwpb 2Ha0P+e1hu7R4fKd6az9z7KYeJw44W068O0S1f9G0WxoD49PBJyt50bVhu04u3ZkISxeqt/Oa5Ly ynak+uWh/llArxb738gxk0pYTvS2IiDbRdo/drxsa1WpitmC5ek1Gom2vlGxxZnuW5SUeI8drzis FYCvbNSea1ynSTpna8Ux/WRPdXLbewtCvkB7aaxbe57pwFbmKdO1hgx7G6aTU6Fpuq12lBbVjvmd Bb1RqArrOF5baiTlWfBfn9iBSy/oZ2E8qrtO1JscZOm3jmDeLjnN6/ZCna2QN56WWTsu41uDfH4h Tp0DU9a3QXnpHAOjzpFitIi0IWtFke/truM86xaFmQabRZOZOareyO+OYbuc9eqLelUhHfzKS9Nv d0HW4fonz59Vr8y06KJ0cijiVOwamvT0bgZcuAmpLWOZOdaIJPpbGI/OpOrsH/PK029RwjdJhIvT 11i3/XoCRf6tn58R/Z32jlZrR6+YmKcLEzD52mmRP9Yd4aL1l+1qrPeIFHEDKmJyyHTidJlYZzoH be3h8o7Y3cUx/40caAOUWVRhchmX+ig90TB5rjQVnbnVnZsU8qXsakYF4GuhTT2r9yaWjOgawBla ShBVuPddMTNeQvYE8NW9Mh15oUggZeCHw7Frsy/qmuWTx3C9lXnWa38XTo9G7ivq/qDbOzpalbPL k9GzS13u+tmK9XN2KXA5W/oh2wPawcjMCsU3i3Zw1mUHq2KmEG3zsl63Y7vf6gqj8HXJehZ+2KHs malndDPmcA7xf6v6T9uoOc6IvtF53VbCuar7MFhmfYTj0t9rxWh9kf2QQH8iYZ40f3Octv3Vcliy tvfnQveV6KbDtC25+hpGRttRUvtp8lidMrMJRhZsLdnE3dpRVcyP50IzbEy/qaVtIOIsT24/TV/P Vce2zjpKYavtr14/sp5G6qWz16MU4xVc9qX26+vFZaqBDz40UzP/8hEHdCBmoh+yHUXsGd435f3A 2DO8b5KL1Pcb7CvZmGnb0z7i7M8nEpIjv+0IpHW6yHRvheNll9QQ3pyvy4+8tF3//D1YLJ2HXTfd AtXvr8P+9x2FIwf26uv14uzapX9fUwebFVg89yps7LoJbn/fj8CtN+8OiO+8ts034ZXFV+H/ib2Y 7igc3rcnkK5ZfoiNNfjHpVWowm44ZLk+KafzGmNehDP9xkVYWv4ubGzugt1798Pttx2Bm2+MmelV j7YJF1dX4UL5+1CtVmETZbzp0PvgjiMHtrVkzWbzItaX87AON8Ft75X1RdazTRjrvhN+8WtnADtS UHnmIbh5u0rfWIVXltbgstgN75Z698qzZ65lDJ+OqT8v/aXvYXkrWM/2wCG8PlWeM+9wWSl/V1aX 4PyFKtyEzW/zhpvg8OHDsO/GYBsOZl3T+1ql7OkdXwzi6f0D7z0YjLZNvwLXf0m2hxVYxzJv+KFb UNYjKGud9of8F0v/VLO75Q20uz+CdrdpGlCNENazxdIF2NyFerfYl8D1w5vwRPs+eGgck2YGofTS r8PBKt46qxuwe/9B2OtUWwVG2vfDw166ASjN/joc+sEuwOVasHvfAbjxHXiParb7j9/e5f3hPbr9 yfZ+F7b3IvqjRqD89OdhX6SeYf18He3S97+PNmkTZP38oXf/8LbbJVPsJqytrsBauYLlVbFNQMAO BvVnUnlHWJ8XX/0nTHALbF6l+nok9TIAACiPSURBVKnL9+2ZtC8Htf2syaPjhMRL+3Oz8jqc+7+v wBvf/x5cfPOyl82B9/0L+KnMB+GAs46mLc1v/z+Q/YmSd3+4/arZz7Ttj1zbJWzvr8r2foPWw3bz J6UF+yZJ7SdchFz7QeiRdiObh7Xnu2F77+41SYPXvwmvv7aEdeeyZ5P27j0IB2876L4nJbKflMzO HOtr28H2l/TKtIwqoWeX5HhlP1zG8cotP/yjzXffvPQ6vIL3Tdk/O9TE4weFlL+vfwKyHaX9JE3r im8Lt4VJOa9rx0taRXA6JsAELsGpJ78J7/r5z0DLrdEB88WXTsDBux/xMOHryeHpbnwOwh8mcN0S qKDjZX/N8dKWh/Iz3RHHg7zJRp0oZMCI6SqYzuWgtKffKaC19n7LJ+6DzGHzYEKVvjabh0M/8wXv J75uGp7h9q7Q8PeOEEjb/nZEuG0phLb/M088ApmHTnj54hu24NE7r4bbZVvE5kyYABNgAm8pAZeD I45QSdO64tvCbWFSJna8xNEMx2ECbzsCFchn98MXXsQH3D2D8NBnPg4fev8h2FX+Lrw0OQwdv/U1 n0gWTq48Dx8//LYDxBf8tiJAZq60HUfHyyMRx4sdBw4Y70OHzTN41nfY3Gx10NhT71xoBU7cux8e eQHF7BmAhz/zCa+9Q/k78DfPPQEdX64NAvHxO7b3KWzv1+gs0Z0DyiVtK4G07W9bhbhqmS29/BJc uOU98O7qGzD11O/Bw18p1MrqGoWNE/cDffQhO/NRB+9VE40zZgJMgAk0NQGXgyOO0EnTuuLbwm1h UiZ2vMTRDMdhAm87Am/iQGyfNxCrd+m56WV49J4j9aLwOSZwHRAg7SGTg7XTj8ac+o/pstiOXkQE idLtNDLjeKlXMrf3enT43NUjkLb9XT2Jti9nXFaUwWVFuGo38Mn0weJLvwt3UK9LIAL/YAJMgAkw AZeDIw6ZpGld8W3htjApEzte4miG4zCBtxkBaTB+8M+vw/xf/QWM//lJmJkpwotnaj3DTLYT7v+V B+DBtn8Hd1yNjQPeZqz5cpufgBBV+Ptnh+Hpv1uBd33o0/DF++/EnafcH9l+ak+lN+HMxB/ETufO 8eqf2cS9EOZPyvY+he39NGnvHfDZzz0AHe2f4vZ+9dXAJVgIpG9/lsyaLuhNeLL756BD7p+En0ym DWeU/gb82oP3aOeusSdNJzwLxASYABN4Swm4HBxxhEqa1hXfFm4LkzKx4yWOZjgOE2ACTIAJMAEm wASYABNgAkyACTABJtAUBFwOjjjCJU3rim8Lt4VJmdjxEkczHIcJMAEmwASYABNgAkyACTABJsAE mAATaAoCLgdHHOGSpnXFt4XbwqRM7HiJoxmOwwSYABNgAkyACTABJsAEmAATYAJMgAk0BQGXgyOO cEnTuuLbwm1hUiZ2vMTRDMdhAkyACTABJsAEmAATYAJMgAkwASbABJqCgMvBEUe4pGld8W3htjAp Ezte4miG4zABJsAEmAATYAJMgAkwASbABJgAE2ACTUHA5eCII1zStK74tnBbmJSJHS9xNMNxmAAT YAJMgAkwASbABJgAE2ACTIAJMIGmIOBycMQRLmlaV3xbuC1MysSOlzia4TgBApXV12Bt1z44euu+ QDj/YAI2Am++/hpcEFhfDnN9sfHhMCawMwQuweuvrcF6tQp79uyB3Xv3wcED++q+Fntn5OJSmAAT YAJMgAkwASaQnIDLwREnp6RpXfFt4bYwKRM7XuJohuNoAq+/9FU4fPdj3u/eyRL8108e1ef4gAmE CXB9CRPh30xgpwlcglNPDsKXOr4CZ0JFZ3Pz8Pyjd4ZCk/7chIuvLUO5is6c3QJ27doVyqAKVTx3 +OgR2EvOiGoFvoOOoCo6gfb44bKjQtNvbm7C3oNH4Nabd+uUmxsX4bXXK/COd7zDi1v1HUl70ZF0 87tuhj2R8nVSPmACTIAJMAEmwASuIwIuB0ecS0ya1hXfFm4LkzKx4yWOZq63OJsXYX7m72EdboA7 PvJROHJj/QuUlUd1hpcmHocfaRvyEmQHZuH5L3+0fmI8K6pr8Lez/wDru26AH7sLy6O974apdzAC cnlZcpFy/rThQq9/B6W5LooK1JdBrC+/2bi+pL5w1l9qdE2RkPV3FdSwCVP9Pw+f+MqL1rwz2CZP b7VNbszDvTf9NLxgLcEE5ubX4NE7D+iAystfhf131Zz4OtBy0DIwB8Uv36XPvPzVe+Gux1ylZaH/ yX7o+eWPAc+v08j4gAkwASbABJjAdUnA5eCIc7FJ07ri28JtYVImdrzE0cx1FEdWhF1v/g3cu/9u r6M8OLsGv/lR0xludKkbixPwyz/eBuOQhULxz+DBlhhpKy9BFst7ETMfmLkAX777YKNi3przKKfi MjCzhnJGr83jx09UY+tH1pcHsb48A61YX74Jv/xT79JOvNiZxI3I+otLqjnjsf62XS8b33oSbvrJ jlq+2X6YGfkS/PRRtL8bFVhe/Af47k0/AR+9I2rnEgmCjpfPoePlGw0SjSyU4fMfNO6QypknYH/m oQapADpHivDHn2/R8c6c+BxkHmlQWlcByiceZOeLpsYHTIAJMAEmwASuPwIuB0ecK02a1hXfFm4L kzKx4yWOZq63OKSjHH4KeVUudafLS3sRl16Gzr13QQHT7wiXtHJyOjsB1p+dy7USyvrbdk0ZJ0U3 zJfzcKfxe2xfWURvrQMz8MKX706R90X46r0HwZvIks3B2vOPgssdVMx3woe/IK10O8yuPQ3yucHm ZgWW5v8SvnL3/Z79lgL0n1qF3/nYrSlk4SRMgAkwASbABJjAtUDA5eCII3vStK74tnBbmJSJHS9x NHO9xcGO8ufQwSCfGQ7NXYDH7ko/A0VWLLUMKYxJn9vA8m5S5a1heaZLreOEE+/Q70D5hIt0vPz6 v76KszN26PreymICbK+SIIEyWH9XifLVy5b1dzXZbsCz//luaBsqoo8iD+WnuyMzQAL804pCHOtt uGfMM/6eMXHyNnHehCfa98FD4yhEG8r6TDfc7Li3GGdSG8yVn4a79pE9ZS6eguzBf+PNroTWIVh9 4TFg10taxXI6JsAEmAATYALNTUD2I9J+kqZ1xbeF28KknOx4SautbU639PIE/OGJp+CFmSK+MWgX HPqxj8MXf+sxuP/u6Oa1F888B0/99RK888hHoPPf3wm7L74CY1//A/jG5Az84wWAD3/8U9D9+Bfg Y++/2S7l5hn43J6M53jJL6xD9wdrm67ISmJzolz81vPwpy8uwY031jq4Mt7ly++En33gAWg5YDY9 tBeGoVheJ5Ynn1HmFzawPPumMjLf77z0LDx7eg1j7oNP/upn4ag9KkiZnvpf5zDaj8MDD97rfDrq lMlyQlSL8LkbPtxQzkhS5P/k1/87fP0bU4D4keG7IfPxduj60kNwzx3b+4hZ6/4Q6v5+1H1lCZ59 8o/gqT99AU6/8QYcOnQIfuK+34GhR+8FG7pvv/wsPHHiT+HF2TOerId+9F74Um8PfPajR8Glf3m9 VSzn1LPPwdT/+RbuDYSfvQfgPbffBof34zHK8h+wHqryarr5NrzznTJi7XPp0g3wc79Uv76o8i+9 dga+Wfgf8NTkn8OrEihe08H9R+BffSgDH/nEL8AD937Q+iaW1PrDIpK0P3lFNj1MFP7Q08OZtTVP Dz/e/l8g59CDzCPN59Lr34K//PMJeKH4HS/5XtTD7UffD/vf+c9ww+0/Aw98MqPZaBnf8xHo+IU7 YQ/W0z/7/WH447/4a3h1bRdk7v0kdPV8Ae45Wquj11L7e+2lCXj276SduBntxP2enVD1h3JVdkLs +wD80oMf9+zE4vNjMHXuAuw7+m/hwU9+EDYvfgue+voJrG9TaD8Pwc9++lfhN499Hu5wmE+Zv6wv f/S1Uc9ee1UU29EXf7vHaq+pPKmOffvy+4XnvTYLcBB1dx90/aeH0b7UERI24Yn79sBDz2CpHaNQ /cb9um6kksOViDg824bm4JnHzH4sriTR8AqMtO+Hh6XjJZuHyvPoeIlG8kLOnOjEpUa1GS/z6HhR s3iU/r/15CPwkx0nZEYwtfqXcO+tMe5RjrI4mAkwASbABJgAE2heAvLen/aTNK0rvi3cFubJiSf4 85YSWBOFnhZZa6x/bUPTohqSb26otRa3fUQsLoyJFmvajJg8f9mkrC6L8eG8GBkpiOHjvSLjp8l0 D4pCYRjDR2p/+bwYn18x6fBofjBjlQ33hwnEC/zwyjsuhocLYiRPyxvwyhse9suU5c2Z8nAzVl1W 1+i5QJbqx5UrZTHcpnj1i2V1Is034RKQs6u+nKqo1fkRB/+afD2Fooq6Ld/zuWyNT9uwWFqYEFmb 7ltzIqqZBvUsF61nSuCFiUGtE2s9bRkKlDc/YK8vuG+Ol+WVK1dU1pHv5akGZWVy4gJNv0X9CZQ8 afuTQtM2WDo77tBDkEvkYhMFVMVMvqe+HpAN1TuVcXFh1FFP0U4sGwtzLbQ/WX9K44aFy04IQe1E n28nymKo1bcd7XlRnB1xMO0UfnUNaal+fWnPnYrY61AGiX6uzA1rW21rezb7Ul2eR5s7IgrDA6JV 2fmOPrS7aIvRzkvbO5wfFrPLG4lkcUZenxOdfjntuXlntPonymKk3ddLax415/6cPt7h66xdzFei 8daLea3TIbsSo4k4hAkwASbABJgAE7jmCMg+Ydq/H/zgByLJH75pUdj+8O2KIvx3+fJlYfuTT7n5 8xYSmM216U4iZHrE+ExRFKfHdEdWdrbzxWA3FNe4mzR+hxegVfRhZzvX4w/MZXjPuBkEVGbrduBp pz7TPxsgsjI3Kvr7+8Xg4KAY6OvSZQ/N0WFeIIkQScrrmyGJS6JXX1OPWDRjQh2nujShZegZL+nw VAfl9Fwul8a1HJJfV25cFM8tiOmxXIB179SWXEOByyrm1aDDH6R4rLJiAB1cA12+7rN5ER6PzOba jax+PTs9PVq3nsmCV08FHSHZngExNjEhCiM50dXqy4Dl0Rq6Oj/m1ZeBgQEx2N+ty8XlW4Frif5Y EQMZdV0Z0TNQELNFbA9zM2JyoiD6H8fr6xgOXtsW9CfLT9P+ZDqnHtCxOdDt1oNMm+azUDAcZV3r 6M2J0fFxUcgPiI6sz6wtqAeXjP0WO2FctNdK+wvKec5cgMZbJe2zZ0LZCTLA99qOqm9toi83INpo GLWffq4z1F63oL2elfZ6VOD2tbqeh+21FijhAZVf6rw7NxHLvpTnB7Qs1K6Hj5UjNKFY0ejr8/r6 calR9HysENSLcqZb7BfNwtz/2sQ8NTwqEtqEdl8f7fm08qjM+JsJMAEmwASYABNoVgJpnS4yXRKn i4xrc7rIsLDTRf62OV1kGDte3sKatLE4ajrIbbnAzI0rF2bMIAAHAJfJU37T8fQ7++05sagfXlbE SKcfjh1YNdS9crkkRvr6RB8OhqnzBNp6ag4VGY5/0sEyMr3seQ8pGllBvU/1tB6s1xtIq/L6LeV5 A3LpxMFzfSjTyKmgY4I+ze4ZXfSK1eXjr9kB5VzqFEV93TXxEv+vIhe8ZpecUkYtJ3Ixnw0x2m0G WwOBc0JcPn/S6A96RUnxMxmkOjoddrxgvVnyGSwM+04ZOQAn5a2fo/VsKFDPxNqMHqRQR53He6Mo uvWAskXkZ+n1C7Ew4jsAQ44XeWFaX9WiHpTVqy8ejDKRpWMywEfnFwjFH6n1J0Ta9idFiLRB1ENp vSac5hJyhNTOpvi/MkVmq7SJ8YXgaFOXhzMFqMPNJuM5X0b0jFrthJTu2mh/djkVXVlfjJ3oEKfX 1SwrMsD363amuyBWlYN3bVbbN9xsRA/sZX6B+oI2N9AaMJ122oTstZIpyfeVK+titIval/OB5NXl KVMeHBPKrSQjbZSmxUBvH9otMysIWrs8O6bsWf+xfjFV2qrx9EXamCfMQGSyWdHS0iIymQz+ZT0n dE/hbED+6A8yO0naE2K/wnFNvTb6CcRBeZQjLL0jKJAj/2ACTIAJMAEmwASakIDsn6X9Y8dLEyr0 aopEn0gXLFM75tUshWxwCYHpeGLHPDsozoc6qXogZhkQe9dDBsO454oZJMe5WHy6qaaVq4G0rPB1 P1ieSoN7ykSiRtJXF0WPHvD3iprrxU+2bvJqHZj2AiPpIyXUD9DpKZezUTkDueD0ej3Q6igI2xBG 6wGvRbEK5JHiB60zkOnzBlxK/qJahhRackLrS+GcGmGawueG/FlXWM8umGCxOGZmWRybWCJnaoda ltbjgQF/ICJZhtCQATp61IBJDnpHphZEAy14Ranrxz1edPp8I/1hSi0/6idJ+5OFmuUO2AZb+gSl 49KDJ2yKf8aBgLPfLI/4tSyh9k71Lu1EwFGAcmhHXVh/10L7kxyr54idOBayE8ZBnPXtRA19aMZL 50hw6RpGmh1Ujt12MUd8XJRngUyxUfVvXs2GCdnrWrkJ/2O7UbM2oNNhX5Sj1WlfqnpJZnu+mFCA +NGvkDYenlWjfmcGg7Moae41fugIJDNeCHYa1Ts2ekDHC3oaFX8dkTpehuZ0MB8wASbABJgAE2AC 1xcB2QdI+8eOl+urLjS4mqqY7CV7YXT0iN6eHtGj/np7zMAeB6H2AUA2sD+DKlAPKENPwNV5QTqm dZcL6QTkgHSyGw6kVbJAeXRoryJEvxcLZkkTXU50frLXnyWUERNLUSdCNKcEISinchA1uja5DEDt k9PnWEq0vlDQM5oSc3aIrQfZkBFjZpqTF7taWRYLuDRn4ZzZMwdHpwnqGe6ZoEc8ZVHoUE/ce8U5 izx6ABQa8AeiEt03YiplnehRZarvrOjNjYpiSc3dCuQe/JFAf8m4BNufLFS3MWgRo2YaiSdPtWzT Q1DU+L+WRK9aftU2EljSpfLQsoT0oMPBZSfcM5aavf2paz9H7QRxDi4TOzFeonaCznjJimlLtVqe 6vPbbW1gXyurcTvSjhIyU0bJmfQ7jn3ZaGhfjJMJN71NKkL8+GSpkZw9tHDunFhYWDB/aJNKa41c qEZWaLDHi7Y7EHSMaYGJcz79njM6Nz5gAkyACTABJsAEmpRAWqeLTMeOlyZV6tUQS24Qm1dP+PTs DjXYDH+3ilmyhkB3PHEpAwnWYurBOQ7EbOep46XxYFhnWztINLj101qcNbLC1/3g7IcuzaXXn1Gw JnJqPwvHLJO6eTY6meDaynPHtVMlb9vhUZaF16AcOdnUex8EhTa6P24dhAdjy1+VBPUsK2a042XV sO4ajczokfor1llqpOVwOF7c+l8Tk0NkiYSuA9gm2nrF1GKtRlvTJ9DfVtqfvDbdxnCDVmsb0wC2 eFCZ1w7YNjJrgV6/nlkVcbz4jhWLnfD0p/aKCqXzJG7y9qevH+U0y+HUkhtiJ3C2SHDIjzMr1Cau Dvt4VjtzqOMlSTsK2us0NaAybzaIzVOvu5+Zd/0N7YtxZoQdEJpfGuHCaUi7o3U0HK3+byMrhGdg hRJqGygdXJbGJ/feUk7x7rGFUGr+yQSYABNgAkyACVwvBGR/Ju0fO16ul1oQ6zoqeho4QJeYPht6 SohPDM+ePes9NSwulAKDB/0k2/FkUHdMXR1YiyMklsgyEhlIN5rFoTv3JE0SR89pMpW+9yTO4iiZ GSSD06uxRY4dMcRFy2/JoELenJEz00QCMa+snNRvu+mdpLswBKIl+qF1axssW3MiU/hlPVtY1E+i Vf2ST6flsaxneskU7reillK5BlOTPb6D0CGLx48MypLoXs4aOVkYEu1qtgdxwBRCe5zoy06gP+mQ Mm/GStb+ZHlx9FCv/miZGx0Qfvb9KnCvIbUXSMgeaOeQQz96vyDX+SZufxRbkco5hXZhidiJU2E7 QfYScezBo5d44sDeOLzRMaAd5bV2FG4/apZHcWEpYK+prHGPyzHsi2hgX6RzUTmZdmrGC62jyeo/ 0YtfH13p9f3PMbNodarfOMWLFs9MXCVwPCbABJgAE2ACTKCpCci+Qto/drw0tWq3Xzi9JwAOiBfI bHhXh1NJoAd9jqVEdMBl7XaSwVzO8siwbvmhwa2Sqe432RdmyPL0NpxWl0/khGxP7a023gBcPdkO p9zibyxP7TFi4xLIvWxmImQH6FuZzJ4DK9NqycL27fHSaLAsZdT8fIFNPesWZ0k9C1xP+MfGgp5x lOmdNG/H8uPRZQ6AAyVazwLlB5ha1nWEy8XfgfRY8vLClOjvJMvyusci8njZBMqiElkKwSDDJVn7 k7npNmhxWgTlt5cdO5RcU3jWgsxjmQwypR70hCU8pweoDjuhz7v0h2WrGVtN1/4oQCpna4/o62n1 B95qphyNbJwRcklLpJZUz+p6L3nSGmscMt0Be01zl8fbon8y06k1ZF9UeS77Yso312qrOyqfLX8T /tLBY8pPkjOZieR6YOBnp9uedcYLceBAx9Y3X09yCRyXCTABJsAEmAAT2FECss+R9o8dLzuqqre+ sOXnjuknc511Xnu5sREcLeuOZ2igpa7IdV53iEmnfmCWDi1UDvZvLz1xouTjPk0kToqkrzCdy5PX bfuzHjpHinYBtxraQE7NzyunJI7p2RgdZG8UJcQaWeKTFVP6tSnqfLpvPVhuMDihuZv9LvA1xHXq 2fo6rWd0KVzt7VHq+oNvVMFZLygLHfDTsgVx1B0/7YxVS7K+JladUcpiqFXNsAluNq3LS6Q/dFqk bH+yPOrcdIqsBdvCQZls4oyb+NINcivFgl5S4W1iGrIHYTug9Kek0efr6K9525+6itr3fAw7Ubt+ 44wAXCYW1B3u49KvNtYFQfeWkqWY/aWwHR1375kSttdBSeP+wtdla/vS6dmXoP7QvrT77QFaxdQK bbuqDOOEkDNRgulVnG34Jm3cNTtOllK/fNSLmlHkmImkJNX1FqJvtVuYUHuA4duVeqdUEuv3anFK jOTzYvTkWbsj15qKA5kAE2ACTIAJMIFmISD7Fmn/2PHSLFrcMTmWxUCL6jyDeHzklFB7EFY3KqJU nBZDPS0C8C01dICgO56hgZYSu9F5UTWzGeQyp1NL/nPf6oYozY+L/sGJ6JNglTl5utkzWhQrK8ti aWlJrJQvqxjR70B53WK65F+NLG+uVh69vkAG9BXDnuPFviFmIE3aH/XkRC59A+MBLtShAa29Yn7V X6izsSwKPWYAl+mvPwBIIm5D3Vozw3qmB3E4oByZFmu+qNX1slgqnrLUs6qYCmz+nBMLq6ui+Fwu ONiXOnHUQ08UMiiT9WV1dVmUSiV0sEQHipX5nOeI7B+ZEAulVWH8jVVRmhnRy7ZsM3C8shLqD10v qdqfLEvrwTZrwhNmu/6VxZPq9fDIOntsTJSwzU0XzABTvTkG2oOb72oZHfrRTjzHee8Kmrj9BQjH lpMsvcO3gp1dKYtKpSJWSnMi101mVWUGRXiRkqwvg+F25G8gc9lvR7kezAPtdWQmTUDYeD8C9iWb xr4EHS/xSk0RC+8JaqYgdOTEqflZMT09rf9OnTrlHZfWQm2+WhbLaAuWlpbFyvJpccyz72hPMv2i uLyK53xbUQmm0/Ua4w+NT4v52VlxcnxYPN5O9IcbSstVZ65PtTSqH3rI9tN7kro0Xak4nAkwASbA BJgAE2gmAmmdLjIdO16aSZM7IItUenV5MjqQVR1Q9R15PXBHrdNoeVIt86QDKtcAYD7fHuh46sGb LDNUXgAF7WQr+fC73utCZXrbk3NdJilPyh/+zKrXasvyesyyF1vccNqkv+eOR2fYaDlbhgJLD+Qe CuNyoEU4RI5xEBF6+VBSkQLx9aBDDpYtrFxMZD1rqSenPId6uEDyrFs3cSB4vM+vhyiLq57JPYH0 chVSvq2+lH3HS4QhSSfPDRedbjqRTH/p2p9USEAPREMu/iRK4kO6n1CETRc+sc/5m+iiE/Xsumk/ 1A7YiNFZO0p/Nvmbt/2Za5VQZ9XrnGV9IXYiCJzu7YPxQnWr9rtDTNMXg5EM6rYJlRexZyRpisMy vuWrkX3pq2NfcNaaPyvGtseLTdcphBQCZ5qZNzq5mIIIz3Yszw05+AfzyAzOB8TS9VrxtnwPnKy/ p5Zy8ir9Z+u87jpQOP9gAkyACTABJsAEmoaA7Muk/WPHS9OocWcFWV+eEX10DwvSkcx29orxufMB gRYK3bUOK75eVg2YaISFJ/3z7cEn4DQO9pbFZM6PR8qTHdHOwSmzySomCnTQyVIj1Wn10tRZ/lNL XxbPOcrrGAiWF5RT4B6S5un+iGtj1XCi1L8rTjkll+AbUmQhVTFTMHu5UCbt/WNCrgAI8EstVy3h gnrjSttwYBZUvWxV+RvLs6Kvwz6Qq9Wz6FPfteKoaA3Vj/ZjBW/Jy6J6qxHO+nAuWHM46jqGT0dF Xjst8r3dbkdktlsUZuoPqOSmua56ZtefEEnbnxRcv/mmbhuLXmKaEKm/0lR0plF3btLjXp6rzRSC wGawQhg7Ya8rjc4rWZu7/Skp3XZC1f9aTLLUKFSvAV8N3j04Jpb0DtMmb3pUa0c4EzGSHmckob2e mI+2I5o+2bHbvrT1j4r6Kxg3RKGr1t7b6iwxTCaPJTa+vtm8gS7oNKGMwktTy8URK0OaRh6HbYWu t2H+La2iZ7AgimrmoUVUFSQdaLScAZenTSXgbybABJgAE2ACTKDpCMg+Xtq/t8LxsksSxA4If5qA QOX1JVi+UIW9e3ZBdfdeuO3wrbBv755tlUyqe9euXSbPSxdh6fx3YWNzF+zZux8OHz6CZZrT230k Ntbg26+twkYVvPJuu+0I3HxjvVIuwlfvOwiPPYNxsnm4MNUFB6n89ZJu5dwGclmOconwU2Ugx1dK 50Egw83yBux/31E4cuAqglTlJvyW8r/5xrd1PdvcsxcO39qgnm1ehMXF87ABN8Ft730/HN4n6+Qm jHXfBb/4tSKO94eh8sxDcHNCWdzRN+Hi6ipcKH8fNjc3oYp1Ze+h98EHjhwAJ/9wZkn1h+l3ov2F xUz0+9LrsPjqG7C56wY4+N6jqIfdiZKni3yNtD8Iyrn2fDccsFwwOubgD+/bDw+N48nMACy99Cgc qKJN3LwEu/cdgBsbIKX1r7KK9nptE/buFrB5w01oOw/DvkYZWGSKFYT1+ZWl5rcvsa6lSSJdfOVl +Nul78GeW+6Ae+462iRSsRhMgAkwASbABJhAXAKyX5b2kzStK74t3BYm5WTHS1ptcbodIXDmiUcg 89AJryx8HTE8eqdtOLUjorzNCrkE//vJb8ItP/8ZaLk16hm7+NIJOHj3Ix4T3FATnunGhUz8ue4I XCvt78xIN2Qe/prHv76deBNG2vfBw9Lx0p6H8tPdsO+60xpfEBNgAkyACTABJsAErn8CLgdHnCtP mtYV3xZuC5MyseMljmY4zo4RWHr5JXhj/+3w7s0L8PxTvwcPf6VQK7t7DDbyn4WwC0BW7MAMnh2T 9HovqAL57H74wos4oaVnAP7jZz8BH/rhQyDK34G/ee4J6PhyzRkG0ApTKy/AvYevdx5vj+u7Vtrf 0suzaCfeA++uvgHPj/43Yye6RmH9xP0g55rZbUMFnpAzXuQMujbpeOmCfY4ZdPb0b496wFfJBJgA E2ACTIAJMIFmJ+BycMSRO2laV3xbuC1MysSOlzia4Tg7QkCINfjqhw9Bz5lQcZl+ODf7O/CB5lu5 ExL0evr5Jpy4dx888kL9a8pNL8Oj9xypH4nPXhMErp32h8uKPozLD3GVW+DT0gfnXvrdBnYC63UW 6/WLmDKTg7XTuNTIz0TeJNmJGyDKP5gAE2ACTIAJMAEm0LQEXA6OOAInTeuKbwu3hUmZ2PESRzMc Z4cIvAl/8sjPwYMnaiOqlpY26Pzt34Bfe/AePTiSgsjKzAOkq6+S6sYqzP/V/4SJv3geZmeK8ELR 10trB9z/Kw9AR/un4I4DDTbFuPpicgnbRuDaaH9yn5Y/eeRj0CH3F8KPy07YsWxCceL34Zm/W4V3 /ctPwxc/eydwDbaT4lAmwASYABNgAkyACTQzAZeDI47MSdO64tvCbWFSJna8xNEMx2ECTIAJMAEm wASYABNgAkyACTABJsAEmoKAy8ERR7ikaV3xbeG2MCkTO17iaIbjMAEmwASYABNgAkyACTABJsAE mAATYAJNQcDl4IgjXNK0rvi2cFuYlIkdL3E0w3GYABNgAkyACTABJsAEmAATYAJMgAkwgaYg4HJw xBEuaVpXfFu4LUzKxI6XOJrhOEyACTABJsAEmAATYAJMgAkwASbABJhAUxBwOTjiCJc0rSu+LdwW JmVix0sczXAcJsAEmAATYAJMgAkwASbABJgAE2ACTKApCLgcHHGES5rWFd8WbguTMrHjJY5mOA4T YAJMgAkwASbABJgAE2ACTIAJMAEm0BQEXA6OOMIlTeuKbwu3hUmZ2PESRzMchwkwASbABJgAE2AC TIAJMAEmwASYABNoCgIuB0cc4ZKmdcW3hdvCpEzseImjGY7DBJgAE2ACTIAJMAEmwASYABNgAkyA CTQFAZeDI45wSdO64tvCbWFSJna8xNEMx2ECTIAJMAEmwASYABNgAkyACTABJsAEmoKAy8ERR7ik aV3xbeG2MCkTO17iaIbjMAEmwASYABNgAkyACTABJsAEmAATYAJNQcDl4IgjXNK0rvi2cFuYlIkd L3E0w3GYABNgAkyACTABJsAEmAATYAJMgAkwgaYg4HJwxBEuaVpXfFu4LUzKxI6XOJrhOEyACTAB JsAEmAATYAJMgAkwASbABJhAUxBwOTjiCJc0rSu+LdwWJmVix0sczXAcJsAEmAATYAJMgAkwASbA BJgAE2ACTKApCLgcHHGES5rWFd8WbguTMrHjJY5mOA4TYAJMgAkwASbABJgAE2ACTIAJMAEm0BQE XA6OOMIlTeuKbwu3hUmZ2PESRzMchwkwASbABJgAE2ACTIAJMAEmwASYABNoCgIuB0cc4ZKmdcW3 hdvCpEzseImjGY7DBJgAE2ACTIAJMAEmwASYABNgAkyACTQFAZeDI45wSdO64tvCbWFSJna8xNEM x2ECTIAJMAEmwASYABNgAkyACTABJsAEmoKAy8ERR7ikaV3xbeG2MCkTO17iaIbjMAEmwASYABNg AkyACTABJsAEmAATYAJNQcDl4IgjXNK0rvi2cFuYlIkdL3E0w3GYABNgAkyACTABJsAEmAATYAJM gAkwgaYg4HJwxBEuaVpXfFu4LUzKxI6XOJrhOEyACTABJsAEmAATYAJMgAkwASbABJhAUxBwOTji CJc0rSu+LdwWJmVix0sczXAcJsAEmAATYAJMgAkwASbABJgAE2ACTKApCLgcHHGES5rWFd8WbguT MrHjJY5mOA4TYAJMgAkwASbABJgAE2ACTIAJMAEm0BQEXA6OOMIlTeuKbwu3hUmZ2PESRzMchwkw ASbABJgAE2ACTIAJMAEmwASYABNoCgIuB0cc4ZKmdcW3hdvCpEzseImjGY7DBJgAE2ACTIAJMAEm wASYABNgAkyACTQFAZeDI45wSdO64tvCbWFSJna8xNEMx2ECTIAJMAEmwASYABNgAkyACTABJsAE moKAy8ERR7ikaV3xbeG2MCkTO17iaIbjMAEmwASYABNgAkyACTABJsAEmAATYAJNQcDl4IgjXNK0 rvi2cFuYlIkdL3E0w3GYABNgAkyACTABJsAEmAATYAJMgAkwgaYg4HJwxBEuaVpXfFu4LUzKxI6X OJrhOEyACTABJsAEmAATYAJMgAkwASbABJhAUxBwOTjiCJc0rSu+LdwWJmVix0sczXAcJsAEmAAT YAJMgAkwASbABJgAE2ACTKApCLgcHHGES5rWFd8WbguTMv1/xxG6y7w0t1gAAAAASUVORK5CYII= --Apple-Mail=_FDC9A972-FA97-4A0B-B8D3-B38879D71A8C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

A diff file is included for your convenience. 

At this time, I would like to request this document for working group adoption.

Thanks,
Dino/Erik

--Apple-Mail=_FDC9A972-FA97-4A0B-B8D3-B38879D71A8C Content-Disposition: attachment; filename=rfcdiff-ecdsa.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-ecdsa.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-farinacci-lisp-ecdsa-auth-02.txt - = draft-farinacci-lisp-ecdsa-auth-03.txt=20 =20 =20 =20 =20 =20 = =20 = = = = =
< draft-farinacci-lisp-ecdsa-auth-02.txt   draft-farinacci-lisp-ecdsa-auth-03.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = lispers.net Internet-Draft = lispers.net
Intended status: = Experimental E. Nordmark = Intended status: Experimental = E. Nordmark
Expires: October 21, 2018 = Zededa Expires: March 8, 2019 = Zededa
= April = 19, 2018 = September = 4, 2018
=
LISP = Control-Plane ECDSA Authentication and Authorization LISP Control-Plane ECDSA Authentication and = Authorization
= draft-farinacci-lisp-ecdsa-auth-02 = draft-farinacci-lisp-ecdsa-auth-03
=
Abstract = Abstract
=
This draft = describes how LISP control-plane messages can be This draft describes how LISP control-plane messages = can be
individually = authenticated and authorized without a a priori shared- = individually authenticated and authorized = without a a priori shared-
key = configuration. Public-key cryptography is used with no new PKI = key configuration. Public-key cryptography = is used with no new PKI
infrastructure = required. infrastructure = required.
=
Status of This = Memo Status of This Memo
=
=
skipping to = change at = page 1, line 34 =C2=B6 = skipping to change at page 1, line 34 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on October 21, = 2018. This Internet-Draft = will expire on March 8, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
carefully, as = they describe your rights and restrictions with respect = carefully, as they describe your rights and = restrictions with respect
to this = document. Code Components extracted from this document must = to this document. Code Components extracted = from this document must
include = Simplified BSD License text as described in Section 4.e of = include Simplified BSD License text as = described in Section 4.e of
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
described in = the Simplified BSD License. = described in the Simplified BSD License.
=
Table of = Contents Table of Contents
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 2 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 2
2. = Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 2. = Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Overview = . . . . . . . . . . . . . . . . . . . . . . . . . . 5 = 3. Overview . . . . . . . . . . . . . . . = . . . . . . . . . . . 5
4. Public-Key = Hash . . . . . . . . . . . . . . . . . . . . . . . 6 4. Public-Key Hash . . . . . . . . . . . . . . . . . = . . . . . . 6
5. Hash-EID = Mapping Entry . . . . . . . . . . . . . . . . . . . 6 5. = Hash-EID Mapping Entry . . . . . . . . . . . . . . . . . . . 7
6. Hash-EID = Structure . . . . . . . . . . . . . . . . . . . . . 7 = 6. Hash-EID Structure . . . . . . . . . . = . . . . . . . . . . . 7
7. Keys and = Signatures . . . . . . . . . . . . . . . . . . . . . 7 7. Keys = and Signatures . . . . . . . . . . . . . . . . . . . . . 8
8. Signed = Map-Register Encoding . . . . . . . . . . . . . . . . 8 = 8. Signed Map-Register Encoding . . . . . = . . . . . . . . . . . 8
9. Signed = Map-Request Encoding . . . . . . . . . . . . . . . . . 8 9. = Signed Map-Request Encoding . . . . . . . . . . . . . . . . . 9
10. Other = Uses . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. = Signed Map-Notify Encoding . . . . . . . . . . . = . . . . . . 10
11. EID Authorization . . . . . . . . . . . . = . . . . . . . . . . 9 11. Other Uses . . . = . . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . = . . . . . . . . . . 10 12. EID Authorization = . . . . . . . . . . . . . . . . . . . . . . 11
13. IANA Considerations . . . . . . . . . . . = . . . . . . . . . . 10 13. Security = Considerations . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . = . . . . . . . . . . 10 14. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 13
14.1. Normative References . . . . . . . . = . . . . . . . . . . 10 15. References . . . = . . . . . . . . . . . . . . . . . . . . . . 13
14.2. Informative References . . . . . . . = . . . . . . . . . . 11 15.1. Normative = References . . . . . . . . . . . . . . . . . . 13
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 12 15.2. Informative References . . . . . . . = . . . . . . . . . . 15
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 12 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15
B.1. = Changes to draft-farinacci-lisp-ecdsa-auth-02.txt . . . . = 12 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 16
B.2. = Changes to draft-farinacci-lisp-ecdsa-auth-01.txt . . . . = 12 = B.1. Changes to draft-farinacci-lisp-ecdsa-auth-03.txt . . . . = 16
B.3. = Changes to draft-farinacci-lisp-ecdsa-auth-00.txt . . . . 13 B.2. = Changes to draft-farinacci-lisp-ecdsa-auth-02.txt . . . . = 16
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 B.3. = Changes to draft-farinacci-lisp-ecdsa-auth-01.txt = . . . . 16
= B.4. Changes = to draft-farinacci-lisp-ecdsa-auth-00.txt . . . . 16
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 16
=
1. = Introduction 1. Introduction
=
The LISP = architecture and protocols [RFC6830] introduces two new = The LISP architecture and protocols = [RFC6830] introduces two new
numbering = spaces, Endpoint Identifiers (EIDs) and Routing Locators = numbering spaces, Endpoint Identifiers = (EIDs) and Routing Locators
(RLOCs) which = provide an architecture to build overlays on top of the = (RLOCs) which provide an architecture to = build overlays on top of the
underlying = Internet. Mapping EIDs to RLOC-sets is accomplished with = underlying Internet. Mapping EIDs to = RLOC-sets is accomplished with
a Mapping = Database System. EIDs and RLOCs come in many forms than = a Mapping Database System. EIDs and RLOCs = come in many forms than
just IP = addresses, using a general syntax that includes Address = just IP addresses, using a general syntax = that includes Address
Family = Identifier (AFI) [RFC1700]. Not only IP addresses, but other = Family Identifier (AFI) [RFC1700]. Not only = IP addresses, but other
=
skipping to = change at = page 4, line 32 =C2=B6 = skipping to change at page 4, line 42 =C2=B6
Public-Key = RLOC: is a JSON string that encodes a public-key as an = Public-Key RLOC: is a JSON string that = encodes a public-key as an
RLOC-record = for a Hash-EID mapping entry. The format of the JSON RLOC-record for a Hash-EID mapping entry. The = format of the JSON
string is = '{ "public-key" : "<pubkey>" }'. = string is '{ "public-key" : "<pubkey>" }'.
=
Control-Plane = Signature: a Map-Request or Map-Register sender signs Control-Plane Signature: a Map-Request or = Map-Register sender signs
the message = with its private key. The format of the signature is the message with its private key. The format of = the signature is
a JSON = string that includes sender information and the signature = a JSON string that includes sender = information and the signature
value. The = JSON string is included in Map-Request and Map- value. The JSON string is included in Map-Request = and Map-
Register = messages. Register = messages.
=
Signature-EID: is a Crypto-EID used for a = Control-Plane signature to Signature-ID: is a Crypto-EID used for a = Control-Plane signature to
register = or request any type of EID. The Signature-EID is register or request any type of EID. The Signature-ID is included
included = with the JSON-encoded signature in Map-Request and Map- = with the JSON-encoded signature in Map-Request and Map-Register
Register messages. messages.
= =
= Multi-Signatures: = multiple signatures are used in LISP when an
= entity allows and = authorized another entity to register an EID.
= There can be more = than one authorizing entities that allow a
= registering = entity to register an EID. The authorizing entities
= sign their own = RLOC-records that are registered and merged into
= the registering = entity's Hash-EID public-key mapping. And when
= the registering = entity registers the EID, all authorizing entity
= signatures must = be verified by the Map-Server before the EID is
= = accepted.
=
3. = Overview 3. Overview
=
LISP already = has several message authentication mechanisms. They can = LISP already has several message = authentication mechanisms. They can
be found in = [I-D.ietf-lisp-rfc6833bis], [I-D.ietf-lisp-sec], and be found in [I-D.ietf-lisp-rfc6833bis], = [I-D.ietf-lisp-sec], and
[RFC8061]. = The mechanisms in this draft are providing a more [RFC8061]. The mechanisms in this draft are = providing a more
granular level = of authentication as well as a simpler way to manage granular level of authentication as well as a simpler = way to manage
keys and = passwords. keys and = passwords.
=
A client of = the mapping system can be authenticated using public-key = A client of the mapping system can be = authenticated using public-key
=
skipping to = change at = page 5, line 34 =C2=B6 = skipping to change at page 6, line 20 =C2=B6
client = itself can register. client = itself can register.
=
2. Anyone can = lookup the Hash-EID mappings. These mappings are not 2. Anyone can lookup the Hash-EID mappings. These = mappings are not
usually = authenticated with the mechanisms in this draft but use = usually authenticated with the = mechanisms in this draft but use
the shared = configured password mechanisms from = the shared configured password mechanisms from
= [I-D.ietf-lisp-rfc6833bis] that provide group level [I-D.ietf-lisp-rfc6833bis] that provide group = level
= authentication. = authentication.
=
3. When a = Crypto-EID, or any EID type, is registered to the mapping = 3. When a Crypto-EID, or any EID type, is = registered to the mapping
system, a = signature is included in the Map-Register message. system, a signature is included in the = Map-Register message.
When a = non-Crypto-EID is registered a Signature-EID= is also When a non-Crypto-EID = is registered a Signature-ID is also
included = in the Map-Register message. = included in the Map-Register message.
=
4. The = Map-Server processes the registration by constructing the = 4. The Map-Server processes the = registration by constructing the
Hash-EID = from the registered Crypto-EID, looks up the Hash-EID in = Hash-EID from the registered Crypto-EID, = looks up the Hash-EID in
the = mapping system, obtains the public-key from the RLOC-record = the mapping system, obtains the = public-key from the RLOC-record
and = verifies the signature. If Hash-EID lookup fails or the = and verifies the signature. If Hash-EID = lookup fails or the
signature = verification fails, the Map-Register is not accepted. signature verification fails, the Map-Register is = not accepted.
=
5. When a = Crypto-EID, or any EID type, is looked up in the mapping = 5. When a Crypto-EID, or any EID type, is = looked up in the mapping
system, = a signature is included with a Signature-EID= in the Map- system, a = signature is included with a Signature-ID in the Map-
Request = message. Request = message.
=
6. The = Map-Server processes the request for a Crypto-EID by 6. The Map-Server processes the request for a = Crypto-EID by
= constructing the Hash-EID from the Signature-EID included in the constructing the Hash-EID from the Signature-ID included in the
= Map-Request. The signer-EID is a = Crypto-EID that accompanies a = Map-Request. The signer-ID is a = Crypto-EID that accompanies a
signature = in the Map-Request. The Hash-EID is looked up in the signature in the Map-Request. The Hash-EID is = looked up in the
mapping = system, obtains the public-key from the RLOC-record and = mapping system, obtains the public-key = from the RLOC-record and
verifies = the Map-Request signature. If the Hash-EID lookup fails = verifies the Map-Request signature. If = the Hash-EID lookup fails
or the = signature verification fails, the Map-Request is not or the signature verification fails, the = Map-Request is not
accepted = and a Negative Map-Reply is sent back with an action of = accepted and a Negative Map-Reply is = sent back with an action of
= "auth-failure". = "auth-failure".
=
4. Public-Key = Hash 4. Public-Key Hash
=
When a = private/public key-pair is created for a node, its IPv6 EID is = When a private/public key-pair is created = for a node, its IPv6 EID is
=
skipping to = change at = page 8, line 11 =C2=B6 = skipping to change at page 8, line 45 =C2=B6
of LISP = message sent. See Section 8 and Section 9 for each message = of LISP message sent. See Section 8 and = Section 9 for each message
type. The = signature data is passed through a sha256 hash function = type. The signature data is passed through = a sha256 hash function
before it is = signed or verified. before it is = signed or verified.
=
8. Signed = Map-Register Encoding 8. Signed = Map-Register Encoding
=
When a ETR = registers its Crypto-EID or any EID type to the mapping = When a ETR registers its Crypto-EID or any = EID type to the mapping
system, it = builds a LISP Map-Register message. The mapping includes = system, it builds a LISP Map-Register = message. The mapping includes
an EID-record = which encodes the Crypto-EID, or any EID type, and an an EID-record which encodes the Crypto-EID, or any = EID type, and an
RLOC-set. One = of the RLOC-records in the RLOC-set includes the the RLOC-set. One of the RLOC-records in the RLOC-set = includes the the
ETR's = signature and signature-EID. The = RLOC-record is formatted with = ETR's signature and signature-ID. The RLOC-record is formatted = with
a LCAF JSON = Type, in the following format: a = LCAF JSON Type, in the following format:
=
{ "signature" : "<signature-base64>", = "signature-eid" : "<signer-eid>" } { "signature" : = "<signature-base64>", "signature-id" : "<signer-id>" = }
=
Where = <signature-base64> is a base64 [RFC4648] encoded string = over Where <signature-base64> = is a base64 [RFC4648] encoded string over
the following = ascii [RFC0020] string signature data: = the following ascii [RFC0020] string signature data:
=
= [<iid>]<crypto-eid> = [<iid>]<crypto-eid>
=
Where = <iid> is the decimal value of the instance-ID the Crypto-EID = is Where <iid> is the decimal = value of the instance-ID the Crypto-EID is
registering to = and the <crypto-eid> is in the form of [RFC3513] where = registering to and the <crypto-eid> is = in the form of [RFC3513] where
quad-nibbles = between colons ARE NOT zero-filled. = quad-nibbles between colons ARE NOT zero-filled.
=
=
skipping to = change at = page 8, line 41 =C2=B6 = skipping to change at page 9, line 27 =C2=B6
=
9. Signed = Map-Request Encoding 9. Signed = Map-Request Encoding
=
When an xTR = (an ITR, PITR, or RTR), sends a Map-Request to the When an xTR (an ITR, PITR, or RTR), sends a = Map-Request to the
mapping system = to request the RLOC-set for a Crypto-EID, it signs the mapping system to request the RLOC-set for a = Crypto-EID, it signs the
Map-Request so = it can authenticate itself to the Map-Server the Map-Request so it can authenticate itself to the = Map-Server the
Crypto-EID is = registered to. The Map-Request target-EID field will Crypto-EID is registered to. The Map-Request = target-EID field will
contain the = Crypto-EID and the source-EID field will contain an LCAF = contain the Crypto-EID and the source-EID = field will contain an LCAF
JSON Type = string with the following signature information: JSON Type string with the following signature = information:
=
{ = "source-eid" : "<seid>", "signature-eid" : "<signer-eid>", {
= "signature" : "<signature-base64>" } "source-eid" : "<seid>",
= "signature-id" : "<signer-id>",
= "signature" : = "<signature-base64>"
= }
=
Where = <signer-eid> is an IPv6 encoded = string according to [RFC3513] = Where <signer-id> is an IPv6 encoded string according to = [RFC3513]
where = quad-nibbles between colons ARE NOT zero-filled. The <seid> = is where quad-nibbles between = colons ARE NOT zero-filled. The <seid> is
the source EID = from the data packet that is invoking the Map-Request the source EID from the data packet that is invoking = the Map-Request
or the entire = key/value pair for "source-eid" can be excluded when a or the entire key/value pair for "source-eid" can be = excluded when a
data packet = did not invoke the Map-Request (i.e. lig or an API data packet did not invoke the Map-Request (i.e. lig = or an API
request). = The <signer-eid> is the IPv6 = Crypto-EID of the xTR that is = request). The <signer-id> is the IPv6 Crypto-EID of the xTR that = is
providing the = Map-Request signature. providing = the Map-Request signature.
=
The signature = string <signature-base64> is a base64 [RFC4648] encoded = The signature string = <signature-base64> is a base64 [RFC4648] encoded
string over = the following signature data: = string over the following signature data:
=
= <nonce><source-eid><crypto-eid> = <nonce><source-eid><crypto-eid>
=
Where = <nonce> is a hex string [RFC0020] of the nonce used in the = Map- Where <nonce> is a hex = string [RFC0020] of the nonce used in the Map-
Request and = the <source-eid> and <crypto-eid> are hex strings = Request and the <source-eid> and = <crypto-eid> are hex strings
[RFC0020] of = an IPv6 address in the form of [RFC3513] where quad- [RFC0020] of an IPv6 address in the form of [RFC3513] = where quad-
nibbles = between colons ARE NOT zero-filled. When <seid> is not = nibbles between colons ARE NOT zero-filled. = When <seid> is not
included in = the Map-Request, string "0::0" is used for <source-eid>. = included in the Map-Request, string "0::0" = is used for <source-eid>.
=
10. Other = Uses 10. Signed= Map-Notify Encoding
=
= When a Map-Server = originates a Map-Notify message either as an
= acknowledgment to a = Map-Register message, as a solicited
= = [I-D.ietf-lisp-pubsub] notification, or an unsolicited = [RFC8378]
= notification, the = receiver of the Map-Notify can verify the message
= is from an = authenticated Map-Server.
=
= An RLOC-record = similar to the one used to sign Map-Register messages
= is used to sign the = Map-Notify message:
=
= { "signature" : = "<signature-base64>", "signature-id" : "<signer-id>" = }
=
= Where the = "signature-id" is an IPv6 crypto-EID used by the = Map-Server
= to sign the = RLOC-record. The signature data and the encoding format
= of the signature is = the same as for a Map-Register message. See
= details in Section = 8.
=
= A receiver of a = Map-Notify message will lookup the signature-id in
= the mapping system = to obtain a public-key to verify the signature.
= The Map-Notify is = accepted only if the verification is successful.
=
= 11. Other = Uses
=
The mechanisms = described within this document can be used to sign The mechanisms described within this document can be = used to sign
other types of = LISP messages. And for further study is how to use other types of LISP messages. And for further study = is how to use
these = mechanisms to sign LISP encapsulated data packets in a these mechanisms to sign LISP encapsulated data = packets in a
compressed = manner to reduce data packet header overhead. compressed manner to reduce data packet header = overhead.
=
In addition to = authenticating other types of LISP messages, other In addition to authenticating other types of LISP = messages, other
types of = EID-records can be encoded as well and is not limited to = types of EID-records can be encoded as well = and is not limited to
IPv6 EIDs. It = is possible for a LISP xTR to register and request non IPv6 EIDs. It is possible for a LISP xTR to register = and request non
IPv6 EIDs but = use IPv6 Crypto-EIDs for the sole purpose of signing IPv6 EIDs but use IPv6 Crypto-EIDs for the sole = purpose of signing
=
skipping to = change at = page 9, line 44 =C2=B6 = skipping to change at page 11, line = 17 =C2=B6
= +-----------------------+------------------------------------+ = = +-----------------------+------------------------------------+
| IPv4 = address prefixes | [RFC1123] | = | IPv4 address prefixes | [RFC1123] = |
| = | | | | = |
| = Distinguished-Names | [I-D.farinacci-lisp-name-encoding] | = | Distinguished-Names | = [I-D.farinacci-lisp-name-encoding] |
| = | | | | = |
| = Geo-Coordinates | [I-D.farinacci-lisp-geo] | = | Geo-Coordinates | = [I-D.farinacci-lisp-geo] |
| = | | | | = |
| LCAF = defined EIDs | [RFC8060] | = | LCAF defined EIDs | [RFC8060] = |
= +-----------------------+------------------------------------+ = = +-----------------------+------------------------------------+
=
11. EID Authorization 12. EID = Authorization
=
When a = Crypto-EID is being used for IPv6 communication, it is When a Crypto-EID is being used for IPv6 = communication, it is
implicit that = the owner has the right to use the EID since it was implicit that the owner has the right to use the EID = since it was
generated from = the key-pair provisioned for the owner. For other EID generated from the key-pair provisioned for the = owner. For other EID
types that are = not directly associated with signature keys, they must types that are not directly associated with signature = keys, they must
be validated = for use by the mapping system they are registered to. be validated for use by the mapping system they are = registered to.
This policy = information for the mapping system must be configured in = This policy information for the mapping = system must be configured in
the = Map-Servers the EID owner registers to. the = Map-Servers the EID owner registers to or a = signed authorization
= provided by a = third-party entity.
=
12. Security Considerations To achieve signed = authorization, an entity that allows another entity
= to register an EID, = must authorize the registering entity. It does
= so by adding = RLOC-records to the registering entity's Hash-EID
= public-key mapping. = The format of the RLOC-record is a JSON encoded
= record as = follows:
=
= {
= "allow-eid" : = "<eid>",
= "signature-id" : = "<signer-id>",
= "signature" : = "<signature-base64>"
= }
=
= The format of the = <signer-id> and <signature-base64> values are = the
= same as described in = Section 8. The <eid> value is in the same
= string format as the = signature data described in Section 8. For
= other non-IPv6 EID = types, the conventions in [RFC8060] are used. In
= all cases, the = string encoding format of instance-ID '[<iid>]'
= prepended is to the = EID string.
=
= This entry is added = to the RLOC-set of the registering entity's Hash-
= EID = 'hash-<hash>' registration. The authorizing entity does = signs
= the Map-Register and = sends it with merge-semantics. The Map-Server
= accepts the = registration after the signature is verified and merges
= the RLOC-record into = the existing RLOC-set. The 'signature' is
= optional and when = not included means the authorizing entity has not
= yet allowed the = registering entity to register the EID <eid>. Note
= multiple entities = can register RLOC-records with the same <eid>
= meaning that = signature verification for all of them is required
= before the = Map-Server accepts the registration.
=
= When the Map-Server = receives a Map-Register for <eid>, it looks up
= 'hash-<hash>' = EID in the mapping system. If not found, the Map-
= Register EID-record = is not processed and the next EID-record is
= retrieved from the = Map-Register message, if it exists. If the Hash-
= EID entry is found, = the registering entity's signature is verified
= first. If the = verification fails, the Map-Register EID-record is not
= accepted. = Otherwise, a search for the RLOC-set is done to look for
= all matches of the = EID being registered with <eid>, for those entries
= found, if any of = them do not have a "signature" JSON item, the EID-
= record is not = accepted. Otherwise, the signature-id is looked up in
= the mapping system = to retrieve the public-key of the authorizing
= entity. If the = verification is successful, then a lookup for the
= next RLOC-record = signature-id is done. Only when all signature
= verifications are = verified, the Map-Register EID-record is accepted.
=
= The Map-Server = should reject an RLOC-record with a signature-id that
= contains the = Hash-EID of the entry disallowing a registering entity
= to self authorize = itself.
=
= Here is an example = of a Hash-EID mapping stored in the mapping
= = system:
=
= EID-record: = [1000]'hash-1111:2222:3333:4444', RLOC-Set (count is 4):
=
= RLOC-record: { = "public-key" : "<pubkey-base64>" }
= RLOC-record: { = "allow-eid" : "[1000]1.1.1.1/32", "signature" : = "<sig>",
= = "signature-id" : "[1000]2001:5:3::1111" }
= RLOC-record: { = "allow-eid" : "[1000]1.1.1.1/32", "signature" : = "<sig>",
= = "signature-id" : "[1000]2001:5:3::2222" }
= RLOC-record: { = "allow-eid" : "37-16-46-N-121-52-4-W",
= = "signature-id" : "[1000]2001:5:3::5555" }
=
= This mapping stores = the public-key of the registering entity with
= Hash-EID = 1111:2222:3333:4444. The registering entry registered = this
= RLOC-record. There = are two authorizing entities, :1111 and :2222,
= who allow it to = register IPv4 EID 1.1.1.1/32. They each registered
= their respective = RLOC-records. And a third authorizing entity :5555
= that registers an = RLOC-record that has not yet authorized the
= registering entity = to register Geo-Coordinate 37-16-46-N-121-52-4-W.
= Note the mapping and = the signature-IDs are all within the context of
= instance-ID = 1000.
=
= 13. Security = Considerations
=
The mechanisms = within this specification are intentionally using The mechanisms within this specification are = intentionally using
accepted = practices and state of the art public-key cryptography. = accepted practices and state of the art = public-key cryptography.
=
Crypto-EIDs = can be made private when control messages are encrypted, = Crypto-EIDs can be made private when control = messages are encrypted,
for instance, = using [RFC8061]. for instance, = using [RFC8061].
=
The = topological or physical location of a Crypto-EID is only = The topological or physical location of a = Crypto-EID is only
available to = the other Crypto-EIDs that register in the same LISP available to the other Crypto-EIDs that register in = the same LISP
Instance-ID = and have their corresponding Hash-EIDs registered. Instance-ID and have their corresponding Hash-EIDs = registered.
=
skipping to = change at = page 10, line 27 =C2=B6 = skipping to change at page 13, line = 27 =C2=B6
This draft = doesn't address reply attacks directly. If a man-in-the- = This draft doesn't address reply attacks = directly. If a man-in-the-
middle = captures Map-Register messages, it could send such captured = middle captures Map-Register messages, it = could send such captured
packets at a = later time which contains signatures of the source. In = packets at a later time which contains = signatures of the source. In
which case, = the Map-Server verifies the signature as good and which case, the Map-Server verifies the signature as = good and
interprets the = contents to be valid where in fact the contents can interprets the contents to be valid where in fact the = contents can
contain old = mapping information. This problem can be solved by contain old mapping information. This problem can be = solved by
encrypting the = contents of Map-Registers using a third-party protocol encrypting the contents of Map-Registers using a = third-party protocol
like DTLS = [RFC6347] or LISP-Crypto [RFC8061] directly by like DTLS [RFC6347] or LISP-Crypto [RFC8061] directly = by
encapsulating = Map-Registers in LISP data packets (using port 4341). encapsulating Map-Registers in LISP data packets = (using port 4341).
=
13. IANA Considerations Map-Reply message signatures = and authentication are not in scope for
= this document. This = document focuses on authentication between xTRs
= and mapping system = components. Map-Reply authentication, which is
= performed between = xTRs is described in [I-D.ietf-lisp-sec].
=
= 14. IANA = Considerations
=
Since there = are no new packet formats introduced for the Since there are no new packet formats introduced for = the
functionality = in this specification, there are no specific requests functionality in this specification, there are no = specific requests
for = IANA. for IANA.
=
14. References 15. References
=
14.1. Normative References 15.1. Normative = References
=
[RFC0020] = Cerf, V., "ASCII format for network interchange", STD 80, = [RFC0020] Cerf, V., "ASCII format for = network interchange", STD 80,
RFC = 20, DOI 10.17487/RFC0020, October 1969, = RFC 20, DOI 10.17487/RFC0020, October 1969,
= <https://www.rfc-editor.org/info/rfc20>. = <https://www.rfc-editor.org/info/rfc20>.
=
[RFC1123] = Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for = Internet Hosts -
= Application and Support", STD 3, RFC 1123, Application and Support", STD 3, RFC = 1123,
DOI = 10.17487/RFC1123, October 1989, = DOI 10.17487/RFC1123, October 1989,
= <https://www.rfc-editor.org/info/rfc1123>. = <https://www.rfc-editor.org/info/rfc1123>.
=
=
skipping to = change at = page 11, line 46 =C2=B6 = skipping to change at page 15, line 5 =C2=B6
=
[RFC8060] = Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical = [RFC8060] Farinacci, D., Meyer, D., and J. = Snijders, "LISP Canonical
= Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, = Address Format (LCAF)", RFC 8060, = DOI 10.17487/RFC8060,
= February 2017, <https://www.rfc-editor.org/info/rfc8060>. = February 2017, = <https://www.rfc-editor.org/info/rfc8060>.
=
[RFC8061] = Farinacci, D. and B. Weis, "Locator/ID Separation Protocol = [RFC8061] Farinacci, D. and B. Weis, = "Locator/ID Separation Protocol
= (LISP) Data-Plane Confidentiality", RFC 8061, (LISP) Data-Plane Confidentiality", RFC = 8061,
DOI = 10.17487/RFC8061, February 2017, = DOI 10.17487/RFC8061, February 2017,
= <https://www.rfc-editor.org/info/rfc8061>. = <https://www.rfc-editor.org/info/rfc8061>.
=
14.2. Informative References [RFC8378] Moreno, V. and D. = Farinacci, "Signal-Free Locator/ID
= = Separation Protocol (LISP) Multicast", RFC 8378,
= DOI = 10.17487/RFC8378, May 2018,
= = <https://www.rfc-editor.org/info/rfc8378>.
=
= 15.2. = Informative References
=
[AFI] = IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY = [AFI] IANA, "Address Family Identifier = (AFIs)", ADDRESS FAMILY
= NUMBERS http://www.iana.org/assignments/address-family- = NUMBERS = http://www.iana.org/assignments/address-family-
= numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, = February 2007.
=
= [I-D.farinacci-lisp-geo] = [I-D.farinacci-lisp-geo]
= Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft- Farinacci, D., "LISP Geo-Coordinate = Use-Cases", draft-
= farinacci-lisp-geo-05 (work in progress), April 2018. farinacci-lisp-geo-05 (work in progress), = April 2018.
=
= [I-D.farinacci-lisp-name-encoding] = [I-D.farinacci-lisp-name-encoding]
= Farinacci, D., "LISP Distinguished Name Encoding", draft- = Farinacci, D., "LISP = Distinguished Name Encoding", draft-
= farinacci-lisp-name-encoding-05 (work in progress), March = farinacci-lisp-name-encoding-05 = (work in progress), March
= 2018. 2018.
=
= [I-D.ietf-lisp-pubsub]
= = Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
= = Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
= = Boucadair, M., Jacquenet, C., and S. Secci, "Publish/
= Subscribe = Functionality for LISP", draft-ietf-lisp-
= pubsub-00 = (work in progress), April 2018.
= =
= [I-D.ietf-lisp-rfc6833bis] = [I-D.ietf-lisp-rfc6833bis]
= Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. = Cabellos-Aparicio,
= "Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) = Control-Plane",
= draft-ietf-lisp-rfc6833bis-10 (work in progress), = March = draft-ietf-lisp-rfc6833bis-13 (work in progress), = August
= 2018. 2018.
=
= [I-D.ietf-lisp-sec] = [I-D.ietf-lisp-sec]
= Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, = A., and D.
= Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 = Saucez, "LISP-Security = (LISP-SEC)", draft-ietf-lisp-sec-15
= (work in progress), April 2018. = (work in progress), April 2018.
=
[X9.62] = American National Standards Institute, "Public Key [X9.62] American National Standards Institute, = "Public Key
= Cryptography for the Financial Services Industry: The Cryptography for the Financial Services = Industry: The
= Elliptic Curve Digital Signature Algorithm (ECDSA)", Elliptic Curve Digital Signature Algorithm = (ECDSA)",
= NIST ANSI X9.62-2005, November 2005. = NIST ANSI X9.62-2005, November 2005.
=
Appendix A. = Acknowledgments Appendix A. = Acknowledgments
=
A special = thanks goes to Sameer Merchant for his = ideas and technical A special = thanks goes to Sameer Merchant and Colin = Cantrell for their
= contributions to the ideas in this draft. ideas and technical contributions to the ideas in = this draft.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-farinacci-lisp-ecdsa-auth-02.txt B.1. Changes to draft-farinacci-lisp-ecdsa-auth-03.txt
=
= o Posted September = 2018.
=
= o Change all = occurrences of signature-EID to signature-ID.
=
= o Document how = Map-Servers sign Map-Notify messages so they can be
= verified by = xTRs.
=
= o Add = multi-signatures to mappings so a 3rd-party can allow an
= entity to = register any type of EID.
=
= B.2. Changes to = draft-farinacci-lisp-ecdsa-auth-02.txt
=
o Draft = posted April 2018. o Draft posted = April 2018.
=
o = Generalize text to allow Map-Reqeusting = and Map-Registering for o = Generalize text to allow Map-Requesting = and Map-Registering for
any EID = type with a proper signature-EID and signature encoded any EID type with a proper signature-EID and = signature encoded
= together. together.
=
B.2. Changes to = draft-farinacci-lisp-ecdsa-auth-01.txt B.3. Changes to = draft-farinacci-lisp-ecdsa-auth-01.txt
=
o Draft = posted October 2017. o Draft = posted October 2017.
=
o Make it = more clear what values and format the EID hash is run o Make it more clear what values and format the EID = hash is run
= over. over.
=
o Update = references to newer RFCs and Internet Drafts. o Update references to newer RFCs and Internet = Drafts.
=
B.3. Changes to = draft-farinacci-lisp-ecdsa-auth-00.txt B.4. Changes to = draft-farinacci-lisp-ecdsa-auth-00.txt
=
o Initial = draft posted July 2017. o Initial = draft posted July 2017.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
= lispers.net lispers.net
San Jose, = CA San Jose, CA
USA = USA
=
 End of changes. 32 change blocks. 
51 lines changed or = deleted 190 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_FDC9A972-FA97-4A0B-B8D3-B38879D71A8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = I-D Action: = draft-farinacci-lisp-ecdsa-auth-03.txt
Date: = September 4, 2018 at 12:00:14 = PM PDT
To: = <i-d-announce@ietf.org>
Reply-To: = internet-drafts@ietf.org


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


=        Title =           : LISP = Control-Plane ECDSA Authentication and Authorization
=        Authors =         : Dino Farinacci
=             &n= bsp;           &nbs= p;Erik Nordmark
Filename =        : = draft-farinacci-lisp-ecdsa-auth-03.txt
Pages =           : 17
= Date =            : = 2018-09-04

Abstract:
=   This draft describes how LISP control-plane messages can = be
  individually authenticated and authorized = without a a priori shared-
  key configuration. =  Public-key cryptography is used with no new PKI
=   infrastructure required.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-aut= h/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03<= br = class=3D"">https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecds= a-auth-03

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-ecdsa-= auth-03


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

= --Apple-Mail=_FDC9A972-FA97-4A0B-B8D3-B38879D71A8C-- --Apple-Mail=_B3B0C1C2-E4EA-49B5-A4AB-81460C454B2D-- From nobody Wed Sep 5 00:46:46 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8913E130E04 for ; Wed, 5 Sep 2018 00:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 qgbmppxHx_lI for ; Wed, 5 Sep 2018 00:46:39 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 36695130DEA for ; Wed, 5 Sep 2018 00:46:39 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id o18-v6so6663508wmc.0 for ; Wed, 05 Sep 2018 00:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6RbcNM7iuY6u7SFmq6UB8MsGaO5FG8+OdUlEQD958QA=; b=kNWXf/5u+gT1uhdbSYxC0bxQuSfI/sHIuvztDqYk4w+m+kCjeElCDVYqOe82+kh7gR 1l3ESxqNWpQJen6mzNLBzv8UWWtbK9vAqJtK3om/j95EfC+0Gl0Zq1/ZS/sDK9jV+JQF adPCf4slvlkz1KGjTrVGe6Mi4PkQji1eQykvNvJCNkVNIU1btlxHhd+Mv2RpoRbpRoqY YivYhl+3sT0nfN4LWHmZjed4NiPPOarmYpqXgg/WJGkB9UWQzqU0GAukiZF9wAV6Q/yd 1Ljbz5YMOqp+hd6swIyMXNYIn/ll2a4X8fAVPcJoF4YCIBTt6qzXxWzb3jkfkMMgZHvX nDXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6RbcNM7iuY6u7SFmq6UB8MsGaO5FG8+OdUlEQD958QA=; b=JWrMXInmxV7klhvMZyk7J/kZor989LJL92CoCuSwqMSjOoc+qq0dn2p2D6Knbwr2j/ mhrOZ94E6dyDMRVp4QQ6gsFWQzYN+xX0rs0qq8wfnbzPEnzZPzPkI56C5YOlKo7cr1Zj FM8YrLAwaUM4aJhA5hCM6+VDKCN/1hFS+CHHP/m5l0XdMpWf5amfGj3O0G0AVjlXaU3+ 6a7rSucsVaHZXi2zJmpVWQd+e0nB/aVigZWhaveEa6AOYTdegXuv4ynx9z8YkVnEj38t o56s6H/8s+1eo0I3dcw1NkNq7bEp7LtIWnbl44zgQa9MaGBD+mRaAVkLCvnE9mijscCf bhJQ== X-Gm-Message-State: APzg51Be6I4LpGGilPCWx8AhpiE87uj4NTzsL9mcOhihwBcbe7FWTFAg 0/86rwur2sP4p/l0HwNEoGTZz9L0KRI= X-Google-Smtp-Source: ANB0VdaOJ4D8o2bOG3FIPu2LNgxvVzWPckh7Zaq3rgkvUEkv4ZLZ8Qpp0b2JsuMzeGvzMyYlsTeO6g== X-Received: by 2002:a1c:2703:: with SMTP id n3-v6mr10210972wmn.153.1536133597258; Wed, 05 Sep 2018 00:46:37 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:e1c7:99c8:9e70:6ba5? ([2001:660:330f:a4:e1c7:99c8:9e70:6ba5]) by smtp.gmail.com with ESMTPSA id m68-v6sm2602873wmb.10.2018.09.05.00.46.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 00:46:35 -0700 (PDT) From: Luigi Iannone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_73859F02-EAF7-4AF9-8CFD-133DCFE3B0C4" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 5 Sep 2018 09:46:27 +0200 In-Reply-To: Cc: Erik Nordmark , Dino Farinacci , lisp-chairs@ietf.org To: "lisp@ietf.org list" References: <153608761426.14137.783984991533026116@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 07:46:45 -0000 --Apple-Mail=_73859F02-EAF7-4AF9-8CFD-133DCFE3B0C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Folks, As you can see from Dino=E2=80=99s email (below) the authors are = requesting that the document https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ = be adopted as WG item. This email starts the usual 14 days call for adoption, this call will = end on Thursday the 19th September, 2018. Please email the WG list stating whether or not you support acceptance. If you email to support the acceptance of this document as a WG item, = please also indicate if you are able and willing to either contribute to, or = review, (or both) the draft. Sitting in silence does not indicate support, please respond = appropriately. The Chairs Joel & Luigi > On 4 Sep 2018, at 21:05, Dino Farinacci wrote: >=20 > Folks, here is an update that reflects comments we received at the = Montreal presentation: >=20 > >=20 > A diff file is included for your convenience.=20 >=20 > At this time, I would like to request this document for working group = adoption. >=20 > Thanks, > Dino/Erik >=20 > >=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt >> Date: September 4, 2018 at 12:00:14 PM PDT >> To: > >> Reply-To: internet-drafts@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : LISP Control-Plane ECDSA Authentication and = Authorization >> Authors : Dino Farinacci >> Erik Nordmark >> Filename : draft-farinacci-lisp-ecdsa-auth-03.txt >> Pages : 17 >> Date : 2018-09-04 >>=20 >> Abstract: >> This draft describes how LISP control-plane messages can be >> individually authenticated and authorized without a a priori = shared- >> key configuration. Public-key cryptography is used with no new PKI >> infrastructure required. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ = >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03 >> = https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecdsa-auth-03 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-ecdsa-auth-03 >>=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 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_73859F02-EAF7-4AF9-8CFD-133DCFE3B0C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Folks,

As = you can see from Dino=E2=80=99s email (below) the authors are requesting = that the document

https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-aut= h/

be = adopted as WG item.

This email starts the usual 14 days call for adoption, this = call will end on
Thursday the 19th September, = 2018.

Please email the WG list stating = whether or not you support acceptance.

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

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

The = Chairs
Joel & Luigi


On 4 Sep 2018, at 21:05, Dino Farinacci <farinacci@gmail.com>= wrote:

Folks, = here is an update that reflects comments we received at the Montreal = presentation:

<PastedGraphic-= 1.png>

A diff file is included for your convenience. 

At this time, I would = like to request this document for working group adoption.

Thanks,
Dino/Erik

<rfcdiff-ecdsa.= html>


Begin forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt
Date: September 4, 2018 at 12:00:14 PM PDT
To: <i-d-announce@ietf.org>
Reply-To: internet-drafts@ietf.org


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


=        Title =           : LISP = Control-Plane ECDSA Authentication and Authorization
=        Authors =         : Dino Farinacci
=             &n= bsp;           &nbs= p;Erik Nordmark
Filename =        : = draft-farinacci-lisp-ecdsa-auth-03.txt
Pages =           : 17
= Date =            : = 2018-09-04

Abstract:
=   This draft describes how LISP control-plane messages can = be
  individually authenticated and authorized = without a a priori shared-
  key configuration. =  Public-key cryptography is used with no new PKI
=   infrastructure required.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-aut= h/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03<= /a>
https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecds= a-auth-03

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-ecdsa-= auth-03


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

= --Apple-Mail=_73859F02-EAF7-4AF9-8CFD-133DCFE3B0C4-- From nobody Wed Sep 5 00:48:12 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9FD130DFA for ; Wed, 5 Sep 2018 00:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 l3e2AZJKxiPp for ; Wed, 5 Sep 2018 00:48:06 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 08C96130DEA for ; Wed, 5 Sep 2018 00:48:06 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id t25-v6so6616144wmi.3 for ; Wed, 05 Sep 2018 00:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=J/k4z4t+5C3j0kek3WxAG7/WlGYTWmk81TnNa1RK4L0=; b=mL8Nr1B1uPKvpClpBZDWzk7WqimGN7kDW6IkIULJNbDqcMJkPVeJus1LbwVTtWu0ef cui0GlGe9QfdyNrhT49nbYMDmZ1MAZEG4qenR7Z2DFMicmVvQysk1/g+EXixieQMxE2+ 3JSakw81BSAENgQ9sq7gjKDzJeCC/cNnfLpIboK+CFarmwUXPEBSXGMiYYXnndBcUUDd xyJBcebNhOSXuZjNOcqDpBxsstgR34feHJy6SvD2ncRLdFnAJAqrBlXw9xiZNMvGyp6I RQuvaYGBFtnbOiPJa1Y4fGYO6bBGXtWY8vEadXHqIXeC+3XbDir5bz8GnwWB2OsLBJJW lNrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=J/k4z4t+5C3j0kek3WxAG7/WlGYTWmk81TnNa1RK4L0=; b=IgkXYoajsLF6ArgTVa5cbVc2EJKTTvpGUkqnaEhLIk/x+mEHaxBp6r6G3+vXiaSv85 kLrhGEvb3BpHZbA9Hd1YSrJatrqEUjGVtbOgwEkWN2tEKPJFj60pb4curZxNgP62DfOV Rg6wKs2VikWpMAAlWRP9xwg8nAqOxEKGhyvkzt+aMdloJhBzU0ceRTqtDo0IxfuHfn+a a1+ZxXedZq/F9Wi2kW3/Wl41oFI1Z7YRMzrLcUXzM/XqOwEFECLUcdAOK+L+J6z7sqV3 5jtl2rpS+oc+wCGyqZKILsp2BKxWjzeO0q4oYcpgBuvmXxWccPfrmahzS97hBk3b0fBg zymg== X-Gm-Message-State: APzg51DC8bS2VALw20cQxMOzbMTBHU9ge59IINYXrh4rKmAE4s0KA6y/ KXBrG6You8q+JtXt38dSp02TCeTI/zw= X-Google-Smtp-Source: ANB0VdY+LKIjxOhkg9WlhDZhHPoolu/MByS3rbo4UdGH9NHKjoqiqc/tmiE3cE3JIRamzqfj9e6B4Q== X-Received: by 2002:a1c:c3c6:: with SMTP id t189-v6mr4894536wmf.59.1536133684186; Wed, 05 Sep 2018 00:48:04 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:e1c7:99c8:9e70:6ba5? ([2001:660:330f:a4:e1c7:99c8:9e70:6ba5]) by smtp.gmail.com with ESMTPSA id w15-v6sm1653521wrs.8.2018.09.05.00.48.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 00:48:03 -0700 (PDT) From: Luigi Iannone Message-Id: <9807BB97-D034-4169-9BBC-366D66164238@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_FE1BAFAE-7463-4B2B-9BC4-3665D411F330" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 5 Sep 2018 09:48:00 +0200 In-Reply-To: Cc: Erik Nordmark , Dino Farinacci , lisp-chairs@ietf.org To: "lisp@ietf.org list" References: <153608761426.14137.783984991533026116@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 07:48:10 -0000 --Apple-Mail=_FE1BAFAE-7463-4B2B-9BC4-3665D411F330 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Sep 2018, at 09:46, Luigi Iannone wrote: >=20 > Folks, >=20 > As you can see from Dino=E2=80=99s email (below) the authors are = requesting that the document >=20 > https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ = >=20 > be adopted as WG item. >=20 > This email starts the usual 14 days call for adoption, this call will = end on > Thursday the 19th September, 2018. Small typo in the ending date: Wednesday 19th September, 2018. Ciao L. >=20 > Please email the WG list stating whether or not you support = acceptance. >=20 > If you email to support the acceptance of this document as a WG item, = please > also indicate if you are able and willing to either contribute to, or = review, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond = appropriately. >=20 > The Chairs > Joel & Luigi >=20 >=20 >> On 4 Sep 2018, at 21:05, Dino Farinacci > wrote: >>=20 >> Folks, here is an update that reflects comments we received at the = Montreal presentation: >>=20 >> >>=20 >> A diff file is included for your convenience.=20 >>=20 >> At this time, I would like to request this document for working group = adoption. >>=20 >> Thanks, >> Dino/Erik >>=20 >> >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> Subject: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt >>> Date: September 4, 2018 at 12:00:14 PM PDT >>> To: > >>> Reply-To: internet-drafts@ietf.org >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>=20 >>>=20 >>> Title : LISP Control-Plane ECDSA Authentication and = Authorization >>> Authors : Dino Farinacci >>> Erik Nordmark >>> Filename : draft-farinacci-lisp-ecdsa-auth-03.txt >>> Pages : 17 >>> Date : 2018-09-04 >>>=20 >>> Abstract: >>> This draft describes how LISP control-plane messages can be >>> individually authenticated and authorized without a a priori = shared- >>> key configuration. Public-key cryptography is used with no new = PKI >>> infrastructure required. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ = >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03 = >>> = https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecdsa-auth-03 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-ecdsa-auth-03= >>>=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 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 --Apple-Mail=_FE1BAFAE-7463-4B2B-9BC4-3665D411F330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 5 Sep 2018, at 09:46, Luigi Iannone <ggx@gigix.net> = wrote:

Folks,

As you can see from = Dino=E2=80=99s email (below) the authors are requesting that the = document

https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-aut= h/

be = adopted as WG item.

This email starts the usual 14 days call for adoption, this = call will end on
Thursday the 19th September, = 2018.

Small typo in the ending date: Wednesday 19th = September, 2018.

Ciao

L.




Please email the WG list stating whether or not you support = acceptance.

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

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

The Chairs
Joel & Luigi


On 4 Sep 2018, at 21:05, Dino Farinacci <farinacci@gmail.com>= wrote:

Folks, = here is an update that reflects comments we received at the Montreal = presentation:

<PastedGraphic-1.png>

A diff file is included for your = convenience. 

At this time, I would like to request this document for = working group adoption.

Thanks,
Dino/Erik
<rfcdiff-ecdsa.html>


Begin = forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt
Date: September 4, 2018 at 12:00:14 PM PDT
To: <i-d-announce@ietf.org>
Reply-To: internet-drafts@ietf.org


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


=        Title =           : LISP = Control-Plane ECDSA Authentication and Authorization
=        Authors =         : Dino Farinacci
=             &n= bsp;           &nbs= p;Erik Nordmark
Filename =        : = draft-farinacci-lisp-ecdsa-auth-03.txt
Pages =           : 17
= Date =            : = 2018-09-04

Abstract:
=   This draft describes how LISP control-plane messages can = be
  individually authenticated and authorized = without a a priori shared-
  key configuration. =  Public-key cryptography is used with no new PKI
=   infrastructure required.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-aut= h/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03<= /a>
https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecds= a-auth-03

A diff from the previous = version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-ecdsa-= auth-03


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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


= --Apple-Mail=_FE1BAFAE-7463-4B2B-9BC4-3665D411F330-- From nobody Wed Sep 5 02:27:09 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD99130E67; Wed, 5 Sep 2018 02:27:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153613962629.19826.14700309732033230613@ietfa.amsl.com> Date: Wed, 05 Sep 2018 02:27:06 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-6834bis-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 09:27:08 -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 WG of the IETF. Title : Locator/ID Separation Protocol (LISP) Map-Versioning Authors : Luigi Iannone Damien Saucez Olivier Bonaventure Filename : draft-ietf-lisp-6834bis-01.txt Pages : 20 Date : 2018-09-05 Abstract: This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism. This document obsoletes RFC 6834 "Locator/ID Separation Protocl (LISP) Map-Versionin", which is the initial experimental specifications of the mechanisms updated by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-6834bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-6834bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-6834bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-6834bis-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 Wed Sep 5 10:17:45 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C1A130E3A; Wed, 5 Sep 2018 10:17:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Pete Resnick To: Cc: draft-ietf-lisp-rfc6833bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153616785215.19847.9068125271782801845@ietfa.amsl.com> Date: Wed, 05 Sep 2018 10:17:32 -0700 Archived-At: Subject: [lisp] Genart last call review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 17:17:33 -0000 Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lisp-rfc6833bis-13 Reviewer: Pete Resnick Review Date: 2018-09-05 IETF LC End Date: 2018-08-31 IESG Telechat date: 2018-09-13 Summary: Ready with Nits By no means my area of expertise, but particularly comparing this document to 6833, it's clear what changed and the new material looks reasonable. One overall nitty thing below. Major issues: None. Minor issues: None. Nits/editorial comments: Somebody went a bit "2119-mad" in this document. In particular, *most* of the MAYs are just goofy and wrong, and many of the SHOULDs shouldn't be there. When you're putting in a 2119 keyword, they should point out a place where an implementer needs to look to make sure they get their implementation correct. A lot of these aren't helpful in that regard. A few examples: In 8.2: In addition to the set of EID-Prefixes defined for each ETR that MAY register, That's not a protocol option being described. (such as those indicating whether the message is authoritative and how returned Locators SHOULD be treated) That's not a piece of implementation advice. In 8.3: This MAY occur if a Map Request is received for a configured aggregate EID-Prefix for which no more- specific EID-Prefix exists; If "MAY" can be replaced with "might or might not", you probably want "may" or "can". Unless also acting as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; That's a statement of fact, not an implementation instruction. Please go through and get rid of the bogus ones. If it's not an indication of an implementation option (or lack thereof), it shouldn't be 2119ed. From nobody Wed Sep 5 10:34:56 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D2F130D7A; Wed, 5 Sep 2018 10:34: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8CL8Q8ufZ9yc; Wed, 5 Sep 2018 10:34:47 -0700 (PDT) Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 067C712426A; Wed, 5 Sep 2018 10:34:47 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id x26-v6so3764872pge.12; Wed, 05 Sep 2018 10:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RWkDiEWKqmTwRizeZYG9SYr2JFp7xglb9j3q8A4qBDU=; b=qUOngfy+umxwjMH7T+ejD4npKXR1KybS5/z03AW9w+nbGe2V4JDD0ZOf4UD1GJQziY ixq+tVm5g8B5bOk+/ve57bdFIkYF/dQP4dihGvuCDIX2f7qWQijkm10rJvkDkXFFYaOR nzEnPTVHFRMa5Ly2vm/fiahrBBx5TTtl+1fP83X9fKASZcC7/SZ2oS6VxkLv+MoAuoMW nOZrp2QBDnRaWLYfUPbCs1o31t9bvUX3kAEy+b8KFQaolsDgctDSFkxrSoOh7PMhF6qw Vrxvf6ST0O2Dfa1rPEp8BgSMXcWKdykTOjTB/LAH4sjGHsoly9PP8BQel9KgBmmImpSA dZTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RWkDiEWKqmTwRizeZYG9SYr2JFp7xglb9j3q8A4qBDU=; b=p5a3GTsYZipBgvThFdqctWVMGUY8Ta7j8o6+Q0RAQZ2mEwACvBwgYl2r9AaYvih0OB wxccV1zh830OnmcOhi9LIvQzcd+WhK+vXAWs7Myc8mCWCv181nd+fVaD0fLk4cUa6Om9 8PBjZ2VRTECR6R/nobP2y32DOrtEB46D5d8EZB3pe9wkh8DiCVWFGTnLPj+J2cuzGz8k sLrmB6xy/7SC5Ho4F81vuQUAR+UF5zFfdVnrGJ9sOMRSj80DzpjRfjTxogNHlJGFzp0H 6tSqOYQ13+1sPK6T4hrlDqqNFENqle3LhoDPXa8Wb7jdD1T+TCX+n+ktbHCgi612zIr0 njLQ== X-Gm-Message-State: APzg51DXUpmO6SbYxrsS2vp7iuLd98g++fVFXC989On8N9//6BSpK01Q PUec4ASt5DcxlTtaiJ41Z1k= X-Google-Smtp-Source: ANB0VdYCjFvir/5HG4hFqRDUyMT3Uk6ekUe2IJGtNJ/5tfnHR0l7fZujzq+z5WTnExp8ct6mOmzkVQ== X-Received: by 2002:a63:2e09:: with SMTP id u9-v6mr36519960pgu.294.1536168886608; Wed, 05 Sep 2018 10:34:46 -0700 (PDT) Received: from ?IPv6:2603:3024:151c:55f0:1cbc:f935:ea82:3c5e? ([2603:3024:151c:55f0:1cbc:f935:ea82:3c5e]) by smtp.gmail.com with ESMTPSA id 1-v6sm5956226pfm.145.2018.09.05.10.34.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 10:34:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153616785215.19847.9068125271782801845@ietfa.amsl.com> Date: Wed, 5 Sep 2018 10:34:43 -0700 Cc: General Area Review Team , draft-ietf-lisp-rfc6833bis.all@ietf.org, IETF Discussion Mailing List , Dino Farinacci , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <31DDA602-60ED-46DC-B7CE-65E2415038DF@gmail.com> References: <153616785215.19847.9068125271782801845@ietfa.amsl.com> To: Pete Resnick X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 17:34:49 -0000 > Reviewer: Pete Resnick > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . Thanks a lot for your review Pete. > Document: draft-ietf-lisp-rfc6833bis-13 > Reviewer: Pete Resnick > Review Date: 2018-09-05 > IETF LC End Date: 2018-08-31 > IESG Telechat date: 2018-09-13 >=20 > Summary: Ready with Nits >=20 > By no means my area of expertise, but particularly comparing this = document to > 6833, it's clear what changed and the new material looks reasonable. = One > overall nitty thing below. >=20 > Major issues: >=20 > None. >=20 > Minor issues: >=20 > None. >=20 > Nits/editorial comments: >=20 > Somebody went a bit "2119-mad" in this document. In particular, *most* = of the > MAYs are just goofy and wrong, and many of the SHOULDs shouldn't be = there. When > you're putting in a 2119 keyword, they should point out a place where = an > implementer needs to look to make sure they get their implementation = correct. A > lot of these aren't helpful in that regard. A few examples: Well we were encouraged by the working group. I will fix this up a bit. = Thanks for your opinion.=20 > In 8.2: >=20 > In addition to the set of EID-Prefixes defined for each ETR that MAY > register, >=20 > That's not a protocol option being described. >=20 > (such as those > indicating whether the message is authoritative and how returned > Locators SHOULD be treated) >=20 > That's not a piece of implementation advice. Fixed. >=20 > In 8.3: >=20 > This MAY occur if a Map Request is > received for a configured aggregate EID-Prefix for which no more- > specific EID-Prefix exists; >=20 > If "MAY" can be replaced with "might or might not", you probably want = "may" or > "can=E2=80=9D. Used =E2=80=9Ccan=E2=80=9D. > Unless also acting > as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; >=20 > That's a statement of fact, not an implementation instruction. >=20 > Please go through and get rid of the bogus ones. If it's not an = indication of > an implementation option (or lack thereof), it shouldn't be 2119ed. Done. Thanks again. Dino From nobody Wed Sep 5 10:54:17 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB89130DE2; Wed, 5 Sep 2018 10:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TEEPhGRfJiBj; Wed, 5 Sep 2018 10:53:23 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 E949A130E9E; Wed, 5 Sep 2018 10:53:22 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id 7-v6so3811687pgf.2; Wed, 05 Sep 2018 10:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oqUYM+Z+WRygCt4O+yfKvroRbhQ4kC4vbEa0JUmhAXU=; b=IiN1KYKGJqSyQAAnBLra75yPoxqyn9ceMkX8asRTW7SeYNVnhhh2AqHN/19o1eTOp2 PST5mPwuL127MdTnDZ50V1p6APJgetsR6tamCwW2mypujBw88ja/6C9GWJsiDmDdvR9R bjiN6ipIeFhmQpEGr5xsWRiEO0CLUwLq4oyNTd1iC7CL7xd/8QTtlx3j8VT4EsytKJVs zCi447J8oOsVIYqrtzZDZtX1b2oAe0fwuaIKP4lXXN7hm6N4hY7Ao1wgGwM0IyT9ob3w vAAn6IsF+4V2SkTnXLOdjArM8i+HZNTTzbq1HQMqpR2yXCYBTgibMFf/ArFaLwrOgtQg oOdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oqUYM+Z+WRygCt4O+yfKvroRbhQ4kC4vbEa0JUmhAXU=; b=buu438DqPAWBNXM2Lumcr1BxR/Q/YldbpGFee7MZTPmjopcaWwHLZFIAVevZ1JKtI3 arB86yOZ/dQpbSBZIwudyRizI6Ym3Sp32esfuoGZO6cgtk8tD7Dqw4wyIgIk5UxCDXT+ oJ8b7JoOPKVVHM8Ysf1XISi3soKe46J5Lp90TCjMFi7rY40UUmDPYDij/gGEmSGmVKVX avZcPyx/6eWOLUVUm13nDkYRyRqrqLYOON2LsSfBM1mcwNGiWDEmAc0hWnexoTqDx+/i 5AUE9BtdKi3wlJlNyMwsfhPugRHk6SnNHdTYvRHUl/f6TXw7GfUmLuPsWcOM+8ImYwOk IHjA== X-Gm-Message-State: APzg51DX2ulibICU5KA9y+3aT8uRUJbcagNZNuspu7GMTfrIEBbmH0mk NPd6Te8+nnP+GGCRikCkpx/c7NTc X-Google-Smtp-Source: ANB0VdaDNSv3WTP3wgWzR79ewIO72TEF06r5xSjDUIJapVXB+9jT4SrkXWpE2fS8RhryOanh3LV27w== X-Received: by 2002:aa7:8713:: with SMTP id b19-v6mr41686830pfo.151.1536170002532; Wed, 05 Sep 2018 10:53:22 -0700 (PDT) Received: from ?IPv6:2603:3024:151c:55f0:1cbc:f935:ea82:3c5e? ([2603:3024:151c:55f0:1cbc:f935:ea82:3c5e]) by smtp.gmail.com with ESMTPSA id g6-v6sm4378583pfb.11.2018.09.05.10.53.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 10:53:21 -0700 (PDT) From: Dino Farinacci Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_751AD908-A4E3-4D80-B125-B1FB46FF50BD" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 5 Sep 2018 10:53:18 -0700 In-Reply-To: <153616785215.19847.9068125271782801845@ietfa.amsl.com> Cc: gen-art@ietf.org, draft-ietf-lisp-rfc6833bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org To: Pete Resnick References: <153616785215.19847.9068125271782801845@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 17:53:41 -0000 --Apple-Mail=_751AD908-A4E3-4D80-B125-B1FB46FF50BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 WG, based on Pete=E2=80=99s response, see diff file. Please let me know = if you don=E2=80=99t agree with my changes. And if you think other MAYs = or SHOULDs should be changed to lower-case (or not). Dino --Apple-Mail=_751AD908-A4E3-4D80-B125-B1FB46FF50BD Content-Disposition: attachment; filename=rfcdiff-6833bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6833bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-13.txt - = draft-ietf-lisp-rfc6833bis-14.txt=20 =20 =20 =20 =20 =20 =20 =
< draft-ietf-lisp-rfc6833bis-13.txt  =  draft-ietf-lisp-rfc6833bis-14.txt >
=
Network Working = Group V. Fuller = Network Working Group = V. Fuller
Internet-Draft = D. Farinacci Internet-Draft = D. Farinacci
Obsoletes: 6833 = (if approved) Cisco Systems = Obsoletes: 6833 (if approved) = Cisco Systems
Intended status: = Standards Track A. Cabellos (Ed.) = Intended status: Standards Track = A. Cabellos (Ed.)
Expires: February 25, 2019 = UPC/BarcelonaTech Expires: March 9, 2019 = UPC/BarcelonaTech
= August = 24, 2018 = September = 5, 2018
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-13 = = draft-ietf-lisp-rfc6833bis-14
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = Control-Plane service interface and communicating with By using this Control-Plane service interface and = communicating with
=
skipping to = change at = page 1, line 48 =C2=B6 = skipping to change at page 1, line 48 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on February 25, = 2019. This Internet-Draft will = expire on March 9, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 3, line 10 =C2=B6 = skipping to change at page 3, line 10 =C2=B6
11.2. LISP = Packet Type Codes . . . . . . . . . . . . . . . . . 38 = 11.2. LISP Packet Type Codes . . . . . . = . . . . . . . . . . . 38
11.3. LISP = ACT and Flag Fields . . . . . . . . . . . . . . . . 39 = 11.3. LISP ACT and Flag Fields . . . . . = . . . . . . . . . . . 39
11.4. LISP = Address Type Codes . . . . . . . . . . . . . . . . 39 = 11.4. LISP Address Type Codes . . . . . = . . . . . . . . . . . 39
11.5. LISP = Algorithm ID Numbers . . . . . . . . . . . . . . . 40 = 11.5. LISP Algorithm ID Numbers . . . . = . . . . . . . . . . . 40
=
12. References = . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. References . . . . . . . . . . . . . . . . . . . = . . . . . . 40
12.1. = Normative References . . . . . . . . . . . . . . . . . . 40 = 12.1. Normative References . . . . . . . = . . . . . . . . . . . 40
12.2. = Informative References . . . . . . . . . . . . . . . . . 41 = 12.2. Informative References . . . . . . = . . . . . . . . . . . 41
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 45 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 45
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 45 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 45
B.1. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 45 B.1. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 45
B.2. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 45 B.2. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 45
B.3. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 45 B.3. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 45
B.4. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 45 B.4. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 45
B.5. = Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 46 = B.5. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . = 45
B.6. Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 46 B.6. Changes to = draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 46
B.7. Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 46 B.7. Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 46
B.8. Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 47 B.8. Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 46
B.9. Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 47 B.9. Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 47
B.10. Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 47 B.10. Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 47
B.11. Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 47 B.11. Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 47
B.12. Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 48 B.12. Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 47
B.13. Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 48 B.13. Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 48
B.14. Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 48 B.14. Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 48
B.15. Changes to = draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48 B.15. Changes to = draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 48
= B.16. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 49
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [I-D.ietf-lisp-introduction] and The Locator/ID Separation Protocol = [I-D.ietf-lisp-introduction] and
= [I-D.ietf-lisp-rfc6830bis] specifies an architecture and = mechanism = [I-D.ietf-lisp-rfc6830bis] specifies an architecture and = mechanism
for dynamic = tunnelling by logically separating the addresses for dynamic tunnelling by logically separating the = addresses
currently used = by IP in two separate name spaces: Endpoint IDs currently used by IP in two separate name spaces: = Endpoint IDs
(EIDs), used = within sites; and Routing Locators (RLOCs), used on the = (EIDs), used within sites; and Routing = Locators (RLOCs), used on the
transit = networks that make up the Internet infrastructure. To transit networks that make up the Internet = infrastructure. To
=
skipping to = change at = page 9, line 25 =C2=B6 = skipping to change at page 9, line 25 =C2=B6
LISP = Map-Register: 3 b'0011' LISP Map-Register: 3 = b'0011'
LISP = Map-Notify: 4 b'0100' LISP Map-Notify: 4 = b'0100'
LISP = Map-Notify-Ack: 5 b'0101' LISP Map-Notify-Ack: 5 = b'0101'
LISP = Map-Referral: 6 b'0110' LISP Map-Referral: 6 = b'0110'
LISP = Encapsulated Control Message: 8 b'1000' LISP Encapsulated Control Message: 8 = b'1000'
Not Assigned = 9-14 b'1001'- b'1110' Not Assigned 9-14 b'1001'- = b'1110'
LISP Shared = Extension Message: 15 b'1111' [RFC8113] = LISP Shared Extension Message: 15 = b'1111' [RFC8113]
=
Values in the = "Not Assigned" range can be assigned according to Values in the "Not Assigned" range can be assigned = according to
procedures in = [RFC8126]. Documents that request for a new LISP procedures in [RFC8126]. Documents that request for = a new LISP
packet type = MAY indicate a preferred value. = packet type may= indicate a preferred value.
=
Protocol = designers experimenting with new message formats SHOULD use = Protocol designers experimenting with new = message formats SHOULD use
the LISP = Shared Extension Message Type and request a [RFC8113] sub- = the LISP Shared Extension Message Type and = request a [RFC8113] sub-
type = assignment. type = assignment.
=
All LISP = Control-Plane messages use Address Family Identifiers (AFI) = All LISP Control-Plane messages use Address = Family Identifiers (AFI)
[AFI] or LISP = Canonical Address Format (LCAF) [RFC8060] formats to [AFI] or LISP Canonical Address Format (LCAF) = [RFC8060] formats to
encode either = fixed or variable length addresses. This includes encode either fixed or variable length addresses. = This includes
explicit = fields in each control message or part of EID-records or = explicit fields in each control message or = part of EID-records or
RLOC-records = in commonly formatted messages. = RLOC-records in commonly formatted messages.
=
skipping to = change at = page 17, line 46 =C2=B6 = skipping to change at page 17, line = 46 =C2=B6
= [I-D.ietf-lisp-6834bis] for more details. [I-D.ietf-lisp-6834bis] for more details.
=
= EID-Prefix-AFI: Address family of the EID-Prefix according to = [AFI] EID-Prefix-AFI: Address = family of the EID-Prefix according to [AFI]
and = [RFC8060]. and = [RFC8060].
=
EID-Prefix: = This prefix is 4 octets for an IPv4 address family and EID-Prefix: This prefix is 4 octets for an IPv4 = address family and
16 octets = for an IPv6 address family. 16 = octets for an IPv6 address family.
=
Priority: = Each RLOC is assigned a unicast Priority. Lower values = Priority: Each RLOC is assigned a unicast = Priority. Lower values
are more = preferable. When multiple RLOCs have the same Priority, = are more preferable. When multiple RLOCs = have the same Priority,
they = MAY be used in a load-split fashion. A = value of 255 means they may be used in a load-split fashion. A value of = 255 means
the RLOC = MUST NOT be used for unicast forwarding. the RLOC MUST NOT be used for unicast = forwarding.
=
Weight: When = priorities are the same for multiple RLOCs, the Weight Weight: When priorities are the same for multiple = RLOCs, the Weight
indicates = how to balance unicast traffic between them. Weight is = indicates how to balance unicast traffic = between them. Weight is
encoded as = a relative weight of total unicast packets that match encoded as a relative weight of total unicast = packets that match
the mapping = entry. For example, if there are 4 Locators in a the mapping entry. For example, if there are 4 = Locators in a
= Locator-Set, where the Weights assigned are 30, 20, 20, and 10, = Locator-Set, where the Weights assigned = are 30, 20, 20, and 10,
the first = Locator will get 37.5% of the traffic, the 2nd and 3rd the first Locator will get 37.5% of the traffic, = the 2nd and 3rd
Locators = will get 25% of the traffic, and the 4th Locator will get = Locators will get 25% of the traffic, and = the 4th Locator will get
12.5% of = the traffic. If all Weights for a Locator-Set are equal, = 12.5% of the traffic. If all Weights for = a Locator-Set are equal,
=
skipping to = change at = page 18, line 38 =C2=B6 = skipping to change at page 18, line = 38 =C2=B6
Unused Flags: = These are set to 0 when sending and ignored on Unused Flags: These are set to 0 when sending and = ignored on
= receipt. receipt.
=
L: When this = bit is set, the Locator is flagged as a local Locator to = L: When this bit is set, the Locator is = flagged as a local Locator to
the ETR = that is sending the Map-Reply. When a Map-Server is doing = the ETR that is sending the Map-Reply. = When a Map-Server is doing
proxy = Map-Replying for a LISP site, the L-bit is set to 0 for all = proxy Map-Replying for a LISP site, the = L-bit is set to 0 for all
Locators in = this Locator-Set. Locators in = this Locator-Set.
=
p: When this = bit is set, an ETR informs the RLOC-Probing ITR that the = p: When this bit is set, an ETR informs the = RLOC-Probing ITR that the
locator = address for which this bit is set is the one being RLOC- = locator address for which this bit is set = is the one being RLOC-
probed = and MAY be different from the source = address of the Map- probed and = may be different from the source address = of the Map-
Reply. An = ITR that RLOC-probes a particular Locator MUST use this = Reply. An ITR that RLOC-probes a = particular Locator MUST use this
Locator for = retrieving the data structure used to store the fact Locator for retrieving the data structure used to = store the fact
that the = Locator is reachable. The p-bit is set for a single that the Locator is reachable. The p-bit is set = for a single
Locator in = the same Locator-Set. If an implementation sets more Locator in the same Locator-Set. If an = implementation sets more
than one = p-bit erroneously, the receiver of the Map-Reply MUST than one p-bit erroneously, the receiver of the = Map-Reply MUST
select the = first Locator. The p-bit MUST NOT be set for Locator- select the first Locator. The p-bit MUST NOT be = set for Locator-
Set records = sent in Map-Request and Map-Register messages. Set records sent in Map-Request and Map-Register = messages.
=
R: This is set = when the sender of a Map-Reply has a route to the R: This is set when the sender of a Map-Reply has a = route to the
Locator = in the Locator data record. This receiver MAY find this = Locator in the Locator data record. This receiver may find this
useful to = know if the Locator is up but not necessarily reachable = useful to know if the Locator is up but = not necessarily reachable
from the = receiver's point of view. See also EID-Reachability from the receiver's point of view. See also = EID-Reachability
Section = 7.1 for another way the R-bit MAY be = used. Section 7.1 for another = way the R-bit may be used.
=
Locator: This = is an IPv4 or IPv6 address (as encoded by the 'Loc- Locator: This is an IPv4 or IPv6 address (as encoded = by the 'Loc-
AFI' field) = assigned to an ETR. Note that the destination RLOC AFI' field) assigned to an ETR. Note that the = destination RLOC
address MAY = be an anycast address. A source RLOC can be an address MAY be an anycast address. A source RLOC = can be an
anycast = address as well. The source or destination RLOC MUST NOT = anycast address as well. The source or = destination RLOC MUST NOT
be the = broadcast address (255.255.255.255 or any subnet broadcast = be the broadcast address (255.255.255.255 = or any subnet broadcast
address = known to the router) and MUST NOT be a link-local address known to the router) and MUST NOT be a = link-local
multicast = address. The source RLOC MUST NOT be a multicast multicast address. The source RLOC MUST NOT be a = multicast
address. = The destination RLOC SHOULD be a multicast address if it = address. The destination RLOC SHOULD be = a multicast address if it
is being = mapped from a multicast destination EID. is being mapped from a multicast destination = EID.
=
skipping to = change at = page 23, line 46 =C2=B6 = skipping to change at page 23, line = 46 =C2=B6
= message. message.
=
Record Count: = This is the number of records in this Map-Register Record Count: This is the number of records in this = Map-Register
message. A = record is comprised of that portion of the packet message. A record is comprised of that portion of = the packet
labeled = 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of = times equal to
Record = Count. Record Count.
=
Nonce: This = 8-octet 'Nonce' field is set to 0 in Map-Register Nonce: This 8-octet 'Nonce' field is set to 0 in = Map-Register
messages if = no Map-Notify message is expected to acknowledge it. messages if no Map-Notify message is expected to = acknowledge it.
Since the = Map-Register message is authenticated, the 'Nonce' field = Since the Map-Register message is = authenticated, the 'Nonce' field
is not = currently used for any security function but MAY be in the = is not currently used for any security function but may be in the
future as = part of an anti-replay solution. = future as part of an anti-replay solution.
=
Key ID: This = is a configured key-id value that corresponds to a Key ID: This is a configured key-id value that = corresponds to a
= shared-secret password that is used to authenticate the sender. = shared-secret password that is used to = authenticate the sender.
Multiple = shared-secrets can be used to roll over keys in a non- Multiple shared-secrets can be used to roll over = keys in a non-
disruptive = way. disruptive way.
=
Algorithm ID: = This is the configured Message Authentication Code Algorithm ID: This is the configured Message = Authentication Code
(MAC) = algorithm value used for the authentication function. See = (MAC) algorithm value used for the = authentication function. See
Algorithm = ID Numbers in the Section 11.5 for codepoint Algorithm ID Numbers in the Section 11.5 for = codepoint
=
skipping to = change at = page 30, line 5 =C2=B6 = skipping to change at page 30, line 5 =C2=B6
until they = need to send, in which case they will send Map-Requests to = until they need to send, in which case they = will send Map-Requests to
obtain a = Map-Cache entry. obtain a Map-Cache = entry.
=
7. Routing = Locator Reachability 7. Routing = Locator Reachability
=
This document = defines several Control-Plane mechanisms for This document defines several Control-Plane = mechanisms for
determining = RLOC reachability. Please note that additional Data- determining RLOC reachability. Please note that = additional Data-
Plane = reachability mechanisms are defined in = Plane reachability mechanisms are defined in
= [I-D.ietf-lisp-rfc6830bis]. = [I-D.ietf-lisp-rfc6830bis].
=
1. An ITR = MAY receive an ICMP Network Unreachable or = Host 1. An ITR may receive an ICMP Network Unreachable or = Host
= Unreachable message for an RLOC it is using. This indicates = that Unreachable message for an = RLOC it is using. This indicates that
the RLOC = is likely down. Note that trusting ICMP messages may the RLOC is likely down. Note that trusting ICMP = messages may
not be = desirable, but neither is ignoring them completely. not be desirable, but neither is ignoring them = completely.
= Implementations are encouraged to follow current best practices = Implementations are encouraged to follow = current best practices
in = treating these conditions [I-D.ietf-opsec-icmp-filtering]. = in treating these conditions = [I-D.ietf-opsec-icmp-filtering].
=
2. When an = ITR participates in the routing protocol that operates in = 2. When an ITR participates in the routing = protocol that operates in
the = underlay routing system, it can determine that an RLOC is = the underlay routing system, it can = determine that an RLOC is
down when = no Routing Information Base (RIB) entry exists that down when no Routing Information Base (RIB) entry = exists that
matches = the RLOC IP address. matches = the RLOC IP address.
=
3. An ITR = MAY receive an ICMP Port Unreachable = message from a 3. An ITR may receive an ICMP Port Unreachable message = from a
= destination host. This occurs if an ITR attempts to use = destination host. This occurs if an ITR = attempts to use
= interworking [RFC6832] and LISP-encapsulated data is sent to a = interworking [RFC6832] and = LISP-encapsulated data is sent to a
= non-LISP-capable site. = non-LISP-capable site.
=
4. An ITR = MAY receive a Map-Reply from an ETR in = response to a 4. An ITR may receive a Map-Reply from an ETR in response = to a
previously = sent Map-Request. The RLOC source of the Map-Reply is previously sent Map-Request. The RLOC source of = the Map-Reply is
likely up, = since the ETR was able to send the Map-Reply to the likely up, since the ETR was able to send the = Map-Reply to the
= ITR. ITR.
=
5. An ITR/ETR = pair can use the 'RLOC-Probing' mechanism described 5. An ITR/ETR pair can use the 'RLOC-Probing' = mechanism described
= below. below.
=
When ITRs = receive ICMP Network Unreachable or Host Unreachable When ITRs receive ICMP Network Unreachable or Host = Unreachable
messages as a = method to determine unreachability, they will refrain messages as a method to determine unreachability, = they will refrain
from using = Locators that are described in Locator lists of Map- from using Locators that are described in Locator = lists of Map-
=
skipping to = change at = page 33, line 9 =C2=B6 = skipping to change at page 33, line 9 =C2=B6
registered, = a 1-minute TTL is returned. If the requested EID registered, a 1-minute TTL is returned. If the = requested EID
matches a = non-delegated part of the authoritative EID-Prefix, then = matches a non-delegated part of the = authoritative EID-Prefix, then
it is not a = LISP EID and a 15-minute TTL is returned. See it is not a LISP EID and a 15-minute TTL is = returned. See
Section 8.2 = for discussion of aggregate EID-Prefixes and details Section 8.2 for discussion of aggregate = EID-Prefixes and details
of = Map-Server EID-Prefix matching. = of Map-Server EID-Prefix matching.
=
o A LISP = Map-Reply from the ETR that owns the EID-to-RLOC mapping or = o A LISP Map-Reply from the ETR that owns = the EID-to-RLOC mapping or
possibly = from a Map-Server answering on behalf of the ETR. See possibly from a Map-Server answering on behalf of = the ETR. See
Section 8.4 = for more details on Map-Resolver message processing. Section 8.4 for more details on Map-Resolver = message processing.
=
Note that an = ITR MAY be configured to both use a = Map-Resolver and to Note that an = ITR may be configured to both use a = Map-Resolver and to
participate in = a LISP-ALT logical network. In such a situation, the participate in a LISP-ALT logical network. In such a = situation, the
ITR SHOULD = send Map-Requests through the ALT network for any EID- ITR SHOULD send Map-Requests through the ALT network = for any EID-
Prefix learned = via ALT BGP. Such a configuration is expected to be Prefix learned via ALT BGP. Such a configuration is = expected to be
very rare, = since there is little benefit to using a Map-Resolver if = very rare, since there is little benefit to = using a Map-Resolver if
an ITR is = already using LISP-ALT. There would be, for example, no = an ITR is already using LISP-ALT. There = would be, for example, no
need for such = an ITR to send a Map-Request to a possibly non-existent = need for such an ITR to send a Map-Request = to a possibly non-existent
EID (and rely = on Negative Map-Replies) if it can consult the ALT EID (and rely on Negative Map-Replies) if it can = consult the ALT
database to = verify that an EID-Prefix is present before sending that = database to verify that an EID-Prefix is = present before sending that
= Map-Request. Map-Request.
=
=
skipping = to change at page 33, line = 33 =C2=B6 = skipping to change at page 33, line = 33 =C2=B6
Map-Register = messages. A Map-Register message includes Map-Register messages. A Map-Register message = includes
authentication = data, so prior to sending a Map-Register message, the authentication data, so prior to sending a = Map-Register message, the
ETR and = Map-Server SHOULD be configured with a shared secret or other = ETR and Map-Server SHOULD be configured with = a shared secret or other
relevant = authentication information. A Map-Server's configuration = relevant authentication information. A = Map-Server's configuration
SHOULD also = include a list of the EID-Prefixes for which each ETR is = SHOULD also include a list of the = EID-Prefixes for which each ETR is
authoritative. = Upon receipt of a Map-Register from an ETR, a Map- authoritative. Upon receipt of a Map-Register from = an ETR, a Map-
Server accepts = only EID-Prefixes that are configured for that ETR. Server accepts only EID-Prefixes that are configured = for that ETR.
Failure to = implement such a check would leave the mapping system Failure to implement such a check would leave the = mapping system
vulnerable to = trivial EID-Prefix hijacking attacks. As developers vulnerable to trivial EID-Prefix hijacking attacks. = As developers
and operators = gain experience with the mapping system, additional, and operators gain experience with the mapping = system, additional,
stronger = security measures MAY be added to the = registration process. stronger = security measures may be added to the = registration process.
=
In addition = to the set of EID-Prefixes defined for each ETR that MAY In = addition to the set of EID-Prefixes defined for each ETR that may
register, a = Map-Server is typically also configured with one or more = register, a Map-Server is typically also = configured with one or more
aggregate = prefixes that define the part of the EID numbering space = aggregate prefixes that define the part of = the EID numbering space
assigned to = it. When LISP-ALT is the database in use, aggregate EID- = assigned to it. When LISP-ALT is the = database in use, aggregate EID-
Prefixes are = implemented as discard routes and advertised into ALT Prefixes are implemented as discard routes and = advertised into ALT
BGP. The = existence of aggregate EID-Prefixes in a Map-Server's BGP. The existence of aggregate EID-Prefixes in a = Map-Server's
database = means that it MAY receive Map Requests for = EID-Prefixes that database means = that it may receive Map Requests for = EID-Prefixes that
match an = aggregate but do not match a registered prefix; Section 8.3 = match an aggregate but do not match a = registered prefix; Section 8.3
describes how = this is handled. describes how this = is handled.
=
Map-Register = messages are sent periodically from an ETR to a Map- Map-Register messages are sent periodically from an = ETR to a Map-
Server with a = suggested interval between messages of one minute. A Server with a suggested interval between messages of = one minute. A
Map-Server = SHOULD time out and remove an ETR's registration if it has = Map-Server SHOULD time out and remove an = ETR's registration if it has
not received a = valid Map-Register message within the past not received a valid Map-Register message within the = past
three minutes. = When first contacting a Map-Server after restart or three minutes. When first contacting a Map-Server = after restart or
changes to its = EID-to-RLOC database mappings, an ETR MAY initially changes to its EID-to-RLOC database mappings, an ETR = MAY initially
send = Map-Register messages at an increased frequency, up to one = every send Map-Register messages at = an increased frequency, up to one every
=
skipping = to change at page 34, line = 21 =C2=B6 = skipping to change at page 34, line = 21 =C2=B6
this flag by = an ETR would be to set it for Map-Register messages sent = this flag by an ETR would be to set it for = Map-Register messages sent
during the = initial "quick registration" with a Map-Server but then = during the initial "quick registration" with = a Map-Server but then
set it only = occasionally during steady-state maintenance of its set it only occasionally during steady-state = maintenance of its
association = with that Map-Server. Note that the Map-Notify message = association with that Map-Server. Note that = the Map-Notify message
is sent to UDP = destination port 4342, not to the source port is sent to UDP destination port 4342, not to the = source port
specified in = the original Map-Register message. = specified in the original Map-Register message.
=
Note that a = one-minute minimum registration interval during Note that a one-minute minimum registration interval = during
maintenance of = an ETR-Map-Server association places a lower bound on maintenance of an ETR-Map-Server association places a = lower bound on
how quickly = and how frequently a mapping database entry can be how quickly and how frequently a mapping database = entry can be
updated. = This MAY have implications for what sorts = of mobility can updated. This = may have implications for what sorts of = mobility can
be supported = directly by the mapping system; shorter registration be supported directly by the mapping system; shorter = registration
intervals or = other mechanisms might be needed to support faster intervals or other mechanisms might be needed to = support faster
mobility in = some cases. For a discussion on one way that faster mobility in some cases. For a discussion on one way = that faster
mobility = MAY be implemented for individual devices, = please see mobility may be implemented for individual devices, = please see
= [I-D.ietf-lisp-mn]. = [I-D.ietf-lisp-mn].
=
An ETR MAY = also request, by setting the "proxy Map-Reply" flag An ETR MAY also request, by setting the "proxy = Map-Reply" flag
(P-bit) in the = Map-Register message, that a Map-Server answer Map- (P-bit) in the Map-Register message, that a = Map-Server answer Map-
Requests = instead of forwarding them to the ETR. See Section 7.1 for = Requests instead of forwarding them to the = ETR. See Section 7.1 for
details on how = the Map-Server sets certain flags (such as those details on how the Map-Server sets certain flags = (such as those
indicating = whether the message is authoritative and how returned indicating whether the message is authoritative and = how returned
Locators = SHOULD be treated) when sending a Map-Reply on behalf of an = Locators SHOULD be treated) when sending a = Map-Reply on behalf of an
ETR. When an = ETR requests proxy reply service, it SHOULD include all = ETR. When an ETR requests proxy reply = service, it SHOULD include all
RLOCs for all = ETRs for the EID-Prefix being registered, along with RLOCs for all ETRs for the EID-Prefix being = registered, along with
=
skipping = to change at page 35, line = 17 =C2=B6 = skipping to change at page 35, line = 17 =C2=B6
=
8.3. Map-Server = Processing 8.3. Map-Server = Processing
=
Once a = Map-Server has EID-Prefixes registered by its client ETRs, it = Once a Map-Server has EID-Prefixes = registered by its client ETRs, it
can accept and = process Map-Requests for them. can = accept and process Map-Requests for them.
=
In response to = a Map-Request (received over the ALT if LISP-ALT is in In response to a Map-Request (received over the ALT = if LISP-ALT is in
use), the = Map-Server first checks to see if the destination EID use), the Map-Server first checks to see if the = destination EID
matches a = configured EID-Prefix. If there is no match, the Map- matches a configured EID-Prefix. If there is no = match, the Map-
Server returns = a Negative Map-Reply with action code "Natively- Server returns a Negative Map-Reply with action code = "Natively-
Forward" and = a 15-minute TTL. This MAY occur if a Map = Request is Forward" and a = 15-minute TTL. This can occur if a Map = Request is
received for a = configured aggregate EID-Prefix for which no more- received for a configured aggregate EID-Prefix for = which no more-
specific = EID-Prefix exists; it indicates the presence of a non-LISP = specific EID-Prefix exists; it indicates the = presence of a non-LISP
"hole" in the = aggregate EID-Prefix. "hole" in the = aggregate EID-Prefix.
=
Next, the = Map-Server checks to see if any ETRs have registered the = Next, the Map-Server checks to see if any = ETRs have registered the
matching = EID-Prefix. If none are found, then the Map-Server returns = matching EID-Prefix. If none are found, = then the Map-Server returns
a Negative = Map-Reply with action code "Natively-Forward" and a a Negative Map-Reply with action code = "Natively-Forward" and a
1-minute = TTL. 1-minute TTL.
=
If the = EID-prefix is either registered or not registered to the = If the EID-prefix is either registered or = not registered to the
=
skipping = to change at page 35, line = 47 =C2=B6 = skipping to change at page 35, line = 47 =C2=B6
If any of the = registered ETRs for the EID-Prefix have requested proxy = If any of the registered ETRs for the = EID-Prefix have requested proxy
reply service, = then the Map-Server answers the request instead of reply service, then the Map-Server answers the = request instead of
forwarding it. = It returns a Map-Reply with the EID-Prefix, RLOCs, forwarding it. It returns a Map-Reply with the = EID-Prefix, RLOCs,
and other = information learned through the registration process. and other information learned through the = registration process.
=
If none of the = ETRs have requested proxy reply service, then the Map- If none of the ETRs have requested proxy reply = service, then the Map-
Server = re-encapsulates and forwards the resulting Encapsulated Map- = Server re-encapsulates and forwards the = resulting Encapsulated Map-
Request to one = of the registered ETRs. It does not otherwise alter Request to one of the registered ETRs. It does not = otherwise alter
the = Map-Request, so any Map-Reply sent by the ETR is returned to = the the Map-Request, so any = Map-Reply sent by the ETR is returned to the
RLOC in the = Map-Request, not to the Map-Server. Unless also acting = RLOC in the Map-Request, not to the = Map-Server. Unless also acting
as a = Map-Resolver, a Map-Server SHOULD never = receive Map-Replies; any as a = Map-Resolver, a Map-Server should never = receive Map-Replies; any
such messages = SHOULD be discarded without response, perhaps such messages SHOULD be discarded without response, = perhaps
accompanied by = the logging of a diagnostic message if the rate of accompanied by the logging of a diagnostic message if = the rate of
Map-Replies is = suggestive of malicious traffic. = Map-Replies is suggestive of malicious traffic.
=
8.4. = Map-Resolver Processing 8.4. = Map-Resolver Processing
=
Upon receipt = of an Encapsulated Map-Request, a Map-Resolver Upon receipt of an Encapsulated Map-Request, a = Map-Resolver
decapsulates = the enclosed message and then searches for the requested = decapsulates the enclosed message and then = searches for the requested
EID in its = local database of mapping entries (statically configured = EID in its local database of mapping entries = (statically configured
or learned = from associated ETRs if the Map-Resolver is also a Map- = or learned from associated ETRs if the = Map-Resolver is also a Map-
=
skipping = to change at page 37, line = 26 =C2=B6 = skipping to change at page 37, line = 26 =C2=B6
messages does = not provide protection against "replay" attacks by a messages does not provide protection against "replay" = attacks by a
= "man-in-the-middle". Additional work is needed in this area. = "man-in-the-middle". Additional work is = needed in this area.
=
= [I-D.ietf-lisp-sec] defines a proposed mechanism for providing = origin [I-D.ietf-lisp-sec] defines = a proposed mechanism for providing origin
= authentication, integrity, anti-replay protection, and prevention = of authentication, integrity, = anti-replay protection, and prevention of
= man-in-the-middle and "overclaiming" attacks on the = Map-Request/Map- man-in-the-middle = and "overclaiming" attacks on the Map-Request/Map-
Reply = exchange. Work is ongoing on this and other proposals for = Reply exchange. Work is ongoing on this and = other proposals for
resolving = these open security issues. = resolving these open security issues.
=
While beyond = the scope of securing an individual Map-Server or Map- While beyond the scope of securing an individual = Map-Server or Map-
Resolver, it = SHOULD be noted that a BGP-based LISP-ALT = network (if Resolver, it should be noted that a BGP-based LISP-ALT = network (if
ALT is used as = the mapping database infrastructure) can take ALT is used as the mapping database infrastructure) = can take
advantage of = standards work on adding security to BGP. advantage of standards work on adding security to = BGP.
=
A complete = LISP threat analysis has been published in [RFC7835]. A complete LISP threat analysis has been published in = [RFC7835].
Please refer = to it for more security related details. Please refer to it for more security related = details.
=
10. Changes = since RFC 6833 10. Changes since RFC = 6833
=
For = implementation considerations, the following changes have been = For implementation considerations, the = following changes have been
made to this = document since RFC 6833 was published: = made to this document since RFC 6833 was published:
=
skipping = to change at page 38, line = 27 =C2=B6 = skipping to change at page 38, line = 27 =C2=B6
11. IANA = Considerations 11. IANA = Considerations
=
This section = provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet = Assigned Numbers
Authority = (IANA) regarding registration of values related to this = Authority (IANA) regarding registration of = values related to this
LISP = Control-Plane specification, in accordance with BCP 26 LISP Control-Plane specification, in accordance with = BCP 26
= [RFC8126]. [RFC8126].
=
There are = three namespaces (listed in the sub-sections below) in LISP = There are three namespaces (listed in the = sub-sections below) in LISP
that have been = registered. that have been = registered.
=
o LISP IANA = registry allocations SHOULD NOT be made = for purposes o LISP IANA registry = allocations should not be made for = purposes
unrelated = to LISP routing or transport protocols. = unrelated to LISP routing or transport protocols.
=
o The = following policies are used here with the meanings defined in = o The following policies are used here with = the meanings defined in
BCP 26: = "Specification Required", "IETF Review", "Experimental BCP 26: "Specification Required", "IETF Review", = "Experimental
Use", and = "First Come First Served". Use", = and "First Come First Served".
=
11.1. LISP UDP = Port Numbers 11.1. LISP UDP Port = Numbers
=
The IANA = registry has allocated UDP port number 4342 for the LISP = The IANA registry has allocated UDP port = number 4342 for the LISP
Control-Plane. = IANA has updated the description for UDP port 4342 as Control-Plane. IANA has updated the description for = UDP port 4342 as
=
skipping = to change at page 40, line = 30 =C2=B6 = skipping to change at page 40, line = 30 =C2=B6
Number values = are in the range of 0 to 255. The allocation of values = Number values are in the range of 0 to 255. = The allocation of values
is on a first = come first served basis. is on a = first come first served basis.
=
12. = References 12. References
=
12.1. Normative = References 12.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-00 (work in progress), July = 2018. = lisp-6834bis-01 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-14 = (work in progress), = (LISP)", draft-ietf-lisp-rfc6830bis-16 = (work in progress),
= July 2018. August = 2018.
=
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
=
skipping = to change at page 45, line = 19 =C2=B6 = skipping to change at page 45, line = 19 =C2=B6
Fabio Maino, = and members of the lisp@ietf.org mailing list for their = Fabio Maino, and members of the = lisp@ietf.org mailing list for their
feedback and = helpful suggestions. feedback and = helpful suggestions.
=
Special thanks = are due to Noel Chiappa for his extensive work and Special thanks are due to Noel Chiappa for his = extensive work and
thought about = caching in Map-Resolvers. thought = about caching in Map-Resolvers.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6833bis-13 B.1. = Changes to draft-ietf-lisp-rfc6833bis-14
=
= o Posted September = 2018.
=
= o Changes to = reflect comments from Genart review.
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-13
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-12 B.3. Changes to = draft-ietf-lisp-rfc6833bis-12
=
o Posted late = July 2018. o Posted late July = 2018.
=
o Moved = RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative = References.
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-11 B.4. Changes to = draft-ietf-lisp-rfc6833bis-11
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for = RFC status and
ran through = IDNITs again. ran through IDNITs = again.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-10 B.5. Changes to = draft-ietf-lisp-rfc6833bis-10
=
o Posted = after LISP WG at IETF week March. o = Posted after LISP WG at IETF week March.
=
o Move AD = field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM = packet format
description = section. description = section.
=
o Say more = about when the new Drop actions should be sent. o Say more about when the new Drop actions should be = sent.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-09 B.6. Changes to = draft-ietf-lisp-rfc6833bis-09
=
o Posted = March IETF week 2018. o Posted = March IETF week 2018.
=
o Fixed = editorial comments submitted by document shepherd Luigi = o Fixed editorial comments submitted by = document shepherd Luigi
= Iannone. Iannone.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-08 B.7. Changes to = draft-ietf-lisp-rfc6833bis-08
=
o Posted = March 2018. o Posted March = 2018.
=
o Added = RLOC-probing algorithm. o Added = RLOC-probing algorithm.
=
o Added = Solicit-Map Request algorithm. o = Added Solicit-Map Request algorithm.
=
o Added = several mechanisms (from 6830bis) regarding Routing Locator = o Added several mechanisms (from 6830bis) = regarding Routing Locator
= Reachability. = Reachability.
=
o Added port = 4342 to IANA Considerations section. = o Added port 4342 to IANA Considerations section.
=
B.7. Changes to = draft-ietf-lisp-rfc6833bis-07 B.8. Changes to = draft-ietf-lisp-rfc6833bis-07
=
o Posted = December 2017. o Posted December = 2017.
=
o Make it = more clear in a couple of places that RLOCs are used to = o Make it more clear in a couple of places = that RLOCs are used to
locate ETRs = more so than for Map-Server Map-Request forwarding. locate ETRs more so than for Map-Server = Map-Request forwarding.
=
o Make it = clear that "encapsualted" for a control message is an ECM = o Make it clear that "encapsualted" for a = control message is an ECM
based = message. based message.
=
o Make it = more clear what messages use source-port 4342 and which = o Make it more clear what messages use = source-port 4342 and which
=
skipping = to change at page 47, line = 5 =C2=B6 = skipping to change at page 47, line = 9 =C2=B6
Can use = othe AFIs then IPv4 and IPv6. = Can use othe AFIs then IPv4 and IPv6.
=
o Many = editorial changes to clarify text. = o Many editorial changes to clarify text.
=
o Changed = some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to = capitalized.
=
o Added = definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply = messages.
=
o Ran = document through IDNITs. o Ran = document through IDNITs.
=
B.8. Changes to = draft-ietf-lisp-rfc6833bis-06 B.9. Changes to = draft-ietf-lisp-rfc6833bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Spec the = I-bit to include the xTR-ID in a Map-Request message to = o Spec the I-bit to include the xTR-ID in a = Map-Request message to
be = consistent with the Map-Register message and to anticipate the = be consistent with the Map-Register = message and to anticipate the
= introduction of pubsub functionality to allow Map-Requests to = introduction of pubsub functionality to = allow Map-Requests to
subscribe = to RLOC-set changes. subscribe = to RLOC-set changes.
=
o Updated = references for individual submissions that became working = o Updated references for individual = submissions that became working
group = documents. group = documents.
=
o Updated = references for working group documents that became RFCs. = o Updated references for working group = documents that became RFCs.
=
B.9. Changes to = draft-ietf-lisp-rfc6833bis-05 B.10. Changes to = draft-ietf-lisp-rfc6833bis-05
=
o Posted May = 2017. o Posted May 2017.
=
o Update IANA = Considerations section based on new requests from this o Update IANA Considerations section based on new = requests from this
document = and changes from what was requested in [RFC6830]. document and changes from what was requested in = [RFC6830].
=
B.10. Changes to = draft-ietf-lisp-rfc6833bis-04 B.11. Changes to = draft-ietf-lisp-rfc6833bis-04
=
o Posted May = 2017. o Posted May 2017.
=
o Clarify how = the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in = Map-Register and Map-
Notify = messages. Break the 16-bit field into a 8-bit Key-ID field = Notify messages. Break the 16-bit field = into a 8-bit Key-ID field
and a 8-bit = Algorithm-ID field. and a 8-bit = Algorithm-ID field.
=
o Move the = Control-Plane codepoints from the IANA Considerations o Move the Control-Plane codepoints from the IANA = Considerations
section of = RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations = section of this
= document. document.
=
o In the = "LISP Control Packet Type Allocations" section, indicate = o In the "LISP Control Packet Type = Allocations" section, indicate
how message = Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how = experimental RFC8113
sub-types = should be requested. sub-types = should be requested.
=
B.11. Changes to = draft-ietf-lisp-rfc6833bis-03 B.12. Changes to = draft-ietf-lisp-rfc6833bis-03
=
o Posted = April 2017. o Posted April = 2017.
=
o Add types = 9-14 and specify they are not assigned. = o Add types 9-14 and specify they are not assigned.
=
o Add the = "LISP Shared Extension Message" type and point to RFC8113. = o Add the "LISP Shared Extension Message" = type and point to RFC8113.
=
B.12. Changes to = draft-ietf-lisp-rfc6833bis-02 B.13. Changes to = draft-ietf-lisp-rfc6833bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Clarify = that the LISP Control-Plane document defines how the LISP = o Clarify that the LISP Control-Plane = document defines how the LISP
Data-Plane = uses Map-Requests with either the SMR-bit set or the Data-Plane uses Map-Requests with either the = SMR-bit set or the
P-bit set = supporting mapping updates and RLOC-probing. Indicating = P-bit set supporting mapping updates and = RLOC-probing. Indicating
that other = Data-Planes can use the same mechanisms or their own that other Data-Planes can use the same mechanisms = or their own
defined = mechanisms to achieve the same functionality. defined mechanisms to achieve the same = functionality.
=
B.13. Changes to = draft-ietf-lisp-rfc6833bis-01 B.14. Changes to = draft-ietf-lisp-rfc6833bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Remove = references to self. o Remove = references to self.
=
o Change = references from RFC6830 to RFC6830bis. = o Change references from RFC6830 to RFC6830bis.
=
o Add two new = action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has = posted to the LISP
WG mailing = list. WG mailing list.
=
o In intro = section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to = I-D.ietf-lisp-introduction.
=
o Removed = Open Issues section and references to "experimental". o Removed Open Issues section and references to = "experimental".
=
B.14. Changes to = draft-ietf-lisp-rfc6833bis-00 B.15. Changes to = draft-ietf-lisp-rfc6833bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6833-00 = individual submission. No other changes made. -rfc6833-00 individual submission. No other = changes made.
=
B.15. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.16. Changes to = draft-farinacci-lisp-rfc6833bis-00
=
o Posted = November 2016. o Posted November = 2016.
=
o This is the = initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into = RFC 6833bis.
=
o The = document name has changed from the "Locator/ID Separation = o The document name has changed from the = "Locator/ID Separation
Protocol = (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the = "Locator/ID
Separation = Protocol (LISP) Control-Plane". = Separation Protocol (LISP) Control-Plane".
=
o The = fundamental change was to move the Control-Plane messages from = o The fundamental change was to move the = Control-Plane messages from
 End of changes. 40 change blocks. 
56 lines changed or = deleted 63 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_751AD908-A4E3-4D80-B125-B1FB46FF50BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 5, 2018, at 10:17 AM, Pete Resnick = wrote: >=20 > Reviewer: Pete Resnick > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lisp-rfc6833bis-13 > Reviewer: Pete Resnick > Review Date: 2018-09-05 > IETF LC End Date: 2018-08-31 > IESG Telechat date: 2018-09-13 >=20 > Summary: Ready with Nits >=20 > By no means my area of expertise, but particularly comparing this = document to > 6833, it's clear what changed and the new material looks reasonable. = One > overall nitty thing below. >=20 > Major issues: >=20 > None. >=20 > Minor issues: >=20 > None. >=20 > Nits/editorial comments: >=20 > Somebody went a bit "2119-mad" in this document. In particular, *most* = of the > MAYs are just goofy and wrong, and many of the SHOULDs shouldn't be = there. When > you're putting in a 2119 keyword, they should point out a place where = an > implementer needs to look to make sure they get their implementation = correct. A > lot of these aren't helpful in that regard. A few examples: >=20 > In 8.2: >=20 > In addition to the set of EID-Prefixes defined for each ETR that MAY > register, >=20 > That's not a protocol option being described. >=20 > (such as those > indicating whether the message is authoritative and how returned > Locators SHOULD be treated) >=20 > That's not a piece of implementation advice. >=20 > In 8.3: >=20 > This MAY occur if a Map Request is > received for a configured aggregate EID-Prefix for which no more- > specific EID-Prefix exists; >=20 > If "MAY" can be replaced with "might or might not", you probably want = "may" or > "can". >=20 > Unless also acting > as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; >=20 > That's a statement of fact, not an implementation instruction. >=20 > Please go through and get rid of the bogus ones. If it's not an = indication of > an implementation option (or lack thereof), it shouldn't be 2119ed. >=20 --Apple-Mail=_751AD908-A4E3-4D80-B125-B1FB46FF50BD-- From nobody Thu Sep 6 00:47:07 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6961D1277D2; Thu, 6 Sep 2018 00:47:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153622002036.11654.298490666162447613@ietfa.amsl.com> Date: Thu, 06 Sep 2018 00:47:00 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-6834bis-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 06 Sep 2018 07:47:01 -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 WG of the IETF. Title : Locator/ID Separation Protocol (LISP) Map-Versioning Authors : Luigi Iannone Damien Saucez Olivier Bonaventure Filename : draft-ietf-lisp-6834bis-02.txt Pages : 20 Date : 2018-09-06 Abstract: This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism. This document obsoletes RFC 6834 "Locator/ID Separation Protocol (LISP) Map-Versioning", which is the initial experimental specifications of the mechanisms updated by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-6834bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-6834bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-6834bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-6834bis-02 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 Sep 7 11:27:20 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852BD130E6B; Fri, 7 Sep 2018 11:27:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com 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 A-1Irv-Il7sS; Fri, 7 Sep 2018 11:27:07 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680132.outbound.protection.outlook.com [40.107.68.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F30130E28; Fri, 7 Sep 2018 11:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2utzJx8+T94x5cg/FUmczeowSUuPLueAiqUV9jIMMcQ=; b=PFEZyzAlpF1U4mJyJp3gBYXxkAJPC2W+20szhi8/ul5xcOU4lS0C0ULnoRg+EUl76qF2I1Q7fAI+sXmzDQmNrbnAW9Q0OdiKq3crajXPyn7CMb/evAHH2UQ55IwAd08Ujtjh2m9Vkg7F3Vt+Dvx1ZzUwWT8F01nEOo7CESqIVzk= Received: from CY1PR0201MB1436.namprd02.prod.outlook.com (10.163.139.143) by CY1PR0201MB1915.namprd02.prod.outlook.com (10.163.56.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.14; Fri, 7 Sep 2018 18:27:05 +0000 Received: from CY1PR0201MB1436.namprd02.prod.outlook.com ([fe80::f564:5b0e:5699:3e82]) by CY1PR0201MB1436.namprd02.prod.outlook.com ([fe80::f564:5b0e:5699:3e82%5]) with mapi id 15.20.1122.009; Fri, 7 Sep 2018 18:27:04 +0000 From: Jonathan Hardwick To: "rtg-ads@ietf.org" , "draft-ietf-lisp-rfc6833bis.all@ietf.org" CC: "rtg-dir@ietf.org" , "lisp@ietf.org" Thread-Topic: Routing directorate review of draft-ietf-lisp-rfc6833bis-13 Thread-Index: AdRGzqJj5vsoZpViT6CRAQq4NAWoag== Date: Fri, 7 Sep 2018 18:27:04 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.137.1.248] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR0201MB1915; 6:7pSyvDUYQuX0lLHWZW0BGmDFfAE9tvPUfkKIhc4xVpmrfpEeuWJVH7dLrJB1Xj6VDhow7PgHSiF4MIvsFDcA8Xb14t0Y58DLwaUNbsOAcbam68Db7XgZeEfVwODKwqR1DnIRODIC1aUIi+QhUZehIOUksr+r1bmrlV9WHAk06YHTagVTara+h+6ME+O8GeZeR8eY4THKH6QhftGYmzpLtz6LPAWm5YmBAHy+CI/zLSmhy+uSc61F+LqUnJeOpY92BxHkvLyGo+iinLCXUnqAJu1iskL7RMTTfBHdHPlUOo/djepRDu9qLpui2/P32SQcZj7V2qP/ALcRVVpj8kaQ14eKfuOz/73W4i4PV0lrQCBiPTMUdDF0VYwFdYLwq0ce7TbInz57oSVSQktrdpCcv6A2ULrD3SBQFyViXUhbUWnhBOgXNMnIKdTBOfwKYl/tUTMWfeLFgtcQhChaHxt1QQ==; 5:nOdnK/h6tOrzv1QCNAqocFGP2o74BpEQbpRulW60Bn/tGEsZJY5EFT69ckFluu0a4OOfY0/GYDzGLuoGMyopawFb+y5rUxibhXz8/tHPfLJg/u3p5d2zQFWLbKdAMDW2FYtYHzTXx2hLb1eg17+QmVjHbH+1i6b0BGFd0hfuey0=; 7:Vl1cg7cuazacR+jXxLw0/9sSoq7B+6gx1aPiHIISHxUK36F8VMOcxEa8bexI5uXbAZrSflnKlJTPDes9Yxs7i+jSMxs+IWgUr1+VUxaRB78O1RXBJLZPhXvaJeWAXKkYy65YeSeko391ye+MU3AeNwwSyhIRysYc4rzoffZwybNsrVgaTEdZj3MfjnyG7OCyeDpopZXGKjrH6HRECQf7zgRhIvB4aeUqsmfZXlVQI+jROhlg8arh+nat39vOaFhz x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ffcddd31-e862-4345-6f36-08d614ef831b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:CY1PR0201MB1915; x-ms-traffictypediagnostic: CY1PR0201MB1915: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699050); SRVR:CY1PR0201MB1915; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0201MB1915; x-forefront-prvs: 07880C4932 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(136003)(396003)(39850400004)(189003)(199004)(66066001)(3846002)(790700001)(99286004)(6116002)(68736007)(106356001)(33656002)(7696005)(105586002)(8676002)(81156014)(81166006)(7736002)(74316002)(72206003)(966005)(478600001)(606006)(14454004)(5250100002)(2501003)(97736004)(8936002)(316002)(102836004)(186003)(110136005)(54906003)(14444005)(256004)(450100002)(25786009)(4326008)(2906002)(86362001)(55016002)(476003)(486006)(54896002)(6306002)(9686003)(236005)(53936002)(5660300001)(2900100001)(26005)(6436002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0201MB1915; H:CY1PR0201MB1436.namprd02.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: tDSRmmj5UXXszBD/vw5oFV8TORTrWr5MTtuG6Zzb1nrRb/eOg9Ognm45ClLTFLYEEpX8Zh/kXqWQIEaFWvHg32+DCCxvHSFGBfzSjtrKy96OpDHbJ8gdSmRz6yGVvtCdi8dJksiZPHn3w+9xxB8Haky04hEZzQeV3tq4RLKvk3yMKc6U5fUrnMGAicJZ9KixuwZ2Vfh/gP2fvoJJ5CeCvkCOncXm2PevFde4MooqUrjitdZkrBZ+4OK4ICo/ur1BaZc92moaaYdjkJVMXS0NniZO2wsZfC8sCqHO+KOH+6Ouq1tXatpuWzjUAJ3smz2TSriTlmd62nRtersu+mbgs/HhFK8kuw3M7qWla54jLF8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0201MB143680B8D8B3602EED7441A384000CY1PR0201MB1436_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: ffcddd31-e862-4345-6f36-08d614ef831b X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2018 18:27:04.6724 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1915 Archived-At: Subject: [lisp] Routing directorate review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 07 Sep 2018 18:27:19 -0000 --_000_CY1PR0201MB143680B8D8B3602EED7441A384000CY1PR0201MB1436_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgdGhlcmUNCg0KSSBoYXZlIGRvbmUgYSByb3V0aW5nIGRpcmVjdG9yYXRlIHJldmlldyBvZiB0 aGlzIGRyYWZ0Lg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1s aXNwLXJmYzY4MzNiaXMvP2luY2x1ZGVfdGV4dD0xDQoNClRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFz IHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNv bWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMg dG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDov L3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQpBbHRob3Vn aCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5n IEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9u ZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZl LCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBk YXRpbmcgdGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzNiaXMt MTMNClJldmlld2VyOiBKb24gSGFyZHdpY2sNClJldmlldyBEYXRlOiA3IFNlcCAyMDE4DQpJRVRG IExDIEVuZCBEYXRlOiAzMSBBdWcgMjAxOA0KSW50ZW5kZWQgU3RhdHVzOiBQcm9wb3NlZCBTdGFu ZGFyZA0KDQpDb21tZW50cw0KVGhpcyB3YXMgbXkgZmlyc3QgZm9yYXkgaW50byBMSVNQLCBzbyBJ IGFsc28gcmVhZCBkcmFmdC1pZXRmLWxpc3AtcmZjNjgzMGJpcyBhbmQgZHJhZnQtaWV0Zi1saXNw LWludHJvZHVjdGlvbiBhcyByYW1wLXVwLiAgSSBmb3VuZCBhbGwgdGhyZWUgZG9jdW1lbnRzIHRv IGJlIHZlcnkgcmVhZGFibGUgYW5kIHVzZWZ1bC4NCg0KSSB0aGluayB0aGlzIGRvY3VtZW50IGlz IHJlYWR5IHRvIGJlIHB1Ymxpc2hlZC4gIEkgbm90ZWQgYSBmZXcgbWlub3IgY29tbWVudHMgYW5k IHF1ZXN0aW9ucyBhcyBJIHJlYWQgdGhyb3VnaCBpdCwgYmVsb3cuDQoNCnNlYzM6IE1hcC1SZWdp c3RlciBjb250YWlucyDigJxvbmUgb3IgbW9yZSBSTE9DcyB0byByZWFjaCBFVFIocynigJ0uICBI b3cgZG8geW91IGRlcmVnaXN0ZXIgYWxsIFJMT0NzIGZvciBhbiBFSUQ/DQoNCnNlYzU6IChEaWFn cmFtcykgSXQgc2VlbXMgYSBiaXQgcmVkdW5kYW50IHRvIHNwZWNpZnkgdGhlIElQdjQvNiBhbmQg VURQIGhlYWRlciBmb3JtYXRzIGhlcmUuICBKdXN0IHJlZmVyIHRvIHRoZSBSRkNzLg0KDQpzZWM1 OiDigJxXaGVuIGEgVURQIE1hcC1SZXBseSBNYXAtTm90aWZ54oCdICA8LSBpbnNlcnQgY29tbWEN Cg0Kc2VjNS4xOiBXaGF0IGFib3V0IGNvZGUgcG9pbnQgNz8gIE5vdCBhc3NpZ25lZD8gIFJlc2Vy dmVkPw0KDQpzZWM2LjE6IOKAnGZyb20gdGhvc2Ugc2l0ZXMgdG8gd2hpY2jigJ0gc2hvdWxkIGJl IOKAnHRvIHRob3NlIHNpdGVzIHRvIHdoaWNo4oCdDQoNCnNlYzYuMTog4oCcZm9yIHRoZSBsYXN0 IG1pbnV0ZeKAnSBpcyBhcmJpdHJhcnkgYW5kIHNob3VsZCBiZSBsZWZ0IHRvIHRoZSBpbXBsZW1l bnRhdGlvbiAvIGRlcGxveW1lbnQgdG8gZGVjaWRlIElNTy4NCg0Kc2VjNy4xOiBIYXZlIHlvdSBj b25zaWRlcmVkIHVzaW5nIG11bHRpLWhvcCBCRkQgaW5zdGVhZCBvZiBSTE9DIHByb2Jpbmc/DQoN CkJlc3QgcmVnYXJkcw0KSm9uDQoNCg== --_000_CY1PR0201MB143680B8D8B3602EED7441A384000CY1PR0201MB1436_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEg TWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIHRoZXJlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgaGF2ZSBkb25lIGEgcm91dGluZyBkaXJlY3RvcmF0ZSByZXZpZXcgb2YgdGhpcyBkcmFmdC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbGlzcC1yZmM2ODMzYmlzLz9pbmNsdWRl X3RleHQ9MSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1saXNw LXJmYzY4MzNiaXMvP2luY2x1ZGVfdGV4dD0xPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91 dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBh bmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVy cG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGlu ZyBBRHMuDQogRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3Jh dGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJh Yy93aWtpL1J0Z0RpcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHRob3VnaCB0aGVzZSBjb21t ZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291 bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBv dGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZl IHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcNCiB0aGUg ZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvY3VtZW50OiBkcmFmdC1pZXRmLWxpc3At cmZjNjgzM2Jpcy0xMyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJldmll d2VyOiBKb24gSGFyZHdpY2sgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S ZXZpZXcgRGF0ZTogNyBTZXAgMjAxOCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklFVEYgTEMgRW5kIERhdGU6IDMxIEF1ZyAyMDE4IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SW50ZW5kZWQgU3RhdHVzOiBQcm9wb3NlZCBTdGFuZGFyZDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48dT5Db21tZW50czxvOnA+PC9vOnA+PC91PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgd2FzIG15IGZpcnN0IGZvcmF5IGludG8gTElTUCwgc28gSSBhbHNv IHJlYWQgZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBiaXMgYW5kIGRyYWZ0LWlldGYtbGlzcC1pbnRy b2R1Y3Rpb24gYXMgcmFtcC11cC4mbmJzcDsgSSBmb3VuZCBhbGwgdGhyZWUgZG9jdW1lbnRzIHRv IGJlIHZlcnkgcmVhZGFibGUgYW5kIHVzZWZ1bC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0 aGluayB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlIHB1Ymxpc2hlZC4mbmJzcDsgSSBub3Rl ZCBhIGZldyBtaW5vciBjb21tZW50cyBhbmQgcXVlc3Rpb25zIGFzIEkgcmVhZCB0aHJvdWdoIGl0 LCBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2VjMzogTWFwLVJlZ2lzdGVyIGNvbnRh aW5zIOKAnG9uZSBvciBtb3JlIFJMT0NzIHRvIHJlYWNoIEVUUihzKeKAnS4mbmJzcDsgSG93IGRv IHlvdSBkZXJlZ2lzdGVyIGFsbCBSTE9DcyBmb3IgYW4gRUlEPzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5zZWM1OiAoRGlhZ3JhbXMpIEl0IHNlZW1zIGEgYml0IHJlZHVuZGFudCB0byBzcGVjaWZ5 IHRoZSBJUHY0LzYgYW5kIFVEUCBoZWFkZXIgZm9ybWF0cyBoZXJlLiZuYnNwOyBKdXN0IHJlZmVy IHRvIHRoZSBSRkNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZWM1OiDigJxXaGVuIGEgVURQ IE1hcC1SZXBseSBNYXAtTm90aWZ54oCdJm5ic3A7ICZsdDstIGluc2VydCBjb21tYTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5zZWM1LjE6IFdoYXQgYWJvdXQgY29kZSBwb2ludCA3PyZuYnNwOyBO b3QgYXNzaWduZWQ/Jm5ic3A7IFJlc2VydmVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZWM2 LjE6IOKAnGZyb20gdGhvc2Ugc2l0ZXMgdG8gd2hpY2jigJ0gc2hvdWxkIGJlIOKAnHRvIHRob3Nl IHNpdGVzIHRvIHdoaWNo4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNlYzYuMTog4oCcZm9y IHRoZSBsYXN0IG1pbnV0ZeKAnSBpcyBhcmJpdHJhcnkgYW5kIHNob3VsZCBiZSBsZWZ0IHRvIHRo ZSBpbXBsZW1lbnRhdGlvbiAvIGRlcGxveW1lbnQgdG8gZGVjaWRlIElNTy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+c2VjNy4xOiBIYXZlIHlvdSBjb25zaWRlcmVkIHVzaW5nIG11bHRpLWhvcCBC RkQgaW5zdGVhZCBvZiBSTE9DIHByb2Jpbmc/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3Qg cmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0201MB143680B8D8B3602EED7441A384000CY1PR0201MB1436_-- From nobody Fri Sep 7 11:42:10 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250301252B7; Fri, 7 Sep 2018 11:42:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1qpoQ0FoA3di; Fri, 7 Sep 2018 11:41:57 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 C80BC12008A; Fri, 7 Sep 2018 11:41:57 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id h79-v6so7409992pfk.8; Fri, 07 Sep 2018 11:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/NnpapEtcuJUGwZYnai3dQz74De11RiAgdSQpnr4HgE=; b=JNYuYyIvRMK/Tm0r9EiGD0hAACGsBxEnj87WrfGLt8+lfvaRVdb+UGG6BdE7c3DYuv S+Yqqf52FKGTrG2BeHCFuAzXkJA0haPehZSWaRQAheUinjnelrIA5LGrO9CsctdBsHxf AM/Ycg8pX3w4aMwVRlt0Vd0j7NvNyzQOLuK67A588pmA0ce5nkYma0Jy7UXO28FA50Ld b8FKUXGpTI8/icTRjOYLDhTUl037+PQCoruND4QIoQsorivCADyVPu1mXkEfxD4z1mr9 pYSQPV6sWXMjp/POX4HYPvClbqNcmOOgExnXbDCbFJQawg0sSBj3w3ugUVFYZAtcF6HJ 0+hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/NnpapEtcuJUGwZYnai3dQz74De11RiAgdSQpnr4HgE=; b=aMFBFn7+mhGFjSA/Tr9A/HFTpleve/KEyRcSgDfEjOPtXbMussVDusL2EDx+oE2ZQB Vp73PYbxgPTztGs1tRnHWD8joEL0EsZ0YdNGUp8gXIaREgh0Px9t68yJAzbq5vy6PQm6 7M6FJQ4dANwo+5MVgz1eAwnd5/HcPuYYkMrIk+QscHsEzQgprJC6PTirev3bCcfrJqAD v1RuYzfPAN9MU3WWWuSOUpe+0VZrAitab+pv9Nwm2+V9skESRfVy50qhP6T5B7QWrawf E0XFX9hZF81ZyXUCcZKrLQmiS9YWLUNxEdHNQJ5VpxDOriTuDSF6mWlM0enmrmb1Bzsy +99g== X-Gm-Message-State: APzg51A34bUS0BPtwgPWISbzpxMwyucbGvHCaTWjCCs4XudY5NllAB5d 7L/FqqvkWEnb3DQKNpE2lWoyr3f2 X-Google-Smtp-Source: ANB0VdbvbsX9JKaOdFrLErNSS0oM4NrBKbYjN05iPE0z5AK5iaSHfAM81+5HqrnVzGGSmMCfmk12Wg== X-Received: by 2002:a62:4bc6:: with SMTP id d67-v6mr10042053pfj.175.1536345717370; Fri, 07 Sep 2018 11:41:57 -0700 (PDT) Received: from [10.31.79.156] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id 74-v6sm12604911pfv.33.2018.09.07.11.41.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 11:41:56 -0700 (PDT) From: Dino Farinacci Message-Id: <56A10EEF-3CF5-4325-A7CB-337D4F22E106@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0D86D51E-72F2-4BED-813A-F468D5360D2A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 7 Sep 2018 11:41:55 -0700 In-Reply-To: Cc: "rtg-ads@ietf.org" , "draft-ietf-lisp-rfc6833bis.all@ietf.org" , "rtg-dir@ietf.org" , "lisp@ietf.org" To: Jonathan Hardwick References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Routing directorate review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 07 Sep 2018 18:42:00 -0000 --Apple-Mail=_0D86D51E-72F2-4BED-813A-F468D5360D2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Hi there > =20 > I have done a routing directorate review of this draft. > = https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/?include_text=3D= 1 > =20 > The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > =20 > Although these comments are primarily for the use of the Routing ADs, = it would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. > =20 > Document: draft-ietf-lisp-rfc6833bis-13=20 > Reviewer: Jon Hardwick=20 > Review Date: 7 Sep 2018=20 > IETF LC End Date: 31 Aug 2018=20 > Intended Status: Proposed Standard Thanks for your comments Jon. > Comments > This was my first foray into LISP, so I also read = draft-ietf-lisp-rfc6830bis and draft-ietf-lisp-introduction as ramp-up. = I found all three documents to be very readable and useful. That is good to hear. Kudos to the working group for this. > I think this document is ready to be published. I noted a few minor = comments and questions as I read through it, below. > =20 > sec3: Map-Register contains =E2=80=9Cone or more RLOCs to reach = ETR(s)=E2=80=9D. How do you deregister all RLOCs for an EID? You set the Record TTL in the EID-record to 0. It is stated here: > sec5: (Diagrams) It seems a bit redundant to specify the IPv4/6 and = UDP header formats here. Just refer to the RFCs. We want to be crystal clear and don=E2=80=99t want readers to have to = shuffle documents. Those header formats are pretty etched in stone, so = we don=E2=80=99t think we=E2=80=99ll have a document maintenance problem = keeping it up to date. > sec5: =E2=80=9CWhen a UDP Map-Reply Map-Notify=E2=80=9D <- insert = comma Fixed. > sec5.1: What about code point 7? Not assigned? Reserved? It is assigned to a non-working group draft. NAT-traversal has not gone = through working group process so far. > sec6.1: =E2=80=9Cfrom those sites to which=E2=80=9D should be =E2=80=9Ct= o those sites to which=E2=80=9D Fixed. > sec6.1: =E2=80=9Cfor the last minute=E2=80=9D is arbitrary and should = be left to the implementation / deployment to decide IMO. Its kind of an architecture constant. > sec7.1: Have you considered using multi-hop BFD instead of RLOC = probing? Yes. But there are too many LISP features we need that would not be = appropriate in a more generalized BFD mechanism. We use RLOC-probing, = not only for reachability testing, but to convey new RLOC changes, = LISP-crypto keys, as well as differnet RLOC types. > Best regards > Jon I will publish a new version of rfc6830bis and rfc6833bis on Monday with = accumilated changes from various comments. Thanks again, Dino --Apple-Mail=_0D86D51E-72F2-4BED-813A-F468D5360D2A Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_5A7CA70E-AB88-435B-9B5C-9DAEE2F4F367" --Apple-Mail=_5A7CA70E-AB88-435B-9B5C-9DAEE2F4F367 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = there
 
I have done a routing directorate review = of this draft.
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/?in= clude_text=3D1
 
The Routing = Directorate seeks to review all routing or routing-related drafts as = they pass through IETF last call and IESG review, and sometimes on = special request. The purpose of the review is to provide assistance to = the Routing ADs. For more information about the Routing = Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
 
Although these comments are primarily = for the use of the Routing ADs, it would be helpful if you could = consider them along with any other IETF Last Call comments that you = receive, and strive to resolve them through discussion or by updating = the draft.
 
Document: = draft-ietf-lisp-rfc6833bis-13 
Reviewer: Jon = Hardwick 
Review Date: 7 Sep 2018 
IETF LC End Date: 31 Aug 2018 
Intended = Status: Proposed Standard

Thanks for your comments Jon.

Comments
This was my first foray into LISP, so I also read = draft-ietf-lisp-rfc6830bis and draft-ietf-lisp-introduction as ramp-up. =  I found all three documents to be very readable and = useful.

That is good to = hear. Kudos to the working group for this.

I think this document is = ready to be published.  I noted a few minor comments and questions = as I read through it, below.
 
sec3: = Map-Register contains =E2=80=9Cone or more RLOCs to reach ETR(s)=E2=80=9D.=  How do you deregister all RLOCs for an EID?

You set the = Record TTL in the EID-record to 0. It is stated here:


sec5: = (Diagrams) It seems a bit redundant to specify the IPv4/6 and UDP header = formats here.  Just refer to the RFCs.

We want to = be crystal clear and don=E2=80=99t want readers to have to shuffle = documents. Those header formats are pretty etched in stone, so we = don=E2=80=99t think we=E2=80=99ll have a document maintenance problem = keeping it up to date.

sec5: =E2=80=9CWhen a UDP Map-Reply = Map-Notify=E2=80=9D  <- insert comma

Fixed.

sec5.1: What about code point 7?  Not = assigned?  Reserved?

It is assigned to a non-working group draft. = NAT-traversal has not gone through working group process so = far.

sec6.1: =E2=80=9Cfrom those sites to which=E2=80=9D should be = =E2=80=9Cto those sites to which=E2=80=9D

Fixed.

sec6.1: =E2=80=9Cfor the = last minute=E2=80=9D is arbitrary and should be left to the = implementation / deployment to decide IMO.

Its kind of an architecture = constant.

sec7.1: Have you considered using multi-hop BFD instead of = RLOC probing?

Yes. But there are too many LISP features we need that = would not be appropriate in a more generalized BFD mechanism. We use = RLOC-probing, not only for reachability testing, but to convey new RLOC = changes, LISP-crypto keys, as well as differnet RLOC types.

Best = regards
Jon

I will publish a new version of rfc6830bis and = rfc6833bis on Monday with accumilated changes from various = comments.

Thanks= again,
Dino


= --Apple-Mail=_5A7CA70E-AB88-435B-9B5C-9DAEE2F4F367 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=PastedGraphic-5.png Content-Type: image/png; x-unix-mode=0666; name="PastedGraphic-5.png" Content-Id: iVBORw0KGgoAAAANSUhEUgAABCwAAACQCAYAAADDVfqNAAAMK2lDQ1BJQ0MgUHJvZmlsZQAASImV VwdYU8kWnltSSWiBUKSE3kQp0gUCoUUQkCrYCEkgocSYEFTsqKjAWlCxYEVXRRRdCyCLDQsWFsXe HxZUlHVxFRsqb5IAuvq99753vm/u/e+ZM+f859yZ+WYA0IrlSaU5qDYAuZI8WVx4MGtsSiqL9AiQ AQZ0gDXw4fHl0qDY2CgAZeD9T3l3AyDK91Vnpa+f+/+r6AiEcj4ASCzE6QI5PxfiQwDgnnypLA8A QhfUW03Nk0JMhCyBngwShNhaiTPV2FuJ09U4SmWTEMeBOA0AMo3Hk2UCoKnkxcrnZ0I/mqUQu0gE YgnEjRAH8EU8AcSfIR6amzsZYi17iO3Tv/OT+Q+f6YM+ebzMQazORSXkELFcmsOb/n+W439Lbo5i IIYVbDSRLCJOmbOybtmTI5WYBvE5SXp0DMS6EF8TC1T2SvxUpIhI7Lf/wJdzYM0AEwCUJuCFREJs ArGlJCc6ql8fkCEO40IMa48miPO4CeqxqEA2Oa7fPzpNKA+NH8A8mSqW0qZYkZ0Y1O9zk0jIHfDZ UCBKSFbzRC/ni5OiIdaE+J48Oz6y3+ZFgYgTPWAjU8QpOcN/joEMWVic2gazzpUP5IX5isTc6H4c lSdKiFCPxSbyeSpuhhBnCeVjowZ4CoQhoeq8sEKhJLGfP1YmzQuO67ffLs2J7bfHGoU54Uq9JcSt 8vz4gbHdeXCyqfPFgTQvNkHNDdfL4o2KVXPAHUEU4IAQwAIK2NLBZJAFxK1ddV3wS90TBnhABjKB EDj3awZGJKt6JPAZDwrAnxAJgXxwXLCqVwjyof7LoFb9dAYZqt581Yhs8BTiXBAJcuC3QjVKMhgt CTyBGvFP0fmQaw5syr6fdCytAR0xlBhCjCCGER1wYzwA98Oj4JMNmxvujfsM8PpmT3hKaCM8Ilwn tBNuTxIXyn5gzgKjQTvkGNafXfr32eG20KsHHoz7Q//QN87EjYEzPgJGCsIDYWwPqP2eq2Iw42+1 7PdFcaGgFAMKm2L/IwNNR02PQS/KSn1fCzWv9MFqcQZ7fsyD8139BPAd+aMlthg7iDVjJ7HzWCNW B1jYcawea8GOKvHg3HiimhsD0eJUfLKhH/FP8Xj9MZVVk7tUu3S6fO7vA3nCaXnKxcKZLJ0uE2eK 8lhBcLcWsrgS/rChLDcXV7iLKvd+9dbyhqna0xHmhW+6wrcA+Av6+voav+mi4Jo8tBAA6tNvOrtj cDkbAHCuhK+Q5at1uPJBAFSgBVeKETCDe5c9zMgNeAI/wAahYBSIAQkgBUyEdRbBeSoDU8FMMA8U gRKwHKwG68FmsA3sAnvBAVAHGsFJcBZcBJfBdXAXzpUO8BJ0g3egF0EQEkJHGIgRYo7YIE6IG+KN BCChSBQSh6QgaUgmIkEUyExkPlKClCHrka1IFfIbcgQ5iZxH2pDbyEOkE/kb+YRiKA3VQ01RW3Q4 6o0GoZFoAjoBzUSnoAXoAnQpuhatRPegtehJ9CJ6HW1HX6I9GMA0MCZmgTlj3hgHi8FSsQxMhs3G irFyrBKrwRrgn76KtWNd2EeciDNwFu4M52sEnojz8Sn4bLwUX4/vwmvx0/hV/CHejX8l0AkmBCeC L4FLGEvIJEwlFBHKCTsIhwln4NrpILwjEolMoh3RC669FGIWcQaxlLiRuI94gthGfEzsIZFIRiQn kj8phsQj5ZGKSOtIe0jHSVdIHaQPZA2yOdmNHEZOJUvIheRy8m7yMfIV8jNyL0WbYkPxpcRQBJTp lGWU7ZQGyiVKB6WXqkO1o/pTE6hZ1HnUtdQa6hnqPeobDQ0NSw0fjTEaYo25Gms19muc03io8ZGm S3OkcWjjaQraUtpO2gnabdobOp1uS2fTU+l59KX0Kvop+gP6B02G5jBNrqZAc45mhWat5hXNV1oU LRutIK2JWgVa5VoHtS5pdWlTtG21Odo87dnaFdpHtG9q9+gwdFx1YnRydUp1duuc13muS9K11Q3V Fegu0N2me0r3MQNjWDE4DD5jPmM74wyjQ4+oZ6fH1cvSK9Hbq9eq162vqz9CP0l/mn6F/lH9dibG tGVymTnMZcwDzBvMTwamBkEGQoMlBjUGVwzeGw4xZBsKDYsN9xleN/xkxDIKNco2WmFUZ3TfGDd2 NB5jPNV4k/EZ464hekP8hvCHFA85MOSOCWriaBJnMsNkm0mLSY+pmWm4qdR0nekp0y4zphnbLMts ldkxs05zhnmAudh8lflx8xcsfVYQK4e1lnWa1W1hYhFhobDYatFq0WtpZ5loWWi5z/K+FdXK2yrD apVVk1W3tbn1aOuZ1tXWd2woNt42Ips1Ns02723tbJNtF9nW2T63M7Tj2hXYVdvds6fbB9pPsa+0 v+ZAdPB2yHbY6HDZEXX0cBQ5VjheckKdPJ3EThud2oYShvoMlQytHHrTmeYc5JzvXO38cBhzWNSw wmF1w14Ntx6eOnzF8ObhX108XHJctrvcddV1HeVa6Nrg+reboxvfrcLtmjvdPcx9jnu9++sRTiOE IzaNuOXB8BjtscijyeOLp5enzLPGs9PL2ivNa4PXTW8971jvUu9zPgSfYJ85Po0+H309ffN8D/j+ 5efsl+232+/5SLuRwpHbRz72t/Tn+W/1bw9gBaQFbAloD7QI5AVWBj5iW7EF7B3sZ0EOQVlBe4Je BbsEy4IPB7/n+HJmcU6EYCHhIcUhraG6oYmh60MfhFmGZYZVh3WHe4TPCD8RQYiIjFgRcZNryuVz q7jdo7xGzRp1OpIWGR+5PvJRlGOULKphNDp61OiVo+9F20RLoutiQAw3ZmXM/Vi72Cmxv48hjokd UzHmaZxr3My45nhG/KT43fHvEoITliXcTbRPVCQ2JWkljU+qSnqfHJJcltw+dvjYWWMvphiniFPq U0mpSak7UnvGhY5bPa5jvMf4ovE3JthNmDbh/ETjiTkTj07SmsSbdDCNkJactjvtMy+GV8nrSeem b0jv5nP4a/gvBWzBKkGn0F9YJnyW4Z9RlvE80z9zZWanKFBULuoSc8Trxa+zIrI2Z73Pjsnemd2X k5yzL5ecm5Z7RKIryZacnmw2edrkNqmTtEjaPsV3yuop3bJI2Q45Ip8gr8/Tg4fsFoW9YqHiYX5A fkX+h6lJUw9O05kmmdYy3XH6kunPCsIKfp2Bz+DPaJppMXPezIezgmZtnY3MTp/dNMdqzoI5HXPD 5+6aR52XPe+PQpfCssK385PnNywwXTB3weOF4QurizSLZEU3F/kt2rwYXyxe3LrEfcm6JV+LBcUX SlxKyks+l/JLL/zi+svaX/qWZixtXea5bNNy4nLJ8hsrAlfsKtMpKyh7vHL0ytpVrFXFq96unrT6 fPmI8s1rqGsUa9rXRq2tX2e9bvm6z+tF669XBFfs22CyYcmG9xsFG69sYm+q2Wy6uWTzpy3iLbe2 hm+trbStLN9G3Ja/7en2pO3Nv3r/WrXDeEfJji87JTvbd8XtOl3lVVW122T3smq0WlHduWf8nst7 Q/bW1zjXbN3H3FeyH+xX7H/xW9pvNw5EHmg66H2w5pDNoQ2HGYeLa5Ha6bXddaK69vqU+rYjo440 Nfg1HP592O87Gy0aK47qH112jHpswbG+4wXHe05IT3SdzDz5uGlS091TY09dOz3mdOuZyDPnzoad PdUc1Hz8nP+5xvO+549c8L5Qd9HzYm2LR8vhPzz+ONzq2Vp7yetS/WWfyw1tI9uOXQm8cvJqyNWz 17jXLl6Pvt52I/HGrZvjb7bfEtx6fjvn9us7+Xd67869R7hXfF/7fvkDkweV/3L41752z/ajD0Me tjyKf3T3Mf/xyyfyJ587FjylPy1/Zv6s6rnb88bOsM7LL8a96HgpfdnbVfSnzp8bXtm/OvQX+6+W 7rHdHa9lr/v+Ln1j9Gbn2xFvm3piex68y33X+774g9GHXR+9PzZ/Sv70rHfqZ9LntV8cvjR8jfx6 ry+3r0/Kk/FURwEMNjQjA4C/dwJATwGAcRmeH8ap72YqQdT3SRUC/wmr728q8QSgBr6Ux3DOCQD2 w2Y7F/pmA6A8giewAeruPtj6RZ7h7qb2RYM3FsKHvr43pgCQGgD4Iuvr693Y1/dlOyR7G4ATU9R3 QqUo76Bb2Ep03VAwF/wg/wYEKXFozC1U3QAAAAlwSFlzAAAWJQAAFiUBSVIk8AAAAZ5pVFh0WE1M OmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6 eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3 LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlv biByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNv bS9leGlmLzEuMC8iPgogICAgICAgICA8ZXhpZjpQaXhlbFhEaW1lbnNpb24+MTA2ODwvZXhpZjpQ aXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj4xNDQ8L2V4aWY6 UGl4ZWxZRGltZW5zaW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8 L3g6eG1wbWV0YT4KzwN2HgAAABxpRE9UAAAAAgAAAAAAAABIAAAAKAAAAEgAAABIAAA/38MgypEA AD+rSURBVHgB7H0PjFvHeecXQLasotrUliHfSUBlw0nhBBDdysjJaeJcqRZB0l7NpHVTI6EDBy4o Ixc4axS1wV6T3h6CBjRQ2DRag/LBpZNoDTt0cKaCA41e1q7ptKVxoO7CXEMjplCqwCrh1qIvXJwp hQvMzfs3f94/zswjuST3I7DL9x7fzPd9v+/PzHxvZt57CP0AfhABRAARQAQQAUQAEUAEEAFEABFA BBABRAARmCME3oMJiznSBrKCCCACiAAigAggAogAIoAIIAKIACKACCACNgKYsEBDQAQQAUQAEUAE EAFEABFABBABRAARQAQQgblDABMWc6cSZAgRQAQQAUQAEUAEEAFEABFABBABRAARQAQwYYE2gAgg AogAIoAIIAKIACKACCACiAAigAggAnOHACYs5k4lyBAigAggAogAIoAIIAKIACKACCACiAAigAhg wgJtABFABBABRAARQAQQAUQAEUAEEAFEABFABOYOAUxYzJ1KkCFEABFABBABRAARQAQQAUQAEUAE EAFEABHAhAXaACKACCACiAAigAggAogAIoAIIAKIACKACMwdApiwmDuVIEOIACKACCACiAAigAgg AogAIoAIIAKIACKACQu0AUQAEUAEEAFEABFABBABRAARQAQQAUQAEZg7BDBhMXcqQYYQAUQAEUAE EAFEABFABBABRAARQAQQAUQAExZoA4gAIoAIIAKIACKACCACiAAigAggAogAIjB3CGDCYu5Uggwh AogAIoAIIAKIACKACCACiAAigAggAogAJizQBhABRAARQAQQAUQAEUAEEAFEABFABBABRGDuEMCE xdypBBlCBBABRAARQAQQAUQAEUAEEAFEABFABBABTFigDSACiAAigAggAogAIoAIIAKIACKACCAC iMDcIYAJi7lTCTKECCACiAAigAggAogAIoAIIAKIACKACCACmLBAG0AEEAFEABFABBABRAARQAQQ AUQAEUAEEIG5QwATFnOnEmQIEUAEEAFEABFABBABRAARQAQQAUQAEUAEMGGxZ2xgB7YuXoT+EOCG m2+Fw9ftGcH3gKBX4NKFTRjAPjh67Bgc3Gcu8pV3LkFvMIIDKzfB4evn10gWhU81TUxOf2r0dv+u 5dJfEE+UL4gJXtktBPZefJk10rP291nTmzWeu0HvytYl2LQ6yNc41A/ccBSO7GofCP12N+wAac4v AguZsLj0+nNw9h/fhut846n9KzfCB+/4CHz4+DE6dMOPhMCV83DqwB3wKr1YaPThkZPXSz/rnrz5 8rNw7scD8Kkgupr9vwL3nf4E9AzLOdxegTee+wa89vbP4L03fxJO3308mt6C/WKKp43L9htwauVO R7dNqtsTprrdhjOnVuBBaiSpQgN+8MjJOUVxUfhUhG9i+lOkt+u3LZn+AniifAFI8MLuIbDn4sus oZ61v8+a3qzxnDW9LXjuT3Pwua9XJcK73geae7/dgR++/G1o/hTgWvg5/OIHPg53nzwiYbh94XX4 zusX4Nprgd7xy5D57Ckw7Z1KFePJ3kSALOCnWcwQqq3ov1SObHQGCyjZFFkeNknWxazY7Cck1CfF VAz+obpJkfrAtJzH7oCU0i7dVJEklcKrdfe/E+IyMd1yfDPF5u7DEsnB/PPZKmed+JQpk7GRaGL6 iwRs4j9oyRegPv/6C7CsdQHl04JrCjcns88pMDThKrXkW8D4MmG4plzdrP191vT04dOyT/3qJ1qC 8er2W1PpNEnR41y5NVE6VmWM1lL0Cwak6PXHLexSBdKTEBuRak4cJ6RJY2xnSKoATxABCYGFnGHx wzP3QerBszRnkYLc6in4BSvX9O7b8MTT1jXvk4XW4Ftw/KB3vse/6QyL++gMCwshmrCAh4yfwls4 7sDrT/4JPP1P7zrYu9D2Gk9DtWWdpCCbu1P67V04AV/76wfgX54yKXcajtlTZrbh2U+twBesRHim BIOXTsNyqNcUTxeXien2Crzy2Jfhay+/BXf+0VPwF5+9zdXsvH3NP58sRqVL0H/ldPxThYnpb3Z6 0pIvwNb86y/AstYFlE8LrincnMw+p8DQhKvUkm8B48uE4ZpydbP291nT04dPyz71q59gCT5bBbIl 2CyfhiN2X3OCJISqtHCZe78V+uO2jCmodptwt9NZB9imY44VZ8zhQJCB5uAlOLEcnXZBq3g4MwSk 9MWCnLRK/OnlUOR52CXFLM/oZUqTz5CK5BbqmD5lybgZ5OQzLMIlbwtPlSW9hN/OrqqXG5ByxtVv ujT+yTWjsJgHyrhIT9AwhT0P2lbWncXsAupPS755UAjysKcQWHb71JJvAePLnjLWJRRWyz53Vf4R 61Nmy+2pc6KFy9z7rdAfd8cWWWHM1dtY882Cz5Amdk+nbmPLTGCxZ1iEPb3cegVO3fSb9np+Oq0d XnroREjy5wqcP/cNOPM3L0DjnwEOwWU6KeAUfPFLq3DPyWMh9wuXdrbglW8/C+Vvvwwtq+whgJWj t8MnM78Hn/4Pd4VvZnnlIrz49BPw1DOvwEoqBYNWC46eegC+tPoFOHksOt24s3Uennn++3B1/810 /4e7YfDGi3Dmr85CozUAuOUo3P7BD8G9X6J1HJHrsNaNPf7YX8J3qHCHKINH7/xDePjzH4QzH/gY PE1FST7DQsBDONTKHhuVEzK6VPcD+uRallyoNOJw6/w5eP77P4H9+wGuXj0EmS/e487eiCiwi5eV 8RQy8eXWJtz1r38Ljz35TXhrcBkuXz4Ev/PwGuTvvysCK2cd4j/89OdAIXE+V6/CDb/6u4H1iN7P 7Hv7Ipyje4pUXvg7aFEXOnTLChy96Rb40IfT8PHf/jjcNtGdXeedT8rfubPw6k+u2rb15jcfhCde tZBKQ6H0eXgvXLVho9DCR+99AE4cFh7jJNKfVW2CeGZzpfIvgXx29br624JzZ56HLtwINx/ahspT L9g2duqLa/DVT/8S/NevfAXW7eB9Ch4vfx1OHQvbTWcWuHjY6cpHy+1cghefeREuXV2B9H2/D9e8 8R14vKTqtx5d1e+keM5QPorLubPfhe5gP6TvzcJx0VcsW3/xefj+pavwK+lPwyeOH3YBSGqfVjWG 9jKTOJhAvoWIL9yOTfs9xvqzSGv365L4w42QvucjsPndM1B6oQGDy7TxvOVO+PwfPwL333UrB0I6 MqDHymvatVFcSmCfjE/DA93+tSvfZdrj2Q8/g5cefBTs3StSOSg9/GGrY2j/HTp5Dx0PyHsy6HOY AJe591veH0/RcU2LjmvoshDo/eAROExj6YunD8AfWAMO9gnOsNjeehP+/nuvQf2178OP3rI2jrc+ K3D7b3wSfu8zn4a7bvPiO6tEaDdN/EioBw8XD4FFzMawGRZhT9lHLbZXQ+g6/EGbrInrrtzMINUc sf4yhQ0SNTtg0KmyWQre/eJ3qhBc9z/s1mLLFGqdSBUMmkWbJzroIav58H076MZAUvnNuleGzzQR ebSOpzXDIlYvEpfyiXo5IaMbpnu52tCzZjHtYmrhM99r6pRxETLxfl2z89VqhF33ScHnA1aZtM+u /GCONmvEWufJ6vcdh/mCvw6983nnM5y/MHzWGr7dV5LoL0E8mwT+SvLZhMLxibSzQYOkfTYVRsu5 liddvzAzw8UjrCmfVWzQHC9jpN96dBW/k+JJdwzSjhOm8gnl6AbRPgH5+n3ZdsL5C7OZgP9ZFAzt ZXZxMIF8CxFfuJpN+j2m+rNVb9CvI1Pyh0yxTkYcCuEoXP+yDwi3e4cmdi34X5j/2NcCcSmcv7Dy of7n8av5bdS/prEwru/CeF6T+9aarLm3J8Bl7v2W98ezxXWy5s5+rliN8bDhjnuypJB3Z8SDf4YF 3QNjzF54q+shs+QV7DPaj8y0iKXmAwGYDzb0uGADuUxwWcCgWWKDqHRg48CetElMKlcgG80WadWr ZFVIYuRrm0GG+nIHOr1aJHWrbLNO1ourNk1/8oCQTZIXOt2ZtTJptFpkY12cKpUitc3wJmrQ4rJ4 QTSTL5JqrUpprtmdXYkmDcTesg/r/vz6Bmm3G6SYSzFMrOt7OWHBbMfWiz+ABtW+m1cYr+OSM/6G jW46W6k3SaNWEgZEKVLthtnZiLQ3KqS8XiGVSpHdH5rsY2CMyEae21SusG7bdavZIJVywbZByS5Z uSQH887niHQaNVKpVkmN+meBLU3LkHKtRqr0uv1XqZFO36cHY/0liGfaqkggn01LU38CJqlskTQa VZaItmJYrrRB6ut5N66lSKUrpplniYsHpKZ8VjFBRju+a/mtR1fxW6Clj6dFY4byCbwG2yreSZZj VBL7NLWXWcbBBPIJeOrZmSkuijYZcZt2v4du9Sdu/jf9ft3k/KHaaNP+57rUbwvavCE9U1yM7CWB fUbYwfjLpv3rPqm77XGttk5y3qA5vUb71l5bXSH1tryF5Hh+wu5IgIuRHiweEvhDmAiR13gszpab bENRa2lNr+6McVL5Kmms59x22t/f9hIWKbJaKJFavUFabTo+EvqhVrwK9FtDcFH3o0hh8IcFQGCx ExbpAukOh2QwGJBBv0da0gANSLktL5jqNwps4J6jDiZ/eqTk7Y8AwSd2jQKf4bBaCa51G202SK0h Jzp6dU4vU6hL5HoNPhMi7fvNu1FuuFOk3PQF0GGPdDa5jJ2KFxiArG2IvNDAwgZQez1hwfVId+6c 612LjRIWqTxpC2O3YavMbD74tNKzNO97RNZdH5AHA97v3nefva0lld/wLgrfA9LrC0wIv0zmcP75 NF2rChr6SxLPkupBS74AMQX9CZ2SUsuxJeYPbDfyTbLmdjbFTv5u4uKIqiCfdaMgo47eA3CqXBBo 6eIZrH7K8gm8inp1+OCd5LgYpWOf5vaye3FQRz5TOzPHJWgxOld0+z1J+DTp1wVlMfAHyMnr+Tc3 2MMCyFUjZll4lNXoGeMi+J9pXNKyT08sze+k/WuH3JDtYTGLPe+0cDHUg7HeNfGn09IE7NpktFlx +prpLMllnAdahQYdo6xHzbAYkS59gNvzPb+x2aAzeL0ZlgG9iLgk8iNtgbHALiOw2AkL+yl5+LT0 tUBSYUgq7BU7KbKxOSRD+prNft/9o4mPdsWZKWENZOvSTNQunylBn3ZLP8UosFXyBsf++qxC9FWW 3qyOiDrFhjtT8idY/IR58ABYo3M75M9QmK0R7ATK95qesQHFuBkBPgLq5QQZNWl4JDuVPLFeW5XJ ZOh3nrhjIe/nufpWxkUI4KsV3xIjukQq5/qJjg3FDQashool9zJFmjScNWzcDuaVT2XdWdAZ6S9J PEuuLy35AuQU9Cdg4sUrRpPNrOP1ePdQMBPE+QCjhhc4X7H2KciYzG8V2BRoeVip4RlW95TlC+GV c6FGm8k2tp1IYi+7FwfV5aPICXiq21kSXLi2TI70+j1J+DTr1wVlUrNJUQ9hbTGftZgb0y9RoZcA FyN7kVHRsk+5qPJZ0v61Q0gFS2WWxt6ohYuRHhLofSz3/htE7KylGz32AMGeyQVZ0qLJiLb3koTA khCxvpH90LnnjseGgy4puOOjQBsq4KLuR0PSaTVJkyZI6F4b8X/NJml3+YNgkUs83l0EljNhsVoL QVXoXMQkOhxHA7IuPqama6a8pRYB5wmh5F2qF9z9EiI6TTx4+d9f7NQgNtyVzrhRIQ8eKbq+MJC0 FJzc67B6fE7qm8sTXKoTR0O9HJcRIjCNo7NovynjIui21PIHWo5Zdux7xfm98XY+IrVVOVGYzRfI erVGG4TODN7eMv98KuvOMkoj/SWIZxNwBC35AvQU9Cdgsu7GviBNXg+PabuLiyMq5yvWjwQZk/lt AODgBYGWHp7BqqQna4Fll8L9Ak0t+YRyXK9evWrYBm3FK+//TmIvuxcH1eWj8gp4qushCS5+jPXO dfs9LHk+o35dUBo1mxT1UAx5XUJHmDrf8DfjElEVegn0Z2QvEoNEyz7lospnSfvXDiEVLJVZGnuj Fi5Gekig97Hc+28IYsfks3yRzhSyPvyaf0kI/XHQIZXCauyeIuKbR+wKBVyU/UhrDycgk1/SbHOO /xIisNgJC7okpN3rk16PTjtqbZC8N2OBOku+1vVBw53LWceZInRn25A/ayCWogkLocUQHSSwCZiP DDvl00WjBteiI4c1ULzhzpLmuHyFMD0rdCMmUYam6hwRJozSAZNHM5mgXk7QoSYNJQHm7CZlXGJ1 yzGLHTzZsmvcG7uZV4ZURf+ZOK7zz6ey7ixsjPTHMdCOZxPQh5Z8AXqc90ibZJjw2MfiIfN9Xg8f 2PJru4GLIyrnIVI+60YmY9gyPcU6AthGXGC0dPEMq0+RN0ZTUz7TcgKr6vbJZTGyl12Kg+ryUVCM 8EyIi6AL3UPm5/QJrU6/R1t/Ii7K/bowaThW5v5Ox25sk/WQgZ1EVoUevycRLoG+Iq83TlYt+5Rk Uz1J3r92KKnJo8rVuPu0cBHtU1kPXB5tvY9jPvA7p+XZwqjrLguhY7C1urOEncnsn2EhPAi2ebWS HGxMxh+IeXUz8rG4RPiRUIbRsuhF/AVoMuJ4sJsILHbCgk0NdiEc8unvQNc2ydP9uXNBuqi8rMOu mRq7N8NC/V3NwtQsP58uu62yt7ZrVdp3wDMI3nCPa8CsEly+8IQFf3sK79x7lCbzzQITG1Co1ate jssYlQRSo7gYdynjIgTjoG45ZuODsM69FoZD0qWbzlbKRbKa9ZY/eY1AjnQC03wmhfv886msOxvG JttQUl1/HAPteDYBNWjJF6DHeY+0SWbTPPaxeMjiC6+H48av7QYujqich0j5jPUeAFPtgjGeYdVP WT7Ga1iigy+ljMNW3T65LOb2Mvs4qC4f1V8snlx+GU9+3RyXMNsZf435uX+AE1o0AZ8UF/1+XRgT nAcZQ9+9gh6CM13ohPoNbzN2HvN8NbinKvT4Pdr6E/jkcdXjhNcbJ6uWfXpVa30n71875NTk0WIt 5mYtXIz0wOXR1nsM3+E/cVrcFmgs7LRJu9MlA7f/x2T2+TPbz4MmDXLFGtkciE9lw+p2uRBwSeZH 4VLh1flFYLETFqzjygHerHk7xwPJrrf5D+K6e+2EBR/sp/I1oc74Q+6o+ZDB24hUV903LUQkNPQa bjHjHJKQEV5DGWyE4uVQ/ZXJG6KXuDrUy/EgZpqw6HfoALvivLGhUq2Hb/gTx+wMf1PGRQjgQd1y zHijEiWEzr3BOkZ03eG68PrdUsi012ApkyvzzyfTXYRvS1Ib6U+Y+qkbzyTiZida8gVIKOiPYcI7 7ywesvjC6+F2v7u4OKJyvmJ9jskYNjBXrCOAbcQFRksXz7D6FHljNDXlow8esu6Tr0CHlNbpDTLj sFW3z8nbyyzioLp8VH9Gepg8LmGWFHaN+blvgBN2r/Wghi0J0Y2Dgp3p9OuCfOj7Q3AGMCHNopf0 H7cZuAq9JLiYJNBlVLTsUy6qfMZo0E3ygw9HxvevHUIqWCqzNPZGxvNS9AvUsGMyS/4s2Gd2nT76 8n0E3wzEeSGeJfMjH008nXsEli5hQYiwkRKdZSFuRSFm9MqBtf5cV6PAk2GazWVv2UjT15Dye8Wj 4VAu2GZrEoEE3tAgvoI0zGFpxXoNNyFsTR9QHn0vFBFl5517kfvkxywwsQGFWp3q5XiAhEw5GOQU yDWL7r4idoc4vXRvCQnqlmMWCPwBvHTuDRS2L4xa/O03xUTTbMPrd67OP59sQ7DUGt2KasxHaIB1 9Cf6tF48G8OPws9a8gXqU9Afw0R/gL2buDiiKshn3chk1BzQB/BUuMBo6eMZrH3K8glThXPr8ibC fNo8kLh4pmOf07CXacdBHflM7WwauARtKXhFt99jzqdZvy6EY/62BMU9XYL9F/7GI+vJeHyboeZ/ xriwWGEel7TsMwio0pWk/WuHiBqWSgwp3KSFi6EejPWuwL98ixp2rH8vJSyEB6zZSmDPvW7VewFC SJwXcEnmR7I0eDb/CCxhwoKmLARjz4mzLPoN9qocoIP60kabDXpHwz5pN6okT1/rmA5pdMSOkvUW kUpz03Uyurttr03K9A0kgY1a+nWBnrWu39k7YtRvsx1wrTVUBXetl99cdBvuYWedr8mi75Ru9Z0E Srde4tcpveCgyE/Z7JwFplkkLOj61mqjSRqNRvCPvs+50wvkbG2hGI92woJ33s0knm4pxus4PIUA HtTtmEZl5L4WmE7HGw3pzszuayKtV+0O2W8DeizKSuvMpug0vgppdXussbHsukivO+sC02Qj9H1V Yj0ax4yXOefTFUnsTNnTHenu1wN7B+wBw4tJb6q/BPGM0TY80JLPoqGrP4YJ91EWD5k/cNuW7H43 cNGVz8KEyRgWk7lscQNzqxqlD6NlgKdFYJbyjTr8rVy0rfXazX67ymZXWDEmDhct+zS2l12Ig66y teRjute0M2NclCwy8ibm59IAJ/J2+sK1GffrLFYS+oNlv9linc4PsT59Ul3jD1LkmcH2DWb0THEx tReXVetLyz6FclqHCfvXDq0Jx9kxAmjhYqoHU72P4T34sxp2rB/r82f+Vhw6BtrwEtP0bY3VgjRe CcR5ARdtPwoKgVcWCIGlTFiQUZu9ytG/l0V3Q3YGZ3Dlrbt3vkP3gKDDjI2CN2VPvt+rI6wc36ci vAxky5H7aYgNd9imnEE7G5Jq3hswRtBb8IQFm/5pJxyiZQwkj1ywePC0yvLOexDL3b/CeGUDtAie aAD3pklLAzf7dj71LhD46e98Gmo0lpZ9y0k8Wqewwa31u7WBrecH9neuwpKBEVxrXV4UPplQUqdB xjagowT6M49njFOzAx35KAVt/bGn7NxHWTyk/uCkfrlt+zGdNS7a8lmoJ9C7ttIS4jlr+diTyJg4 HxbPGC6a9mlmL7OPg0byJbAzM1wYl0YHzM9p+6zW76EPqWbcrzP1B2+pk9RWSjYetrzBIH66yBvh ksBemMI1/Y+V0zxI0r92SPE2JDaeaPIVebsOLgn0YKT3SKajflDDjsdy2Z+H7bLcZ7Q23JR8wek3 BfRCcTH1oyhJ8PpiILCYCQtvs8qYdWBiJtM/NX3QoW8UoTMpwhqNdCZHZ09ET8jrbJTZ4FAqn8qQ ciO8XLtWDHXEbKEWmaywzIc7tMpu2Z7BDUit4G3myWVcLawxvqe1twBrPGL04nEpfquXs55ocZkk /H2BTppZIxBrlXOC3imuwstghNvm4lAZF2G9X3BpAMcs7LWmjIYPPz+28qulhmSjmAu1aavcarE6 8b1BFoVP0XAG3TpZy2VoMke22YCOEujPopcknon86h4ry0cr1tYfxSRn2yT3UTaQoUvoHLcdkHU3 HoTFtFnioi2fBXZCvWvpKyGes5evTyp5/tTZiUcpUqzV6WxGJzkaFs9ETHTs0yqnby+zj4NG8iW0 M31cRC71j836PSb647zp9uvM/IEPtLL5POuPsbY2Q996F9EfMaLniqetv4T24qGq639eOd1v0/61 Q4f3j3Jlcc87XS7U71fGJaEetPWuLoJ7J29/5f6hXFFn3Vve4X8RAk000tnf6UDf04nz6+4ef4G6 hYSFrh/JnOHZoiHwHothGjD35Gd76yJs9ndgZWUfDEfXwOGbDsPB6/YpYLEDWxcvQn9nH6zs24HR gRvg6OHrIbbkzjZc7GwCJQbDwQBWjr4PjhyMLaHAR/QtV6hs3W1KjpLYd8NRODxFWtFc4C/LjcAO bL/Th+3BDhVzCAPqD0ePHYP5M7VF4TOZtZjHs2R057004jLvGorm752LF6APB2DfzghWaGy5fnpN JmNC314wvjDw5uBAX38e0wb9Oq+oyveV83DfgTvgLL231B7C6dtGcPFCH66hfcghHIRbjx1WqcX4 HnNcjEnOruCM+9ezEyw5pbnXu6W7i1sAB/bBzpCOw44die9D7rIfJdcI1mCKwJ5OWJiChuUQAUQA EUAEEAFEABFABBABJQSEgRZdwgYPnbheqRjehAggAgIC6EcCGHvrEBMWe0vfKC0igAggAogAIoAI IAKIwCwRwIHWLNFGWsuKAPrRsmp2rFyYsBgLEd6ACCACiAAigAggAogAIoAIGCKwfR5OrdwBr9Li 9DX38MhJnGFhiCQW28sIoB/tWe1jwmLPqh4FRwQQAUQAEUAEEAFEABGYOgI7l+Dc2e/CT64ehF// zGfg+Cw2ZJm6UEgAEZgxAuhHMwZ8fshhwmJ+dIGcIAKIACKACCACiAAigAggAogAIoAIIAKIgIsA JizQFBABRAARQAQQAUQAEUAEEAFEABFABBABRGDuEMCExdypBBlCBBABRAARQAQQAUQAEUAEEAFE ABFABBABTFigDdgIbF+6AG/99GdwzTXXuIiMAK75N/CB247AviXE6Mo7l6A3GMGBlZvg8PXXRUpo iotpuUhG8IcFQOAKXLqwCQPqMUePHYt/l/gCSLNMLKr6+zLJPK+yXNm6BJv9IW1fHA4P3HAUjsTE 4OnLgX47fYzNKKDfmuGWrBT6QzL8sPRyIYD+MC/6xITFFDVx6fXn4Ow/vg3X+cbD+1duhA/e8RH4 8PFjc5MMOP/Y7XDHoy0ZjVQR+j94CJZvL+ttOHNqBR6k23WnCg34wSMnZbmFM1NcTMsJpPFw0RDY foPuAn+nswt8k+4Cf2L5PGfRVOLwq+7viynflLne2YJzzzwP3asxdK7sh4/e/wCcOByX3t6C5/40 B5/7elWqaFwMlm6exskC+O2bLz8L5348AF9XIhqN/b8C953+BPQMyzmR6wq88dw34LW3fwbvvfmT cPru49H0pvLLvPstxefFJ+HrT70MB9//fth+6y245RNfhNWH7oFjyoqaCnDJKl0Af0gmIJaWEdiB H778bWj+FOBa+Dn84gc+DnefPCLdsn3hdfjO6xfg2muB3vHLkPnsKTYuuPTGi3D2tUtw3XtvhntP 3w2HpZK07nNnodbdgutu/PeQ++zJQAzbeecCvPStZ+DsSw34Z1r2EP07+v7b4UMf/gh89K6PwYlb eY2mcTBRTwz9QdLorp4Q/EwNgWYxQ6hyo/9SObLRGUyNvk7FnVqRZLM5srqaIymP50yJzAd3OpKo 3DsgpbSjl0yxGVvAFBfTcrHMTPHHVjnr2GmmvKQ6NwNPC5dhk2Rd3yk2+2YEsdQUEFD39ykQX/wq Bw2S9tqEmG/6qsZYWZkvuXWk0mm7rcmVW7HlTH5ktFTi2dz7bZ8UUzH9iFCdpEh9YFrOQ5z7DaSK JF67XplJfnP649rpSVJVq6tPyrkoneTIvIX/5fIHNQ1N8y4tPKfJyETqHpCi2x+2xyupAulJ9Y5I VbL1NGkIAwM+zpGvO1VwHw6LIZv1YvT4yI5rGdJktJLGM0ko9ZO5bx/URVn0O3GGxRTTRT88cx+k HjxLKaQgt3oKfsGi9e7b8MTT1jXvk4XW4Ftw/KB3vvvfbz57H3zgC5THdAkGr5yGOWJtQuBcgVce +zJ87eW34M4/egr+4rO3KdVriotpOSWmJnQTs1Wq8z7VeaKM9IR4modqtHC5ch7uO3AHWN5NExbw EM6wmAcVUh7M/H1OmN99NnYuwJP/8T/DPzktGPQaT0PVnoyXgmzuTvvqu+8CfO5rRfhE5KNl/rQc siXYLJ+GI/umJ9py+e0OvP7kn8DT//SuqwEHtzA9eIi+Cyfga3/9APzLUyblTsMxWzfb8OynVuAL 1oSYDO0LvDTrvsD8+u3rj52Cjz36qgN3Og/VP/st+Mn3noQHvdlDqQL0fvCI72mzp53Zfy+XP8we Pz9FLTz9hefuXPBzm7cUVLtNuNsJAgDbtF+z4vRrHNYz0By8BCfcgQHDAuTrzr1C3f7xxNYrcPtN vwnevO5MvggP/tavwbU/78H/qf8P+PLXn6ZVpKExeAVO2rRM46AXzxyOtP9jv04bsqkVWPSMyzzz 3yrxp9ZDkdFhlxSzPDufKU3+CZNITveY8Z1e1hkWuog495viYlrOjEuzUm1hhoVkq2bVLU0pLVyk TDx7LLA0WKAgiICFgJZPMMhGpJxx2rxsuc2uTutAi8cF9VstGQWg1csNmM7owwuceedhOGiSDJvV kiedkffDkBTZdSDzNMtOXedUlgX1B08Ls/jWwnMWDCWiIfi5a79ZYUzS21jzzYIQZz0Qwvq3IF93 WBLq9sUQNkuF0izW5Tkddlk6TqqWK6TL/CtcyKnrAv0hHPhduIozLKaWCgJgmcewp9Y0u3iKZhet HD2d7ggvPXQihJMrcP7cN+DM37wAjX+21nZdppM1TsEXv7QK95w8Frx/5xK8+MyLcOnqjZC+5yOw +d0zUHqhAYPLtNwtd8Ln//gRuP+uW4PlfFdEvqNnWGzBy2eehx/Tdc1HTt5D+ZHXvNlVMn4Abv7o vXD3Cb4WzUcy/vTKRXju6Sq8Dfvh5L0PwMm4ddKU5jmKgbXe+tcyObiLPfFz1un9w09/TmtxP1ev wg2/+ruB9Xrez/5vNVz8pWQ7iMYzWE77yvZFOEfXHFde+DtoUZUfumUFjt50C10LmIaP//bH4bbD 4sJaZ23hqz+5CvspIG9+80F4wjJGmtEulD4P7wVnwTqFCD5KMQ9dm0718uLTT8BTz7wCK6kUDFot OHrqAfjS6hfg5DE7JR4qws7WeXjm+e/D1f0303XWd8OAroE881dnodEaUDs9Crd/8ENw75doHUf8 dWj6Qyj1cRcT4CJk4sutTbjrX/8WHnvym/DW4DJcvnwIfufhNcjff1fMjKVZyEf3I6B+24Ub4eZD 21B56gXbVk59cQ2++ulfgv/6la/Auh1sTsHj5a/DKeY/Dm7bW2/C33/vNai/9n340VvWBqPWZwVu /41Pwu995tNw120hPs7igGZcMi1n82Tg74zeCqTv+3245o3vwOMldf1Z63wff+wv4TsUv0OHDsHR O/8QHqb7CPy///kq/Ij646/+7r3UpkUftBlduH9iHIydjeXieZlG3P3wM3jpwUfBelgPqRyUHv4w gBVc6N+hqPZDC5ll99sgGMp68BVVLxfzdNRX5+RODfzWI67V/nmF9L/feeMxuOHOR+2Caxs9+Oop N+bRPt2naJ/OtnH6a7pQh1ceuUufwERK7CV/0Gw3jeJ8Ajxdfer1e2bYvwbu5ynaj2vRfhzd3M2d IXQFXjx9AP7AmuzAPvJMChZPtGZYCPVmyjB86f7A3haM3JgDRj9snDWmrNLPQr+uVG/B+y/8N3jy m3/njKsOpeAP/+w/welTcbO0Ne1Tiak9etMuJEn2DEmWefRlFm0ARi223j10feagTdbEdWVC5p6a KskUNkjgSTjN/I9ba5wp1smYhCXPmIbxzbS3SdY8niLWtw6afH3aaq3LSmofCGuo8xub8cV7G8Tb g0NeU90nBY9f4TtdaMTXJ/waq0/hPv+haTl/PXHno80ak9uyD/9fquDfqyMcD38563wtZG36sFsT njIF6RVqnUh2uV2kyWo+fJ8XuhGfXN7EH+QaFM8S4CJk4sNwtK+tVoN+a3E2K/kEX4rkkdlPnshe S9e6jllLv7oeMlvMNC6ZlrM1Ha7HWH9XoAcR+us1SgGf8+MrxyNFc5zD25TjGbU1Lxb7sZDO13y+ biRzuL4lOq5dB+LZIvhtCCbKevCVVS8X/XTUV+UET8P1GOu3lLp++2fOcqvktVlpUmcbewzIujBr 1rY72n9iP5uTMywZjuPS+YNJu2kU5xPg6WpQr98zw/41nTvFZr8V18maOxOuYjX+w4bbz8uSQt6d Me6bScHiie+6IzavW56lNSQVti/GKonuLY43f0Y/drwyvp7IOxTah/TaRvi4ysQ+IxnBHwAhmB4C zJFCNq8cNHkHNx3Y+LEnbYKTyhXIRrNFWvUqWRWSGPmab/Dudyy6qWe10abl1qXB5bipiozvMQGg U1llnfRKx58+oRv1rKbc33OkPS5LEqsGutmOKzd9ahF/Z6Pg0swQeZw9Iu2NCimvV0ilUmSJndBk UQQFVVz8xU3L+euJPh+RjbyHNZBcYZ00WtRemg1SKRds3QcSADS8dho1UqlWSa1WJQXW2cqQcq1G qvS6/VepkU7fr7xNkmeDWpo8Wyvb9DbWxamDKVLb9JdzJBi0uO17HSi6fpFUKR/rxTVbNzK/hv4Q DVjMLwlwCfG/Sr1JGrUSszf66IJUA3McZyifwGMqWySNRpUlTi1d5EobpL6ed30oRSpd0a+9hEWK rBZKpFZvkFa7RTYEf7LqCMgn0LT1rRqXTMvZ2jXw9xB6SvqjHWA+RRzIarlG2u0mKa2mWXy05B4X d2OMcq5+Uo9nfVJ340ittk5yXrIrvUZ93YsxFVJvh0wH1pZ4yf02BA91PciF1ctFDTbk+iZ7ZuC3 tC3Tb//Mua4XXL+mmxN6PbDgtHmaxE/7Ny80p6lfci/4g2G7aRTnE+DpKk+33zO7/jX382y5Sbyl GtbSvV7d6dOl8lXSWM+xvjXfCDPBkhBvyTxtG1PZAml0zdJ76vFM34vsEn57gSyphIyr1gLLWgzt 05DNvVAMExZT1DJ3pALpDodkMBiQQb9HWtIABki5La9377NBNx1A0AAif3qk5GZAAXxPQCXHojtV i9VubvBBU64ang10CXG+x6xbpU/QvI564AmI9Ft8kkGWL/ysUXCfaqSF3cpHDqbDIR8Ysx2LYzsL I7LuYrgcCYs+e+tJKr8RAuCA9PriwDN4i846wF7dSwpZM31k3fYafFZNVHJJbrhTpNz0DViGPdLZ 5MZr7A9BMbWv6OAirv2FVJ60BciHrTIbvPqftM9UPiFGlFoOg8zf2e7g9OmOO7iUB9kj0qWJsB53 N44nneHjze4K7Mkj0ATQiEum5ThX7pGiv4v0NPTXqXgdOSB5aSaZ9RSJJxJlLANMLswFZi9jEtqy QEP2FC9gH/KNEzlbOr8NQcVMD8IAY6z++EBGfjoawsxULin6LZ3H4L31y7T9U2ef06IbkTr7egxb JEcHXVZSMktnmLVZPKAPTXgzpk5iCncuoz8Yt5uGcV5UixaebkHdfg+R+tC+WWjSb3IfTORT7Zj7 eabUprOVKk5fJZ0luYzTfhUatE+2PskZFlGzolIku7pGytU6EbqAsWKYxsHYSsUfRXuhyQppXNWr szEQZOU37Bnbp0gbjyUEMGEhwTHZE+ZIbmNmP130Ha9V2j6i4lSpFNnYHJIhfT1Zv+/+0cRHm81s yAhTEmk1gmNlSv5EBxGeQuSIO1bx0XZOGd9jOzQjUmOzKOi0LmEg0616T2mBBGdfhJKNvcgHyTxg NNiTDi+JwQNvei0uiPP7liNhQV8d5SWxMkWaHIuFMvRHdZ1bHV5vSqzP/uya+WwYq5MbljMXG+4w O5UZTOAPckVGZzq4iP63WvFNcqRLwLxOrSzzjOUTYoQ3gGYyeh1wYYqod08QvJGdfO25cWk46JKC Owsq4FMCTVl2p1b+dNQXl0zLBZhV9HeBnrr+eN1WAtl74uqxMGzzRFU0lt7di/HN7GVs+yDKw3EK 2Id424SOtXg00vuM/TYEFy0ZhfLq5bjOdidhwenH20zy9k+AZ8wh58nCxGpq62vejIs12//b7Mlx 2CaEY6qf0s/qOqcMLIQ/JPA/I/lkxWjh6RbV6/dYhWbVv+Y2nSm2KN0ee2DhjFmypEX79lF2zbDQ WhLigNJvVfiA3zc2smclxiwtdmrQScB6JTS/BXsJi0PM/6n8PEGZwD412dtLt2PCYora5o4cXONv B4LVWgh1ofENcWB/0mNdeozbZNO7i1Ia0CHTEaZ0cccKssD4VuiQikG4wKZE0acQ3gBanBERJKV+ he5N4T3BLdsy90jBegpsPwl215KO2mxQuBa714UYoIOJnSimdHAR6zAtJ9YRf2w1bLKNZfMFsl6t kWaro7S7uw6PbEpshH3wusKnxIo2Mz6ZlcAf4kFT+pXLMma2kVWb0LCVWv5Ha9zmsmWrU+B9Ziyf wOO6u4wrKCPnNTDIHnRIpbAauzeBuMO4LaVAUysumZbzoGXfXJ6wDge7TaCno7+yG+tSdH8LIWfr VEufvmbdOB7AkhFerIOgvajwr6gDlaoU7tHi0VDvrI3TbacV+Fe5RUtGoUL1clxn852wSN7+CfCM ORTidXadbHbcp9HUBspuzGf4SgOYMdVO+WfGU0SbLZFfCH8Q9KDrf0bySQgp7vMml9Hr9zhlxTLT 619zP/faR2YvFrZ0Rrb14dfkRFzUdVcCNrMuOoYMSJsuTy4V8iST5jMSvbEOl9up0f+f0VexbX9h lXPBXsLacP4wVcQlgX2q8LRH78GExRQVzx2pQNq9Pun16LSq1gbJS/tQdH0c8OBhO2wqRejOvSF/ 1gA1RdbF5SRjHItv+iM6lo88PeV8KwzS6DMFb/o4ZCvOhoKbVTagWa365QvSU7vC6eSs3YAGPIFh 4bRm7X7lTWWjuETtn+DQ4hh7AVqFBz1ceI2m5XgNCkexm/tkSFW0k5Dq1HkUpsRGNBCsrogOG2+E 6WyZsbNBuK60/SFETt1LTJYIWaX6Yv2PyyHbHL8+E/kYjxx7pg8mI+dJaqB9ezXI/PKEmSwfRYjR DN/HITIumZaTlGKdcHkCvIn3xtKLqkO4LrwKjlXbq7GlQBKW7IbFO9DyCSaegFNgzyZ208QOtHhM qHfZD/xtdUg7PSEptWQUaKqX4zqLHmwIFU/8kNOP9VuLbsL2T531Id9cM5UmGXfpXIpuuud9GL50 +Zv4PMn7fTe+GU8sxsdwsRD+wG1D2/+M5JPx0sLTLcraWWtZwdh+j0eP93un17/mWHp+NuryRJy3 NwOT2TeTgi2P8V13JOB1q8aQUb9LKmve8hMaPzPyUgsPGe+b8aVi214hne9YeyGEL/0Qx1WC3FbS J3QMZ7UV02sfdERclHsxYTFFTTFHYlOtXWLCmkdrTbe8PEMwdN3ZCYJjBZ8Q0ole7H3KomMFAYjk O3irfaXNZm6kSYMG4rawZCBkokdELeMu8421rM5Bx9sMKO1Mx0zRJSAdJp9vb49A1RxjL0AHbgm5 oIuLV4VpOa+8+veQdJt1utFmkaxmvWUbVkC0/nLSkh1/nYzHsUFfmOrmt2u3Um/TJoDV0A4bb7jj 7dCpjusKdP3BL6TBuToutHLB/4KDUy6HbHP8+kzkYzxy7Jk+mO45T6IcvGNC99Yp1ugaU7HXxcvI 8sm4aMUlxisQrXIBPcfwJt4r0BPldm6JqoNft3YKD3xwhoULCccpYB8B0JJfWDq/DYFES0ahvHo5 rjPVwYZAZgKHnL6azZi3fzrMMvzsdtVpW3ligvLsbWAd0T7q0JrUvYxnFuNjak4YB2fSjglJaG16 RvLJeGnh6RZl7WzowF6uXzybfv86zM+oL3XapN3pkoE7bZDJ7OM/6rojA69bL4bIm/bLYyQRHd0H rHJZpTPBXsL6IeF6FeX2lqwrUcObYhDAhEUMOEl/Yo4c0khs1vgeD9n1tkBKmEqkO0ATHEve/M2p nm1ISQOO0pIQmgmOCxSM6X6dLddYLVfY61hT+Rq7ZRIHDLNMnhTsHfjpGxfaLWeGR3qVvnbJGaSH Ts2WGODBRK0j5BRm+lTFxaVpWk5i2eBkRPcVWBdeG1qKyR4xHhU6WexeumZf3LfEYVFoaCLqCg/w UQIm8IeoKjWuM1kjZJGqEvxPZ8DLppbr+rtEXPGE8aibsBD0QKdCi6kKm7IwMA/4FKPp35TS4Tky LpmWC0Ch6O8CPSP9sU1LOQPik6pgne59wzbJ0yct3ky6wMakvLq5OGI+EdKuRTOoqIPoCrR+YTwu i9+GSM9k1NKDTgef60xvsBHCrNElTj8QUxTq02n/FKpjt4hvb7AeBkhT1oVlqZBzZ5yykvxguNmi b+equX/0AYw3KuS3TPSI2crS+IPQHum2m0ZxXlaHFp5uUb1+j0Bv6v1rNT9jMkcmLPj+cpx7Xrdu DOEPSBTHK5pxkPM45kiwl7AZ4yIufFyVwD7HsLOXf8aExRS1zww51JG6wqsh5amD3FH5usgwNkf+ BdOCY1nTqORBhTC1jAZ433sZpOr5K1fp3hD+pfjSnd6J8NSdPXUIfyrqlTD5HnWrbHq1Mw0wb8ux kXc3vXJpBzbMCxDjQVSnI6SPi0PYtFyAbYMLoxZ/a0dRfs+rVBvbSDO1FmsbViGe8aedNX+dwu7V EDawpeV1G25jf5AkNDvRwcVshgXFs8ynP3rroMO4Dfh72E3jrrEYoZuwEJYC0aVf/tDTrfJXHAd8 itGkTyN14pJpuQAGiv4u0AsmF6LrYHGexh+//ure243ob8E6XUYDS23iO2gB8WZ8gdlrQJdxjETj F1fK9Lel89sQIJjdhfYvQgq4l9TLcZ0F/Ta6/sn9wukHYooiEdX2T7E6+zapH5IqSntE8Vms9PXG 1tLViE+zKPdZAu1oRDnTy8voDywOhcRdEadAu2kY58U6tfB0C+r2ezi9afev1fyMxQ1fwoI/cLCW YnOunSNx3CFvwj7oNEmzGzXAoDx5M5WstyH6OxwCGcaXZhwUqog/FOyFvRmIlaB76bEl/mtE9Hhj +2R144EfAUxY+BGZ4Pk4RxI7+TlxlkW/wWYsAKRJaaPNkg+jYZ9uUFMlebrRW9q/Flh0LBrEs8W6 25j2SdXbydq6LtIKkVd8KgiZAg0qm2Rzs0u63R7jw1+s3+QDYyeZ4OyY7b8v0fmoQ1Yp/84SByq/ OwWbb3rj/OZtJijRcl+BOqDT2EdD+kYDd+2p9erNIfttQI+lUtKJCS5WBablJOKxJ1ZwT9Fp+hXS ojryRBj126RIrzt4pclG6PsonYrFJIQ93Z++/WFgvwFiwOpjLAgZf6CNV7XtvAvEoseDt+/JEyus n7CgiwTN/EGgaXqohYvgf8HBaUynYJbyMR51ExbiW4aobje8t6DQtxZV+WtuLVsLDC4YTcc/leOS aTlL2cynNfxdoKelP7pPRYrFpTRZb3TJkMbpRpkncSxcgnW6VinQdXyV68bUbidbztoUrUEa9K/Z bJCyPbuN6jK1SmqNpn29Xm8S+kKrmE+M/ceUMv1p6fw2BIhx/YuQIvYl9XJcZ0BnFVZdXVt2IP3V G6TTi1V+FCvB6yZ+ay0PSNj+BRmJuyK8CYv6db7SstvIQacqtVPWtlpRH6YDN25ExoaoCjSvL6U/ mLabQrwN4s5tPtCOCZhr4emWM09Y0H0Sptq/VpOZ26zcPg3b66xPbr3Ovd6hfVCaJRr2O2Tdayuo nfvHHV7SLpsvkXqrS/pD2lbTcn06+6gklLM2/fT6tIIK2CHjaxYJCypHprjBxlW1Nb70Oittpk7Z M7VPJhke+BHAhIUfkQmej3Ukcfqgby+L7oY8CHA6snywbp2nC753MwuBOOx+51rYNH6/0OEZXSt5 wqc8+cvQGSNuEsCiE3Be/+1G5zJf7KkEDQwZStORj85WCYluPAvs3Rf+HUgCSXzK9DnGcbhYFZiW k4jHnNDpZyzL68hlTS/n/NFrMdNT7Yql4CpjE2zU6bRiYVaARMfTQ7Yc+kpTi5bYcEfbk80V+2fk D6x0ggMdXKj/eXYYxIxPEQzrCM1MPvY0n3c6mD5og+/0sTmvohziKzptnVsbSXn6Fr4D8pnGJdNy VN1G/p5Afy22j4/sO6JviFhKFsl04pXlupHu260TOmvKe0OTKI//mMXjUD65TQXsI/T+hBeXzW9D 4BjbvwgpY11SL8d15te1/zzl74tE0B532chv6fAhcfs3jjHf70P6dpCw2OfhMm6Wp7/9jJv96CNt drqk/mDUbiaI8wx8HTzdQqydHbMkm9GQDqbZv+Z+Hheb2aySAP9R/VuvPbO+g/uZeQkLz2fCv+mD ts2QDr2AjXo8EwrpHAr2Es5juHwWCSP71OFtj92LCYspKpw1SjHrBsVMrb/RGnToG0W814MKAwLL adKZHKk0fQs7hA5+Nk9fEeQrY82WGPOyCAGNPqkV/a8vDFujxotUGa90apiPNX5XsiP+alaRF54h jlqGwHThx8R3HnglY4BdfVycKkzLBRgIuTAkG8VcZAdqtVglMZMrWH2Dbp2s5TLuzsW8sfFPc/cK tGvFUJrZQi0yWWGV5QNfnd2yaaJD1x88RhN+K+Mi7OMQxMx6CuhgGpXMm4l8lMecbfPcf1hHii7h cSZoDthO+P59T7r1UsjgNUWKtTp9muIkyQI+ZBqXTMtRfRv5e0L9dTZ82NB9dSobVfaq5ciEBdOJ 53NcNwlNdzLFA/x5fMrfQZsXyXP7z5Xb4g9TO14qvw1Bidl4TP8ipBj3jbHluM6iO+qODUgzRMOI Kl5jMvnaZT99OcZMpv1TZJHdZs2o8F5ZLPJXqI6zb2uAJz5QmI2/L6s/aLebCeO8ZwDKeLoFTPs9 Hr3p9a95ey/7lUfZ+e6sezMG/S8KsH4fkI2S97vcLqRzpdBxx6BTp3vRZUP7kPYYZ7VIWgodVxYz xsYzWR7lM8FeVguFoM9n1kjgLfZC5dr2KZTFQxmB91in1DjwM8cIbG9dhM3+Dqys7IPh6Bo4fNNh OHjdviDHV87DfQfugLP0l1J7CKdvG8HFC324Zt8ODOEg3HrscLDMxK5chP9y+83w5y1aYbYMg2/d TyniZ7YI7MD2O33YHuxQskMY7OyDo8eOwcEQU5kYXzvbcLGzCdQ4YTgYwMrR98GRqRIEUPaHiQk5 24rmXj5L5xe3AA7sg50hjUfHjsTbmGlcMi03W3X5qO3AlSsA+6jP7bP+bb8Op1Y+Bq/Su2jCAh46 cb3vfjxdFgTm3m+XBehIOXah/QMaC9/chB3a/o0uD+CGm2+Dw+M6PjtvwulrPgBPu3LQBDZ86/7j kVIt6g+z9odZ05utXhakf037Bpc2t2B0zQHaNxjBwcNHqT+M64BegXe2+tDfHtEuxQ4MhgA3HD2m UG62GmDU7P6P/rhque2ToTPVA0xYTBXeGVcudPBn3Tm+8OLD8L4/eMIWmL63Gb561zSTIzPGFckh AoiAOQKmccm0nDmnxiWvvHMReqOb4Njh66Q63njyU3Dnl6v0Wgpqm034xJFxnTepOJ4gAojAkiFw 5cJzcOB9n3OlykFreAaOy2FjySRGcZIigP3rpAhi+WVAABMWy6BFT4YZd/B3ts7DU6Xvwf995x/g z5+wOuXWJw9d8hdwzDnB/4gAIrDXETCNS6bldgHv80+egju+/Cpkcmvwqd/5d3ArnUjxj2cfg0ef tuZW0M9qFUaP3w2YrnDgwP+IwF5F4IfPfgpSX3D6S3QpDZz57G17FQqUOwYB7F/HgIM/7UkEMGGx TGrfPk+nH99hTz+mG6DBIydpr3mKn+3zj8HKHY9KFMqtPtx/fLp0JYJ4ggggAvONgGlcMi23C2h4 CYtQ0pkidJ5/CG7Fp6ih8OBFRGAvIbB94XV47r//L7i6/whkHrgHjmEWcy+pX1lW7F8rQ4U37hEE MGGxTIreuQTnzn4XfnL1IPz6Zz4Dx6+fckv4zpvw3Ldfg5/v3w/X/uIvw8nf/Bh9sjhlmsukL5QF EdgLCJjGJdNyu4DpzvYWtH90Hpr/+8ew1fspnXU2hOGBfwvpzO/Db5+8FWdW7IJOkCQigAggAguL APavF1Z1yPh0EMCExXRwxVoRAUQAEUAEEAFEABFABBABRAARQAQQAUQgAQKYsEgAHhZFBBABRAAR QAQQAUQAEUAEEAFEABFABBCB6SCACYvp4Iq1IgKIACKACCACiAAigAggAogAIoAIIAKIQAIE/j8A AAD//xc+oTwAADiQSURBVO2dfahj13XoV2Cmk4F6WnvCuG8GOjYOxQlYTm3yJnkvE6oJhHy0Vpy6 qemT8xwMcggmlXmQoD+ScPtHiwzFVijmjourfPga23KgcigyIbJrJc1TeGjeQymRie9QzR9ycm+f 5UaXh8bRhf3Wkc7+OJ/aex/pXOnedWFGR0dn773Wb+299j7r7L3Puxj+Af0RgbUnsA+7167BcAxw 0y23wZl3L0+h67tvwsAp6PisjJM3nYOzNy6xwOWpknLO1+HNqwMYwTE4d/483HAs5eIPXXHry/P6 22/CzmgCJ0/dDGcOddsx80uHjcvem1fhjV/9Go4fd50lTNBv/h687/az6AXobxEEVq8/Wl+/tAh7 xOVx1NrDYfNncbY1/c223VK6cNJpcwmXgs4ulYATsKA/IrD2BMYdlgVwgm+s3B4uSZ0dtlXKTctw yuH/MuX2kso7ZNmO2tJGnWXZ6JAxi1NnbXmO2GZ21n4Ofdsx8kuHj0unnBF+kvtLyFTYkW79kx1W 36ywSiXmX3mTdXYmca0ff1vR/mht/dIc3Av4+Wi1h1X3Z2PWrpVZLptl+UJh+lks11h/vABDx2Zh 224pXTjWtLmES0Fnl08All8ElUAEUiCANwZ5N4hQWdLNcLea9wy+M9jRZbDMQrWbgoKrWYRgkquy 0TwRU7DRPBEO1e9ry1MOZHOVzqEySUAZIxulx8Wo3QaU0j+x3aiwfL7AisXC1FdOgxa5zfm+Qr+I 9btSuaEXQRwlAM7PzQu8Cxu6aZfZH4myyM8nqm9Hqz2k58/MjTJk1YJ86MTb3OyzwJY0hJyKKdqS YbuldOFWTptLuBR0Ng0CFLBIgzKVsXwCRjcGNuLIzhfym2ww7+GXTRFrmKa76QZxspvzn5ou3UZr CDCJyGvLc8ya5QLLYsCvtNVLQmD10xrZKD0uRu12QZR7POCLvmJucHNBZa5kNpNtVinkWQGf6jr/ chl+45SZPul1zjlBnkbso950+yOj+mJU51fSQqkIdfjbQ3r+zNRgrXJWPnzKlli92WSb6uzZTBnn Ly3jz7bdUrpwa6TNJVwKOpsOAQpYpMOZSlk2ARwk5dyI9XJmWExYNTcbWOarh/wmy8BWYtCFT97m zqT0DGSP9C2LAeGYS4lnDJwV+WnpfslOT6N2a1dEIJV600utX+Kxs0W6/ZGRjOSXpHFjjqg9xMBZ 5k8jOVYEKLFt8fBpzCrKTKfVGkfatndKF16VbLmE50Zn0yHwLqcYnAZFf0sksL97BZ5+7sfwzolb 4IGH74HRT1+Ey3/3DLS7I4Bbz8Gd7/8g3P/IF+DC2Rt8UlyHKy99Gy7/w/PQ/jeA0/AWQOYSfOmR Itx34bzv2l146fJz0If3wC2n96D25PPQxcsvfWkDvn7v78Lff+1rsDXN5BI8Xv0buHQ+ZJPI69fg xaeegCeffgVOZTIw6nbh3KWH4JEiynbeJ9v+m/DS0y9C/x2AP/j4A/CJ22/0yYNf916Hb1V/gJss noAL9z2E+vm3WTPRT2a/d/VH8PhjfwvfQ31Onz4N5z705/Do598Pl9/3UXgKL8OOBr58V4g8Mgu9 I9TxRdTxLZT/BPwa/vGLX4W6kzJTgM1HPwzwDiqP/05fuA/tcTaQp7XdTewAC7B7QPK4E/vws5ee gVd/+Q6cOAHw+ne+CE+86lyfhfLm5+F3AJngn4PmI/c/BHedUWx+/Qo8cPJueAZ/r3YHcPHffwCP ffM78MboLXjrrdPw6Uc3oPTgRfDVtGl+s//s6ouSgfnh/i688sK3oPrCy9B12uBpgFPn7oRP5j4L 9/7xxcDmrnu7r8O//PA1aL32Y/j5G84Go87fKbjzjz4Jn/3cvXDx9jPxMpiUt1Y8sd68/AL85Fe/ wbbk/mEluekDfwL3hLQdsK7Xi2gPdvXMzi+ZcpmxM69nCdottxfYceHJf3b5Ach8EVt/dhNGrzwc 0c534WXsx36B/uNshF8F1y+/idfc8pH74Z675rQpLsCKfqpchsglsudK2B+ZqZ+gvqyDX0o4fjFv f0H6qt2j2wOmc2R95vvQH52A7P15uEPtU502+eJz8GNsDH+QvRc+cUdYW0jWboOSx52x82fTHPeu wUvPfhtqz//zdOx6+tZTcO7mW+GDH87Cxz/1cbh9QTupv/3Tx+CmD311WuRGcwe+fslltvsKfObm j83GePhrttyCV75y0VV2D175VhX+FX3OiRv+EP77X1wE/wj66ivPwj/96x5efwI+/YUH4TY+kLFt t5QufHydNhe3BtDHChBIJy5ytEsZdSoMTY3/sqyoTjtTormBzedGPbbhbkw3S8unjc4+c+Wm94m2 5rrYWV4l1veZZNxviBkKYeWVG9veFDittcDlL9SYCFIrV/VrRVdvYFvbvufvpvq5+Q5anKWXhyrz wiLjyNTZo0LNO/R4I3zTTRu7G9shod0Vc2keDllZhwles+Hf/FR58hbK0cm3WPfWay6VZX3hyW0+ R9v12DaRKfv3XxixipjeHV5vilvdSFGMy1srnuH1Jhu1Ya1tvbZNx61iWc/s/ZIhl6mcNvUsvJyw dhhot06Zllw4VudT74nygG1w/xKxOaf0q8CKDX9Pppa4Hsd6XFCXhP2RGY0E9WUd/FKi8YtN+wvS 17d73Ibickp8qC9dQLsNSh53JrzehMqmZDMZNGLHWsG+VklseNjd5BunZ1lL7P47Ylt5X5/tW+ba rshlJMW6dzw83q7JcWK24l1OYttuKd2MqX98nTYXw/pFly+PAC0JWR5bkfOouymdmTsYy5UqrN6o s63KxvTNCd6AxQ6rKMGKTKHMmp0u67bqrKicLzUGogymDBIy+Qprt+tiE0pnUFrYbLLWVsmVI8Nq nvWxA1big0T8zG1UWbvbZc2tDUXuDGv4Nm7oVLjjz7F2YI4vdqTuEgpABy76hanEFvo56dBR8WUf jk6lrSbr9dq4Hti7E/3CAhYodateZ3X812hssQK/Gc1uoO0a0/P1eo21euGrHc3tbmGHRHaX1Uf/ aMK22w1WmzKps7Lo5HOsKpggs1qDbQ99YSxF1umNUqbAaq0Oazc2xdtDcPoKq/d96bD7N24P+gqF XzmUbzRxZM0WK6zltMFOC9vsLBDnbbNONnwgm2FF3OW/0Wqzbg/bUa2i6Ach+mFSm/LWiSeGNHvN Gqtu1VhN4RG56aaim5E/s003rQWW9SyRXzLkMpXTpp4laLcLan+6N2jbSqC75g90Yz2qF7m/L7Ce 31VM+azXf7pc0Ekk6o/MqCSoL0obXGU/bz9+sWl/Qfradld4Bsc2I7FUNehLLf1ZUFSDMzb+bMKa Jd6mcaxa3pqOP7udNqtV8S0e2P8G+1oDkXyXiv0rcJ8KPoLeaapjXTdwkfXvYzGUY1p1nILBLzl+ xrGwd7CLpdu2W0oXPr5Om4uvAtHXAyNAAYsU0HtvXDOs2vHd4I532PZA3vEP22URKChU/U9xdxSn qcyUUDq1ze5sNoPoEMUGQvj0yr3pVju+nZYsL1dueYjstOWMBpwi5/ltokSVPcET56odGTEvbHmj 0Vb6YZbbtYLgstHkXY1TGHba4sYZmKqb8+ti/sZyYLAZ/ZRcLcvU7lZ2SGB3VVbbY9u1zZApsZ4y 6WbcrQrb+nfHt60vtjo56dplHozDp7i1XiCryaDNGm21DjqXTFgfA32hbyPEJ0j8tbu5kPpjVZ5i +1Xn6QU4YVtuMDM4yHavVHQz8me26bBY23q2OL+kwWWKx76ecTuYtFtbLrws/in6o3mbbioBoMCT Wc9v3v6Il7Nun9pcPIqZ90ee5IZfTOqL+vBklf2S7fgliZ9XsWvbXfFpwbFNdMBiUe1WldnsWNef YSCAv+a61AwpYsR2hspgIeQK/VOyLOBvKxp3xWzhPM6A7IlxZsiDOPQ//G10ABvTmRRqsKUSjFb4 RLNtt5TOB9L9mjaXcCnobDoEKGCRAmf1xjW36Q9A+AUYs5p43VKGNQdjNh4N2XDo/huP0aHypRY5 OaUtpFMTHSJ3zM6NvXujoHZ8coqckp8QayifbvumyDnvgS/zWQf5Lc9U/t4WDy5kWdMTn7HUT5Hd 6Sj8t4pjZRaLqptQI/GBZBd5k+Urw8zuzpRpfpNsYIcEdveJa/VV1LF5NyFO7oqsxZo3iMUmctDg bSO29cVKHTdRXz4xCdR53XwnbDTcwYHWrN2OR31WdgdlwfpjWd7a8PQz02hLim68PYu6FufPbNOh 97Lyuwv1Sxpc/CgxSKZfz2RiwXJuu7XlIsviR/plTlhDzKIoKpviMdav81mCwIKzL3hJ6/Wpz0XV y6auqOnNjo1kVNrgavt5m/GLn5td+3Ny0Waq8OS+UEoRVQ8W125lWaZHUbL581Fm4+YqzDP5139p 4u9SJtxLZzpmbW24Sz0ys3Flj7/5DHKsI58jipKHneCMaWcmUa4SvjRYJJweyPKD4wDvld5vlM7L g39Lmwsvlz4PggAFLFKgrt64zh9kKc4bneB0SmXM5xZ/TK10any/iGCHKBu32vGJKXIRg1eZj3+K HGNqYEKuB1SCHL5AhjMbQiwVidGL6y30U24MMrjPQWAmsKK/qtvizCvZ6XY0ZnZnzMoOit6mdl8E G1k3NF5VqMi62fWPBCTffFWdwWJbXxJop+wirmtrUdpom9XKxdj1uHn/DAvb8taFp4DDD6StI/kq uhnVa9t0K+GXNLgIhBb1jKfFT/12u7j2p18m9hJKALrc4hFvZUp2YJmhotyaHZpwkaoZ1BWZyPrI SEalDa60n0ca5uMXF6GNn/fR12aq8AyObaLqweLarU9sg69RsvmzcAKU3rFuvlRmW/UG63S30TMv 8k/hgmPTgTJLuOqOSYRdMGARXOo8k6Ujghqu3BhED6wECRVbl4k/MaXzE5l9T5tLuBR0Nh0CFLBI gbMcfOVZZ+7MNtkAZ+s/MyyTCfvnOMoM2+q57lx0arIMUa4IRMi8ZcenTJET13mhxDpwZelHsd6f Jpz06yLQElgqogQejPRT0gWmCTulCv2XtSREsou8yfJiUwbd0ia+S5SvlnYQessy9OyuFJ3gUNSN iLrjyVrIGmajKL7yvFl98ZRs9kWVc+4UTyVrJfDAA24g2q4ckAXqj215arqOf7gkuXnLk+dT46kg mh1KGbyyKRcK3QzrtW06xb+YcZG6JPdLMq9ILg4i23qm4NVvt1ImMy5KYe6hfplOArl8EfK12ey9 QV0EAnlfEyxl/c6YceH6SbvE1hV+ecJPIxlFG1xxP+8wMR6/YJoFtD+naG2m68TTUUz8GdTR2M1B c6zOx7kib9uDsdxcM5NlOXeGcGZDLkURdgHcIydqvD5uizGu4xdLUZGNgJgGTDxpKZ0Hh/iSNhdR MB0cAAEKWKQAXdxARkwx84ogG2Bws0rvlZ5volOT09hEueJmUuYtAxbK1EEx1dqTM+tW865zLoY4 cJkn5KrTgaV0+FIWmaNyvdFTMpku/MagK9YWSt1kqcmPZPm6A0TBX8vulnawtntyIk4OwtaijsXk K2S1HMga1ZcYOeb9hHLyzV3z1eD+FVHJxTpvHMAUKg02GKmjnZj6Y1lefJAuqjx53si/RCltdV7K ENmWRF2RPkS0J1HXZD6izdumUwMWRvVMypDcL8m8Irkgb+t6pthKv91KmZLWF1FmRD+jiDc9VJ9+ t7Ep9ZQlc2FTtf3p1+W74CLqtY7k0i5xdUUnJ51rjGQUbXDF/fxUcclRb/yymPbnFC2YzmsPsTzl bFZvPVD0MvJnOrVB9xopg1e2qPRj1sdNrWvVCivm+fJYHugveJaGReWgc15wFzN81cAEysz3Q4u0 C84IKck3hswCuSVN+UyZcI0oHSfh/Uybi7d0+pYuAQpYpMBbDLS1blyVKWsmHY3o1AwH+Ki/dOBh TlfZlT3CgffrfE8NfE3UzkDueRG2dANvDMSSEBP9cMId35gpdOCsvBZL3Lws1LbmjtHM7pZ2SGD3 ReARdSeibnjKELKaDWTt6ounZLMvuAkX31grU2poplXqdWAZFGah5BkYvCm/6Zfn5NkRcgbrfFR9 VeQ0an+aGLQui5JNSSx0M/RntulWwi9pcFHlNK1nCl79dru4+iLKhDxz94VWJAo5HLbERrXFak28 5ntuGxn3WAmfnPKZiYBPSlc5wCG4rEPA4jD5ebfKWY9fErQ/p2hh93ntQekfAkts0N/x4Lq3X1lc uw1pmZqndPxZdFYT3PdpqyQDF5sLasTqW4icYINccoayTHpiA04ouDO7fCL2G3IfnWmwwg18hC5V 9qV1lkTzfeS89gpc6DtB6XxA3K/pchkPuvjGwIb7r8m2R4HF6eFi0tmFEKCAxUIwxmdieuOqPkHj 6+rCSpiobcV6oI5PDMQGmei8/VPglV3ZIayDdgRTrsliZDzjOvBAXq4SVvphWrHHA2RZgy9rDskz ePPmXpTow9wxGtvdxg4J7J4Ih5tYbBSKG1b5TBLMXshqErDwPtHSbg/B0g3O4GwX/pTFqWv+HV7d nMZjtQEqATWcwq7+4lwuB8XO5lz+jXdtysNM14anC0x8aLQloVtaAQv7erY4v6TBRQ3cGtczYQC8 WXJvBDTara2/lqXNjkZiszoMbGstTFdmnYmnocACN23BgsRN3OyGInotuj/pQXwXfN0Zinoy6NQV vZx0rjKpL2vnl4zGL0n8vJe0dntQlqD437g26si3uPn7FVGvsO2k02969bO/OZf5TLpSv/lv4JDp 4o7UJcuQqWAIQf6przct1mZLnOWvGM/oy2Vp/MGZ5w1f7rJoNY332LbdUjovR/4tXS6dindmTdQ9 DpeOPhdLgAIWi+UZmpvpjSu+X088WQK8Ydps9mZreDH3yXjIeu06K+HbPrLqjY/tAN+RWHmSBTgL pN6brYefDHvizQaBSLRH07CBJU6z89+18TQ2+mHa8faWXDeY3WDd4ayAfsu7a/O6Biys7JDE7twe CT7VYNd0GQS+FWM0fTPGKHDTbjuQtWoPCXRykqoDQadN1DoDVx/cFX6nx6r4Jh//u+HV15uVm/wt KPhWn7p8bbDTjvwDS9vy1oknOi42Go3w3xgP8Y0p7tph51XJY/HbCI9dw9nWa9t0TrEH4ZeE7ppc UMwk9cyl6wlSz223llx4Wfxz0q9J/50rs05/wAaDPuv3d0T/xq/ln0PlhmwafHB38ue/h36KOsCn k8ugV+j1qZ8cYR/eZm381+m0WbXI31JQxFcld6bnW60OwxeExfzZDtRjsoz56bD6+ZnKZuOXRbQ/ p1zt9jDZlm+tUsZnw17dE5gL9CsLarcx1SL4k4U/mwY28hlcRlljXfQFvAtwxp8VPD8LOjpvm+O/ BIs1OyOX0Th5l2rdaZmj7bpn3C03kee5q3ZQ3343EP2Zs69cvR8np227pXTcCt7PdLnIWVGzvmU5 9xpeDembJEABC8liaUdqwEJ3b55+03uTM3PafAA2+/SsmRZReDk4E+XiVNNZCEJOE/Q3NLlPhbcM UW6+GrsL8k7LK6+6iVEYWGP9ppmMWb3EO7AIObED8usWVr75OckuMDCIyEzwx0GGrt2N7ZDQ7hGi 65/2DIq8NgnYAW8k+PTVwG/KVPcwvnb1RV+N4JUT1izL6aiiHWD94see9ocZjHtV8dv0GmfDTeV6 ni5MPxy+GpfnBCzWhWenEs+SsxFBWNt6bZvOrQB29czeLxlzSVzPXEVN2i0msePiliU+wm4MnfaU jfGP+Mpf/upsbEt5zxuERMbeA1EHeFuVfaL3wgP6hk/0syF+gbcB/hn/9M68P0qkrUl9WSO/xJmY jF+S+XleovOp3x7EDJeYehPWryym3aoyxx/b+DMnYCGW+7r6ZbDv5O1g+hmxPCNemuhfx/h2kLC+ mZcZeB0v2kodewY2k8clybJNhy2t5rLYtltKxwl6P9Pl4h+fL2rWj1cn+hZFgAIWUWQWeF52cHLH e53sR9vN6UwK7kTVz2yugE99lUn4uM6xMHX2WIY7x03cMONSjtmpkdghOWw9YK9RCXXi+XIjNlgx 1UWUPxskxk1B5Lob6ccToSaNMt8ElA9IgRXLG+LmLUw3kdz6ACO57jKBguZGjLZ2N7KD4G5vd2sk bsJRv8U2CrgUSLmxcOpqoA4oa3EDv6FdOd+omxK7+pJMu+1mVdQrtf1BJseqbaX9ucU4s33kwIXX zwyrNFpsqzgbhAVea6qIaFTeGvH0d/QelsogXLCxrde26RQb2NUzO79kzGVB9czJRrvdumXacXET i48ha1T8r/2VvktcphzUcTbhrL5kAksBlcvkoagDPF18/jJhSkcB+bic3s+gj1Tlk/5Stz9SU9sc a9cX1I/vARTUQcq9Sn7e2WNoNn6a2SAot5dYUj8vc9NtD0NW82/0iE/znX6lWnD7lYhg3mLarZQ4 7sjOn41Zs1IIHXs67b5YqbOFTa5QhHdmVPB6qvZH5XpPuWp2OO7J2b3ZUkPMAlEvHDQ2RJAlHzlG lPXfrN1SOpW1PE6TixNgVANpK9avSCiH9uhdjmbYWOlvhQns7V6DwXAfTp06BuPJcThz8xm44d3H liPx/h5c2x4AFgbj0QhOnXsvnL1hSWW5Gtjodx2Z9PdQTBTt2E3n4MySZVwO7JhcD8AOMdKs1E82 9SWZAvuwe+0aDPePYX3bh8nJm+DcmRshslU4tru2C3DyGOyPsb2ePwtm1dOwvGTKQfo8EwqcUnIb Lqn6pcT1zA6kDRe7kpxU1+Cv7rwFvtHFw3wVRt99EG5wTtPfoSeQbj2zwHkA7e/ta1dhCCfh2P4E Tp0/DzdGdkJBfVaeJ+zD3ttD2Bvto/BjGGF/ew51NOs7g3rHn8G++vUB7ON4d/LWCG665XYcS8an oF+PKIH91+Hh4++Dp1z1MeAK333wjiMK42DUpoDFwXCnUokAESACRIAIEIEYAldffBTe+2dPTK/Y aO3A1y+eibmafiICRIAIEAEisHgC168+Cyff+9/cjAvQHV+GO969+HIox2gCFLCIZkO/EAEiQASI ABEgAikS2N+9Ak9u/hD+4+2fwDeeqLsll6DP/hrOpygHFUUEiAARIAJEwCHws299BjJfmPVHha0e XP6L2wlMygQoYJEycCqOCBABIkAEiAARCCewd+UxOHX3Vz0/VrtDePCOGz3n6AsRIAJEgAgQgTQI 7F39ETz7T/8b3jlxFnIP3QfnDZZjpSHfUSiDAhZHwcqkIxEgAkSACBCBdSDw9uvw7AuvwW9OnIDf +u3fhwsf+yjcZrJYfx10JBmJABEgAkSACBABbQIUsNBGRRcSASJABIgAESACRIAIEAEiQASIABEg AmkRoIBFWqSpHCJABIgAESACRIAIEAEiQASIABEgAkRAmwAFLLRR0YVEgAgQASJABIgAESACRIAI EAEiQASIQFoEKGCRFmmjcq7Dm1cHMII03kNtJNihufj622/CzmgCJ0/dDGduXP67idIu79AY6tAo sg+7167BcAz4rvfb4Mzyq5wRueT1c7X023vzKrzxq1/D8ePHXQ4TgOO/B++7/Sx61fX/s9XPNl26 xA5//7cedkjX6lQaETAjcPj9hBmP1bk6+XhidXQhSVaIAKO/1SMwarMsAMNqwsqd4erJt/YSjdhm dsY3U26noE3a5aWgEhVhRmDckW26vWptegH1c8X065QzU//p+FDxL1Nhq0berBLJq231s00nS07h 6Aj0f2thhxRMTUUQAWsCR8BPWLM50IQLGE8cqPxU+KoSgFUV7LDJ1a3mZwPnXJWN5imHg/+8O9Cu UMBiHi2L36VDzVU6FulNk6Rdnql8jBnVT/PsKcVKt+kF1M8V02+7UWH5fIEViwWW4UGL3OZ837sm NdVWP9t0qWJZsbq0DN3Xwg7LUFwzz8PeHx12/TTNHLjMiMsR8BMBQGtxYgHjibXQk4RMmwAFLFIi 3t10AxbZzflP+cgRL9kqY9YsF1g2m2Wlrd6Sy3KyT7s8c5WM6qd59pRipdv0AurnCuvX48Fi9L1z g8VrWFNt9bNNt3REK1yXlqH7ytphGcpq5nnY+6PDrp+mmQOXGXE5Yn4iAGtlTyxgPLGyupFgB0mA AhYp0ReDEpxhMZ5XpscRH8Yh9jwA9HvaBIzqZ9rCHYbysE3nDvOsqRXWTx0EH0ZvaqufbbqlN8cj 1v+trB2WbujoAg57f3TY9Yu2bPwvRlyOmJ+IJ0e/EoHDT4A23VzafiL78LOXnoFXf/kOnDgB8Pp3 vghPvOoUloXy5ufhd+Cdacnv4MdH7n8I7jqjbAV3/Qo8cPJueAavqHYHcPHffwCPffM78MboLXjr rdPw6Uc3oPTgRbhhmkPYf9fhykvfhsv/8Dy0/w3gNLwFkLkEX3qkCPddOB+WING5/d0r8PRzP4Z3 TtwCDzx8D4x++iJc/rtnoN0dAdx6Du58/wfh/ke+ABfO+iVOIOf+Lrzywreg+sLL0HV0PA1w6tyd 8MncZ+HeP74Ysqkh2uPlF+Anv/oNoDlmfwj/pg/8Cdxz4Sw/4/3cfxNefPpFePOd90D2vv8Kg+9f hs3n2zB6C3ne+iH4/P/4Cjx48TZvGvHNojyR1pCLkPMUZB/4Uzj+0+/B45vz6kuC+inkTHBgaL+9 3dfhX374GrRe+zH8/A1nQ1rn7xTc+UefhM9+7l64ePuZoDBWXILZmJ7Zu/ojePyxv4XvYeM7jRXz 3If+HB79/Pvh8vs+Ck9hZrjMC758140h2RraXc3BkCeAff08EP1UXQ2Pf3b5Ach8Eb1pdhNGrzwc 4zfdjK9fgxefegKefPoVOJXJwKjbhXOXHoJHiujDzvt9mE8YQztY1Wtfkcb6uen10u3Cy5efg19g P3X2wn3Yf4T4StHOAG75yP1wz10hbdEnc+zXpP2frv3wumefqsP/xR7hAvbBF9Q+2C8g6vgS9gV9 5PCHuQJcPL+4XXP17KAIpKsfTyLsY9I/8MQAoe394U/A//tfr8LPsSv8wJ/cj317Uh4L6I9MuUgV 7Y72rsFLz34bas//M3SRw+lbT8G5m2+FD344Cx//1Mfhds/Oygen34GMz7SJJuCS1E9Agv5WW79d eAn9Zx/eA7ec3oPak89P68qlL23A1+/9Xfj7r30NtqaD9EvwePVv4JLPr1j1D6K9G45bbdNNWViM J0R5q+yXtA1NF6ZB4PDHZA5KwyEr87XTcz43/JvwKZFjrAMs9F+xHj5TY9RjG+6GkmHpcuVmeLoE mEadiitjlhVLuVB5A5tbJpBztF0XT6vDdMyUw/alCLdHNm7TzZHcKDGsHOdcrtJik1B2FuU5+dhw 0ZATAvUlXL4wPQP1M1Rf/ZPm9huxSiaiHbjto7jVDQpgxSWYjcmZQYu3hWh5Q/elsbG7K5g5Tydh uP1j2wOmOgj9XDWtP0yeYI/7jVjfUm5sR8phbgfLeu2TwEQ/NaleugHb4H1QxKal0v8DKzb6ahF2 xwn6PyP7KZv2lZqDeFl3mmIvlLK/v45POfdXPTvMsjHSj5ecwA/utDdD+3O1n1gMj3B/pJbDj8P6 IysunI/F52TQEPWBy6V+BscgB6efbJ/pjM/McCbgksBPWI2zzBSbXa34GLV+hB+XmNd7WvYPGu09 dNxqm26qabgdY8cTGuUFx60zrOn5JRujU5plEaAlIcsii7ex2+0Gq9XrrNGos3Ke38DkWLXRYHU8 P/1Xa7Dtoe+W1++IMwVWa3VYu7Ep3jSAUyZYve9Lx3ZYRQlWZApl1ux0WbdVZ0XlfKkxZ3BmyGTU DQ5qcqUKq6PeW5WNqczegEUCOYfyDSqO088WK6zl6NhpYVnF6eDKWxZXZsJ6zRqrbtVYrVYRHGM3 3QyxQ73dQ55bnpua0BtQtL9xebb2C5Fzfn1JUD85UptPK/vxjjvDiuVN1mi1WbfXZU3Fjk5dCLQH Ky42SrlpcHDCl3048pS2mqzXa7NKwfvGimB9WZP2cBD6JTAHT6p/QzhgJX5zjp+5jSprd7GebW0o N20Z1hj4/S6WlGa95oq5n/r6eRPqptuuzfyqU6dr2/4FjRNWL/L6XWC9EDTeUjW+WbdbU/sNRX+Z LbdiBRu2y24dyLEFxyuYrh0wXGhXP2154g2F6s+K1Qb6sw7bLGaV9gAs6M9iUUb8mKQ/suQSIcn8 0xPWLPE6D6xQ3pr6iW6nzWrV8pRZcAxycPqlOj6bD893RQIutvXadpzlk1zrqyJjJl9h7XZdbKjv +NPCZpO1tkpue8qwWl/1r4sb92iNWxVZHdkA7zu00k1BWIx3Q8qbP27FwlL1S1pWpotSIkABi5RA 267Ng0yJ9RQfNu5WxWDB/2RDDqrQEVb9swx22GaOB038kdxkELwdYoZVOzveDMc7bHsgV48nkbNd ljM4irWetxz8Nhm0WaM9LyAzYVsuC/2ARYF1pAo4dmyKoAcU6hGzLLh4euVZc1Edv0F94dI5n0b1 U01oeGxnvwnr443jTtjNED7p4q8Azm36ZlksgIuJetu1gmibG54ntiNWFQHL4ADf2u4onB1Pv1Z6 9fMg9PNLavNd94Zwp8VvSjFY4buB3WnLmTNhN7d2drCs1z4Iuvr5kunfKCuBqsATM89v8Tf9/vIj v1u2Wxv7CbtllVfeTsZsNBqx8Vg6nE7F7XeyZbzdWeyfrv1s9JtKaslTbe8lz8yZMaspQdjFBCy8 TE36I2su3iINvg3la9FLzZB0I7YzVAZtIVekqV+a47MQVY1OmXBhlvU6SX9rpIxzsSLjZndWJ0R7 z3BfgrPY3Bmk3rZk2T8oZQIYjFtt0wWg6I0nVDYm9zkH6ZcCqtKJVAlQwCIl3MJJ6exUrziOYs03 BXnSZQUn+on/cptqUMIZRPCARIY1B2M2Hg3ZcOj+G49ZTzwpy7HWcHGKqx2iV6awMpLI2ZdPmHTe thJW/PQc3kAaBizC9JJPWQrM7YsiStQpLwEXq/riFdWofnqTGnxbhP0mbDTcwQHhrF6PR31WdmcP BYJPC+Cir5y0McAGPgv1/o2VWUjeQUkCu+MEUjEjYOnt4SD08zK0/aZbt7ubPBga5h/l03jcC8P3 pqdF2MGgXvtA6OrnS6YfsMBwbEPMoiiybXkfz/p1/nQwbPaFv0TN75bt1sZ+8mY3LwLS7bI7g0As gZF1P7uxoKCMgkLXfjb6TYux4il1BigF/VlPPjjx+jNFsQSHukycIqy5WMuHr23kD39yFeZ5KK6Z Z5r6pTc+01Q+5jITLuoN78qOk5W2x9uJ0FG8Zlu2NX5NEJFB/6CUaTRutU0XEFbqExiTqdcq5enb T+Z9EH5JFZ+O0ydAAYuUmAsnZRiw2Oyqj/UdYWWDzVfVJ8pKJ+oGNKbTuiKOt9RpGwkZqB1icMqw P/MEcipTwWIdob/IwHfJMDYfxaFWPNMrZhlub/En6jhN2G8mT5k65SXgosipX188AhrcvHjTGX1L Yr/RNquVi7HrhvMxMyxsuejrJ22cwf1ClHu6WRaKjbyDkgR2T8LTo5iUPbo9yGtS088jo/0XXd/b 4jeqET5a5sOfjLkyJbGDTb32oZBymb221SSd6uPLLT7HAJ808xs3dYaCTz7jr0pbMWm3VvbDvSn4 DK3qtE/cYWXnaef0iWd2Ftif9MRDAu/MKWPNQhPo2sFKP6dEK57z2ntXTG33+rNQFY1P6jJxMrbm YiwVT+AE8PjDodlnvlRmW/UG63S3tV6dnKZ+attd6viM40nwacLFtl4LnxUxNlbHzYnHyUrb23KX 0wV1lG0t0JZs+gelTKNxq226gL2lPtHjCUyklKfv52Xe4eOQ5fqlgKp0IlUCFLBICXfQScUUrDTk gANTAhZeZyAb8mz9WYZlMmH/nA42w7Z6sXfYMcIFf5IdIj6lip8JiYkTyKlySbSQWMrgZejTTS2v E5ySIjezyomnc74c3K865clrjO0XK6fMN05Xo/oZruT8s6qcJvZTbgjFYELUbTlwDOinlhewnx6X +UrxK2R+gWnzziWRssh0iexuwpOLLD6lDAGGIdekpp8oO9mBXt2W07ydGRRh3lHkA74ApWpbEzvY 1msfDiFXhNy+y8VXs3Ry2jLka7ONmwd1EUAs1vsi38QHKk/tdmtrP6lXoYY6jGQAw2mPG85UxEHN XeoVsX9JQoX17GCrHwpnxVPxCf5AsKPvTkMsfwuOURICweR6TJxyEnBJImbsJsk5Vp8zvkpTv9TG Z0l4umn1uWCChPXauL+10U/IKMfGwh7CX8u25mlLtv2DKDO4/NRRIXLcapsuwEXqEz2ewESx5UXl oZw/AL8UUJVOpEqAAhYp4U7VES/yaZcGH+GAcSAfMhHBl4N0OGAqJzo4vglYvhrcv8JXUMxXKYOu Qw1GgHHM1uSb8c3TW6c8eY0Nl7z7tMDT4U0JyHzjdDWqnzFkY3+ytJ9Y14o6FioNNhipUbEY/aw6 xFgNYn6UcoTf0EdF/mU6G7un1x6knKnpF0Pb5CdRt8UU3LDUytKciOu61bx7k1b07CvkDLxs7GBd r33i6+nnS4RfTdP1xIyyLGtjE+wpS2jm+/1g+ZFnrNqtrf3kBoqZjSbbbs18eiY7WxaSwSUg28LP L3bvJ66/nh1s9cNSrHgq7R25BP7GUf4scKXVCcFE3NRFZZOAS1SW2ufHrI+bfdeqFVbM8+VkPIBe 8Cyd8meZpn6pjc/8Slp81+eCmSes18b9rYU+UkY5RhT2EHVbtjV1/GbdPyhcjMattukCXKQ+cWNO ySYssBKVhzyfPQC/FFCVTqRKgAIWKeEWjjhiMOwRQ3EcqgObXSMbrNcZKFPLTQMBnsLNvwgHrBmw EFPyTOVUBkmZUsNcUJEiiqG4YHag2MG76djsZ7ERm/+Jqy8bdVaJ12bqhQnsp8ipX1/Uss1vXryp Nb9Z2U/hkt8KvpJXyTPAdgFcNDXDy9QnfcoGfjwD5TV4Xhsp+q10ezgA/Ti7hJ/C90I+dq8ZeV0p 5GZDeRuG34crdVDfLyl2N63XPh5S7nj9fMlkwGIOF5Fu2BLLJ4rVmnh9tr7OIqf4A8t2KzmY2W/Q cPfhyJVYefoGDHwDV6872wgvW2Rl91XdoVOQ4zXR+lXKHW8/eZ2ZfrY3BqKfFpsDSnUmfT7rJOxm Q15neyR09be1kAzFtbjXhrq/yuzSmHYbkleSUxPcT2lLea37ZkwUT8icgn6pjc+SwHPTmnBJXK9N +1sb/YQvMw1YJOgfRJnAjMattukCXMzH194xkZNhVB4KF1u/NO6xEi754zPQAxuTBvShE6tCgAIW KVlCbAyV2Zi/y7jiOPQbsvKmB3wSXQ3sfSEVnQQW2MvfbI7MOsQkcuLTFPG2hSy+XjBcWnV39/Ar opyh72rFDpCr+m6W5VRiJ1LPV3X7cnC/6pWnRtSN7KfIaVJfVFmN6qea0OjYxn7KjTJORfdX3X5d vnLxYAMWylpqwLrpqxCqbf02Un8zsjvWyDTbg1grnpp+RpUr8uJRh792GfckCFvr4aaUMwiA+d/A xJS3YUAgwGBjhwT12qeprn6+ZDg1WI+LTId6io2d+ZNkYGFP8WQaiyNLf2Zrv0m/LpY3zKaJl6b+ vFlyN990Z68FNoazUC0sia4dbPWzu7FTgtgh44mW8rYuvz8L09H0nEl/ZM3FVCiN6ydd+TahSszy sDT1S298pgFoziUmXGzrtX1/O0f4sJ+FLzMNWCToH0SZ6KNNxq226QJ66413be0nglq2fimw1Ma3 xDOgD51YFQIUsEjJEmqnOp3Wjm85GE3fdDAK3ITZNmQ2bIsnYIA3FZvNnrjJnoyHrIfvgC7hJmnZ ivp2keQATDvEJHLK9XfOgDnHap2Byw93Ud7psSoOqIPvQEcd3VfVjXA5wWSMb5ZwXyPlvKJwLH7D V9mpd8SqA0fnmK+03LXtQ1bfkIPZ/FbI8hSRp0F5tvZT5AwOHvU6D6P6maDK2NhPvo0FbySb/K05 +NabunwNpXOjcdABi/H2lrzxyW6w7nBWmfotfmM4u8kL2MjW7mgHG55T81nUz4PQL0FVE0nVp8GQ K7NOf8AGgz7r93eEf5xerMwgcHxLvTfbt2Yy7Ik30Tj1TG46KYqwsoN1vZbFTo+09VtAumFH3pDN bu6Db8TxFWP+1daf2dpvss2KaNepPvjJpxrLN4jMfuOb5pkrFJ9C2362+tnyxH0qMoJLlm21+/iq 1yFrV2WQ2GEW8Gfx6mr9atQf2XLRkiTsIuxT8xlcnlhjXfQhfMjg+IkKnp/Voyxrhr6He5Zfmvql OT4Lo2VyzoiLbb1O0N+a6DK9VshoGrBgzLp/EGXO/Jb2uNU2naOoxXjC+j4nqV/y6en09TGToYxN TgmWR4ACFstj683Z4yTl4Ci0w8cGxddEBwcDckpU4AYNS+w3vTdxfBCmfoauQfdKa/RN7RDj35Yh s7WXE9ccK093VL34cZh+cvmGlz1Pwz89wZyAYwtLGzYNlTGr8mztl6C+CIuY1E+RyObA3H5j5RV6 Uzs5G26KgbS0SaA9LIKLkYpjVi/xAauUi9ct/hls00narTlPRyW7+nkQ+hkZIOLi8JkBTlDX76/k PhUR9stXfa805UWa28G6XvMixae+fiLJ9MAmHb7C1Q32OvU573lTlTd3628J2q2d/bwcxOwa9Im8 H3amDff4nam1YlEJveVzP7Gw+pmEp9i3JKI9LClg4X2o4S07zH/a2T3KHvPO4xjMfZU2t5UzvZwf Tz8L7sa0UVkZ9rdJ9Et3fBalsOZ5Ey4J6rX9+FNTD36ZeJovb4qFPXAPi1lIXI7p1bpt3T8gF76n madOesZMIeNW23Soq9V4IoH9ukn8krAJ9yvSNtxs9LmaBChgkaJdRv0W2yjkcO0Ubyizz8A0cGVN dOA3Z22XuywiarA42m5OZ1KEOatsroCzEnzz1RMykI5V7oSsk2USObebVWUwqfDM5Fi1HdRvbofv OnPPqzEVB54vlYLl4dPaqM3ArcpzoRlzSVhfuK206ydPkODT1H7OLAX++kFZrzOs0mixreJssOix nSPbgriYqTlijTLfnFHWy2J5Q9SfqLXNxnZXBDPlaV8/D0Y/RVXLwyFrVPyvxUV/FbJEpNeohAbE 8uVGRLBCimRqB6t6LYtTjvT1UxLhoXm6On+VKb5tyr/0yZu35beE7dbGfvIV1WqdkLPTgsuALHWL TKZvB2P9EvLcbvp8L+7rUWvWxate1ZusSPUsfjDtj4y5WMg0SzJmzUoh1Ec4fVOxUmcxkytEqWnp dxDjM6GkxYE2l4T1Okl/q60WyliYji2lXxEBC1xaOOt+RmzLHdP7xwZW/YPtuNU2HcKwGk8ktJ+1 XxI24eMzaRttu9KFB0LgXU6p6GTp7xAS2Nu9BoPhPpw6dQzGk+Nw5uYzcMO7j62cpvZy7sPutWsw 3D8Gp47tw+TkTXDuzI2wMA2vX4EHTt4NzyCxzd4YHr59AteuDuE4ljWGG+C282eWytKey1LFWmDm hvbb34Nr13YBTh6D/THW5/Nn4YaFGXuBamFW17Ht9fcA6yXAsZvOwRkDQe3tbsgzgcoHo18CgU2T OnVte4AGPAXj0QhOnXsvnNW2oaEd1qheA1yDv7rzFvhGF4HmqzD67oPoCVfwL5H9VlAfv0ip67cP 16+jL3P8mfPf3o/g0qmPwqsoFwYs4Mt33eiX8GC+p8plH/beHsLeaB91HcMIxyHnzp9fbp+Uqn4z E9r3RwdTBUxLXXn9HJubjHtsx6226UyBL/T6NfFLC9X56GZGAYuja3vSfB4BxYGv1KBsntz0OxEg AkRgCQSuvvgovPfPnpjmvNHaga9fXG7QdgkqUJYGBK6/fQ12JjfD+TPv9qT66Tc/Ax/6yzqey0Bj 0IFPnF3RyLFHavpCBI4AAdtxq226A0BKfukAoK9AkRSwWAEjkAgrSmCNHPiKEiSxiAARWHMC+7tX 4MnNH8J/vP0T+MYTzk2q81eCPvtrOD/7Qv8fUgJXvnkJ7v7LVyFX2IDPfPo/w204keJ/PvMYfPUp Z24F/hXrMHn8nsXNapzlSv8TASJgS8B23GqbzlbOBOnILyWAt8ZJKWCxxsYj0ZdMYO8KTnu9ezrt FTdig69cWJFpr0tWm7InAkSACHACe1ceg1N3f5V/nX5Wu0N48A7yhx4oh/ALvzEIVS1Xge3nvgy3 eSdfhF5KJ4kAEUiJgO241TZdSmqpxZBfUmkcnWMKWBwdW5OmpgT234SXnvk+/PKdG+C/fO5zcMeN NO3VFCFdTwSIwJoTePt1ePaF1+A3J07Ab/3278OFj30Un7STL1xzq2qJv7+3C72fX4HO//kF7O78 CmfZjGF88j9BNven8KkLt9HMCi2KdBERSJGA7bjVNl2KqvGiyC9xEkfrkwIWR8vepC0RIAJEgAgQ ASJABIgAESACRIAIEIG1IEABi7UwEwlJBIgAESACRIAIEAEiQASIABEgAkTgaBGggMXRsjdpSwSI ABEgAkSACBABIkAEiAARIAJEYC0IUMBiLcxEQhIBIkAEiAARIAJEgAgQASJABIgAEThaBChgcbTs TdoSASJABIgAESACRIAIEAEiQASIABFYCwIUsFgLM5GQRIAIEAEiQASIABEgAkSACBABIkAEjhYB ClgcLXuTtkSACBABIkAEiAARIAJEgAgQASJABNaCAAUs1sJMJCQRIAJEgAgQASJABIgAESACRIAI EIGjRYACFkfL3qQtESACRIAIEAEiQASIABEgAkSACBCBtSBAAYu1MBMJSQSIABEgAkSACBABIkAE iAARIAJE4GgRoIDF0bI3aUsEiAARIAJEgAgQASJABIgAESACRGAtCFDAYi3MREISASJABIgAESAC RIAIEAEiQASIABE4WgQoYHG07E3aEgEiQASIABEgAkSACBABIkAEiAARWAsCFLBYCzORkESACBAB IkAEiAARIAJEgAgQASJABI4WAQpYHC17k7ZEgAgQASJABIgAESACRIAIEAEiQATWggAFLNbCTCQk ESACRIAIEAEiQASIABEgAkSACBCBo0WAAhZHy96kLREgAkSACBABIkAEiAARIAJEgAgQgbUgQAGL tTATCUkEiAARIAJEgAgQASJABIgAESACROBoEaCAxdGyN2lLBIgAESACRIAIEAEiQASIABEgAkRg LQhQwGItzERCEgEiQASIABEgAkSACBABIkAEiAAROFoEKGBxtOxN2hIBIkAEiAARIAJEgAgQASJA BIgAEVgLAhSwWAszkZBEgAgQASJABIgAESACRIAIEAEiQASOFgEKWBwte5O2RIAIEAEiQASIABEg AkSACBABIkAE1oLA/wfKyD/8j4JTPQAAAABJRU5ErkJggg== --Apple-Mail=_5A7CA70E-AB88-435B-9B5C-9DAEE2F4F367-- --Apple-Mail=_0D86D51E-72F2-4BED-813A-F468D5360D2A-- From nobody Mon Sep 10 14:22:22 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 133E1130DE1; Mon, 10 Sep 2018 14:22:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2018 14:22:21 -0700 Archived-At: Subject: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 10 Sep 2018 21:22:21 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-lisp-rfc6830bis-16: No Objection 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work on this document! I have some relatively minor comments/nits: (1) §18: s/RFC8060/RFC8061 (2) §1: "Finally, [I-D.ietf-lisp-introduction] describes the LISP architecture." First of all, it would seem to me that the Architecture should be a Normative reference...but I-D.ietf-lisp-introduction says that it "is used for introductory purposes, more details can be found in RFC6830, the protocol specification." This document obsoletes rfc6830...so it seems to me that there is a failed circular dependency. (3) References to rfc2119/rfc8174 and rfc8126 should be Normative. From nobody Mon Sep 10 14:43:46 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 153A5130DE1; Mon, 10 Sep 2018 14:43:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2018 14:43:45 -0700 Archived-At: Subject: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 10 Sep 2018 21:43:45 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-lisp-rfc6833bis-13: No Objection 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There are several issues in §5.1 (LISP Control Packet Type Allocations) that need to be fixed. I don't think any of them raise up to a DISCUSS, but I would like to see them resolved before publication. §5.1 "defines the LISP control message formats and summarizes for IANA the LISP Type codes assigned by this document". (1) Instructions (or anything directed) to IANA should be in the IANA Considerations section. There isn't even a pointer to this section later on for IANA to look at it. (2) The text seems to imply ("Message type definitions are") that the types are defined here (or at least in rfc6833, which this document Obsoletes), but they are defined in rfc6830, rfc8111 and rfc8113. Please properly identify the source (only the rfc8113 line has a reference). (3) Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting rfc6830, I think that, because of how the contents of that RFC were distributed, this document should also be tagged as Obsoleting rfc6830. (4) The LISP Packet Types registry was set up in rfc8113. This document asks that IANA "refers to this document as well as [RFC8113] as references" (§11.2), and it seems to try to change the registration (or the text is incomplete) in (§5.1): "Values in the "Not Assigned" range can be assigned according to procedures in [RFC8126]." Which procedure? s/Not Assigned/Unassigned (§6 in rfc8126) (5) Because of the point above, this draft should (at least) Update rfc8113 (see also below). (6) This document says that "Protocol designers experimenting with new message formats SHOULD use the LISP Shared Extension Message Type". I think this statement makes rfc8113 a Normative reference -- which results in a DownRef. Suggestion: given that this document already updates the registry set up in rfc8113, and recommends the use of the Shared Extension Message, it may be a good idea to simply adopt the contents of that document here (grand total of 6 pages) and declare it Obsolete. (7) Type 7 is missing. From nobody Mon Sep 10 19:13:19 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643E9130E17 for ; Mon, 10 Sep 2018 19:13:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 fcwWihM-4AzW for ; Mon, 10 Sep 2018 19:13:15 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 D423A13104C for ; Mon, 10 Sep 2018 19:13:14 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id x7-v6so26619312qtk.5 for ; Mon, 10 Sep 2018 19:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CcUbFUOnFScAud2LqiElwYRrYmvv9Kdx4fbBFUmNBBg=; b=Cuzny2xKtZ27xXlleN0+c5ioZbNTlMiW9Z5CvYI5z+2DcKj8ZUTtvF7+yowIuA8PYj 8G+e8Y5CWhk2rAZmLDgUePNEu7z3ICSWPkY3XNmDjV02pNQh88/IC7japQjrvWjFKDNa UuR2yTzJWirM8UarLFVRDinqg8FBMD7se66/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CcUbFUOnFScAud2LqiElwYRrYmvv9Kdx4fbBFUmNBBg=; b=tItQLVO2flHlIT9pyTvOX2yWERINWC9QkcOxflutvNWvIYnQTaaiQEH9cM4ltJznxh CYGnJBs2W1vHPMYrtGGb2+2yZOMfQcfLC8CDcsay8npj3Vyrzn6aO8lQ8JWu4N+BXruq DZvDmWtwWbtPbC5xj8EcWxAiCA2MYC0btJu9/BphW6UmBv1LRIJNMOMwN15bT9Zg/4jy uN6u9uJ04YwYvGcjFh1A+P1N8o1XEj7qXTlKuOBeWnP9rq9OsqFPpJh2ztN+xW58+Ahn oq+eoPQj3AJ2vO3oUZUcKdCEqXXWIOYFAHltYbcZMN39SOjyXmQeVYVTZruy/aB2yxuS JfQg== X-Gm-Message-State: APzg51D07gKEYlUeHSHQtbb6qJSV/xFI3c6khgP4aUeo881M0azkctct jbbTeYsFie7IW6sKS9cIWwjX77pCPHLyu5UhV/qaNght0J8= X-Google-Smtp-Source: ANB0Vda+RtUvaujke2BlAy5qajZTQc2Ej1HKc0PKjqK5/Ddvln0TZDq/bcGG3rMgmPilZbZQBWO4F7+F8B/SNEd0Plk= X-Received: by 2002:a0c:d842:: with SMTP id i2-v6mr16355801qvj.145.1536631993621; Mon, 10 Sep 2018 19:13:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Mon, 10 Sep 2018 19:13:12 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:922b:34ff:fe5d:efa3] In-Reply-To: References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> From: Kyle Rose Date: Mon, 10 Sep 2018 22:13:12 -0400 Message-ID: To: Dino Farinacci Cc: IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000021742005758f0470" Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 02:13:17 -0000 --00000000000021742005758f0470 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Apologies for the two-week absence: I've been on vacation (especially from email) for most of that period. On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacci wrote= : > > The whole point of LISP is to create a routing overlay for the EID > address space, the RIB of which is managed by a global mapping system, no= t > BGP sessions. If control plane traffic managed by BGP (or static routes, = or > whatever networks use once the DFZ RIB is limited to entities in the core= ) > continues to flow, that is of small comfort to end users trying to get da= ta > over the data plane. From the perspective of end users, BGP is being > replaced routing of the traffic that matters to them. > > That really is not true. You need both the overlay and underlay to get > user traffic to flow. > Sure, just like you need link layer connectivity and closed circuits. User traffic is directly handled by the overlay, which is an added layer of novel complexity. When you add complexity, you inevitably add room for bugs and mysterious behavior. Anyway, I'm happy to drop this point for secdir because this is more of a general architectural observation than something specifically related to security. > > * It does not resolve the trust anchor problem. Instead of proposing a > PKI, you seem to be proposing a trusted third party authoritative for the > Hash-EID namespace. (Q.v. section 2, the Hash-EID definition: "Another > entity=E2=80=9D) > > The trust anchor is the mapping system. And that is the PKI. And the > mapping system is distributed. > What PKI? That's part of what I'm trying to establish. How do entities decide to trust each other? E.g., if entity A has pairwise trust with peer B, but needs an EID mapping for peer C, it needs some way to establish that the replies it's supposedly receiving from C are genuine. One popular model enabling you to do that without employing transitive trust is end-to-end signing chained to a trust anchor. With TLS as deployed on the web today, the trust anchors are a set of mostly mutually agreed-upon CA certificates that serve as roots for the certificates presented by every public web server. There are of course issues with this model (q.v., certificate transparency, Symantec), but its behavior is well-established and its properties are understood. What is the equivalent here? It sounds like the answer here is mapping system-specific. E.g., from a quick perusal of the DDT draft, it sounds very DNSSEC-like (which might suggest a course of action to eliminate the need to develop, deploy, and maintain a custom security protocol, but that is a different discussion). Where an interface is described without reference to a specific implementation, a set of assumptions (e.g., "correct routing relies on the authenticity of mapping system responses") and associated security requirements for any conforming mapping system (e.g., "entities making use of mapping system responses must have some way to authenticate them that does not rely on transitive trust") need to be stated for the document to be a complete description of a system component. That is, without first clearly defining the required properties of any valid implementation of described interfaces, there's no way to evaluate whether the component under review will do what it's supposed to. A good place to put these assumptions and requirements is in the security considerations section: those statements are not normative for the system component described by the draft in which they appear, but are effectively requirements for whatever system component is to implement that interface in a conforming way. Enumerating them as such (in the document describing the interface in detail) allows the reader to evaluate the requirements in light of the system using the interface, while also providing a convenient checklist for those designing conforming systems. A set of well-crafted security considerations sections also makes it much easier for a reviewer to understand the security of the system as a whole without having to understand the details of every implementation, and to verify that individual system components under review will have the appropriate behavior. I'm going to skip the comments related to draft-farinacci-lisp-ecdsa-auth, just to limit scope here. We can get back to it once that document has been adopted and more fully fleshed-out. > "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed: > > Right as I explained DTLS does. > Check again. Just to be sure, I've tried several tools and the letters "T", "L", and "S" do not appear consecutively anywhere in this document. Neither do "SSL" nor "transport-level security". > > I would like to see a discussion of whether and how the nature and scal= e > of this problem differs from that of the status quo. BGP sessions and RIB > push have properties that are well-established from decades of experience= : > surely LISP does not have exactly the same properties. The security > considerations should make clear, for instance, how a loss of control pla= ne > connectivity differs from the loss of a BGP session, and how this impacts > visibility and behavior of the data plane. > > Please look at the deployment drafts. Please note, you are reviewing a > document that is focusing on encapsulating packets on an overlay. All the > other support pieces are broken out, in what the WG felt was logical, in > sepreate documents. > I think this gets back to the point I made at the end of my original review, which is that this system is difficult to evaluate from a security perspective in a piecewise manner given the dependencies between the different layers and the lack of explicitly-enumerated security requirements for each system component implementing a given interface. Kyle --00000000000021742005758f0470 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies for the two-week absence: = I've been on vacation (especially from email) for most of that period.<= br>

On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacc= i <farinacci@gmail.com> wrote:
> The whole point of LISP is to create a r= outing overlay for the EID address space, the RIB of which is managed by a = global mapping system, not BGP sessions. If control plane traffic managed b= y BGP (or static routes, or whatever networks use once the DFZ RIB is limit= ed to entities in the core) continues to flow, that is of small comfort to = end users trying to get data over the data plane. From the perspective of e= nd users, BGP is being replaced routing of the traffic that matters to them= .

That really is not true. You need both the overlay and underlay to g= et user traffic to flow.

Sure, just lik= e you need link layer connectivity and closed circuits. User traffic is dir= ectly handled by the overlay, which is an added layer of novel complexity. = When you add complexity, you inevitably add room for bugs and mysterious be= havior. Anyway, I'm happy to drop this point for secdir because this is= more of a general architectural observation than something specifically re= lated to security.
=C2=A0
>=C2=A0 * It does not resolve the trust anchor pr= oblem. Instead of proposing a PKI, you seem to be proposing a trusted third= party authoritative for the Hash-EID namespace. (Q.v. section 2, the Hash-= EID definition: "Another entity=E2=80=9D)

The trust anchor is the mapping system. And that is the PKI. And the= mapping system is distributed.

What PK= I? That's part of what I'm trying to establish. How do entities dec= ide to trust each other?

E.g., if entity A has pai= rwise trust with peer B, but needs an EID mapping for peer C, it needs some= way to establish that the replies it's supposedly receiving from C are= genuine. One popular model enabling you to do that without employing trans= itive trust is end-to-end signing chained to a trust anchor. With TLS as de= ployed on the web today, the trust anchors are a set of mostly mutually agr= eed-upon CA certificates that serve as roots for the certificates presented= by every public web server. There are of course issues with this model (q.= v., certificate transparency, Symantec), but its behavior is well-establish= ed and its properties are understood. What is the equivalent here?

It sounds like the answer here is mapping system-specific.= E.g., from a quick perusal of the DDT draft, it sounds very DNSSEC-like (w= hich might suggest a course of action to eliminate the need to develop, dep= loy, and maintain a custom security protocol, but that is a different discu= ssion).

Where an interface is described without re= ference to a specific implementation, a set of assumptions (e.g., "cor= rect routing relies on the authenticity of mapping system responses") = and associated security requirements for any conforming mapping system (e.g= ., "entities making use of mapping system responses must have some way= to authenticate them that does not rely on transitive trust") need to= be stated for the document to be a complete description of a system compon= ent. That is, without first clearly defining the required properties of any= valid implementation of described interfaces, there's no way to evalua= te whether the component under review will do what it's supposed to.

A good place to put these assumptions and requiremen= ts is in the security considerations section: those statements are not norm= ative for the system component described by the draft in which they appear,= but are effectively requirements for whatever system component is to imple= ment that interface in a conforming way. Enumerating them as such (in the = document describing the interface in detail) allows the reader to evaluate = the requirements in light of the system using the interface, while also pro= viding a convenient checklist for those designing conforming systems.
=

A set of well-crafted security considerations sections = also makes it much easier for a reviewer to understand the security of the = system as a whole without having to understand the details of every impleme= ntation, and to verify that individual system components under review will = have the appropriate behavior.

I'm going t= o skip the comments related to draft-farinacci-lisp-ecdsa-auth, just to lim= it scope here. We can get back to it once that document has been adopted an= d more fully fleshed-out.

<= span class=3D"gmail-">> "TLS" does not appear anywhere in the = draft of LISP-SEC I reviewed:

Right as I explained DTLS does.

= Check again. Just to be sure, I've tried several tools and the letters = "T", "L", and "S" do not appear consecutively= anywhere in this document. Neither do "SSL" nor "transport-= level security".
=C2=A0
> I would like to see a discussion of whether and how the nature and sca= le of this problem differs from that of the status quo. BGP sessions and RI= B push have properties that are well-established from decades of experience= : surely LISP does not have exactly the same properties. The security consi= derations should make clear, for instance, how a loss of control plane conn= ectivity differs from the loss of a BGP session, and how this impacts visib= ility and behavior of the data plane.

Please look at the deployment drafts. Please note, you are reviewing= a document that is focusing on encapsulating packets on an overlay. All th= e other support pieces are broken out, in what the WG felt was logical, in = sepreate documents.

I think this gets b= ack to the point I made at the end of my original review, which is that thi= s system is difficult to evaluate from a security perspective in a piecewis= e manner given the dependencies between the different layers and the lack o= f explicitly-enumerated security requirements for each system component imp= lementing a given interface.

Kyle
--00000000000021742005758f0470-- From nobody Tue Sep 11 02:15:44 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E489E13108B for ; Tue, 11 Sep 2018 02:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 X63SSecDzAoV for ; Tue, 11 Sep 2018 02:15:39 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 A254D130E73 for ; Tue, 11 Sep 2018 02:15:38 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id n2-v6so24916896wrw.7 for ; Tue, 11 Sep 2018 02:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xzn0KVFzcJipXxXZ0mcknGYFjlT+oht034oJFBiHOoM=; b=FcyOnI8w4hmsGDXdackdC8h4kXUw2WB3iLfP+OTIuan3akSMxjBqBxFH/g1NU3G/q7 /2Ig/SLx34GGmBk8A4Vc9WCtH5k+5YhCwuIMXOvvNLfFX4Cm08tW0grRU3X2WoKWUr8x 4z7k0Mukh9GFyQy06HjJSptv4+c5b6HQGhFMf6nYqZim9H+73zaogb/01fjQEL8LXHB7 HRfQkkOEvCqiCmukqu7QIyusfYskO8ox+WUp71m9cOyDtQiZaPtKNgh8FtTYv9qJaFon N48SdQuCx5cIdMFjSsW8MxBiuRbxULeICUmKo9bEcW4KqjuJQbPRT6ITeFSjBJb5mAri oZtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xzn0KVFzcJipXxXZ0mcknGYFjlT+oht034oJFBiHOoM=; b=USwip7qeWUpquIMcgHYx8jYWro8T2IFz6T7sbbcgdfLi8W+4JqnqlYq9D5l+QOzzbS hp/ZAFM/Yhtaa7jjqAFGHihF33XQVXLrQtbll43wMuJsVrrpWtcPttrqudV/jJ6jr7bT lKvMS+jR72tspVtkuscgV6jidsEuNNZTUSprdqHLFbw7bVKvkSySfT/gLDZmaFLF/sIA elkRXTuvAkUUX/i46SHlfUcnddNoaWXk8XkUMEE9GzUO8iLCavS6YAZ0gWXv0uAjytgL H7bf8HEYguYlaig1Cm11WXAkn5l/dyuQt4tSQ9r82XY762zc8z5eJO+b5DYITElmGcHR DzFQ== X-Gm-Message-State: APzg51Auom1TFzA9WKSzzCISxsskGXb05sJEQmSlQAXo41c2lX4wap9x RQPZ1PUZ6cSSCFRbKAoQavmEfQ== X-Google-Smtp-Source: ANB0VdYiQHB6/G1pdwD4tjsQr8uwBRNpTUDExrRBIueJsabB3mkjZTsllJBFGCZ+ykkOJSylKW8vOQ== X-Received: by 2002:a1c:a507:: with SMTP id o7-v6mr715217wme.45.1536657336904; Tue, 11 Sep 2018 02:15:36 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:b493:b5af:65cf:aebf? ([2001:660:330f:a4:b493:b5af:65cf:aebf]) by smtp.gmail.com with ESMTPSA id i4-v6sm18415462wrs.85.2018.09.11.02.15.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 02:15:35 -0700 (PDT) From: Luigi Iannone Message-Id: <673793DD-2D70-4FE7-A94E-BE74B5496F20@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_3F213EDD-ABC3-4227-B9BD-085FDA533DDE" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 11 Sep 2018 11:15:32 +0200 In-Reply-To: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org To: Alvaro Retana References: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 09:15:42 -0000 --Apple-Mail=_3F213EDD-ABC3-4227-B9BD-085FDA533DDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alvaro, thanks for your feedback. See my comments inline and let us know what you think. > On 10 Sep 2018, at 23:43, Alvaro Retana = wrote: >=20 > Alvaro Retana has entered the following ballot position for > draft-ietf-lisp-rfc6833bis-13: No Objection >=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 = https://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: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > There are several issues in =C2=A75.1 (LISP Control Packet Type = Allocations) that > need to be fixed. I don't think any of them raise up to a DISCUSS, = but I would > like to see them resolved before publication. >=20 > =C2=A75.1 "defines the LISP control message formats and summarizes for = IANA the LISP > Type codes assigned by this document". >=20 > (1) Instructions (or anything directed) to IANA should be in the IANA > Considerations section. There isn't even a pointer to this section = later on > for IANA to look at it. This can be easily fixed changing the first sentence to: This section defines the LISP control message formats and = summarizes for IANA the LISP Type codes assigned by this document (see = details IANA considerations in Section 11). What do you think? >=20 > (2) The text seems to imply ("Message type definitions are") that the = types are > defined here (or at least in rfc6833, which this document Obsoletes), = but they > are defined in rfc6830, rfc8111 and rfc8113. Please properly identify = the > source (only the rfc8113 line has a reference). >=20 Would it be sufficient to add a sentence listing the messages that this = documents re-defines and the original RFC which is obsoleted? > (3) Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting = rfc6830, I > think that, because of how the contents of that RFC were distributed, = this > document should also be tagged as Obsoleting rfc6830. Meaning that 6833bis obsoletes both 6830 and 6833? >=20 > (4) The LISP Packet Types registry was set up in rfc8113. This = document asks > that IANA "refers to this document as well as [RFC8113] as references" = (=C2=A711.2), > and it seems to try to change the registration (or the text is = incomplete) in > (=C2=A75.1): "Values in the "Not Assigned" range can be assigned = according to > procedures in [RFC8126]." Which procedure? s/Not Assigned/Unassigned = (=C2=A76 in > rfc8126) I think that there is some missing text, and that most proper sentence = would be: Note that according to [RFC8113] the LISP Packet Type values 7 = and 9 to 14 can be assigned via Standards Action [RFC5226 ]. >=20 > (5) Because of the point above, this draft should (at least) Update = rfc8113 > (see also below). >=20 > (6) This document says that "Protocol designers experimenting with new = message > formats SHOULD use the LISP Shared Extension Message Type". I think = this > statement makes rfc8113 a Normative reference -- which results in a = DownRef.=20 > Suggestion: given that this document already updates the registry set = up in > rfc8113, and recommends the use of the Shared Extension Message, it = may be a > good idea to simply adopt the contents of that document here (grand = total of 6 > pages) and declare it Obsolete. >=20 Or just make a 8113bis standard track. The RFC Editor will hold the = document until an RFC number is assigned to all normative references. Having said that, I wonder if we really need that =E2=80=9CSHOULD=E2=80=9D= .=20 If I experiment with new messages and I make sure that nothing goes = beyond my own deployment, why being constrained? And what if (still isolating my experiment) for any reason I would like = to play with the reserved bits of existing messages? How do I do it? I would change the sentence in: =20 The LISP Shared Extension Message is for experimentation = purposes as described in [RFC8113 = ]. > (7) Type 7 is missing. It is not assigned, and yes=E2=80=A6 should be stated (see above). Ciao L. >=20 >=20 --Apple-Mail=_3F213EDD-ABC3-4227-B9BD-085FDA533DDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Alvaro,

thanks for your = feedback.

See = my comments inline and let us know what you think.

On 10 = Sep 2018, at 23:43, Alvaro Retana <aretana.ietf@gmail.com> wrote:

Alvaro Retana has = entered the following ballot position for
draft-ietf-lisp-rfc6833bis-13: No Objection

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 https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


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



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

There are several issues in =C2=A75.1= (LISP Control Packet Type Allocations) that
need to be = fixed.  I don't think any of them raise up to a DISCUSS, but I = would
like to see them resolved before publication.

=C2=A75.1 "defines the LISP control message = formats and summarizes for IANA the LISP
Type codes = assigned by this document".

(1) = Instructions (or anything directed) to IANA should be in the IANA
Considerations section.  There isn't even a pointer to = this section later on
for IANA to look at it.





(2) The text seems to imply = ("Message type definitions are") that the types are
defined = here (or at least in rfc6833, which this document Obsoletes), but = they
are defined in rfc6830, rfc8111 and rfc8113. =  Please properly identify the
source (only the = rfc8113 line has a reference).


Would it be = sufficient to add a sentence listing the messages that this documents = re-defines and the original RFC which is obsoleted?


(3) = Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting rfc6830, = I
think that, because of how the contents of that RFC were = distributed, this
document should also be tagged as = Obsoleting rfc6830.

Meaning that 6833bis obsoletes both 6830 and = 6833?



(4) The LISP Packet Types = registry was set up in rfc8113.  This document asks
that IANA "refers to this document as well as [RFC8113] as = references" (=C2=A711.2),
and it seems to try to change = the registration (or the text is incomplete) in
(=C2=A75.1):= "Values in the "Not Assigned" range can be assigned according to
procedures in [RFC8126]."  Which procedure?  s/Not = Assigned/Unassigned (=C2=A76 in
rfc8126)

I think that = there is some missing  text, and that most proper sentence would = be:



(5) Because of the point above, this draft = should (at least) Update rfc8113
(see also below).

(6) This document says that "Protocol designers experimenting = with new message
formats SHOULD use the LISP Shared = Extension Message Type".  I think this
statement = makes rfc8113 a Normative reference -- which results in a = DownRef. 
Suggestion: given that this document = already updates the registry set up in
rfc8113, and = recommends the use of the Shared Extension Message, it may be a
good idea to simply adopt the contents of that document here = (grand total of 6
pages) and declare it Obsolete.


Or = just make a 8113bis standard track. The RFC Editor will hold the = document until an RFC number is assigned to all normative = references.

Having said that, I = wonder if we really need that =E2=80=9CSHOULD=E2=80=9D. 
If= I experiment with new messages and I make sure that nothing goes beyond = my own deployment, why being constrained?
And what if (still = isolating my experiment) for any reason I would like to play with the = reserved bits of existing messages? How do I do it?
I would = change the sentence in:
 
	=
The LISP Shared Extension Message is for experimentation purposes =
as described in [RFC8113].



(7) Type 7 is missing.

It is not = assigned, and yes=E2=80=A6 should be stated (see above).

Ciao

L.






= --Apple-Mail=_3F213EDD-ABC3-4227-B9BD-085FDA533DDE-- From nobody Tue Sep 11 02:18:20 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C431310FD for ; Tue, 11 Sep 2018 02:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 Q--s5GvM_H9W for ; Tue, 11 Sep 2018 02:18:03 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 9EDEA130E5C for ; Tue, 11 Sep 2018 02:18:02 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id g33-v6so24968933wrd.1 for ; Tue, 11 Sep 2018 02:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=n5Y724u5OXBBefCq76QbkwEaAJCmLwZc4l8kZizCLmE=; b=FI5W/HF1NtjizkgUludyYFXWdBlUaP7lmljM7chywyn0F4Hnpu8YQ6+gLNkgAy6+P4 gXE851T9k9L7Q/ucfKbksZ6MAgpoJQ1+0VwtrNDKOXSEUwfYe0NQSjxU6ug3wHKuTCDy 75LsVFhqvMAYGJC1BTF7sitXDf2MTLb45l0RmsYoDJAIykm5WbQPBbJmvspr6fB3tBan 3bwYYZ3SiqpKxBoLK/Yiz+KXp7JcD6O7mc6YhtPUaAXcBG1o8j3uUxVF661MLXJ8Puzm Kjv0Ij5PycGfDSaSvFoUS/y9h0Sz9SxNWc5ujV/L++uhxEBeZJk0jSEtxH0StEWzAwY8 PyxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=n5Y724u5OXBBefCq76QbkwEaAJCmLwZc4l8kZizCLmE=; b=BNMIyaKRD9Nk9FCWABbIKkEEaRKNuHKc/BMcec1eHPUsRWM3I3Gm7Tq3/GF1CPNsz4 Y2SvKgY+dW+Di8OXm8lyCKkSTz0zuI1dkpU6+m5scZbTwD9NHNj2FwkSWnsXieFudRND kF81pLxcbQSI9VsA/HmCDEOdAqo72k9KYLWJ5vEJz1detJi1E+TaEzcwKIbSpg1pint3 XJ7o1PBsKWmr9uztrKYxHN4WkPCwV4UkZ+ZCODsJmceO1qyKWHQkRuwrYz7y+WYRREtz knEUbos1u/vhF0YRiP6NHUJhpSZaoy+nLt9BSsU9Bw6dpF6/ZxgkZyg14mzElRz21wHn Qxug== X-Gm-Message-State: APzg51AqaIUJM6mde4+4ugR0QdAgK197QGRS+vpFAdvoLgRvNvuhP5+k gdw5rcy/NH2Zf01x120fm9F//Q== X-Google-Smtp-Source: ANB0VdZ2TE703+Co0QLym0A3pHRe2gHn4oJxyxOcpxp0AiHk1ZabCOSsF8QSmcc9Jwmk4jo+0y43XA== X-Received: by 2002:a1c:b441:: with SMTP id d62-v6mr693199wmf.17.1536657481045; Tue, 11 Sep 2018 02:18:01 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:b493:b5af:65cf:aebf? ([2001:660:330f:a4:b493:b5af:65cf:aebf]) by smtp.gmail.com with ESMTPSA id y205-v6sm9837464wmc.3.2018.09.11.02.17.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 02:17:58 -0700 (PDT) From: Luigi Iannone Message-Id: <77109099-A756-4563-968C-5AC17FF38291@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_722DBC36-275B-4B0C-80DA-04799B4F7825" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 11 Sep 2018 11:17:57 +0200 In-Reply-To: Cc: Dino Farinacci , IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk To: Kyle Rose References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 09:18:12 -0000 --Apple-Mail=_722DBC36-275B-4B0C-80DA-04799B4F7825 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Kyle, good for you having a break, hope you enjoyed your vacation. Any thoughts about my last email on the subject? Ciao L. > On 11 Sep 2018, at 04:13, Kyle Rose wrote: >=20 > Apologies for the two-week absence: I've been on vacation (especially = from email) for most of that period. >=20 > On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacci > wrote: > > The whole point of LISP is to create a routing overlay for the EID = address space, the RIB of which is managed by a global mapping system, = not BGP sessions. If control plane traffic managed by BGP (or static = routes, or whatever networks use once the DFZ RIB is limited to entities = in the core) continues to flow, that is of small comfort to end users = trying to get data over the data plane. =46rom the perspective of end = users, BGP is being replaced routing of the traffic that matters to = them. >=20 > That really is not true. You need both the overlay and underlay to get = user traffic to flow. >=20 > Sure, just like you need link layer connectivity and closed circuits. = User traffic is directly handled by the overlay, which is an added layer = of novel complexity. When you add complexity, you inevitably add room = for bugs and mysterious behavior. Anyway, I'm happy to drop this point = for secdir because this is more of a general architectural observation = than something specifically related to security. > =20 > > * It does not resolve the trust anchor problem. Instead of = proposing a PKI, you seem to be proposing a trusted third party = authoritative for the Hash-EID namespace. (Q.v. section 2, the Hash-EID = definition: "Another entity=E2=80=9D) >=20 > The trust anchor is the mapping system. And that is the PKI. And the = mapping system is distributed. >=20 > What PKI? That's part of what I'm trying to establish. How do entities = decide to trust each other? >=20 > E.g., if entity A has pairwise trust with peer B, but needs an EID = mapping for peer C, it needs some way to establish that the replies it's = supposedly receiving from C are genuine. One popular model enabling you = to do that without employing transitive trust is end-to-end signing = chained to a trust anchor. With TLS as deployed on the web today, the = trust anchors are a set of mostly mutually agreed-upon CA certificates = that serve as roots for the certificates presented by every public web = server. There are of course issues with this model (q.v., certificate = transparency, Symantec), but its behavior is well-established and its = properties are understood. What is the equivalent here? >=20 > It sounds like the answer here is mapping system-specific. E.g., from = a quick perusal of the DDT draft, it sounds very DNSSEC-like (which = might suggest a course of action to eliminate the need to develop, = deploy, and maintain a custom security protocol, but that is a different = discussion). >=20 > Where an interface is described without reference to a specific = implementation, a set of assumptions (e.g., "correct routing relies on = the authenticity of mapping system responses") and associated security = requirements for any conforming mapping system (e.g., "entities making = use of mapping system responses must have some way to authenticate them = that does not rely on transitive trust") need to be stated for the = document to be a complete description of a system component. That is, = without first clearly defining the required properties of any valid = implementation of described interfaces, there's no way to evaluate = whether the component under review will do what it's supposed to. >=20 > A good place to put these assumptions and requirements is in the = security considerations section: those statements are not normative for = the system component described by the draft in which they appear, but = are effectively requirements for whatever system component is to = implement that interface in a conforming way. Enumerating them as such = (in the document describing the interface in detail) allows the reader = to evaluate the requirements in light of the system using the interface, = while also providing a convenient checklist for those designing = conforming systems. >=20 > A set of well-crafted security considerations sections also makes it = much easier for a reviewer to understand the security of the system as a = whole without having to understand the details of every implementation, = and to verify that individual system components under review will have = the appropriate behavior. >=20 > I'm going to skip the comments related to = draft-farinacci-lisp-ecdsa-auth, just to limit scope here. We can get = back to it once that document has been adopted and more fully = fleshed-out. >=20 > > "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed: >=20 > Right as I explained DTLS does. >=20 > Check again. Just to be sure, I've tried several tools and the letters = "T", "L", and "S" do not appear consecutively anywhere in this document. = Neither do "SSL" nor "transport-level security". > =20 > > I would like to see a discussion of whether and how the nature and = scale of this problem differs from that of the status quo. BGP sessions = and RIB push have properties that are well-established from decades of = experience: surely LISP does not have exactly the same properties. The = security considerations should make clear, for instance, how a loss of = control plane connectivity differs from the loss of a BGP session, and = how this impacts visibility and behavior of the data plane. >=20 > Please look at the deployment drafts. Please note, you are reviewing a = document that is focusing on encapsulating packets on an overlay. All = the other support pieces are broken out, in what the WG felt was = logical, in sepreate documents. >=20 > I think this gets back to the point I made at the end of my original = review, which is that this system is difficult to evaluate from a = security perspective in a piecewise manner given the dependencies = between the different layers and the lack of explicitly-enumerated = security requirements for each system component implementing a given = interface. >=20 > Kyle --Apple-Mail=_722DBC36-275B-4B0C-80DA-04799B4F7825 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Kyle,

good for you = having a break, hope you enjoyed your vacation.

Any thoughts about my last email on the = subject?

Ciao

L.


On 11 = Sep 2018, at 04:13, Kyle Rose <krose@krose.org> wrote:

Apologies for the = two-week absence: I've been on vacation (especially from email) for most = of that period.

On Tue, Aug 28, 2018 at 6:17 PM, Dino = Farinacci <farinacci@gmail.com> wrote:
> The = whole point of LISP is to create a routing overlay for the EID address = space, the RIB of which is managed by a global mapping system, not BGP = sessions. If control plane traffic managed by BGP (or static routes, or = whatever networks use once the DFZ RIB is limited to entities in the = core) continues to flow, that is of small comfort to end users trying to = get data over the data plane. =46rom the perspective of end users, BGP = is being replaced routing of the traffic that matters to them.

That really is not true. You need both the overlay and underlay = to get user traffic to flow.

Sure, just like you need = link layer connectivity and closed circuits. User traffic is directly = handled by the overlay, which is an added layer of novel complexity. = When you add complexity, you inevitably add room for bugs and mysterious = behavior. Anyway, I'm happy to drop this point for secdir because this = is more of a general architectural observation than something = specifically related to security.
 
>  * It does not resolve the trust anchor = problem. Instead of proposing a PKI, you seem to be proposing a trusted = third party authoritative for the Hash-EID namespace. (Q.v. section 2, = the Hash-EID definition: "Another entity=E2=80=9D)

The trust anchor is the mapping system. And that is the PKI. And = the mapping system is distributed.

What PKI? That's part of = what I'm trying to establish. How do entities decide to trust each = other?

E.g., = if entity A has pairwise trust with peer B, but needs an EID mapping for = peer C, it needs some way to establish that the replies it's supposedly = receiving from C are genuine. One popular model enabling you to do that = without employing transitive trust is end-to-end signing chained to a = trust anchor. With TLS as deployed on the web today, the trust anchors = are a set of mostly mutually agreed-upon CA certificates that serve as = roots for the certificates presented by every public web server. There = are of course issues with this model (q.v., certificate transparency, = Symantec), but its behavior is well-established and its properties are = understood. What is the equivalent here?

It sounds like the answer here is = mapping system-specific. E.g., from a quick perusal of the DDT draft, it = sounds very DNSSEC-like (which might suggest a course of action to = eliminate the need to develop, deploy, and maintain a custom security = protocol, but that is a different discussion).

Where an interface is described without = reference to a specific implementation, a set of assumptions (e.g., = "correct routing relies on the authenticity of mapping system = responses") and associated security requirements for any conforming = mapping system (e.g., "entities making use of mapping system responses = must have some way to authenticate them that does not rely on transitive = trust") need to be stated for the document to be a complete description = of a system component. That is, without first clearly defining the = required properties of any valid implementation of described interfaces, = there's no way to evaluate whether the component under review will do = what it's supposed to.

A good place to put these assumptions and requirements is in = the security considerations section: those statements are not normative = for the system component described by the draft in which they appear, = but are effectively requirements for whatever system component is to = implement that interface in a conforming way. Enumerating them as such = (in the document describing the interface in detail) allows the reader = to evaluate the requirements in light of the system using the interface, = while also providing a convenient checklist for those designing = conforming systems.

A set of well-crafted security considerations sections also = makes it much easier for a reviewer to understand the security of the = system as a whole without having to understand the details of every = implementation, and to verify that individual system components under = review will have the appropriate behavior.

I'm going to skip the = comments related to draft-farinacci-lisp-ecdsa-auth, just to limit scope = here. We can get back to it once that document has been adopted and more = fully fleshed-out.

> "TLS" = does not appear anywhere in the draft of LISP-SEC I reviewed:

Right as I explained DTLS does.

Check again. Just to be = sure, I've tried several tools and the letters "T", "L", and "S" do not = appear consecutively anywhere in this document. Neither do "SSL" nor = "transport-level security".
 
> I would like to see a discussion of whether and how the nature and = scale of this problem differs from that of the status quo. BGP sessions = and RIB push have properties that are well-established from decades of = experience: surely LISP does not have exactly the same properties. The = security considerations should make clear, for instance, how a loss of = control plane connectivity differs from the loss of a BGP session, and = how this impacts visibility and behavior of the data plane.
=
Please look at the deployment drafts. Please note, you are = reviewing a document that is focusing on encapsulating packets on an = overlay. All the other support pieces are broken out, in what the WG = felt was logical, in sepreate documents.

I think this gets back = to the point I made at the end of my original review, which is that this = system is difficult to evaluate from a security perspective in a = piecewise manner given the dependencies between the different layers and = the lack of explicitly-enumerated security requirements for each system = component implementing a given interface.

Kyle

= --Apple-Mail=_722DBC36-275B-4B0C-80DA-04799B4F7825-- From nobody Tue Sep 11 02:23:38 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5A1130E81 for ; Tue, 11 Sep 2018 02:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 mKbnrrMgfHuf for ; Tue, 11 Sep 2018 02:23:34 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 53B24130E2E for ; Tue, 11 Sep 2018 02:23:34 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id a108-v6so24939226wrc.13 for ; Tue, 11 Sep 2018 02:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=93HzuaueeSoEroLmpd0v46rYrZ1vJHw/gPa4pAazh2Y=; b=EX9uzM93mTBUmSwmXhX8OhAo7TrXkoSSd3TrcRUsnac44fUxTAVm084tYDcE7fPPAc GjykmgulDLNuLfMOzC5kOiUb5eIUaBkWr89FRZQkiWPfRkjePBIpI9TXdgkM2/R6EtHn kNu3zzwjmNGxYR7yyvB4pHE/hU8Xuvaw3XuJyH1qYiUNhQ289iNEsT91hU5jNLAEglqJ Rf//a98F2sxl6CDkf72I0c5RgwSPCc71GSFTm5pgVJwNkfC0Y/rPo1lMNGCFkFTsN6Pf kG66rS5I8mkzJZk50XIAa6tE930Q2grSJ4h92qkH56L23YYg/6aZxI/FD8OAGmH83usG kpNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=93HzuaueeSoEroLmpd0v46rYrZ1vJHw/gPa4pAazh2Y=; b=JjC4RDYGgt0Pb668ipnQ1/lrBOitPuEgQiTh3+KnJ4ER7c7VpAOLgVcZQtSh+l+AEY rHUHrhGhS7rv44xgaouBhzyoLdg2/2OFvk03QU+xn4jXXGglAntXUGf4Rx29EV9JP1ph w6FYS8gQpbKyBTdjuOSHNkFM7pcPPuGLJ5GMPi3Yv6woS58tuXTzA4C26PWXJAOFn/QG GYjxIUymSK8n3j20YxjiB1i7IpSfWnG2FVWfKmruwgTMhH1TDKRDGEnzQa0CNYgo4Vpu MqakuuZIPvKV6mSjBU8CIeVrtHgIMKXd4NS1lieSaG8aYnkTrzpT1yx3sTEt8zCJdpir L+HQ== X-Gm-Message-State: APzg51BX6cu+b9TmOTLOHCk/BzB1Oa8FA8/uQ96uTIqbeEFe04gC9Ty7 6v+ElU7v6fD8yV4Yamk2/JFccA== X-Google-Smtp-Source: ANB0VdbKJfe4OUEVNPcgozGFHhSPxJuITYaH61Sb4QJhnZaCIQ/AZzaDd06J4VTDolbR4trE2LLJbQ== X-Received: by 2002:adf:ba12:: with SMTP id o18-v6mr17720482wrg.249.1536657812738; Tue, 11 Sep 2018 02:23:32 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:b493:b5af:65cf:aebf? ([2001:660:330f:a4:b493:b5af:65cf:aebf]) by smtp.gmail.com with ESMTPSA id v46-v6sm19205388wrc.63.2018.09.11.02.23.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 02:23:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Luigi Iannone In-Reply-To: <56A10EEF-3CF5-4325-A7CB-337D4F22E106@gmail.com> Date: Tue, 11 Sep 2018 11:23:28 +0200 Cc: Jonathan Hardwick , "rtg-ads@ietf.org" , "draft-ietf-lisp-rfc6833bis.all@ietf.org" , "rtg-dir@ietf.org" , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <17D52CE3-C68D-4435-87D9-00730EE2E546@gigix.net> References: <56A10EEF-3CF5-4325-A7CB-337D4F22E106@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Routing directorate review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 09:23:36 -0000 Hi Dino, a quick point on the control message type 7. > On 7 Sep 2018, at 20:41, Dino Farinacci wrote: >=20 >> sec5.1: What about code point 7? Not assigned? Reserved? >=20 > It is assigned to a non-working group draft. NAT-traversal has not = gone through working group process so far. This point has been raised as well by Alvaro. My take is that officially type 7 is NOT assigned and the document = should state so. Eventually, NAT-traversal will be published and type 7 will be = officially assigned.=20 But until then, documents should mark it as unassigned. Ciao L. From nobody Tue Sep 11 06:50:20 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB8C130DF5 for ; Tue, 11 Sep 2018 06:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 uodYZJJ_6Bzk for ; Tue, 11 Sep 2018 06:50:17 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5035130DF2 for ; Tue, 11 Sep 2018 06:50:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A4BF5660131; Tue, 11 Sep 2018 06:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1536673815; bh=obQ0GcKV3oQxt1r+dEHbsmoC0tm8ZjUxnCWQg4GnrUk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ay1nhZ1FSpmH8lzaw9/ZcnfKb8vuhUaVigr64a4/F9pmoapsJfftoXegB5hnhH1ll /Y5WPcuSTHURlBg1UuS+0FLzklXHCEciAEqmy5UpSuhrrBw9xgE5bgjS8kweS35iS1 zhT8Q62jO84dHcOH33l8okF5kbCsJIoctC1n4vPw= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 E22C46600FA; Tue, 11 Sep 2018 06:50:14 -0700 (PDT) To: Dino Farinacci , Luigi Iannone Cc: db3546@att.com, "lisp@ietf.org" References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 11 Sep 2018 09:50:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 13:50:19 -0000 Any change to lisp-intro should be done by discussion with the RFC Editor, as it is in the RFC Editor queue (pending reference completion). If the working group considers it acceptable, we could easily ask them to change the references to 6830 and 6833 to the bis documents (after all, it is alreay blocked by documents which depend upon those.) Yours, Joel On 9/10/18 11:27 PM, Dino Farinacci wrote: > If you guys have source for the intro doc, I could point it to bis > documents? > > Dino > > > Begin forwarded message: > >> *Resent-From:* > >> *From:* Alvaro Retana > > >> *Date:* September 10, 2018 at 2:22:21 PM PDT >> *Resent-To:* farinacci@gmail.com , >> vince.fuller@gmail.com , dmm@1-4-5.net >> , darlewis@cisco.com >> , acabello@ac.upc.edu >> >> *To:* "The IESG" > >> *Cc:* draft-ietf-lisp-rfc6830bis@ietf.org >> , Luigi Iannone >> >, lisp-chairs@ietf.org >> , lisp@ietf.org >> *Subject:* *Alvaro Retana's No Objection on >> draft-ietf-lisp-rfc6830bis-16: (with COMMENT)* >> >> Alvaro Retana has entered the following ballot position for >> draft-ietf-lisp-rfc6830bis-16: No Objection >> >> 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 https://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: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for the work on this document! >> >> I have some relatively minor comments/nits: >> >> (1) §18: s/RFC8060/RFC8061 >> >> (2) §1: "Finally, [I-D.ietf-lisp-introduction] describes the LISP >> architecture."  First of all, it would seem to me that the >> Architecture should >> be a Normative reference...but I-D.ietf-lisp-introduction says that it >> "is used >> for introductory purposes, more details can be found in RFC6830, the >> protocol >> specification."  This document obsoletes rfc6830...so it seems to me >> that there >> is a failed circular dependency. >> >> (3) References to rfc2119/rfc8174 and rfc8126 should be Normative. >> >> From nobody Tue Sep 11 07:05:10 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0B6130DDB; Tue, 11 Sep 2018 07:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 X5YbtzYlsjfl; Tue, 11 Sep 2018 07:05:06 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 D015F12F1A2; Tue, 11 Sep 2018 07:05:05 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id l202-v6so47325820oig.7; Tue, 11 Sep 2018 07:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=JsqMBmMDQnFn4jwPYW0Xv33AX706UKK+7BOKCLNR81s=; b=rFoKaoxiJEY90H96+28F5s7+E7PFDO3zcPnn5XvSJb+cq74RjVYAQTXyXYhdmqhS29 wh+sMs15XOI/yzlBML2y8AK6SxzYaTa3vkP4Ko3rscJZ0Iy1d6gP6P/VeP1IMTCu38Lf m7JyZSybP8dsb5LoQXPlvE+fgKV0UXUgP+2MjYrL4+joVu5ttsRvjPxyRpvRClWQGAV5 DL9tOfdVVZg8JgdAPXeSLMreHFsdiFqJowlW2EJ6HfuTPcHbERaR2kvn+SpXakYBlsj1 i37ZfpSOt3P+ZMWVBEqcZ/bVMFPrLoXv1e9vQ19+7VERhCbfyTTYY2VbKe2kym1HzTGE kLYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=JsqMBmMDQnFn4jwPYW0Xv33AX706UKK+7BOKCLNR81s=; b=iphuQ3WNMFIObuhqKS8xfr2O1or4Tx2/i4mLir4RGZ9N5u7hptUGGeihIiJ57IdeZy GVgv2IQICLr2YX8PMw+edz2j9/z/wZGYRFZbgQ0TIHAtsAqERA2zlOJtxQ926M3K8LuK eWh7/kdRscgDeI1+e87LPpks0q3UU74MPKIOWvRBvxTigxU1sgWLZ0AyajGnhf+IGLLH xFky2Ly6ND460qFGLDrn63WN3/IO0BNSDdsujlwIELShQa7Ecf2eLANRQPGdn0EIyul4 8gzdj2U0gCdUzql20trHxHUeCwvhtoRP0q4brIw6I1S76nvNtsj9/4PzXLSsWHUX0bdS 4z/Q== X-Gm-Message-State: APzg51CQvg/pjPX7pgUYJInLL4G4N+0a3Cl3Duz7MsK2Ul14qmCzg7dO ZEPV2Dhj3/L/tzgQlBPkAd+Ozlofe8Ff9oON4FaYNQ== X-Google-Smtp-Source: ANB0VdZJ7Uur2TfgxFFLZsMLpuGMwNXDm2C5+/gJSuGEWftqSRZmr4lTvySxdIa4fOndfPmLeuO0szqgSqVNBsOsdaY= X-Received: by 2002:aca:a12:: with SMTP id 18-v6mr28052905oik.292.1536674704954; Tue, 11 Sep 2018 07:05:04 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 11 Sep 2018 10:05:03 -0400 From: Alvaro Retana In-Reply-To: <673793DD-2D70-4FE7-A94E-BE74B5496F20@gigix.net> References: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> <673793DD-2D70-4FE7-A94E-BE74B5496F20@gigix.net> X-Mailer: Airmail (506) MIME-Version: 1.0 Date: Tue, 11 Sep 2018 10:05:03 -0400 Message-ID: To: Luigi Iannone Cc: draft-ietf-lisp-rfc6833bis@ietf.org, The IESG , lisp@ietf.org, lisp-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000ec993a057598f53b" Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 14:05:09 -0000 --000000000000ec993a057598f53b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On September 11, 2018 at 5:15:38 AM, Luigi Iannone (ggx@gigix.net) wrote: Luigi: Hi! Some comments below. Thanks! Alvaro. Hi Alvaro, thanks for your feedback. See my comments inline and let us know what you think. On 10 Sep 2018, at 23:43, Alvaro Retana wrote: Alvaro Retana has entered the following ballot position for draft-ietf-lisp-rfc6833bis-13: No Objection 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There are several issues in =C2=A75.1 (LISP Control Packet Type Allocations= ) that need to be fixed. I don't think any of them raise up to a DISCUSS, but I would like to see them resolved before publication. =C2=A75.1 "defines the LISP control message formats and summarizes for IANA= the LISP Type codes assigned by this document". (1) Instructions (or anything directed) to IANA should be in the IANA Considerations section. There isn't even a pointer to this section later o= n for IANA to look at it. This can be easily fixed changing the first sentence to: This section defines the LISP control message formats and summarizes for IANA the LISP Type codes assigned by this document (see details IANA considerations in Section 11). What do you think? The main point is that is you want IANA to look at this text, then the best way is to put it in the IANA Considerations section. They may be ok with a pointer the other way around: from Section 11 to this section (otherwise they might not notice). (2) The text seems to imply ("Message type definitions are") that the types are defined here (or at least in rfc6833, which this document Obsoletes), but they are defined in rfc6830, rfc8111 and rfc8113. Please properly identify the source (only the rfc8113 line has a reference). Would it be sufficient to add a sentence listing the messages that this documents re-defines and the original RFC which is obsoleted? I just want the text to be clear about what is defined here and what isn=E2=80=99t. I think that references (like the one in there for rfc8113)= would be enough. (3) Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting rfc6830, I think that, because of how the contents of that RFC were distributed, this document should also be tagged as Obsoleting rfc6830. Meaning that 6833bis obsoletes both 6830 and 6833? Yes. (4) The LISP Packet Types registry was set up in rfc8113. This document asks that IANA "refers to this document as well as [RFC8113] as references" (=C2=A711.2), and it seems to try to change the registration (or the text is incomplete) in (=C2=A75.1): "Values in the "Not Assigned" range can be assigned according = to procedures in [RFC8126]." Which procedure? s/Not Assigned/Unassigned (=C2= =A76 in rfc8126) I think that there is some missing text, and that most proper sentence would be: Note that according to [RFC8113] the LISP Packet Type values 7 and 9 to 14 can be assigned via Standards Action [RFC5226 ]. (5) Because of the point above, this draft should (at least) Update rfc8113 (see also below). (6) This document says that "Protocol designers experimenting with new message formats SHOULD use the LISP Shared Extension Message Type". I think this statement makes rfc8113 a Normative reference -- which results in a DownRef. Suggestion: given that this document already updates the registry set up in rfc8113, and recommends the use of the Shared Extension Message, it may be = a good idea to simply adopt the contents of that document here (grand total of 6 pages) and declare it Obsolete. Or just make a 8113bis standard track. The RFC Editor will hold the document until an RFC number is assigned to all normative references. Having said that, I wonder if we really need that =E2=80=9CSHOULD=E2=80=9D. If I experiment with new messages and I make sure that nothing goes beyond my own deployment, why being constrained? And what if (still isolating my experiment) for any reason I would like to play with the reserved bits of existing messages? How do I do it? In general because you want to avoid squatting on code points, leaking, etc.. We=E2=80=99ve seen cases in other WGs where experiments later became mainstream and changing code points was then a huge pain. In any case, I=E2=80=99m fine with the sentence below. Thanks!! Alvaro. I would change the sentence in: The LISP Shared Extension Message is for experimentation purposes as described in [RFC8113 ]. (7) Type 7 is missing. It is not assigned, and yes=E2=80=A6 should be stated (see above). Ciao L. --000000000000ec993a057598f53b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On September 11, 2018 at 5:15:38 AM, Luigi Iannon= e (ggx@gigix.net) wrote:

Luigi:

Hi!

Some comments below.=C2=A0 Thanks!

Alvaro.

Hi Alvaro,

thanks for = your feedback.

Se= e my comments inline and let us know what you think.
On 10 Sep = 2018, at 23:43, Alvaro Retana <aretana.ietf@gmail.com> wrote:

Alvaro Retana has entered the following= ballot position for
draft-ietf-lisp-rfc6833bis-13: No Object= ion

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


Please refer to=C2=A0https://www.ietf.org/i= esg/statement/discuss-criteria.html
for more information = about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found he= re:
https://datatracker.ietf.org/doc/draft-ietf-lisp= -rfc6833bis/



----------------------------------------------------------------------
COMMENT:
-----------------------------------------= -----------------------------

There are severa= l issues in =C2=A75.1 (LISP Control Packet Type Allocations) that
need to be fixed.=C2=A0 I don't think any of them raise up to a D= ISCUSS, but I would
like to see them resolved before publicat= ion.

=C2=A75.1 "defines the LISP control = message formats and summarizes for IANA the LISP
Type codes a= ssigned by this document".

(1) Instructio= ns (or anything directed) to IANA should be in the IANA
Consi= derations section.=C2=A0 There isn't even a pointer to this section lat= er on
for IANA to look at it.

This can be easily fixed changing the firs= t sentence to:

 This section defines=
 the LISP control message formats and summarizes
           for IANA the LISP Type cod=
es assigned by this document (see details IANA considerations in Section 11=
).

What do you think?<= /div>

The main point is= that is you want IANA to look at this text, then the best way is to put it= in the IANA Considerations section.=C2=A0 They may be ok with a pointer th= e other way around: from Section 11 to this section (otherwise they might n= ot notice).

=




(2) The text seem= s to imply ("Message type definitions are") that the types aredefined here (or at least in rfc6833, which this document Obsol= etes), but they
are defined in rfc6830, rfc8111 and rfc8113.= =C2=A0 Please properly identify the
source (only the rfc8113 = line has a reference).


Would it be sufficient to add a sentence listing the m= essages that this documents re-defines and the original RFC which is obsole= ted?

I just want = the text to be clear about what is defined here and what isn=E2=80=99t.=C2= =A0 I think that references (like the one in there for rfc8113) would be en= ough.

<= br class=3D"Apple-interchange-newline">

=
(3) Even though draft-ietf-lisp-rfc683= 0bis is tagged as Obsoleting rfc6830, I
think that, because o= f how the contents of that RFC were distributed, this
documen= t should also be tagged as Obsoleting rfc6830.
<= div>
Meaning that 6833bis obsoletes both 6830 and = 6833?

Yes.





(4) The LISP Packet Types registry = was set up in rfc8113.=C2=A0 This document asks
that IANA &qu= ot;refers to this document as well as [RFC8113] as references" (=C2=A7= 11.2),
and it seems to try to change the registration (or the= text is incomplete) in
(=C2=A75.1): "Values in the &quo= t;Not Assigned" range can be assigned according to
proce= dures in [RFC8126]." =C2=A0Which procedure? =C2=A0s/Not Assigned/Unass= igned (=C2=A76 in
rfc8126)
I think that there is some missing =C2=A0text, and = that most proper sentence would be:

Note that according to [RFC8113] the LISP Packet Type values 7 and 9 to= 14 can be assigned via Standards Action [RFC5226].



(5) Because of the point above, thi= s draft should (at least) Update rfc8113
(see also below).
(6) This document says that "Protocol designers experimenting with n= ew message
formats SHOULD use the LISP Shared Extension Messa= ge Type".=C2=A0 I think this
statement makes rfc8113 a N= ormative reference -- which results in a DownRef.=C2=A0
Sugge= stion: given that this document already updates the registry set up in
rfc8113, and recommends the use of the Shared Extension Message, = it may be a
good idea to simply adopt the contents of that do= cument here (grand total of 6
pages) and declare it Obsolete.=


O= r just make a 8113bis standard track. The RFC Editor will hold the document= until an RFC number is assigned to all normative references.

Having said that, I wonder if we really need th= at =E2=80=9CSHOULD=E2=80=9D.=C2=A0
If I experiment with new messa= ges and I make sure that nothing goes beyond my own deployment, why being c= onstrained?
And what if (still isolating my experiment) for any r= eason I would like to play with the reserved bits of existing messages? How= do I do it?
<= p>In general because you want to avoid squatting on code points, leaking, e= tc..=C2=A0 We=E2=80=99ve seen cases in other WGs where experiments later be= came mainstream and changing code points was then a huge pain.

In any= case, I=E2=80=99m fine with the sentence below.


Thanks!!<= /p>

Alvaro.

<= div class=3D"" style=3D"word-wrap:break-word">

I would change the sentence = in:
=C2=A0
 The LISP Shared Extension Message is for=
 experimentation purposes as described in [RFC8113].



(7) Type 7 is missing.
It is not assigned, and yes=E2=80=A6 should be stat= ed (see above).

Ciao

L.











--000000000000ec993a057598f53b-- From nobody Tue Sep 11 07:39:30 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D86130E03; Tue, 11 Sep 2018 07:39:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Z2KSevK7MFVo; Tue, 11 Sep 2018 07:39:12 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 1076D1292AD; Tue, 11 Sep 2018 07:39:12 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id j26-v6so12331543pfi.10; Tue, 11 Sep 2018 07:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WkzNRsx0/FK7UpHpJv+T0YDaMsD977hbTXDqabCm3ds=; b=uXQVIMFnXPionbmzcDvHCel4ilvDCvezREqvzmMDJ5ZQErxXpzEPICX2L7qP8Er3e2 3RltKHAjN6ko+PafKOiZmFPXYlqiBNPYzuFbmWl/D5TnQKOoz8/p+kr1KhZiMDogBo7V 4+k4EPDmDBBuryypOVKw9VMdhax27CE3ZbcSQr7aJnTzqfwlvgdQMYeFC9Y8evTrlTOg WJagMKH6WSwNuIsPWXNV7uQbLmEaOfD8pMWcJUrJ4snMztpnj+lw9TXxoVa9N5b0eU2E 6GFL1Jl6ZD0yBxPe9B+UxwRzhQuWxzZmG6DCd0DtlSQF0qH4pa0HEQlLPQQJ+5ZrKA8n vaWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WkzNRsx0/FK7UpHpJv+T0YDaMsD977hbTXDqabCm3ds=; b=uHwMkxr6KLNX7xXMpSpzeTyGsyvm02yROyR9JJui9tghfHi2RpRbGvvclXBy3Zkj/F /U/GliCbSnEJnRXCxPHn1n2esMzIW7tXjYEiHpx7IVItwDuLUA6Puc9jxPiLYWAjtSXe OKdnUGSAX9lnI6CdVPRSJRqODpEk6Iclg7Yj0GBwAOXZbfD5hE2g78BpYsuqSRC32Z0D gsN35/aNTwf5vieMTO0PlaahfkStWX1cO/p1lxD7kv/l0NUzUAsz9zAL/0ncE2j59Igq bTfmF1elza6qGzQqQPOQ9g9eSXv/YEnSt1cCRKA7Xd4Hp0nDIqGvd1cHSm3cvGRITJgR fqSQ== X-Gm-Message-State: APzg51CZt91UjXqvBAgn9ObzQsPPBglWEBZGqEsgwfcPyO+U6OdjAuo9 6j7pb7a8Cv+VOltTIf3+40vBLPr1 X-Google-Smtp-Source: ANB0VdY8YaPnTarRio2Alj40ZYat24uP+I6atGTuj62VNvZBeWHfa0NrOE1uVmRTnGLSGRP8y0Fjsg== X-Received: by 2002:a63:931b:: with SMTP id b27-v6mr5160987pge.143.1536676751598; Tue, 11 Sep 2018 07:39:11 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id f87-v6sm50932489pfh.168.2018.09.11.07.39.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 07:39:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <17D52CE3-C68D-4435-87D9-00730EE2E546@gigix.net> Date: Tue, 11 Sep 2018 07:39:09 -0700 Cc: Jonathan Hardwick , "rtg-ads@ietf.org" , "draft-ietf-lisp-rfc6833bis.all@ietf.org" , "rtg-dir@ietf.org" , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4F8143BE-291E-4F63-8603-5FE36615DFF5@gmail.com> References: <56A10EEF-3CF5-4325-A7CB-337D4F22E106@gmail.com> <17D52CE3-C68D-4435-87D9-00730EE2E546@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Routing directorate review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 14:39:14 -0000 I will update the spec to say type 7 is not assigned. Dino > On Sep 11, 2018, at 2:23 AM, Luigi Iannone wrote: >=20 > Hi Dino, >=20 > a quick point on the control message type 7. >=20 >> On 7 Sep 2018, at 20:41, Dino Farinacci wrote: >>=20 >>> sec5.1: What about code point 7? Not assigned? Reserved? >>=20 >> It is assigned to a non-working group draft. NAT-traversal has not = gone through working group process so far. >=20 > This point has been raised as well by Alvaro. >=20 > My take is that officially type 7 is NOT assigned and the document = should state so. > Eventually, NAT-traversal will be published and type 7 will be = officially assigned.=20 > But until then, documents should mark it as unassigned. >=20 > Ciao >=20 > L. >=20 From nobody Tue Sep 11 07:39:37 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A31130E01 for ; Tue, 11 Sep 2018 07:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 n_P9GsLO9uAM for ; Tue, 11 Sep 2018 07:39:33 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 ABD98130E84 for ; Tue, 11 Sep 2018 07:39:30 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id f21-v6so1267022wmc.5 for ; Tue, 11 Sep 2018 07:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vmHy4Q04gogQ0Z41oVTFZAm6wNWlHsFuYIsCMM4wNfk=; b=wuJ4AXzV2M/4gAFNMu9u8da19pg6WiQGDRDH6DZ4+2KYmVPR1UsNMv1hQ4F+UnaZFV aJGn2bjIr4u3iWPwceRjx/xkzZhO5bk30Jt1cMuBnoNNKmaOpAuw451yoqbTRwQNR9is 6uzuu1LUp5wnz6FYAlBs6bi8eda34fSnnrupbQ5k8jE9ctmHZK0xGJHDjggCMWHGjoyj rKV391pJi3xAPia6hztSicq/DfhdjwkboqunKBVDMqjsLexAoYeyBH1tgH0GjsyJcYyH C0m9FrxhWPbUSa9hR9WmLtIvv0P4M0ugqC+6Bz2ZS1DPBE8+laWMx+JueihY+depdqVz A6bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vmHy4Q04gogQ0Z41oVTFZAm6wNWlHsFuYIsCMM4wNfk=; b=f+qZPAPklFHtyLuvBfcboKGYx7EHD95LTC10W9levmc0xJv5yYHCX5l5qTng4MFO2Y Puoq0jpy65djv0onupZYIUyGhFoLn7H5scWTaZCjbhcK/nv3aS2G0NoRSCzKNggB6WSw NCy2C4WqIlPPdUCCww4wFPCd7tIE2cfQdmy9vUvlQwSnVmrx+UOAuc8yhhTCht8inROf ba32EhR0YdWjpNCprTkSV8uctmMclifkvh3xc7fRD5B1ReZRVm/WS9ivoCTgKSJC4ILJ 9pDU7iDxuJ5OGnP0al5x3n58EHRFfcPXRVZQT+FksXalQFFNvriG0Yqq3jHCgZOr3G/j XtSw== X-Gm-Message-State: APzg51AONjeG+KBhu5joyaqVoYDhWJEsXQeutW1e5zx/0BU7ZXGBcIfn YwfEfUHtDOtLUdX5cM90Py/ZCw== X-Google-Smtp-Source: ANB0VdYpuZjbT2dI2+QibRR/CjkHTk8TzjjlNlD6pJNNFFVN+G8p18oTNtpgGMQtgK0s8KzQlSeb+Q== X-Received: by 2002:a1c:3351:: with SMTP id z78-v6mr1648702wmz.23.1536676768848; Tue, 11 Sep 2018 07:39:28 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:b493:b5af:65cf:aebf? ([2001:660:330f:a4:b493:b5af:65cf:aebf]) by smtp.gmail.com with ESMTPSA id l12-v6sm22327470wrv.29.2018.09.11.07.39.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 07:39:27 -0700 (PDT) From: Luigi Iannone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B95A8066-3931-40E2-8FBF-C5E5F1640534" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 11 Sep 2018 16:39:23 +0200 In-Reply-To: Cc: draft-ietf-lisp-rfc6833bis@ietf.org, The IESG , lisp@ietf.org, lisp-chairs@ietf.org To: Alvaro Retana References: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> <673793DD-2D70-4FE7-A94E-BE74B5496F20@gigix.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 14:39:36 -0000 --Apple-Mail=_B95A8066-3931-40E2-8FBF-C5E5F1640534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alvaro, thanks for the reply. I think everything is clear. I need just one = clarification: > On 11 Sep 2018, at 16:05, Alvaro Retana = wrote: >=20 > On September 11, 2018 at 5:15:38 AM, Luigi Iannone (ggx@gigix.net = ) wrote: >>>=20 >>> There are several issues in =C2=A75.1 (LISP Control Packet Type = Allocations) that >>> need to be fixed. I don't think any of them raise up to a DISCUSS, = but I would >>> like to see them resolved before publication. >>>=20 >>> =C2=A75.1 "defines the LISP control message formats and summarizes = for IANA the LISP >>> Type codes assigned by this document". >>>=20 >>> (1) Instructions (or anything directed) to IANA should be in the = IANA >>> Considerations section. There isn't even a pointer to this section = later on >>> for IANA to look at it. >>=20 >> This can be easily fixed changing the first sentence to: >>=20 >> This section defines the LISP control message formats and summarizes >> for IANA the LISP Type codes assigned by this document = (see details IANA considerations in Section 11). >>=20 >> What do you think? >=20 > The main point is that is you want IANA to look at this text, then the = best way is to put it in the IANA Considerations section. They may be = ok with a pointer the other way around: from Section 11 to this section = (otherwise they might not notice). >=20 >>=20 >>=20 >>=20 >>>=20 >>> (2) The text seems to imply ("Message type definitions are") that = the types are >>> defined here (or at least in rfc6833, which this document = Obsoletes), but they >>> are defined in rfc6830, rfc8111 and rfc8113. Please properly = identify the >>> source (only the rfc8113 line has a reference). >>>=20 >>=20 >> Would it be sufficient to add a sentence listing the messages that = this documents re-defines and the original RFC which is obsoleted? >=20 > I just want the text to be clear about what is defined here and what = isn=E2=80=99t. I think that references (like the one in there for = rfc8113) would be enough. >=20 >>=20 I think I=E2=80=99ve got now you point. What we should do is not modify = section 5.1, is modifying section 11.2. We should update the text and following table: Name Number Defined in ---- ------ ----------- LISP Map-Notify-Ack 5 RFC6833bis We should add there all the code points of messages that are re-defined = in this document and ask IANA to update the registry so that the entries = point to this document (and not anymore 6830). Did I got it right? Ciao L. =20 --Apple-Mail=_B95A8066-3931-40E2-8FBF-C5E5F1640534 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Alvaro,

thanks for = the reply. I think everything is clear. I need just one = clarification:

On 11 Sep 2018, at 16:05, Alvaro Retana = <aretana.ietf@gmail.com> wrote:

On September 11, 2018 at = 5:15:38 AM, Luigi Iannone (ggx@gigix.net) wrote:

There are several issues in =C2=A75.1 (LISP Control Packet = Type Allocations) that
need to be fixed.  I don't = think any of them raise up to a DISCUSS, but I would
like = to see them resolved before publication.

=C2=A75.1 "defines the LISP control message formats and = summarizes for IANA the LISP
Type codes assigned by this = document".

(1) Instructions (or anything = directed) to IANA should be in the IANA
Considerations = section.  There isn't even a pointer to this section later on
for IANA to look at it.

This can be easily fixed = changing the first sentence to:

 =
This section defines the LISP control message formats and =
summarizes
           for IANA the LISP Type =
codes assigned by this document (see details IANA considerations in =
Section 11).

What do you = think?

The main point is that is you want IANA to look at = this text, then the best way is to put it in the IANA Considerations = section.  They may be ok with a pointer the other way around: from = Section 11 to this section (otherwise they might not notice).





(2) The = text seems to imply ("Message type definitions are") that the types = are
defined here (or at least in rfc6833, which this = document Obsoletes), but they
are defined in rfc6830, = rfc8111 and rfc8113.  Please properly identify the
source (only the rfc8113 line has a reference).


Would it be sufficient to add a = sentence listing the messages that this documents re-defines and the = original RFC which is = obsoleted?

I just want the text to be clear about what is defined here = and what isn=E2=80=99t.  I think that references (like the one in = there for rfc8113) would be enough.


<= /blockquote>

I think I=E2=80=99ve got now you point. What we = should do is not modify section 5.1, is modifying section = 11.2.
We should update the text and following = table:
	=
Name                 Number          Defined in
        ----                 ------          -----------
        LISP Map-Notify-Ack  5               RFC6833bis


We should add there all the code points of = messages that are re-defined in this document and ask IANA to update the = registry so that the entries point to this document (and not anymore = 6830).

Did I got it = right?

Ciao

L.


  



= --Apple-Mail=_B95A8066-3931-40E2-8FBF-C5E5F1640534-- From nobody Tue Sep 11 08:02:10 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A071130E7F; Tue, 11 Sep 2018 08:02:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2018 08:02:08 -0700 Archived-At: Subject: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 11 Sep 2018 15:02:08 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-lisp-rfc6833bis-13: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1) Versioning and backward compatibility Section 5.2 says: "Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol." However, there is no versioning mechanism for this protocol specified. How is versioning supposed to work? Further given there is no new version, I wonder if the changes as outlined in section 10 are all backward-compatible? Especially for the introduction of the Message-Notify-Ack message, I guess there is no problem if a server sends it, however, as the sender of the Message-Notify message might not know if the other end supports sending of the Message-Notify-Ack it can't rely on it. This should be further discussed in the doc! Or is there another strategy to achieve backward compatibility? 2) Size and MTU As outlined in the TSV-ART review (Thanks Colin!) this document does not discuss fragmentation or Path MTU discovery. RFC8085 recommends to either perform Path MTU discovery or limit the message to 576 bytes for IPv4 or 1280 bytes for IPv6 (minus any static header). As this seems to be an appropriate size for LISP messages, I would recommend this approach. Relying on IP fragmentation (as indicated in the reply to the TSV-ART review) is not recommended by RFC8085 as this would lead to IP packet without a UDP header, in the case of LISP, which can cause problem and loss when NATs are involved. In any case the chosen approach needs to be further discussed in the doc. 3) Rate-limiting and congestion control Sec 5.3: "Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- Request for the same EID-Prefix be sent no more than once per second." As already noted by the TSV-ART review (Thanks Colin!), RFC8085 actually recommends to not send more the one packet per 3 seconds, and that is a restriction for all traffic not on a per-receiver base, or implement congestion control. This limit is meant to not only protect the receiver but also the network from overloading. Why do you use a smaller interval here? Also if (appropriate) rate limiting is used, this should either be a MUST or more explanation when it is okay to use a smaller rate limit should be provided. However, after all, I don't think you those the right approach here for rate limiting. A Map-Request is always expected to be followed by some reply. For these kind of communication pattern, RFC8085 recommends to limit the number of outstanding requests to 1 (see sec 3.1.1 of RFC8085 recommending one packet per RTT), also for all traffic and not only per receiver. However, this would also require to implement some simple mechanism to detect a message as lost (see also further below in point 4). Similarly I'm not sure about the intent of this requirement in section 5.5: "Map-Replies SHOULD be sent for an EID-Prefix no more often than once per second to the same requesting router. " My understanding is that Replies are only sent when a request is received. Why is this additional rate limit needed? Again if used it should be 3 seconds for all traffic to be inline with RFC8085. Also again, why is that not a MUST? Further recommendation are needed here. Further section 6.1 say "Both the SMR sender and the Map-Request responder MUST rate-limit these messages. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination." This seems to be the same rate limit as mention above, or not...? It would probably make sense to rate limit the SMR even further. Please clarify and provide more guidance, e.g. what should the value of a potential additional rate limit for SMR be? Respectively the following sentence in section 6.1 is also unclear: "The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply" Why is the rate-limit as currently proposed depend on the fact if a Map-Reply is received? Is the ITR supposed to retransmit the Map-Request...? And finally the Map-Register, Map-Notify and Map-Notify-Ack messages does not seem to have any rate-limits. Recommendations inline with RFC8085 should be provided for the total traffic and not only for a few message types. Again, Map-Notify and Map-Notify-Ack messages should be send only once per RTT as there is a feedback mechanism. For Map-Register sec 8.2 say: "Map-Register messages are sent periodically from an ETR to a Map- Server with a suggested interval between messages of one minute." However, this a rather a low bound than an upper bound. A required (MUST) rate limit is still needed. 4) Loss detection and retransmission As also mention by the TSV-ART review (Once more thanks to Colin!), this spec has an ACK mechanism for Map-Requests and now also for Map-Notify, however, it does not specify what to do if the ACK is not received (loss detection and retransmission scheduling). This makes the spec incomplete and needs to be further specified in the doc (and also has a relation to the point 3 above of course). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Further comments: 1) The example given in 5.5 should probably used IPv6 addresses and use the IP address space that is reserved for documentation purposes. 2) I find the security requirements in this doc very unsatisfying. Most important the doc requires the support of authentication mechanism but not the use of it. I would like to see more clear MUST requirements here. Further, today and at this stage of the protocol (moving from exp to PS) I find it not acceptable anymore to have certain security feature as optional and outsourced into a different work-in-process draft. However, I leave further discussion to the SEC ADs. 3) Given the following statement: "Note that while this document assumes a LISP-ALT database mapping infrastructure to illustrate certain aspects of Map-Server and Map- Resolver operation..." it seems that RFC6836 should be a normative reference, as it might not be possible to understand all details explained in this doc with knowing ALT. 4) Further I would also think that I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub should be normative references as the meaning of the respective bits it not further specified in this doc. Or can these bits just be ignored if I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so that should be stated. Clarification questions: 1) Sec 5.3.: "For the initial case, the destination IP address used for the Map-Request is the data packet's destination address (i.e., the destination EID) that had a mapping cache lookup failure." Does that mean that the Map-Request needs to use the IPv4 or IPv6 depending on the IP version used by the initial message from the EID. Is that always the case or just for this initial message? I would assume that for all other cases this is actually independent...? Because otherwise there would be a constraint on what needs to be requested. I would like t see further clarification about this in the doc. 2) In section 5.3: "The ITR MAY include all locally configured Locators in this list or just provide one locator address from each address family it supports." Would it make sense to include a SHOULD requirement to at least the address family that is used to send the Request is included (to increase chance to enable a communication/get a reply)...? 3) Sec 5.4: "If all Weights for a Locator-Set are equal, the receiver of the Map-Reply will decide how to load-split the traffic. " Shouldn't the receiver in this case split the traffic equally? Otherwise how would you signal that the traffic should be split equally? Maybe use all zero instead to let the receiver decide...? 4) sec 6.1: "When an ITR receives an SMR-based Map-Request for which it does not have a cached mapping for the EID in the SMR message, it may not send an SMR-invoked Map-Request." I guess this should be normative and probably also a MUST NOT or at least SHOULD NOT. 5) Section 7 seems to imply that if it is detected that no route is available, the ITR should basically do nothing and just drop any incoming packets for that ETR. Would it make sense for incremental deployability, to just forward the packet to the IP address of the EID instead...? This way the source host would not benefit in mobility cases but still gets connectivity otherwise. Or is that anyway not the implication? If that is the case, that should be further clarified in the doc. 6) Section 8.2 says: "Note that the Map-Notify message is sent to UDP destination port 4342, not to the source port specified in the original Map-Register message." Actually why is that? Some minor editorial comments: 1) First sentence in intro: the pointer to ietf-lisp-introduction as currently introduced, makes this reference look very normative: "The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and [I-D.ietf-lisp-rfc6830bis] specifies..." I would recommend the following wording: "The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see also [I-D.ietf-lisp-introduction]) specifies..." 2) Also in intro: Given that 6830bis is a normative reference "LISP RFC 6830bis" should be replaced with the new RFC number in the text. This should be noted to the RFC editor; probably this is more obvious if RFCXXX is used instead. 3) Sec 5.4: "...for another way the R-bit MAY be used." This looks like a lower case may would be more appropriate. From nobody Tue Sep 11 08:17:51 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 413F3130E9E; Tue, 11 Sep 2018 08:17:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2018 08:17:36 -0700 Archived-At: Subject: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 11 Sep 2018 15:17:36 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-lisp-rfc6830bis-16: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a couple of smaller discuss points with should be straight-forward to address and one more high-level discussion point that might not have a solution (depending on the deployment status of LISP I guess) but I would like to at least have a discussion. I start with the straight-forward onces: 1) Unfortunately ECN decapsulation is slightly more complicated than described in section 5.3. Please check section 3.2 in rfc6040 and revise accordingly (maybe also provide a pointer to rfc6040 instead or in addition to rfc3168)! (Also it seems like the text on ECN is simply just twice in sec 5.3; not sure that is helpful). 2) Further, also in sec 5.3: "The inner-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header DSCP field ('Traffic Class' field, in the case of IPv6) considering the exception listed below." However, I didn't find any exceptions listed later in the doc. However, setting the DSCP field might also be matter of local policy. E.g. if DSCP is not used for a different purpose in the receiver side LISP network, it could make sense to restore/keep the original value in the inner header. 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while "IPv4-encapsulated packet with the DF bit set to 1" should be addressed as well. 4) I would like to see another sentence in section 12 explicitly stating that the source port SHOULD be the same for all packet belong to the same flow. 5) Sec 5.3 says "Both N- and V-bits MUST NOT be set in the same packet." What happens if both bits are set? The 'Nonce/Map-Version' is just ignored, or maybe the packet should be dropped or something? Please clarify in the doc! 6) And now the more-discussion-needed point: So my underlying concern is the same as brought up by the TSV-ART review that lisp information are not end-to-end integrity protected or authenticated. However, while briefly thinking about how this could be eventually realized, I noticed that there is actually no mechanism to extend the LISP header in any way. There is no version, no option and the LISP header seems to have a fixed, implicitly specified length without an explicit length field. This seems too late to add any kind of extensibility mechanism at this stage of the protocols lifetime, however, I would still like to discuss if there was any discussion about extensibility, what was the reason to chose this approach, and potential if some background about the choice should be given in the doc. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) In sec 7.1 I would recommend to provide a pointer to RFC4459 and align the language to more what RFC4459 recommends: OLD "This behavior is performed by the ITR when the source host originates a packet with the 'DF' field of the IP header set to 0." MAYBE: "This behavior MAY be performed by the ITR only when the source host originates a packet with the 'DF' field of the IP header set to 0. 2) Sec 4: "...this document recommends that a maximum of two LISP headers can be prepended to a packet." MAYBE: "it is RECOMMENDED that a maximum of two LISP headers can be prepended to a packet." ? From nobody Tue Sep 11 08:19:33 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5250A130E9D; Tue, 11 Sep 2018 08:19:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 T2Y-NnPgnQ6T; Tue, 11 Sep 2018 08:19:22 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 0F5F0130E9C; Tue, 11 Sep 2018 08:19:22 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id w14-v6so11476047plp.6; Tue, 11 Sep 2018 08:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MzILQYkHL0MsqVjleYEq32dcebkWpQEFsW6g+QRVOrA=; b=QXmi70Uvk0EGemqR/i4b3xYAyKMCgnxg/5iCOvCB3uDkbRYXZWHdwM71kbLltuv87y LE5L8LOd5M23BBYrDBIPJrmQlOUycuusU0huxSsn7vjFFvUPFGC3ZiqUcplSJcjF0BOi G/3EczjXWnzeHrqUfZdaxdI0MqMe1K2ub7Il/PhcU6nEtlTM+xdpL8ZSTZ9XqMBJR1o9 Q0V+Y0L9qGaIpdektviAvA/ea22FByrMfZqj/ph8lXir7WiWU2AhtCbJtA8OpvJEqvB5 NEwSkNjCo1xrCjLzeBNa3xnCE3uoe2qzH+DL4bycB7NVKjYzmx653Wzpzty6Uk1yieY+ wWow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MzILQYkHL0MsqVjleYEq32dcebkWpQEFsW6g+QRVOrA=; b=cqfoI3mWlghlAnmHmfI0RcnJsl16V6oFwBiTVIeSI//slt2BfCw0tKWz8aNqKsa5jc TNqN4gPQUz9qQbAweEdvGwgJVepbixqYF98iaXI3No0HxfjJWfsTsv8ARTe62Cwu7n3z sfm3FML0Kx6m6pueHAVoM2hLPNZgADKVHLq6IvgBd/KD0cD+rWvKn2EviS2SgoCkBpcX uJxW9gQ0JLZnTiwnwG09SG7Vg5LOQdv1uSEXv1GGAQEJHEvLGZ9kerxi52GKOSHbCAxd 8A/Q9+cK9eqopheXqtOAxUdjQJcPOVvn7zT9z/Br0j7H5YB8CutX3nSCjRyYW7YEbcb7 GwcQ== X-Gm-Message-State: APzg51Cc6Zd7lpBWVoe5Kx+iNBG/QmsGYvn3/f64wKa7ZoouFYsOhEER 7katPbZxUHvxAyC848FI59A= X-Google-Smtp-Source: ANB0VdZwnUKn4Myz5mY3ejqiZX/jhC1Sobs2RcVIwRKbFlilSi2wz+D7DJTiFY0P4tU3EZXjAFypSQ== X-Received: by 2002:a17:902:8308:: with SMTP id bd8-v6mr27674791plb.134.1536679161596; Tue, 11 Sep 2018 08:19:21 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id y7-v6sm28378394pge.8.2018.09.11.08.19.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 08:19:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2018 08:19:19 -0700 Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> To: Alvaro Retana X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 15:19:24 -0000 > (1) =C2=A718: s/RFC8060/RFC8061 Fixed. > (2) =C2=A71: "Finally, [I-D.ietf-lisp-introduction] describes the LISP > architecture." First of all, it would seem to me that the = Architecture should > be a Normative reference...but I-D.ietf-lisp-introduction says that it = "is used > for introductory purposes, more details can be found in RFC6830, the = protocol > specification." This document obsoletes rfc6830...so it seems to me = that there > is a failed circular dependency. Deborah and the lisp-chairs are replying to this. > (3) References to rfc2119/rfc8174 and rfc8126 should be Normative. Ack. Dino From nobody Tue Sep 11 08:30:06 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF4E130EA4; Tue, 11 Sep 2018 08:29:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 svvOyvUcLcj8; Tue, 11 Sep 2018 08:29:56 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 1D686130EA1; Tue, 11 Sep 2018 08:29:56 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id g2-v6so10542824plo.2; Tue, 11 Sep 2018 08:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jF+8TQINnxPKjifCU3kT3vw3vissMNt7qkMzv0fUuFA=; b=b2lGTiX4u3yD62pZXqOzcZjeeIn2ZvCeenvaPjqdAg+ovHZqeJd5FpehdKvTO1zxzG toquadjCLSZ77xdZSuLf1gU7RD0IAYUB6v+cs7MveMBT2lEuZmvziDmigK4SR4GCUcIj pFl7RP3u0uAKpUP10GL9uFwFPEF8zTw44gMXoaV+8EtLBJYbDBwTaTItdbB0rDkH6jnd gYDFHAQ1vy5OlUgRu5vaaVEnTp1Y+wKnRYLd7Js/xK1WBiTW2iFwCjAn4D05+FxHhWc3 XmFK530Jno2WWl6dcboc1eqcr6+NwKCsUKIBkHv46soXw12en0kLPU5G5B8yhQ4w/8rl tJ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jF+8TQINnxPKjifCU3kT3vw3vissMNt7qkMzv0fUuFA=; b=duzOobK/TT7A1lqmCyWrhKG3c0IIryY4pIZi+7Ya6Mnau8kXDg2GAM4H/he8tvhhXc TGEbj6d5q1Z0SPX52ECvEJjLZLSw7Loln7wbVExSrDC39xCkIUpZo4hX6sMyLKrtJwsC dBxD+OLcIzmHS3EQfMz3es9Yc3n59GGeNZ3JVgFY8WdS4Vi5JY/rMTrkf/OYtGZgxpO3 3l8oOobH79Hhvp/yCou859Zl8Cc1s/npAk1tcGSpKkoNBY+eHYvfe9Cq029/0GftmoB9 r8WMspjX/I05Rl0FmMN2DOGl9bd2hU8blL1mTVFEpWSeqQGZ4SEiqqKvVpJhMuZ5bilP WyLA== X-Gm-Message-State: APzg51AfyMpvodYd0OaAIZe/CFyWAP6dsp/mrDTb2ZgYYUJirQ4cQBdt YI4wNuFhc4Ob4NqAzLnZNdUrbuSA X-Google-Smtp-Source: ANB0VdYO30ybDhXU8bKuUb7aM6tT5efPYpTj0x4E8ihBYwYPFQvg3LVXOG0kGoGrvTl7PB3PlC9RZw== X-Received: by 2002:a17:902:6b0b:: with SMTP id o11-v6mr27751810plk.214.1536679795621; Tue, 11 Sep 2018 08:29:55 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id f184-v6sm40166076pfc.88.2018.09.11.08.29.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 08:29:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 08:29:53 -0700 Cc: IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> To: Kyle Rose X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 15:29:59 -0000 Responding. The draft-ietf-lisp-sec authors need to respond to one of = your points below about DTLS. > On Sep 10, 2018, at 7:13 PM, Kyle Rose wrote: >=20 > What PKI? That's part of what I'm trying to establish. How do entities = decide to trust each other? The xTRs has a trust association with the mapping system because they = have (1) a business relationship with them and (2) a shared-key that is = used to verify Map-Register messages. =46rom that, Map-Registers and = Map-Requests are can be signed where public-keys are stored by that = trusted mapping system. That is what is documented in = draft-farinacci-lisp-ecdsa-auth-03, and soon to be = draft-ietf-lisp-ecdsa-auth-00 (hopefully). > E.g., if entity A has pairwise trust with peer B, but needs an EID = mapping for peer C, it needs some way to establish that the replies it's = supposedly receiving from C are genuine. One popular model enabling The mapping system allows all of A-C to trust each other. > you to do that without employing transitive trust is end-to-end = signing chained to a trust anchor. With TLS as deployed on the web = today, the trust anchors are a set of mostly mutually agreed-upon CA = certificates that serve as roots for the certificates presented by every = public web server. There are of course issues with this model (q.v., = certificate transparency, Symantec), but its behavior is = well-established and its properties are understood. What is the = equivalent here? >=20 > It sounds like the answer here is mapping system-specific. E.g., from = a quick perusal of the DDT draft, it sounds very DNSSEC-like (which = might suggest a course of action to eliminate the need to develop, = deploy, and maintain a custom security protocol, but that is a different = discussion). >=20 > Where an interface is described without reference to a specific = implementation, a set of assumptions (e.g., "correct routing relies on = the authenticity of mapping system responses") and associated security = requirements for any conforming mapping system (e.g., "entities making = use of mapping system responses must have some way to authenticate them = that does not rely on transitive trust") need to be stated for the = document to be a complete description of a system component. That is, = without first clearly defining the required properties of any valid = implementation of described interfaces, there's no way to evaluate = whether the component under review will do what it's supposed to. >=20 > A good place to put these assumptions and requirements is in the = security considerations section: those statements are not normative for = the system component described by the draft in which they appear, but = are effectively requirements for whatever system component is to = implement that interface in a conforming way. Enumerating them as such = (in the document describing the interface in detail) allows the reader = to evaluate the requirements in light of the system using the interface, = while also providing a convenient checklist for those designing = conforming systems. The designs are done, the references in the various specs are modest = because of the state of the documents. We are sorry for it being hard to = navigate. But for me, I am for less documents versus more, but the = working group wants more modularity in the documentation so hence why = all the pieces don=E2=80=99t seem to be connected (but they are by the = security design of LISP). > A set of well-crafted security considerations sections also makes it = much easier for a reviewer to understand the security of the system as a = whole without having to understand the details of every implementation, = and to verify that individual system components under review will have = the appropriate behavior. >=20 > I'm going to skip the comments related to = draft-farinacci-lisp-ecdsa-auth, just to limit scope here. We can get = back to it once that document has been adopted and more fully = fleshed-out. >=20 > > "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed: >=20 > Right as I explained DTLS does. >=20 > Check again. Just to be sure, I've tried several tools and the letters = "T", "L", and "S" do not appear consecutively anywhere in this document. = Neither do "SSL" nor "transport-level security=E2=80=9D. The draft-ietf-lisp-sec authors need to comment. > > I would like to see a discussion of whether and how the nature and = scale of this problem differs from that of the status quo. BGP sessions = and RIB push have properties that are well-established from decades of = experience: surely LISP does not have exactly the same properties. The = security considerations should make clear, for instance, how a loss of = control plane connectivity differs from the loss of a BGP session, and = how this impacts visibility and behavior of the data plane. >=20 > Please look at the deployment drafts. Please note, you are reviewing a = document that is focusing on encapsulating packets on an overlay. All = the other support pieces are broken out, in what the WG felt was = logical, in sepreate documents. >=20 > I think this gets back to the point I made at the end of my original = review, which is that this system is difficult to evaluate from a = security perspective in a piecewise manner given the dependencies = between the different layers and the lack of explicitly-enumerated = security requirements for each system component implementing a given = interface. >=20 > Kyle I don=E2=80=99t know how to move forward from here. I think we need help = from the lisp-chairs and Deborah. Dino From nobody Tue Sep 11 09:00:06 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73156130EC6; Tue, 11 Sep 2018 08:59:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CCt6CbI5TPOF; Tue, 11 Sep 2018 08:59:55 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 3C097130EC1; Tue, 11 Sep 2018 08:59:55 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id s13-v6so12447937pfi.7; Tue, 11 Sep 2018 08:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Rd1cVMmTMyVtt/r/jpn1hsBiD+Vn5rXYZ9SRI4vpeH0=; b=L7Td+hcHlbtufPuonaa9p1Mi3UxrebpojZeofrFXqif/7LiYmUdY0xdc7Jm4KGPBSf +qVzpoE9ilY59LTDRIIID9sQHim+X1IuRy+tbJiNCk3CxkKvRiNv3qwHEaNvVCaNlHTp /H8HbGfro09CRX4574K2asLmcdAe90sYhfhUPVfvzuoxpUztHbR6LvuNz5WmxHlOhlUp zAbHiWWRsLldSglLnUYGVJLvotAJ3Rki9t1V7XBZ8NVaa0hoTmweA62ztEFksoSGDl03 YJ9tG/wWX6GA+xZtlSWi3xjYaDbW9lnJsGYJKlRN2Wma/uBSBNZgdXwEQOo1PdpCnTU/ WRYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Rd1cVMmTMyVtt/r/jpn1hsBiD+Vn5rXYZ9SRI4vpeH0=; b=YqyvxNAhuYmfuPdJr62C7H7no6i/vDIAk3/FNgZHBaL6dHc74ov07xR9+RkCGQNRxK tRvLAHNj51syXuM6yEOoipKOvUjg38HlgPXDhf3qb51fLUlaWYd9AojkNQrMN/+eDywW hUc4/z2QupzOxKnMgQ5xwdI1HG68PaoGGb2ST1NlE9zF6yzscgA788VTYrs1QfVJ7n3x gW5toyrWWuBUprreNwBWfRwsqbKqkHfaUteLgBJas5+Ql8dHjo3ylX1w1bHKOwD3R3Wg CHpyyCqpQ4KoNshkZq9I/OpYrVfjm7HL+R009qf3oD0/9BahwhlWTGtICiMTKrkSrJ1m v6Ww== X-Gm-Message-State: APzg51AOBCFyJnAgpD71lWzugM3eLEbn0Eu9/qK8wjv402qgD2Vmcuea 4kYXlzzSl6R72TjnQ9TjjRI= X-Google-Smtp-Source: ANB0Vdaz6hde/tY9Gxr1R/8B7BZfDTwTB4EZCqjOzKsFYedhS9CK6VYsbOMNUFb4kYdqySqIWJg4UQ== X-Received: by 2002:a63:6343:: with SMTP id x64-v6mr29343573pgb.173.1536681594706; Tue, 11 Sep 2018 08:59:54 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id g25-v6sm38524745pfd.23.2018.09.11.08.59.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 08:59:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2018 08:59:53 -0700 Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, Dino Farinacci , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 15:59:57 -0000 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-lisp-rfc6830bis-16: 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 = https://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: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ Thanks for your comments Mirja. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I have a couple of smaller discuss points with should be = straight-forward to > address and one more high-level discussion point that might not have a = solution > (depending on the deployment status of LISP I guess) but I would like = to at > least have a discussion. I start with the straight-forward onces: >=20 > 1) Unfortunately ECN decapsulation is slightly more complicated than = described > in section 5.3. Please check section 3.2 in rfc6040 and revise = accordingly > (maybe also provide a pointer to rfc6040 instead or in addition to = rfc3168)! > (Also it seems like the text on ECN is simply just twice in sec 5.3; = not sure > that is helpful). Well it doesn=E2=80=99t have to be. I am a bit hesitant to just point to = another long complicated RFC. This text has gone through review for = quite a long time and many ECN experts decided we should write it this = way. And this text did go through IESG review when RFC6830 was made = experimental RFC. > 2) Further, also in sec 5.3: > "The inner-header 'Differentiated Services Code Point' (DSCP) field > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be > copied from the outer-header DSCP field ('Traffic Class' field, = in > the case of IPv6) considering the exception listed below." > However, I didn't find any exceptions listed later in the doc. = However, setting > the DSCP field might also be matter of local policy. E.g. if DSCP is = not used > for a different purpose in the receiver side LISP network, it could = make sense > to restore/keep the original value in the inner header. This is a dangling reference where the =E2=80=9Ctext below=E2=80=9D was = removed or reworded. So I will remove this reference. > 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while > "IPv4-encapsulated packet with the DF bit set to 1" should be = addressed as well. This is discussed in length. I don=E2=80=99t know how you could have = missed this. > 4) I would like to see another sentence in section 12 explicitly = stating that > the source port SHOULD be the same for all packet belong to the same = flow. Done. > 5) Sec 5.3 says "Both N- and V-bits MUST NOT be set in the same = packet." > What happens if both bits are set? The 'Nonce/Map-Version' is just = ignored, or > maybe the packet should be dropped or something? Please clarify in the = doc! If they are both set, there is text in the docuemnt that already says: The N-bit is the nonce-present bit. When = =20 this bit is set to 1, the low-order 24 bits of the first 32 = =20 bits of the LISP header contain a Nonce. See for details. Both N- and V-bits MUST = =20 NOT be set in the same packet. If they are, a decapsulating = =20 ETR MUST treat the 'Nonce/Map-Version' field as having a = =20 Nonce value present. > 6) And now the more-discussion-needed point: > So my underlying concern is the same as brought up by the TSV-ART = review that > lisp information are not end-to-end integrity protected or = authenticated. I would like you to be more specific. Beacuse there is a lot of security = in the protocol and we believe the current drafts, in their entirety, = inicdate so. > However, while briefly thinking about how this could be eventually = realized, I > noticed that there is actually no mechanism to extend the LISP header = in any Right, by design so it is efficient for hardware AND software = forwarding. But we do have the LISP-GPE header that can be used for = extensions. But that has limited deployment. > way. There is no version, no option and the LISP header seems to have = a fixed, We decdied as a working group that the UDP port number would indicate = what header follows and therefore what LISP version is used. > implicitly specified length without an explicit length field. This = seems too That is right, the header is 8 bytes, fixed, by design. > late to add any kind of extensibility mechanism at this stage of the = protocols > lifetime, however, I would still like to discuss if there was any = discussion > about extensibility, what was the reason to chose this approach, and = potential > if some background about the choice should be given in the doc. Well the original authors didn=E2=80=99t believe in having a lot of = options in protocols, otherwise it will cause more un-interoperability. = But has time has gone on, I believe we made the right choices, and have = discovered that LISP is quite extensible, and even 10 years after the = the original design, we can continue to add more LISP use-cases with the = same basic protocol. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1) In sec 7.1 I would recommend to provide a pointer to RFC4459 and = align the > language to more what RFC4459 recommends: OLD "This behavior is = performed by > the ITR when the source host originates > a packet with the 'DF' field of the IP header set to 0." > MAYBE: > "This behavior MAY be performed by the ITR only when the source host = originates > a packet with the 'DF' field of the IP header set to 0. Changed. Thanks for the suggestion. > 2) Sec 4: "...this document recommends that a maximum of two > LISP headers can be prepended to a packet." > MAYBE: > "it is RECOMMENDED that a maximum of two > LISP headers can be prepended to a packet.=E2=80=9D Changed. Thanks again, Dino From nobody Tue Sep 11 09:11:48 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F79130EE9; Tue, 11 Sep 2018 09:11:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153668230562.17065.1739648310452686985@ietfa.amsl.com> Date: Tue, 11 Sep 2018 09:11:45 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-17.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 11 Sep 2018 16:11:46 -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 WG of the IETF. Title : The Locator/ID Separation Protocol (LISP) Authors : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Albert Cabellos Filename : draft-ietf-lisp-rfc6830bis-17.txt Pages : 44 Date : 2018-09-11 Abstract: This document describes the Data-Plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. This document obsoletes RFC 6830. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-17 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-17 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 Tue Sep 11 09:13:48 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB886130EEA; Tue, 11 Sep 2018 09:13:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 q-PNx5KbXRiw; Tue, 11 Sep 2018 09:13:44 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 D3474130EC0; Tue, 11 Sep 2018 09:13:44 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id j8-v6so11551694pll.12; Tue, 11 Sep 2018 09:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NRzUIPThlYMx2s7LGLSvc8CaOTPAkJAvb6TnXxF48xU=; b=SeqTt73+UVvwlWjhOws/bejk7RYxEpdy1XrDZiarU9SWHlvwMHipM3NYRtv/tkpliB KWm6rN1Y9uWglOPHO7vgbN/mnGxej978BWtStfY8lUgQA0Imy6iR6Jo9KyPsBWRHdods DK88m1/5QFzlQ8K1duU/H+eEZqZ+j7dKg+HM/+95Nt63+OgSkenuNCmZtq1cvul3YdzR H0VqlNU754lt2JPWbnD4hPZsMxvUVBilCeFY7zpRXoDMTS0de5HJrLyQRrxYFxq16+bk yr9FLHq1Edkx8G5UCRDQ2sO9m1hH0uIXiHxE6E/f/WqMgO3HQufuPVoGHIIrOjTnyuWM mLLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NRzUIPThlYMx2s7LGLSvc8CaOTPAkJAvb6TnXxF48xU=; b=LPMmTtUFe6FcMnydd9F5EsVFEzf405x+3itL3xom8Yk42ZL8UnCk7QPvNFJ56+cLo/ 56pynLXp3b9XK0bSyMABZnb3Sspynk2rXncuqdFZcYne1cioct7S/245Rji1/ILjVHzG TDVvMrVdDo6OMRmEjC5kxE4qBjmfkRS1pqRPkVuQBbQ3GcdEKL3j0s/ZhgtXflCmVBr4 fpnPTOeBmDcudEzee+HCJE6tx7+SLEjTjnTUpDr0uRLmMPeMOONOzi8rPiZa/VE6Mi9p fqohbAA7MHgy2OclMQkZx8K+kJ1DUpJxzXwsPFYtRkMs9gq6Jhmi0+LuAgRLnLcELUpx 8Bag== X-Gm-Message-State: APzg51AzM4suefWsAiUGoKklTjjeilzsAavTrq661szSvHJN3N9plQkM 9iGzGiEy/IHFjFS5861fuxrU+Ljb X-Google-Smtp-Source: ANB0VdbMp3540XmImM7OQlXtruiAizZoUtsFc2zxa/JbsGdu6/kE1kcbYNmJgM+LQlW5Os+6Y0VrVQ== X-Received: by 2002:a17:902:9045:: with SMTP id w5-v6mr28352256plz.10.1536682424181; Tue, 11 Sep 2018 09:13:44 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id 16-v6sm31349174pfo.164.2018.09.11.09.13.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 09:13:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153668230562.17065.1739648310452686985@ietfa.amsl.com> Date: Tue, 11 Sep 2018 09:13:42 -0700 Cc: i-d-announce@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <27061AF2-F461-4A90-8165-A2A550D59D7E@gmail.com> References: <153668230562.17065.1739648310452686985@ietfa.amsl.com> To: lisp@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-17.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 16:13:47 -0000 Folks, this submittal contains all changes that reflect comments = received up until today.=20 As for RFC6833bis, I am not doing a submittal right now since there are = some open issues that management is dealing with. ;-) Dino > On Sep 11, 2018, at 9:11 AM, Internet-Drafts@ietf.org wrote: >=20 >=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 WG of = the IETF. >=20 > Title : The Locator/ID Separation Protocol (LISP) > Authors : Dino Farinacci > Vince Fuller > Dave Meyer > Darrel Lewis > Albert Cabellos > Filename : draft-ietf-lisp-rfc6830bis-17.txt > Pages : 44 > Date : 2018-09-11 >=20 > Abstract: > This document describes the Data-Plane protocol for the Locator/ID > Separation Protocol (LISP). LISP defines two namespaces, End-point > Identifiers (EIDs) that identify end-hosts and Routing Locators > (RLOCs) that identify network attachment points. With this, LISP > effectively separates control from data, and allows routers to = create > overlay networks. LISP-capable routers exchange encapsulated = packets > according to EID-to-RLOC mappings stored in a local Map-Cache. >=20 > LISP requires no change to either host protocol stacks or to = underlay > routers and offers Traffic Engineering, multihoming and mobility, > among other features. >=20 > This document obsoletes RFC 6830. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-17 > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-17 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-rfc6830bis-17 >=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 Tue Sep 11 09:23:15 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758F8128766; Tue, 11 Sep 2018 09:23:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WaLWfGu-vAep; Tue, 11 Sep 2018 09:23:04 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 C8F0A1277BB; Tue, 11 Sep 2018 09:23:04 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id d4-v6so12490998pfn.0; Tue, 11 Sep 2018 09:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nHPDNyg0QYJhagiwriVhR9WfR6Er7zJqXOuKKGk6Tz8=; b=uNLgZ9TXyDyG1mMfehSykGB+oxYjJJoWNZm/N+JqNQnltE2NzKgSo+EOiylj5svjdS dqabIR1sVWV56OnmDXsl7An06coXSHd8Hi1noEWyTjoAm9TPaA/98TJkaKi1EPuGfo8H 2HrOy3H2H9xQ2Y/BGDFLaRbha6DpV8Fitcn6PEcceR5QswFK5xjUrElwAL6W8ZTQNOSR xsTYoMy+d66XUipfkQMjH7s729PLSIcDlaS7iEqN7IFPtA6FfdGNWwmbvBBIqQ5hRMVn H2FEmx3sL57iRcoazfwqbNJ2JoObL9AdrOgZZ8Lkf5Jvxqb4Wh+Fr82xXANl1Yv/cFxP 4OiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nHPDNyg0QYJhagiwriVhR9WfR6Er7zJqXOuKKGk6Tz8=; b=AzFihMEj1GxFBUBYiVRlxECQB/LsTKfDo2+BOMlGTeBk9xvcSY6WU6ecdEocXyi/0S GSP8HsL4rAZ9lf1K7E2HzDmPioLatvDsYsrYeNcxaWmfZukw19M1ioUgiMnLs4tG5dxC 4dibWmf7VVReECEClE+ID02L0Q4LmYYh76NVIbvPNTuWkee0xM7ID54XbP+1IV4qo2vf kI9M3g6GrR/a0Xs9Na0Mq5Mv//AkYZ2eVhSwaM9f3sGayMCIxep7eyt/XtK0xCke7CSy 0/EVVHKQK2y9yu8IMTsbpZZD0hHz89y6S6jsCAuN92QqOkVdtHiRTzylKzPsZ3zQHgAC VUPA== X-Gm-Message-State: APzg51B2Xzn5XYmW8NYtIgXR5MirL29q5VgmeUInbObQOkSkONO6RMGU u6hnWAcUmzwjivD8VxePNGQ= X-Google-Smtp-Source: ANB0VdYX3bcCB5jj69TaY05BzsBcXE60ocWWDKGrX/kFaglpMggAjqI9eTcFUJi2S3l5CmvLbtA+kA== X-Received: by 2002:a63:e40d:: with SMTP id a13-v6mr29221857pgi.289.1536682984339; Tue, 11 Sep 2018 09:23:04 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id q25-v6sm30190760pfk.96.2018.09.11.09.23.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 09:23:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2018 09:23:02 -0700 Cc: The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> To: Alvaro Retana X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 16:23:06 -0000 > Alvaro Retana has entered the following ballot position for > draft-ietf-lisp-rfc6833bis-13: No Objection >=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 = https://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: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ Thanks for your comments Alvaro. See my responses below. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > There are several issues in =C2=A75.1 (LISP Control Packet Type = Allocations) that > need to be fixed. I don't think any of them raise up to a DISCUSS, = but I would > like to see them resolved before publication. >=20 > =C2=A75.1 "defines the LISP control message formats and summarizes for = IANA the LISP > Type codes assigned by this document". >=20 > (1) Instructions (or anything directed) to IANA should be in the IANA > Considerations section. There isn't even a pointer to this section = later on > for IANA to look at it. These are not instructions. The instructions are in the IANA = Considerations section. And IANA already knows what to do and already = have done so. So there is no confusion with them. > (2) The text seems to imply ("Message type definitions are") that the = types are > defined here (or at least in rfc6833, which this document Obsoletes), = but they > are defined in rfc6830, rfc8111 and rfc8113. Please properly identify = the > source (only the rfc8113 line has a reference). It means exactly what it says. Only type 15 extensions are defined in = 8113. I have added text that this document, RFC6833bis does obsolete = both 6830 and 6833. > (3) Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting = rfc6830, I > think that, because of how the contents of that RFC were distributed, = this > document should also be tagged as Obsoleting rfc6830. Done. > (4) The LISP Packet Types registry was set up in rfc8113. This = document asks > that IANA "refers to this document as well as [RFC8113] as references" = (=C2=A711.2), > and it seems to try to change the registration (or the text is = incomplete) in > (=C2=A75.1): "Values in the "Not Assigned" range can be assigned = according to > procedures in [RFC8126]." Which procedure? s/Not Assigned/Unassigned = (=C2=A76 in > rfc8126) The early values are already registered with IANA. This document is = asking to register the new ones which include type 15. And the values = *within* type 15 are documented in RFC8113. > (5) Because of the point above, this draft should (at least) Update = rfc8113 > (see also below). Don=E2=80=99t follow. > (6) This document says that "Protocol designers experimenting with new = message > formats SHOULD use the LISP Shared Extension Message Type". I think = this > statement makes rfc8113 a Normative reference -- which results in a = DownRef.=20 > Suggestion: given that this document already updates the registry set = up in > rfc8113, and recommends the use of the Shared Extension Message, it = may be a > good idea to simply adopt the contents of that document here (grand = total of 6 > pages) and declare it Obsolete. I=E2=80=99m yielding to the lisp-chairs and Deborah for this one. > (7) Type 7 is missing. Fixed. Thanks again, Dino From nobody Tue Sep 11 09:29:27 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AB4130EEA for ; Tue, 11 Sep 2018 09:29:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 GHLUyRZRw-_3 for ; Tue, 11 Sep 2018 09:29:22 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B925C130EE9 for ; Tue, 11 Sep 2018 09:29:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=CsIxpoBKen4LV1KxhfpkyhAx6E+dGj+0EzSIiDBg3scMKRQ/jN+6cl51zRqGclduMYlxtystdMOu7Ts0iZqDb3SH5rFVv1s4GW3BL5+kB3lbpmD0nuCfgIp+TXsNbDmQFUr8sWs2ewmVFfNXUC3bzrMUIsZB/Vac7XJyCZkP0/I=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1355 invoked from network); 11 Sep 2018 18:28:19 +0200 Received: from mue-88-130-61-021.dsl.tropolys.de (HELO ?192.168.178.24?) (88.130.61.21) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 Sep 2018 18:28:19 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> Date: Tue, 11 Sep 2018 18:28:17 +0200 Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) X-PPP-Message-ID: <20180911162819.1346.76251@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 16:29:24 -0000 Hi Dino, please see below. > Am 11.09.2018 um 17:59 schrieb Dino Farinacci : >=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-lisp-rfc6830bis-16: 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 = https://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: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >=20 > Thanks for your comments Mirja. >=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> I have a couple of smaller discuss points with should be = straight-forward to >> address and one more high-level discussion point that might not have = a solution >> (depending on the deployment status of LISP I guess) but I would like = to at >> least have a discussion. I start with the straight-forward onces: >>=20 >> 1) Unfortunately ECN decapsulation is slightly more complicated than = described >> in section 5.3. Please check section 3.2 in rfc6040 and revise = accordingly >> (maybe also provide a pointer to rfc6040 instead or in addition to = rfc3168)! >> (Also it seems like the text on ECN is simply just twice in sec 5.3; = not sure >> that is helpful). >=20 > Well it doesn=E2=80=99t have to be. I am a bit hesitant to just point = to another long complicated RFC. This text has gone through review for = quite a long time and many ECN experts decided we should write it this = way. And this text did go through IESG review when RFC6830 was made = experimental RFC. Procedere explained in RFC6040 are actually not that complicated. It=E2=80= =99s mainly the table provided in section 3.2. Please have a look at the = draft. However, I disagree that it =E2=80=9Enegative=E2=80=9C to point = for this part to another RFC. This is not a unique problem, that=E2=80=99s= why we have RFC6040 and all approaches that face this problem should = point to RFC6040 and implement the same strategy. However, if you look at RFC6040 you see that the main problem is that if = the inner codepoint is Not-ECT, you should just not copy the codepoint, = which make sense because that probably means that ECN is not supported = by the endpoints. Respectively, packets marked with CE should be drop to = preserve the congestion signal. This is pretty straight-forward and = should be clear.=20 I don=E2=80=99t know how this could have been missed with RFC6830 but = that seems to indicate it did not have each review for this aspect and = we really need to fix that at least now. >=20 >> 2) Further, also in sec 5.3: >> "The inner-header 'Differentiated Services Code Point' (DSCP) field >> (or the 'Traffic Class' field, in the case of IPv6) SHOULD be >> copied from the outer-header DSCP field ('Traffic Class' field, = in >> the case of IPv6) considering the exception listed below." >> However, I didn't find any exceptions listed later in the doc. = However, setting >> the DSCP field might also be matter of local policy. E.g. if DSCP is = not used >> for a different purpose in the receiver side LISP network, it could = make sense >> to restore/keep the original value in the inner header. >=20 > This is a dangling reference where the =E2=80=9Ctext below=E2=80=9D = was removed or reworded. So I will remove this reference. Okay, that makes sense. I still don=E2=80=99t think that always just = copying is the right approach as I applied above. I would like to see = further text here. >=20 >> 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while >> "IPv4-encapsulated packet with the DF bit set to 1" should be = addressed as well. >=20 > This is discussed in length. I don=E2=80=99t know how you could have = missed this. I didn't miss that discussion but the text got fixed incorrectly because = it doesn=E2=80=99t not address IPv4 through the whole text. Please have = a look and fix that as well. I think this is mainly an editorial issue = but and important one to fix. >=20 >> 4) I would like to see another sentence in section 12 explicitly = stating that >> the source port SHOULD be the same for all packet belong to the same = flow. >=20 > Done. >=20 >> 5) Sec 5.3 says "Both N- and V-bits MUST NOT be set in the same = packet." >> What happens if both bits are set? The 'Nonce/Map-Version' is just = ignored, or >> maybe the packet should be dropped or something? Please clarify in = the doc! >=20 > If they are both set, there is text in the docuemnt that already says: >=20 > The N-bit is the nonce-present bit. When = =20 > this bit is set to 1, the low-order 24 bits of the first 32 = =20 > bits of the LISP header contain a Nonce. See target=3D"echo-nonce"/> for details. Both N- and V-bits MUST = =20 > NOT be set in the same packet. If they are, a decapsulating = =20 > ETR MUST treat the 'Nonce/Map-Version' field as having a = =20 > Nonce value present. Okay, sorry, I actually missed that. That=E2=80=99s fine. Thanks! >=20 >> 6) And now the more-discussion-needed point: >> So my underlying concern is the same as brought up by the TSV-ART = review that >> lisp information are not end-to-end integrity protected or = authenticated. >=20 > I would like you to be more specific. Beacuse there is a lot of = security in the protocol and we believe the current drafts, in their = entirety, inicdate so. I was thinking about the option to add an authenticated hash, anyway... >=20 >> However, while briefly thinking about how this could be eventually = realized, I >> noticed that there is actually no mechanism to extend the LISP header = in any >=20 > Right, by design so it is efficient for hardware AND software = forwarding. But we do have the LISP-GPE header that can be used for = extensions. But that has limited deployment. >=20 >> way. There is no version, no option and the LISP header seems to have = a fixed, >=20 > We decdied as a working group that the UDP port number would indicate = what header follows and therefore what LISP version is used. Okay, that needs to be explained in the doc! Mirja >=20 >> implicitly specified length without an explicit length field. This = seems too >=20 > That is right, the header is 8 bytes, fixed, by design. >=20 >> late to add any kind of extensibility mechanism at this stage of the = protocols >> lifetime, however, I would still like to discuss if there was any = discussion >> about extensibility, what was the reason to chose this approach, and = potential >> if some background about the choice should be given in the doc. >=20 > Well the original authors didn=E2=80=99t believe in having a lot of = options in protocols, otherwise it will cause more un-interoperability. = But has time has gone on, I believe we made the right choices, and have = discovered that LISP is quite extensible, and even 10 years after the = the original design, we can continue to add more LISP use-cases with the = same basic protocol. >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> 1) In sec 7.1 I would recommend to provide a pointer to RFC4459 and = align the >> language to more what RFC4459 recommends: OLD "This behavior is = performed by >> the ITR when the source host originates >> a packet with the 'DF' field of the IP header set to 0." >> MAYBE: >> "This behavior MAY be performed by the ITR only when the source host = originates >> a packet with the 'DF' field of the IP header set to 0. >=20 > Changed. Thanks for the suggestion. >=20 >> 2) Sec 4: "...this document recommends that a maximum of two >> LISP headers can be prepended to a packet." >> MAYBE: >> "it is RECOMMENDED that a maximum of two >> LISP headers can be prepended to a packet.=E2=80=9D >=20 > Changed. >=20 > Thanks again, > Dino >=20 >=20 >=20 From nobody Tue Sep 11 09:29:40 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D22C1310C7 for ; Tue, 11 Sep 2018 09:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 49DjfTw1662n for ; Tue, 11 Sep 2018 09:29:33 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 4F173130F1E for ; Tue, 11 Sep 2018 09:29:33 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id m11-v6so48403408oic.2 for ; Tue, 11 Sep 2018 09:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=2NSLCnX4UiB4mfat4TaOQ7lQDiTOtbXU35aTFet2TJs=; b=SUPAdHz5q8H8VpBM+a/3voF2eB+Gq2GVQRhHsQZ5qSJMQTTZfUpTXlK/RJRJ9MedFs vuzF2QFuiC2B2foTQbjWqen2mgwT7KTkkTx7wUDC3O6LJsrCkoF7dWKj1pQZ/cAzVVw6 8fV04fPRlyooX2Ew3w/J/h3gJIPzAAZcSIOCyrAH4Xsobc7O0ak+8erdSVT63agDxoQH TAYp/G7MIayiKecckB4OdIPczv/BUp5xhlnLDaMbS0jbXFHS0ytPQFkaY6UEq9Z0ogFQ KtaNpF6aw/Y/2kP4Jl20R96GLEj4mx8Zp3ngjwdcAFTz2n+7zL0lDnd1ii3fzdAHN/Pg /MPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=2NSLCnX4UiB4mfat4TaOQ7lQDiTOtbXU35aTFet2TJs=; b=IP9TgcfAzWojlxm0AoAOl86Jwke6DxI6QGCPHIgw8fo3bKIfF3NGXxOOkrjLJn+Wcj rBX7Hne7gVK31jO0We6T1Td5MUGEYljPczbFaHQnBnpOoO6DnwLQFK4gBO3lW97w6AKX B/BI/cR5X+o7a4eRzOhxtS5qoGHxkkRzRk9ehNMFtBQKBbN1X3PIle9wvz0c1DVPCqhI 07pR4s7Y3VoE8AJ7ti+FQ08iUfLUlffDUrD68DSfXbGQq8JeTEwyOUslk3uN80E13ijM hdxWb8T2I+pPnXHY3t4PwBbEF84Sgh4/XfB9FWEA4MDyI7WiCYZW22dWork+MJ0dUZSO s+WQ== X-Gm-Message-State: APzg51BUVFoxPI1bnOoGN9JE1URVzwRwcjKOfpm8Ygs5DF+vTbDvWNKV yPimbQjOKsRpoFUmkUIzY8kVNv0mlT1u6VaQ0WNPGg== X-Google-Smtp-Source: ANB0VdYXCfXuG05u+usso6MYs2ax50rO/Bs5Dn9wO88JjEZAdTt+xDVLoavsg1rC5RXtSAo3eiHjCD2DEs4gsWGdsmI= X-Received: by 2002:aca:586:: with SMTP id 128-v6mr26011623oif.185.1536683372648; Tue, 11 Sep 2018 09:29:32 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 11 Sep 2018 12:29:32 -0400 From: Alvaro Retana In-Reply-To: References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> X-Mailer: Airmail (506) MIME-Version: 1.0 Date: Tue, 11 Sep 2018 12:29:31 -0400 Message-ID: To: Dino Farinacci , Luigi Iannone , "Joel M. Halpern" Cc: "lisp@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008f203305759afa0f" Archived-At: Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 16:29:39 -0000 --0000000000008f203305759afa0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On September 11, 2018 at 9:50:29 AM, Joel M. Halpern (jmh@joelhalpern.com) wrote: Hi! Any change to lisp-intro should be done by discussion with the RFC Editor, as it is in the RFC Editor queue (pending reference completion). If the working group considers it acceptable, we could easily ask them to change the references to 6830 and 6833 to the bis documents (after all, it is alreay blocked by documents which depend upon those.) The reference would still be circular: rfc6830bis would point at lisp-introduction for architecture details, and that would point back here. If lisp-introduction was just that (an introduction) and the details were in rfc6830 to start with=E2=80=A6. Maybe the easy fix is to just not point = to lisp-introduction from rfc6830bis, because the details should be here (and rfc6833bis) already. s/Finally, [I-D.ietf-lisp-introduction] describes the LISP architecture.// Alvaro. Yours, Joel On 9/10/18 11:27 PM, Dino Farinacci wrote: > If you guys have source for the intro doc, I could point it to bis > documents? > > Dino > > > Begin forwarded message: > >> *Resent-From:* > >> *From:* Alvaro Retana > > >> *Date:* September 10, 2018 at 2:22:21 PM PDT >> *Resent-To:* farinacci@gmail.com , >> vince.fuller@gmail.com , dmm@1-4-5.net >> , darlewis@cisco.com >> , acabello@ac.upc.edu >> >> *To:* "The IESG" > >> *Cc:* draft-ietf-lisp-rfc6830bis@ietf.org >> , Luigi Iannone >> >, lisp-chairs@ietf.org >> , lisp@ietf.org >> *Subject:* *Alvaro Retana's No Objection on >> draft-ietf-lisp-rfc6830bis-16: (with COMMENT)* >> >> Alvaro Retana has entered the following ballot position for >> draft-ietf-lisp-rfc6830bis-16: No Objection >> >> 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 https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for the work on this document! >> >> I have some relatively minor comments/nits: >> >> (1) =C2=A718: s/RFC8060/RFC8061 >> >> (2) =C2=A71: "Finally, [I-D.ietf-lisp-introduction] describes the LISP >> architecture." First of all, it would seem to me that the >> Architecture should >> be a Normative reference...but I-D.ietf-lisp-introduction says that it >> "is used >> for introductory purposes, more details can be found in RFC6830, the >> protocol >> specification." This document obsoletes rfc6830...so it seems to me >> that there >> is a failed circular dependency. >> >> (3) References to rfc2119/rfc8174 and rfc8126 should be Normative. >> >> _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --0000000000008f203305759afa0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On September 11, 2018 at 9:50:29 AM, Joel M. Halp= ern (jmh@joelhalpern.com) wrote:=

Hi!

Any change to l= isp-intro should be done by discussion with the RFC=C2=A0
Editor, as it is in the RFC Editor queue (pe= nding reference completion).
If the working group considers it acceptabl= e, we could easily ask them=C2=A0
to change the references to 6830 and 6833 to the bis documents (afte= r=C2=A0
all, it is alreay b= locked by documents which depend upon those.)

The reference would still be circular: rfc6830bis would point at= lisp-introduction for architecture details, and that would point back here= .

If lisp-introduction was just that (an introduction) and the detail= s were in rfc6830 to start with=E2=80=A6. Maybe the easy fix is to just not= point to lisp-introduction from rfc6830bis, because the details should be = here (and rfc6833bis) already.

s/Finally, [I-D.ietf-lisp-introduction= ] describes the LISP architecture.//

Alvaro.




Yours,
= Joel

On 9/10/18 11:27 PM, Dino Farinacci wrote:
> If you guys = have source for the intro doc, I could point it to bis=C2=A0
> documents?
>=C2=A0
> Dino
>=C2=A0
>=C2=A0
> Begin forwarded message:
>=C2=A0
>> *Resent-From:* <alias-bounces@ietf.org <mailto:alias-bounces@ietf.org>>
&g= t;> *From:* Alvaro Retana <= aretana.ietf@gmail.com=C2=A0
>> <mailto:aretana= .ietf@gmail.com>>
>> *Date:* September 10, 2018 at 2:22:= 21 PM PDT
>> *Resent-To:* f= arinacci@gmail.com <mailto:fa= rinacci@gmail.com>,=C2=A0
>> vince.fuller@gmail= .com <mailto:vince.fuller@= gmail.com>, dmm@1-4-5.net=C2=A0
>> <mailto:dmm@1-4-5.net>, darlewis@cisco.com= =C2=A0
>> <mailto:= darlewis@cisco.com>, acabello= @ac.upc.edu=C2=A0
>&= gt; <mailto:acabello@ac.upc.edu>
>> *To:* "The IESG" <iesg@ietf.org <mailto:iesg@= ietf.org>>
>> *Cc:* draft-ietf-lisp-rfc6830bis@ietf.org=C2=A0
>> <mailto:draft-ietf-lisp-rfc6830bis@ietf.org>, Luigi Iannone=C2=A0>> <ggx@gigix.net <mailto= :ggx@gigix.net>>, lisp-chairs@ietf.org=C2=A0
>> <mailto:lisp-chairs@ietf.org>, lisp@ietf.org <mailto:lisp@ietf.= org>
>> *Subject:* *Alvaro Retana's No Objection on=C2=A0
>> draft-ietf-lisp= -rfc6830bis-16: (with COMMENT)*
>>
>> Alvaro Retana has e= ntered the following ballot position for
>> draft-ietf-lisp-rfc683= 0bis-16: No Objection
>>
>> When responding, please keep = the subject line intact and reply to all
>> email addresses includ= ed in the To and CC lines. (Feel free to cut this
>> introductory = paragraph, however.)
>>
>>
>> Please refer to https:/= /www.ietf.org/iesg/statement/discuss-criteria.html
>> for more= information about IESG DISCUSS and COMMENT positions.
>>
>&= gt;
>> The document, along with other ballot positions, can be fou= nd here:
>> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830= bis/
>>
>>
>>
>> ------------------= ----------------------------------------------------
>> COMMENT:>> ----------------------------------------------------------------= ------
>>
>> Thanks for the work on this document!
>= ;>
>> I have some relatively minor comments/nits:
>>>> (1) =C2=A718: s/RFC8060/RFC8061
>>
>> (2) =C2= =A71: "Finally, [I-D.ietf-lisp-introduction] describes the LISP
>= ;> architecture." =C2=A0First of all, it would seem to me that the<= span class=3D"Apple-converted-space">=C2=A0
>> Architecture= should
>> be a Normative reference...but I-D.ietf-lisp-introducti= on says that it=C2=A0
>&= gt; "is used
>> for introductory purposes, more details can b= e found in RFC6830, the=C2=A0<= br>>> protocol
>> specification." =C2=A0This document o= bsoletes rfc6830...so it seems to me= =C2=A0
>> that there
>> is a failed circular depen= dency.
>>
>> (3) References to rfc2119/rfc8174 and rfc812= 6 should be Normative.
>>
>>

_____________________= __________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

--0000000000008f203305759afa0f-- From nobody Tue Sep 11 09:37:11 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C349A130EE4 for ; Tue, 11 Sep 2018 09:37:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 P8nxFJ3dhQhx for ; Tue, 11 Sep 2018 09:37:07 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 13312130EC0 for ; Tue, 11 Sep 2018 09:37:07 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id x17-v6so12511575pfh.5 for ; Tue, 11 Sep 2018 09:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=81T4v2xM1iYuCsHIyf81tdgITELNBwYLSCpmTibCNXg=; b=k9Svf9usTr3jx6AEWiSmB/b33kBypH2QYSAbE/vP83CX+a26odSKFQoS1F3auKF8Fo 4K2hJpKl9QhmJK49SEuSBCG1ok64uQLMV2S8k5/HeX0Yc/XZlnQ2kc5fv4UID6AoIYdz SXU/93vc0BNGQ8viNsWhY7llBpPHQa6b8DOrBidIqMIhriuDYnDrQ1zSC386BSVIr+tS dA3PVqdN9SmGhz4UJUYQHsE1hunzXexq54rhvj0Jg7pr/C4po/tITubv9UV8dChKFEeR rreCLXHwKmLeyViY/AsbvCw5gxBEGp6eO9XTWZ76FzO6M24lciRxcYsbfxe5Sov4wzIj 8cTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=81T4v2xM1iYuCsHIyf81tdgITELNBwYLSCpmTibCNXg=; b=oYGS0rTJpkhGO5rtF4ClXRaC58Ekc9sJvL6yyn2Sfzqo2aqY2TxWS7b6rIE67hi3zp xHQ+j9CR57J3TPSFDPIX2TWeYhPKHss4YoPVdV6tLqqJKRVMHg19HDpyw7TSe2CGR3ro t9U3ddiDtdIC4l+akegXIU0YsMkNa6hzfs9uDZCK2SMcIcDr1xkahlxmDWUUkDKZp2h+ W1xRWLj5XCuNY2blQ08SGAlNd+23UWdohr4iYxS6RVYpKwTgq+gs/jXIA+grgFN85OHg G1kZaGYaXnbbXz4cCDbrQCNvT2VtyhSM4c1U2Bf7LgvaxB/zJJLHV9e4Aq5KIyrnKjO8 kKSw== X-Gm-Message-State: APzg51CVCOfA0qy/ZCwAn4zxvomyNNp4wVhwzb+A9dnEKFs8wPGBR2nC tMQuVAAscZLYCK/99d7pMjo= X-Google-Smtp-Source: ANB0VdZAunPBHtAS+hcX+ML4uDJVaM5okD5S9PuTECgSOW/NPsw1A4GAjEs7roqAKCirQ2/7VjF9Sw== X-Received: by 2002:a63:e756:: with SMTP id j22-v6mr29565365pgk.185.1536683826478; Tue, 11 Sep 2018 09:37:06 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id f67-v6sm61507085pfe.75.2018.09.11.09.37.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 09:37:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 09:37:04 -0700 Cc: Luigi Iannone , "Joel M. Halpern" , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8A78EF35-B0E4-43EC-A6B7-EB7DED60210F@gmail.com> References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> To: Alvaro Retana X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 16:37:10 -0000 Right now there is no circular dependency. To summarize: (1) RFC6830 does not point to 6830bis or lisp-intro. (2) lisp-intro points to RFC6830. (3) 6860bis needs to point to RFC6830. Let=E2=80=99s please don=E2=80=99t change any this. Let=E2=80=99s not = make this more complciated then it needs to be and let=E2=80=99s not = confuse people, especially the authors. ;-) Dino > On Sep 11, 2018, at 9:29 AM, Alvaro Retana = wrote: >=20 > On September 11, 2018 at 9:50:29 AM, Joel M. Halpern = (jmh@joelhalpern.com) wrote: >=20 > Hi! >=20 >> Any change to lisp-intro should be done by discussion with the RFC=20 >> Editor, as it is in the RFC Editor queue (pending reference = completion). >> If the working group considers it acceptable, we could easily ask = them=20 >> to change the references to 6830 and 6833 to the bis documents (after=20= >> all, it is alreay blocked by documents which depend upon those.) > The reference would still be circular: rfc6830bis would point at = lisp-introduction for architecture details, and that would point back = here. >=20 > If lisp-introduction was just that (an introduction) and the details = were in rfc6830 to start with=E2=80=A6. Maybe the easy fix is to just = not point to lisp-introduction from rfc6830bis, because the details = should be here (and rfc6833bis) already. >=20 > s/Finally, [I-D.ietf-lisp-introduction] describes the LISP = architecture.// >=20 > Alvaro. >=20 >=20 >=20 >>=20 >>=20 >> Yours, >> Joel >>=20 >> On 9/10/18 11:27 PM, Dino Farinacci wrote: >> > If you guys have source for the intro doc, I could point it to bis=20= >> > documents? >> >=20 >> > Dino >> >=20 >> >=20 >> > Begin forwarded message: >> >=20 >> >> *Resent-From:* > >> >> *From:* Alvaro Retana > >> > >> >> *Date:* September 10, 2018 at 2:22:21 PM PDT >> >> *Resent-To:* farinacci@gmail.com ,=20 >> >> vince.fuller@gmail.com , = dmm@1-4-5.net=20 >> >> , darlewis@cisco.com=20 >> >> , acabello@ac.upc.edu=20 >> >> >> >> *To:* "The IESG" > >> >> *Cc:* draft-ietf-lisp-rfc6830bis@ietf.org=20 >> >> , Luigi Iannone=20 >> >> >, lisp-chairs@ietf.org=20 >> >> , lisp@ietf.org = >> >> *Subject:* *Alvaro Retana's No Objection on=20 >> >> draft-ietf-lisp-rfc6830bis-16: (with COMMENT)* >> >> >> >> Alvaro Retana has entered the following ballot position for >> >> draft-ietf-lisp-rfc6830bis-16: No Objection >> >> >> >> 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 = https://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: >> >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >> >> >> >> >> >> >> >> = ---------------------------------------------------------------------- >> >> COMMENT: >> >> = ---------------------------------------------------------------------- >> >> >> >> Thanks for the work on this document! >> >> >> >> I have some relatively minor comments/nits: >> >> >> >> (1) =C2=A718: s/RFC8060/RFC8061 >> >> >> >> (2) =C2=A71: "Finally, [I-D.ietf-lisp-introduction] describes the = LISP >> >> architecture." First of all, it would seem to me that the=20 >> >> Architecture should >> >> be a Normative reference...but I-D.ietf-lisp-introduction says = that it=20 >> >> "is used >> >> for introductory purposes, more details can be found in RFC6830, = the=20 >> >> protocol >> >> specification." This document obsoletes rfc6830...so it seems to = me=20 >> >> that there >> >> is a failed circular dependency. >> >> >> >> (3) References to rfc2119/rfc8174 and rfc8126 should be Normative. >> >> >> >> >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Sep 11 09:41:12 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722E5128CF2 for ; Tue, 11 Sep 2018 09:40:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 2_O6peiTZLSI for ; Tue, 11 Sep 2018 09:40:55 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 95BED128B14 for ; Tue, 11 Sep 2018 09:40:52 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id f62-v6so15453387qke.2 for ; Tue, 11 Sep 2018 09:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/bpDNXkFidMPnjzTu4buW2A9tvBBViqCUENYjpd+OGk=; b=IcxdOu9RnireLun38gdIlCHIHBEwBeLqLpyVuRY1bPhRvrKAGpSQqToMbIG6QakA+t R3eyVXnc7HwAIUgjieCatDXK7rN/sqBXvYZ5e8dNGyz+tOJosB9F2ZtvqK/ScoW9biWn 9S3h11G7jaPvXCkHGqb+u49hnHpYiHPFquklk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/bpDNXkFidMPnjzTu4buW2A9tvBBViqCUENYjpd+OGk=; b=mC73jjvcClys19h6g5sgHjkw91JYMQXiqAa3XvVbDiE2zZhWEZh6XtNGgD/7tS1+e6 CfmocBZuUCw1MbNti5Mov9/EBk6k1ot8BI4u7SYl9dZ/7YnDt14ONlVzCbg0xDmZyNR0 QK0llEkzu3WiVvitrNJZjoBiUWaH4RXQI0qEvpbRz8T1Ba1pBSUpAUy205tV2ySKh/yD 7W4jNmVf+goTncy+1gaSNp5yZaYTfCrL+F6oNeGyWRivwauZn4NR3jMYtLq/p+Ce+bkb wLR1YT47uWLOpXat8648UhXudl4xkS/bRJqbxopTc921hdyQo7JNy+EcZPg0a7gH9CRZ QLNg== X-Gm-Message-State: APzg51ArmBw+CpzdCtkpsweOu6cwvfCn1LbPjOsTeaHOAfWrMRbJNG8p DXnxibFsiaQxYepO69BXsfLJXdM7/ex3l7zLOvhnrQ== X-Google-Smtp-Source: ANB0VdZJTTV7/fT4BuuinqLkoEJJv4A65jrWrsFpVjdBAk+wFlnC9zsiepzUlSiM44b4QsK0W89aM8+oJfP8yKnXEdU= X-Received: by 2002:a37:2381:: with SMTP id j123-v6mr19155128qkj.259.1536684051442; Tue, 11 Sep 2018 09:40:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 09:40:50 -0700 (PDT) X-Originating-IP: [2001:4878:a000:3000:b804:b2b6:546:6e10] In-Reply-To: <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> From: Kyle Rose Date: Tue, 11 Sep 2018 12:40:50 -0400 Message-ID: To: Dino Farinacci Cc: IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000004c5aa05759b23ed" Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 16:40:58 -0000 --00000000000004c5aa05759b23ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci wrote: > > E.g., if entity A has pairwise trust with peer B, but needs an EID > mapping for peer C, it needs some way to establish that the replies it's > supposedly receiving from C are genuine. One popular model enabling > > The mapping system allows all of A-C to trust each other. > Explain how with a detailed example, or point me to a detailed explanation in a specific document. The mechanism is still not entirely clear to me. If A and C don't have an established business relationship, how does A know that the responses it's getting for EID mappings owned by C are genuine and not modified by B? This is a critical property of the system, and so it needs to be made obvious to the reader. > The designs are done, the references in the various specs are modest > because of the state of the documents. We are sorry for it being hard to > navigate. But for me, I am for less documents versus more, but the workin= g > group wants more modularity in the documentation so hence why all the > pieces don=E2=80=99t seem to be connected (but they are by the security d= esign of > LISP). > I agree with, and am not taking issue with, modularity: no one wants a monolithic design for something this complex. But the interfaces between the documents, by which I mean the requirements they impose on each other, must be made explicit. When a system achieves complexity warranting design modularity, it's simply not sufficient to describe individual system components without providing a framework for analyzing how they fit together without having to read and fully understand all of it. All the information *might* in fact be there, but as an outsider not implementing LISP, and with finite time to review, asking me to understand the minutiae of the entire LISP ecosystem in order to understand the security properties of the overall system is simply not reasonable. I should be able to consume a high-level architectural overview, containing sufficient detail to understand the security properties of the overall system, and then use that to drill into areas of concern more deeply. This is why I want the high-level security requirements documented somewhere, along with a set of high-level explanations of how the proposed system components combine to satisfy them. Put another way: as someone whose day job it is to read and review design documents and to offer architectural consulting on everything from from network architecture and hardware design to build automation and SDLC tools to dynamic job orchestration and application security, being able to achieve a high-level mental picture of the critical properties of a design is an important first step in evaluating a system's fitness for a particular task. Document authors have a responsibility to make their work consumable by people who don't already have the full context. Kyle --00000000000004c5aa05759b23ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Sep 11, 2018 at 11:29 AM, Dino Farinacci <farinacci@gmail.com&g= t; wrote:
> E.= g., if entity A has pairwise trust with peer B, but needs an EID mapping fo= r peer C, it needs some way to establish that the replies it's supposed= ly receiving from C are genuine. One popular model enabling

The mapping system allows all of A-C to trust each other.

Explain how with a detailed example, or point me = to a detailed explanation in a specific document. The mechanism is still no= t entirely clear to me. If A and C don't have an established business r= elationship, how does A know that the responses it's getting for EID ma= ppings owned by C are genuine and not modified by B? This is a critical pro= perty of the system, and so it needs to be made obvious to the reader.
<= /div>
=C2=A0
The designs are done, the references in the various specs are modest becaus= e of the state of the documents. We are sorry for it being hard to navigate= . But for me, I am for less documents versus more, but the working group wa= nts more modularity in the documentation so hence why all the pieces don=E2= =80=99t seem to be connected (but they are by the security design of LISP).=

I agree with, and am not taking issue = with, modularity: no one wants a monolithic design for something this compl= ex. But the interfaces between the documents, by which I mean the requireme= nts they impose on each other, must be made explicit. When a system achieve= s complexity warranting design modularity, it's simply not sufficient t= o describe individual system components without providing a framework for a= nalyzing how they fit together without having to read and fully understand = all of it. All the information *might* in fact be there, but as an outsider= not implementing LISP, and with finite time to review, asking me to unders= tand the minutiae of the entire LISP ecosystem in order to understand the s= ecurity properties of the overall system is simply not reasonable. I should= be able to consume a high-level architectural overview, containing suffici= ent detail to understand the security properties of the overall system, and= then use that to drill into areas of concern more deeply. This is why I wa= nt the high-level security requirements documented somewhere, along with a = set of high-level explanations of how the proposed system components combin= e to satisfy them.

Put another way: as someone= whose day job it is to read and review design documents and to offer archi= tectural consulting on everything from from network architecture and hardwa= re design to build automation and SDLC tools to dynamic job orchestration a= nd application security, being able to achieve a high-level mental picture = of the critical properties of a design is an important first step in evalua= ting a system's fitness for a particular task. Document authors have a= responsibility to make their work consumable by people who don't alrea= dy have the full context.
=C2=A0
Kyle
--00000000000004c5aa05759b23ed-- From nobody Tue Sep 11 09:46:06 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349E7130DE3; Tue, 11 Sep 2018 09:46:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KcpYk8ExgCfg; Tue, 11 Sep 2018 09:46:01 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 8A85B128B14; Tue, 11 Sep 2018 09:46:01 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id x26-v6so12543419pge.12; Tue, 11 Sep 2018 09:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xFH0nvAKF7TpMkuMhgANvpCNDge+LZDc9z2JArJ31eQ=; b=jrk5M+HnBdYPe2lUP8zOourCyCMDQ+aipXj4eyP4CUmJ71jAG9ZV8XnoXybgrFfatY dQ/mUVcMKRCeTTmuzIhbAKrc3CLzApF9z/Nep5VEqHCEAQMip6qP9z+MXkwnqIQcjdJr ZQhuc9cr8T0bjyn0Dtul7D8UcDfCXKQLLcNfKP5zWWwBbNnD+jpX3VGFxlO4lcbH8JNC 35FmL/ttlD+G7HjEfqpObysRlYvQiwurWkIdJRvoo9FGKkL3zV0wEWZ7e7QEmRAF4qfB jOARWiSZUM5B2HROp22KTpI9YPZDCGsa12LPvLu/KWMoD6b9VeJWzABQWLxInBh3xjM9 fW8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xFH0nvAKF7TpMkuMhgANvpCNDge+LZDc9z2JArJ31eQ=; b=rSW4o/9hXbY8Nm4QmU01omn12ePFn67VCWFqBrBCMwJyNsW0KUwBXuFIGkNiEJ1YBN D9SC9NGvMF0UCg84aZtSutMxb1Yb9L9KR5HF8TmHB4nLMMwtYGBvC0F5+LPFfsZqjBky d5tP1IDTEP2oCuEd3/JdOBJigLA7expSrXc0oncI/SSTDHckhNI5iNgtjRq0wt4fONbu AKPuZ4+xgWkgNWm/NNLDIvspOOPQV2SsNQSOCHWkCjui1pS6XXvuvwbvTI77LnGYWKcA CNyBwFbUygEr0cWpMMH4iSn/Z93+zGxrcYXuNGqvPkcM67PwXeXu0fNQTPuVV63hNR9K nYkw== X-Gm-Message-State: APzg51BskRvlcTKQKPz3+96ylJFqtexs13sH2DvVpmtpkXDLb/V3Zm2u kn/YzAzGzydIJDpo0XmySxib3xxr X-Google-Smtp-Source: ANB0VdbgkgczhM7yoMObSQpVLRCT5ZgPH8iabVpyd1topYzF3tvbWQ8uNvNFjFfPg9qR2Qjd30kV4w== X-Received: by 2002:aa7:83cd:: with SMTP id j13-v6mr30399494pfn.236.1536684361066; Tue, 11 Sep 2018 09:46:01 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id w5-v6sm23592931pfn.44.2018.09.11.09.46.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 09:46:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> Date: Tue, 11 Sep 2018 09:45:59 -0700 Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 16:46:04 -0000 >> Well it doesn=E2=80=99t have to be. I am a bit hesitant to just point = to another long complicated RFC. This text has gone through review for = quite a long time and many ECN experts decided we should write it this = way. And this text did go through IESG review when RFC6830 was made = experimental RFC. >=20 > Procedere explained in RFC6040 are actually not that complicated. = It=E2=80=99s mainly the table provided in section 3.2. Please have a = look at the draft. However, I disagree that it =E2=80=9Enegative=E2=80=9C = to point for this part to another RFC. This is not a unique problem, = that=E2=80=99s why we have RFC6040 and all approaches that face this = problem should point to RFC6040 and implement the same strategy. I am just worried it will be ignored because there are implementations = out there that do what they already do. If we want to suggest to = consider the procedures in RFC6040, I am okay with that, but you need to = provide the wording because I certainly don=E2=80=99t want it too = strong. >>=20 >>=20 >>> 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while >>> "IPv4-encapsulated packet with the DF bit set to 1" should be = addressed as well. >>=20 >> This is discussed in length. I don=E2=80=99t know how you could have = missed this. >=20 > I didn't miss that discussion but the text got fixed incorrectly = because it doesn=E2=80=99t not address IPv4 through the whole text. = Please have a look and fix that as well. I think this is mainly an = editorial issue but and important one to fix. I am sorry. I don=E2=80=99t know what you think is wrong. Please point = to the text specifically. >>=20 >>> 6) And now the more-discussion-needed point: >>> So my underlying concern is the same as brought up by the TSV-ART = review that >>> lisp information are not end-to-end integrity protected or = authenticated. >>=20 >> I would like you to be more specific. Beacuse there is a lot of = security in the protocol and we believe the current drafts, in their = entirety, inicdate so. >=20 > I was thinking about the option to add an authenticated hash, = anyway=E2=80=A6 LISP uses lisp-crypto (RFC8061) which uses AEAD. >>=20 >>> However, while briefly thinking about how this could be eventually = realized, I >>> noticed that there is actually no mechanism to extend the LISP = header in any >>=20 >> Right, by design so it is efficient for hardware AND software = forwarding. But we do have the LISP-GPE header that can be used for = extensions. But that has limited deployment. >>=20 >>> way. There is no version, no option and the LISP header seems to = have a fixed, >>=20 >> We decdied as a working group that the UDP port number would indicate = what header follows and therefore what LISP version is used. >=20 > Okay, that needs to be explained in the doc! >=20 > Mirja The document says that UDP port 4341 is assigned and when so, the LISP = header as docmented is used. We shouldn=E2=80=99t just encourage = versioning if the philosophy it not to churn often. Dino From nobody Tue Sep 11 09:48:51 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE57213112F for ; Tue, 11 Sep 2018 09:48:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 w7NRZrGvEeUP for ; Tue, 11 Sep 2018 09:48:34 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 C47FF1310D9 for ; Tue, 11 Sep 2018 09:48:27 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id z125-v6so17175227qkb.12 for ; Tue, 11 Sep 2018 09:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X2fhHEN+ZyCDFM3jVfcRm0t4+SP+/VD37ofszG8PoIQ=; b=YqxbVYgVGtA8kgLeDad2fNIMYHLG9KdrLEqIEDOjKSZi2ktZAutSJ3M41D9WbieiJY NPn3MhWT5QRhPHLCk8I/uMBrpg7ANSZJnN1kkV6d28/+B+tZL7WcB/xjuqVVlvr9YTm3 jZ+ygM/vfIZ5qCeidT8Awe9RG+bBAIfmLz4Hc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X2fhHEN+ZyCDFM3jVfcRm0t4+SP+/VD37ofszG8PoIQ=; b=m/AKjz0PgYyLv8juQQe/1yuyoZP7MaRtPXNfgAn2+90UoS1h1tM+iWADpBKIN+bVsT BHIV2A2XJHJ/MYyWgzonjp/x6Q1G65xJD+nEa9mHdJ5G99psM0RcizKqJ5VQyw6zV+7k dChOfEGzi9l6/ugqcAneqcKsSa9VozZZQ6UnGchx4AJoAGVFpvowX17l4N95tmdOgH0U ZNhP/4NNuwT+Oz/Ox34UA9HuhLrg+FWACjhhFhzSBDK4mxim0vAh+sWCfLGe9+5nrAUK QVqVKCKjXdbYJs8ebnmUqR0yGu9qDJMw9lC6W9/9tsvojiR8z7aMckTQltGK3Nx3Eq4a eu/g== X-Gm-Message-State: APzg51Dsn5AAsDD0LrnxG0mzQrpPx7Uc6IFWDkhTwAyHoFbWfIV45tCx pdblG6G7ztGg9iUe4n7cp2BltTHN/XDZk758zkVCjA== X-Google-Smtp-Source: ANB0VdZMmNcAFB01I++cNiK22cTaKGOVmu/jyc6u6v0xrl4FAhl81RwXLUK1cvKTD4Fya0ivPUhJIxuZlfTAthvFH/U= X-Received: by 2002:ae9:e8d8:: with SMTP id a207-v6mr20018909qkg.235.1536684506663; Tue, 11 Sep 2018 09:48:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 09:48:26 -0700 (PDT) X-Originating-IP: [2001:4878:a000:3000:b804:b2b6:546:6e10] In-Reply-To: <77109099-A756-4563-968C-5AC17FF38291@gigix.net> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <77109099-A756-4563-968C-5AC17FF38291@gigix.net> From: Kyle Rose Date: Tue, 11 Sep 2018 12:48:26 -0400 Message-ID: To: Luigi Iannone Cc: Dino Farinacci , IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000026e15b05759b3ef0" Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 16:48:43 -0000 --00000000000026e15b05759b3ef0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that the first point is probably not secdir-related, but it is still something that should be addressed. To the second point re: RFC 7835 and resource attacks on control vs. data plane, what I want to see is an analysis for operators of novel attack vectors that are created by LISP. For instance, the threat mitigation section says: q( The control plane is the most critical part of LISP from a security viewpoint, and it is worth noticing that the LISP specifications already offer an authentication mechanism for mappings registration [RFC6833]. This mechanism, combined with LISP-SEC [LISP-SEC], strongly mitigates threats in non-trustable environments such as the Internet. Moreover, an authentication data field for Map-Request messages and Encapsulated Control messages was allocated [RFC6830]. This field provides a general authentication mechanism technique for the LISP control plane that future specifications may use while staying backward compatible. The exact technique still has to be designed and defined. To maximally mitigate the threats on the mapping system, authentication must be used, whenever possible, for both Map-Request and Map-Reply messages and for messages exchanged internally among elements of the mapping system, such as specified in [LISP-SEC] and [LISP-DDT]. Systematically applying filters and rate limitation, as proposed in [RFC6830], will mitigate most of the threats presented in this document. In order to minimize the risk of overloading the control plane with actions triggered from data-plane events, such actions should be rate limited. ) but this doesn't specifically address the fact that a pull-based control plane will fail in a different way, and one that is potentially harder to diagnose, from a push-based one. One area in which it differs is that a loss of a BGP session followed by a network partition is obvious to all users trying to move traffic between those two networks, while choking off control plane traffic in LISP may only affect some endpoints in a mysterious way. Kyle On Tue, Sep 11, 2018 at 5:17 AM, Luigi Iannone wrote: > Hi Kyle, > > good for you having a break, hope you enjoyed your vacation. > > Any thoughts about my last email on the subject? > > Ciao > > L. > > > On 11 Sep 2018, at 04:13, Kyle Rose wrote: > > Apologies for the two-week absence: I've been on vacation (especially fro= m > email) for most of that period. > > On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacci > wrote: > >> > The whole point of LISP is to create a routing overlay for the EID >> address space, the RIB of which is managed by a global mapping system, n= ot >> BGP sessions. If control plane traffic managed by BGP (or static routes,= or >> whatever networks use once the DFZ RIB is limited to entities in the cor= e) >> continues to flow, that is of small comfort to end users trying to get d= ata >> over the data plane. From the perspective of end users, BGP is being >> replaced routing of the traffic that matters to them. >> >> That really is not true. You need both the overlay and underlay to get >> user traffic to flow. >> > > Sure, just like you need link layer connectivity and closed circuits. Use= r > traffic is directly handled by the overlay, which is an added layer of > novel complexity. When you add complexity, you inevitably add room for bu= gs > and mysterious behavior. Anyway, I'm happy to drop this point for secdir > because this is more of a general architectural observation than somethin= g > specifically related to security. > > >> > * It does not resolve the trust anchor problem. Instead of proposing = a >> PKI, you seem to be proposing a trusted third party authoritative for th= e >> Hash-EID namespace. (Q.v. section 2, the Hash-EID definition: "Another >> entity=E2=80=9D) >> >> The trust anchor is the mapping system. And that is the PKI. And the >> mapping system is distributed. >> > > What PKI? That's part of what I'm trying to establish. How do entities > decide to trust each other? > > E.g., if entity A has pairwise trust with peer B, but needs an EID mappin= g > for peer C, it needs some way to establish that the replies it's supposed= ly > receiving from C are genuine. One popular model enabling you to do that > without employing transitive trust is end-to-end signing chained to a tru= st > anchor. With TLS as deployed on the web today, the trust anchors are a se= t > of mostly mutually agreed-upon CA certificates that serve as roots for th= e > certificates presented by every public web server. There are of course > issues with this model (q.v., certificate transparency, Symantec), but it= s > behavior is well-established and its properties are understood. What is t= he > equivalent here? > > It sounds like the answer here is mapping system-specific. E.g., from a > quick perusal of the DDT draft, it sounds very DNSSEC-like (which might > suggest a course of action to eliminate the need to develop, deploy, and > maintain a custom security protocol, but that is a different discussion). > > Where an interface is described without reference to a specific > implementation, a set of assumptions (e.g., "correct routing relies on th= e > authenticity of mapping system responses") and associated security > requirements for any conforming mapping system (e.g., "entities making us= e > of mapping system responses must have some way to authenticate them that > does not rely on transitive trust") need to be stated for the document to > be a complete description of a system component. That is, without first > clearly defining the required properties of any valid implementation of > described interfaces, there's no way to evaluate whether the component > under review will do what it's supposed to. > > A good place to put these assumptions and requirements is in the security > considerations section: those statements are not normative for the system > component described by the draft in which they appear, but are effectivel= y > requirements for whatever system component is to implement that interface > in a conforming way. Enumerating them as such (in the document describing > the interface in detail) allows the reader to evaluate the requirements i= n > light of the system using the interface, while also providing a convenien= t > checklist for those designing conforming systems. > > A set of well-crafted security considerations sections also makes it much > easier for a reviewer to understand the security of the system as a whole > without having to understand the details of every implementation, and to > verify that individual system components under review will have the > appropriate behavior. > > I'm going to skip the comments related to draft-farinacci-lisp-ecdsa-auth= , > just to limit scope here. We can get back to it once that document has be= en > adopted and more fully fleshed-out. > > > "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed: >> >> Right as I explained DTLS does. >> > > Check again. Just to be sure, I've tried several tools and the letters > "T", "L", and "S" do not appear consecutively anywhere in this document. > Neither do "SSL" nor "transport-level security". > > >> > I would like to see a discussion of whether and how the nature and >> scale of this problem differs from that of the status quo. BGP sessions = and >> RIB push have properties that are well-established from decades of >> experience: surely LISP does not have exactly the same properties. The >> security considerations should make clear, for instance, how a loss of >> control plane connectivity differs from the loss of a BGP session, and h= ow >> this impacts visibility and behavior of the data plane. >> >> Please look at the deployment drafts. Please note, you are reviewing a >> document that is focusing on encapsulating packets on an overlay. All th= e >> other support pieces are broken out, in what the WG felt was logical, in >> sepreate documents. >> > > I think this gets back to the point I made at the end of my original > review, which is that this system is difficult to evaluate from a securit= y > perspective in a piecewise manner given the dependencies between the > different layers and the lack of explicitly-enumerated security > requirements for each system component implementing a given interface. > > Kyle > > > --00000000000026e15b05759b3ef0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that the fi= rst point is probably not secdir-related, but it is still something that sh= ould be addressed.

To the second point re: RFC 783= 5 and resource attacks on control vs. data plane, what I want to see is an = analysis for operators of novel attack vectors that are created by LISP. Fo= r instance, the threat mitigation section says:

q(= The control plane is the most critical part of LISP from a security
=C2= =A0=C2=A0 viewpoint, and it is worth noticing that the LISP specifications<= br>=C2=A0=C2=A0 already offer an authentication mechanism for mappings regi= stration
=C2=A0=C2=A0 [RFC6833].=C2=A0 This mechanism, combined with LIS= P-SEC [LISP-SEC],
=C2=A0=C2=A0 strongly mitigates threats in non-trustab= le environments such as the
=C2=A0=C2=A0 Internet.=C2=A0 Moreover, an au= thentication data field for Map-Request
=C2=A0=C2=A0 messages and Encaps= ulated Control messages was allocated [RFC6830].
=C2=A0=C2=A0 This field= provides a general authentication mechanism technique for
=C2=A0=C2=A0 = the LISP control plane that future specifications may use while
=C2=A0= =C2=A0 staying backward compatible.=C2=A0 The exact technique still has to = be
=C2=A0=C2=A0 designed and defined.=C2=A0 To maximally mitigate the th= reats on the
=C2=A0=C2=A0 mapping system, authentication must be used, w= henever possible, for
=C2=A0=C2=A0 both Map-Request and Map-Reply messag= es and for messages exchanged
=C2=A0=C2=A0 internally among elements of = the mapping system, such as specified in
=C2=A0=C2=A0 [LISP-SEC] and [LI= SP-DDT].

=C2=A0=C2=A0 Systematically applying filters and rate limit= ation, as proposed in
=C2=A0=C2=A0 [RFC6830], will mitigate most of the = threats presented in this
=C2=A0=C2=A0 document.=C2=A0 In order to minim= ize the risk of overloading the control
=C2=A0=C2=A0 plane with actions = triggered from data-plane events, such actions
=C2=A0=C2=A0 should be ra= te limited. )

but this doesn't specifically ad= dress the fact that a pull-based control plane will fail in a different way= , and one that is potentially harder to diagnose, from a push-based one. On= e area in which it differs is that a loss of a BGP session followed by a ne= twork partition is obvious to all users trying to move traffic between thos= e two networks, while choking off control plane traffic in LISP may only af= fect some endpoints in a mysterious way.

Kyle
<= /div>

On Tue, Sep 11, 2018 at 5:17 AM, Luigi Iannone <= ggx@gigix.net> wrote:
Hi Kyle,

good for yo= u having a break, hope you enjoyed your vacation.

= Any thoughts about my last email on the subject?

C= iao

L.


On 11 Sep 2018, at 04:13, Kyle Rose <krose@krose.org> wrote:
<= br class=3D"m_-8526680949437643856Apple-interchange-newline">
Apologies for the two-week absence: I've= been on vacation (especially from email) for most of that period.

On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacci <fa= rinacci@gmail.com> wrote:
<= span class=3D"m_-8526680949437643856gmail-">> The whole point of LISP is= to create a routing overlay for the EID address space, the RIB of which is= managed by a global mapping system, not BGP sessions. If control plane tra= ffic managed by BGP (or static routes, or whatever networks use once the DF= Z RIB is limited to entities in the core) continues to flow, that is of sma= ll comfort to end users trying to get data over the data plane. From the pe= rspective of end users, BGP is being replaced routing of the traffic that m= atters to them.

That really is not true. You need both the overlay and underlay to g= et user traffic to flow.

Sure, just lik= e you need link layer connectivity and closed circuits. User traffic is dir= ectly handled by the overlay, which is an added layer of novel complexity. = When you add complexity, you inevitably add room for bugs and mysterious be= havior. Anyway, I'm happy to drop this point for secdir because this is= more of a general architectural observation than something specifically re= lated to security.
=C2=A0
>=C2=A0 * It does not resol= ve the trust anchor problem. Instead of proposing a PKI, you seem to be pro= posing a trusted third party authoritative for the Hash-EID namespace. (Q.v= . section 2, the Hash-EID definition: "Another entity=E2=80=9D)

The trust anchor is the mapping system. And that is the PKI. And the= mapping system is distributed.

What PK= I? That's part of what I'm trying to establish. How do entities dec= ide to trust each other?

E.g., if entity A has pai= rwise trust with peer B, but needs an EID mapping for peer C, it needs some= way to establish that the replies it's supposedly receiving from C are= genuine. One popular model enabling you to do that without employing trans= itive trust is end-to-end signing chained to a trust anchor. With TLS as de= ployed on the web today, the trust anchors are a set of mostly mutually agr= eed-upon CA certificates that serve as roots for the certificates presented= by every public web server. There are of course issues with this model (q.= v., certificate transparency, Symantec), but its behavior is well-establish= ed and its properties are understood. What is the equivalent here?

It sounds like the answer here is mapping system-specific.= E.g., from a quick perusal of the DDT draft, it sounds very DNSSEC-like (w= hich might suggest a course of action to eliminate the need to develop, dep= loy, and maintain a custom security protocol, but that is a different discu= ssion).

Where an interface is described without re= ference to a specific implementation, a set of assumptions (e.g., "cor= rect routing relies on the authenticity of mapping system responses") = and associated security requirements for any conforming mapping system (e.g= ., "entities making use of mapping system responses must have some way= to authenticate them that does not rely on transitive trust") need to= be stated for the document to be a complete description of a system compon= ent. That is, without first clearly defining the required properties of any= valid implementation of described interfaces, there's no way to evalua= te whether the component under review will do what it's supposed to.

A good place to put these assumptions and requiremen= ts is in the security considerations section: those statements are not norm= ative for the system component described by the draft in which they appear,= but are effectively requirements for whatever system component is to imple= ment that interface in a conforming way. Enumerating them as such (in the = document describing the interface in detail) allows the reader to evaluate = the requirements in light of the system using the interface, while also pro= viding a convenient checklist for those designing conforming systems.
=

A set of well-crafted security considerations sections = also makes it much easier for a reviewer to understand the security of the = system as a whole without having to understand the details of every impleme= ntation, and to verify that individual system components under review will = have the appropriate behavior.

I'm going t= o skip the comments related to draft-farinacci-lisp-ecdsa-auth, just t= o limit scope here. We can get back to it once that document has been adopt= ed and more fully fleshed-out.

> "TLS" does not appear anywhere in the draf= t of LISP-SEC I reviewed:

Right as I explained DTLS does.

= Check again. Just to be sure, I've tried several tools and the letters = "T", "L", and "S" do not appear consecutively= anywhere in this document. Neither do "SSL" nor "transport-= level security".
=C2=A0
=
> I would like to see a discussion of whether and how the nature and sca= le of this problem differs from that of the status quo. BGP sessions and RI= B push have properties that are well-established from decades of experience= : surely LISP does not have exactly the same properties. The security consi= derations should make clear, for instance, how a loss of control plane conn= ectivity differs from the loss of a BGP session, and how this impacts visib= ility and behavior of the data plane.

Please look at the deployment drafts. Please note, you are reviewing= a document that is focusing on encapsulating packets on an overlay. All th= e other support pieces are broken out, in what the WG felt was logical, in = sepreate documents.

I think this gets b= ack to the point I made at the end of my original review, which is that thi= s system is difficult to evaluate from a security perspective in a piecewis= e manner given the dependencies between the different layers and the lack o= f explicitly-enumerated security requirements for each system component imp= lementing a given interface.

Kyle

--00000000000026e15b05759b3ef0-- From nobody Tue Sep 11 09:57:18 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31771124BE5; Tue, 11 Sep 2018 09:56:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yJHpRKdXDy6L; Tue, 11 Sep 2018 09:56:52 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 2EFF4130F0F; Tue, 11 Sep 2018 09:56:52 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id b11-v6so12537958pfo.3; Tue, 11 Sep 2018 09:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vb2pwHTPakpIw9AeIdXU3iHbXJjZgAedb3A6VO4p3tI=; b=BonI908U8DqsV4EKB+sBQN8QYEcnBEznAbt6uKC89E3jna8KUxVhyccB2mHHmJmtQD EhwXpgTUH+qI0NJamdamfLiEs8UQokFElP0ATSxVhOjyRnGVT4RFwOn1mjA5Iy8BhFCG +KaeUG7ijmHIap4jIvSt8OkVeqp2cUgX1+03UY/gsmvBonSIXUkgHJdCLNQKUMbCed5V beBPg0jZGCy0nrs6E/iGd0ebfdRCqvH37CuZ4/abXPCRF6rDfPVzoDwo4MxePtPm+dfs bACjVllRu3PFhnPXl340jkrU6qrEpIiiRYk6abVubCFuYSKB0bNFNRFn4wzlQzc7YVsm eBZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vb2pwHTPakpIw9AeIdXU3iHbXJjZgAedb3A6VO4p3tI=; b=UaLhyXgsN+UJOZZ7Ga/ta9m4b7h0bD3nRkmjPYxC07w83Qy3fssQukTMlWWY2PbFAC +DqK2wZaR2u+RLMqLPYrvMTff0XQk0CXuvYTgDJQIKoHvZMAh6uPLjfXkQRqSlUUhR84 qp4yxKYmUmuE8GUW9IdCoQ/6hDzOvi9/fxeC5nOqV7IYLvDlDPeVmhtOAs7IdNaiKuRb 0P8BlN4Yg43S+AwtHwJN1xwJFIxo9ETJGMSXR6V4Cc7sWQkF8I7u2bI9OG63bUwFBKtH rMyc5F8rIgqzuuW35jXMf7Ypk9I+bgYMfj6ntB8bGVNAXUMYRhINcwfmV0g5fvfs3IC8 9rRQ== X-Gm-Message-State: APzg51ARLRpcLkYiTpUgX5se/BVPIe4zLXkVmwaWCrSkAVy5QoaXUtnS nbNQEHkNW14b589ugXlWIqs= X-Google-Smtp-Source: ANB0VdYsJZ7wEBHUQBxSuoPbmVKvt8zSTb3WXmIl38BEhKoj9D2AIA5k0sWHtsK7GtUR5a/i6UZm2A== X-Received: by 2002:a65:5304:: with SMTP id m4-v6mr29746960pgq.250.1536685011575; Tue, 11 Sep 2018 09:56:51 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id r87-v6sm44078833pfb.1.2018.09.11.09.56.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 09:56:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 09:56:49 -0700 Cc: IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk , =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Transfer-Encoding: quoted-printable Message-Id: <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> To: Kyle Rose X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 16:56:55 -0000 On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci = wrote: > > E.g., if entity A has pairwise trust with peer B, but needs an EID = mapping for peer C, it needs some way to establish that the replies it's = supposedly receiving from C are genuine. One popular model enabling >=20 > The mapping system allows all of A-C to trust each other. >=20 > Explain how with a detailed example, or point me to a detailed = explanation in a specific document. The mechanism is still not entirely = clear to me. If A and C don't have an established business relationship, = how does A know that the responses it's getting for EID mappings owned = by C are genuine and not modified by B? This is a critical property of = the system, and so it needs to be made obvious to the reader. (1) A, B, and C register their mappings to the mapping system. They have = a trust relationship with each of their respective map-servers. (2) Those map-servers, who participate in the same mapping system and = know about each other via LISP-DDT delegations, can sign referrals to = tell map-resolvers that A uses to look up mappings for B and C can trust = the map-servers of B and C. (3) The map-servers can proxy-reply with the mappings for B and C to A. = Or B and C can Map-Reply specifically with signed Map-Replies according = to draft-ietf-lisp-sec. Do I need to say more? > I agree with, and am not taking issue with, modularity: no one wants a = monolithic design for something I was talking about the docments being modular (but the design is = obviously so as well). > this complex. But the interfaces between the documents, by which I = mean the requirements they impose on each other, must be made explicit. = When a system achieves complexity warranting design modularity, it=E2=80=99= s And they should be by how the reference each other. If you think there = is text that makes assumpiton without a reference to the particular = draft, then we can add it.=20 > simply not sufficient to describe individual system components without = providing a framework for analyzing how they fit together without having = to read and fully understand all of it. All the information *might* in = fact be there, but as an outsider not implementing LISP, and with finite = time to review, asking me to understand the minutiae of the entire LISP = ecosystem in order to understand the security properties of the overall = system is simply not reasonable. I should be able to consume a = high-level architectural overview, containing sufficient detail to = understand the security properties of the overall system, and then use = that to drill into areas of concern more deeply. This is why I want the = high-level security requirements documented somewhere, along with a set = of high-level explanations of how the proposed system components combine = to satisfy them. Yes, understand. The LISP design, especially the security design, as = evolved over 10 years. So having continuity over that long period of = time with work items as well as people has been challenging. And with = the IETF process to boot, it was more difficult. I=E2=80=99m sure you = understand this. The best I can offer is, that you tell us where you are confused at a = point in the text and we add text to clarify it. But the problem we have = is that the IETF process will not allow us to reference documents that = are more inmmature than the document referencing it. > Put another way: as someone whose day job it is to read and review = design documents and to offer architectural consulting on everything = from from network architecture and hardware design to build automation = and SDLC tools to dynamic job orchestration and application security, = being able to achieve a high-level mental picture of the critical = properties of a design is an important first step in evaluating a = system's fitness for a particular task. Document authors have a = responsibility to make their work consumable by people who don't already = have the full context. Well, we have, and each generation of people that come along want more = changes and more consumability We are doing the best we can given the = existing parameters, for a decade. ;-) So I suggest, you look at something and say =E2=80=9CI think this is a = bug=E2=80=9D, or =E2=80=9CI see something missing here, is there a = design and does it need a reference=E2=80=9D. I don=E2=80=99t know, = that=E2=80=99s the most practical way I can see moving forward. I think we are going to have the same issues/recommendations for = Mirja=E2=80=99s comments as well. Dino From nobody Tue Sep 11 10:00:38 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D64130E5F; Tue, 11 Sep 2018 10:00:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153668523718.16843.5793905560643442682@ietfa.amsl.com> Date: Tue, 11 Sep 2018 10:00:37 -0700 Archived-At: Subject: [lisp] I-D Action: draft-farinacci-lisp-name-encoding-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 11 Sep 2018 17:00:37 -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 WG of the IETF. Title : LISP Distinguished Name Encoding Author : Dino Farinacci Filename : draft-farinacci-lisp-name-encoding-06.txt Pages : 5 Date : 2018-09-11 Abstract: This draft defines how to use the AFI=17 Distinguished Names in LISP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-farinacci-lisp-name-encoding/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-farinacci-lisp-name-encoding-06 https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-name-encoding-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-farinacci-lisp-name-encoding-06 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 Tue Sep 11 10:11:31 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC396130EDF; Tue, 11 Sep 2018 10:11:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gYmEMbGr89OW; Tue, 11 Sep 2018 10:11:28 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 D8D98130EDB; Tue, 11 Sep 2018 10:11:27 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id f6-v6so11641146plo.1; Tue, 11 Sep 2018 10:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sKCjNHSLw2CR962a/4A9846/i1bDAFle5yAzogvd+8A=; b=P1l/QAWyiqydtxbbMes8QzIRkUJa8HJhrFXAmMPV+DEBHr1JtoNQzHUxoaKKQsUkX9 a82ZU/7R2Piy9XZUlnXJ34aBswT9k3VZso+9soki6aDDt7WDxJ4xw1BeKY+hUCBusGgw xiDSc3HYi6nO05fWFoIjgQhqH/Cy3DiezNTdpRq8to5SoEpVcDzuLNMz8ciUbfVrMSS+ YtUxHz2XJ1dh6cxXpWbFCQVGAcTbNXOgh0cXwxQxjiK21C5tRTThugsN+jOoAKt1gQ9j yQ5q34cpSUTcvZYMk/EXfDoxv6Ymll5cN9R5SaMOrGT9T6v87PZvuDO4nxRuEUmSWEIN pcfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sKCjNHSLw2CR962a/4A9846/i1bDAFle5yAzogvd+8A=; b=XRohv2pikEcq2R7WmaVV7I98nKpj4gY3wn9zO4aMjpS2teXdbO93SaRrsvvDCuJIkB fTctegXvHkPhiIwP6ZV26s0cAiFM7GCJXVDPIHoc7nQWnEnfsNJBmsYWqkKDlMHJ5PlJ 8N/xCsTYi1lHUzT+B0ClmLFEHhkt6v0JHq1xttFCjidQ7lusb1R8yVcjHGKqxszz3BVD z+8aNA5z81qmjc1EiyI2h0sj2fJxYOntqfXkI358768eBrA65e42QT8+KGd5Y9vrkPrA MLc6+Z7xuBfV6AuZ7xBW/G6NyD5QWVa9o7xJ96M/Ex8GUjIro3hfqQUqAKG43+gM8d1p gYnw== X-Gm-Message-State: APzg51DC+yumWZSRdTjMACLoRf/Eo5vnIZhT1KcoPDfoXb8QLPBg6Vk5 xTAW9p66JU6v13rfS/xU+G8= X-Google-Smtp-Source: ANB0VdaK8B/50WVjFAnJv1uLA1Qa5q1cnmh/06FujepCHoB2vBDQw7/tmBB+f8cF+OS2Z5dQHLnxhw== X-Received: by 2002:a17:902:2e83:: with SMTP id r3-v6mr28326760plb.80.1536685887443; Tue, 11 Sep 2018 10:11:27 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id j27-v6sm34749919pfj.91.2018.09.11.10.11.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 10:11:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 10:11:25 -0700 Cc: Luigi Iannone , IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <6546936B-3AFD-47C4-8A27-8298DDDBBA09@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <77109099-A756-4563-968C-5AC17FF38291@gigix.net> To: Kyle Rose X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 17:11:30 -0000 > but this doesn't specifically address the fact that a pull-based = control plane will fail in a different way, and one that is potentially = harder to diagnose, from a push-based one. One area in which it differs = is that a loss of a BGP session followed by a network partition is = obvious to all users trying to move traffic between those two networks, = while choking off control plane traffic in LISP may only affect some = endpoints in a mysterious way. IMO, a feature and not a bug. And arguably harder to diagnose makes it = more secure. Dino From nobody Tue Sep 11 10:30:45 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1005130EDF for ; Tue, 11 Sep 2018 10:30:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 QDicx4cEmxSK for ; Tue, 11 Sep 2018 10:30:42 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 33B35124D68 for ; Tue, 11 Sep 2018 10:30:42 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id z8-v6so29077509qto.9 for ; Tue, 11 Sep 2018 10:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0Ykstjgvjv+xWHoVjK9RkGrKiHMyLapiP8v8g/vu6ec=; b=Cja/sRXzP1h9yIC3h5a64K2zqkqeSHIbPP7zlmsL/CH6StWQE39JpGQsibru6lTs2c lIFUreGZvSjQFMi6HwplKvvavpMrkW+J2J/crMKWcdUPf/MHJwzPmBxqGqhmJZLLihZg aMWpe63Sc0+5NWm8U4opWtrPF65SpBqgnO5Qw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0Ykstjgvjv+xWHoVjK9RkGrKiHMyLapiP8v8g/vu6ec=; b=I6PhQTST2yqc5NSpubdHF90/ncThOruXnte0Fkx/zBQFpyBvNq2hgCd6T4YRkBcWUw LtEoll3SCsR3Uphqee7H/dtgNj6KEnBQhkEpZaRsx9ZFW/1mUIgphDjX1GyMnFc9fYdN PyHDWbj3zGUBeZm/z3qQGpQFSQ1X+FKY3iBg7mZt4KNqkJAAAt6X7TNGLW/hlG+bECVX YP/l9/3ZajpVWevTEwUd2ufWvxw/ILQi3xMEBQqpjt78fadXjze1ppHzhsBayLormuAi yu11Kjsg9dSQ3X0mgfBQvTux222Byv7fR1U1HTyQyZRhXOEyXUebps/qgI7Mi0IyS2dt ki2Q== X-Gm-Message-State: APzg51B/RaADnIg64W40vbqHUmqRxU5KFYLRFgSVb6MdTv6i5fXjSB1h fWasxr3UiXZl/PZbVub8bPKTVSoerzaIWejjZ2qo3Q== X-Google-Smtp-Source: ANB0VdZkRVHMw+sQKPsENXMwAV66RfzDbVWKAAEWnJKt6GSpKtgjWsiL0nztcWAawlbwRPBmvbxCR6+o8jmlirj0qnM= X-Received: by 2002:a0c:d5d3:: with SMTP id h19-v6mr19625084qvi.218.1536687041167; Tue, 11 Sep 2018 10:30:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 10:30:40 -0700 (PDT) X-Originating-IP: [2001:4878:a000:3000:7163:4dac:f91f:e5b5] In-Reply-To: <6546936B-3AFD-47C4-8A27-8298DDDBBA09@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <77109099-A756-4563-968C-5AC17FF38291@gigix.net> <6546936B-3AFD-47C4-8A27-8298DDDBBA09@gmail.com> From: Kyle Rose Date: Tue, 11 Sep 2018 13:30:40 -0400 Message-ID: To: Dino Farinacci Cc: Luigi Iannone , IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000038574e05759bd51d" Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 17:30:44 -0000 --00000000000038574e05759bd51d Content-Type: text/plain; charset="UTF-8" On Tue, Sep 11, 2018 at 1:11 PM, Dino Farinacci wrote: > > but this doesn't specifically address the fact that a pull-based control > plane will fail in a different way, and one that is potentially harder to > diagnose, from a push-based one. One area in which it differs is that a > loss of a BGP session followed by a network partition is obvious to all > users trying to move traffic between those two networks, while choking off > control plane traffic in LISP may only affect some endpoints in a > mysterious way. > > IMO, a feature and not a bug. And arguably harder to diagnose makes it > more secure. > Possibly. But being better or worse isn't my point, so much that it's *different* in a material way from a security perspective. Those deltas are where something proposing to supplant the prevailing mechanism for DFZ routing needs to be clear to operators. Kyle --00000000000038574e05759bd51d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Sep 11, 2018 at 1:11 PM, Dino Farinacci <farin= acci@gmail.com> wrote:
> but= this doesn't specifically address the fact that a pull-based control p= lane will fail in a different way, and one that is potentially harder to di= agnose, from a push-based one. One area in which it differs is that a loss = of a BGP session followed by a network partition is obvious to all users tr= ying to move traffic between those two networks, while choking off control = plane traffic in LISP may only affect some endpoints in a mysterious way.
IMO, a feature and not a bug. And arguably harder to diagnose makes = it more secure.

Possibly. But being better or worse i= sn't my point, so much that it's *different* in a material way from= a security perspective. Those deltas are where something proposing to supp= lant the prevailing mechanism for DFZ routing needs to be clear to operator= s.

Kyle

--00000000000038574e05759bd51d-- From nobody Tue Sep 11 10:36:56 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACB2130DC3; Tue, 11 Sep 2018 10:36:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 a3pJ_K6G2kWR; Tue, 11 Sep 2018 10:36:41 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 E0977124D68; Tue, 11 Sep 2018 10:36:40 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id h79-v6so12566185pfk.8; Tue, 11 Sep 2018 10:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNB3TgKAhyftnsk4CoZ0lWF+70fokZUoV4lIvfqII+E=; b=CVd2R0LCK/B0Mu4Slixif87C63y5jvrb1HYler8BCf0JguuR3MXrtY19aFp3c4WfGH VlBO0vO6VRuwXVd5pidRsQ55/eY0gcngD8iWEbBm5NMg9AwliN1nvnO2atd7kIUMANx7 pLsocImceBxD3VZiaDe6S6tVNBOOjneIYPaXuztu79MRSLFsNmk5IchiC6T9GXqXBkDb Lqs2Pik/YFsYRB9/2dZGgTLJq0biSRS3HOGZUipewrjOKfyQWx7tyKOOVYM9GneCAasU OOckYlMixWjAG4OBJn0fp7Pi4NoSjHTLcvTLFSNXbL5JQAXxjtWLFXk/7zRDWl3KXLGH dGFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNB3TgKAhyftnsk4CoZ0lWF+70fokZUoV4lIvfqII+E=; b=D2gXT9Ko6B2mms9SRCEO72lkhChcNJGWwRHJE8hFrdesfHDsIktiycMMeZkpX32d5N ldqFk3TJBsNQuKIB+vfNdhyhfZX8J9LvOGVNqflo8GJbdhgR5aBDYoQdvKRo0005J0hY feBFmGYHuAhbaMlZ3eRqVa9yhjUt1myHaXDiVk3BvVMCLN2srJJPKaQUPq82gzarDb1v xU2iEaeITtDVteAKo/dEqij2bV4R/DrIJw1MsiFyg1kIxMZfPlhw3T7VoS7zQPy7UfKr Vba3QkYN4/WV21+MjnHhTUNm98+bPxKjmrP78IiTAvdDugUsuj+B+ZN/RqwV00R4poPF dOxQ== X-Gm-Message-State: APzg51AuERgsX0wz2C8AtWUO/7AD0BLS4ZgI1gTzHdypFCG0PRA5RZxf BNhhxOwVYu7RMAAfGX/AE54= X-Google-Smtp-Source: ANB0VdY8tO3aSc7RjJzd7yaBS+X5rZC3z5eUZ0Qedz2dOhss3x4APkTlK58pIzmClgOJLrjVXw2AWA== X-Received: by 2002:a65:50c9:: with SMTP id s9-v6mr29729037pgp.417.1536687390407; Tue, 11 Sep 2018 10:36:30 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id y18-v6sm23145446pfl.90.2018.09.11.10.36.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 10:36:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 10:36:28 -0700 Cc: Luigi Iannone , IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <77109099-A756-4563-968C-5AC17FF38291@gigix.net> <6546936B-3AFD-47C4-8A27-8298DDDBBA09@gmail.com> To: Kyle Rose X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 17:36:43 -0000 We are not supplanting the mechanism for routing. There is a layer above = routing that can (1) pull like DNS, and/or (2) push like BGP to realize = an overlay. Dino > On Sep 11, 2018, at 10:30 AM, Kyle Rose wrote: >=20 > On Tue, Sep 11, 2018 at 1:11 PM, Dino Farinacci = wrote: > > but this doesn't specifically address the fact that a pull-based = control plane will fail in a different way, and one that is potentially = harder to diagnose, from a push-based one. One area in which it differs = is that a loss of a BGP session followed by a network partition is = obvious to all users trying to move traffic between those two networks, = while choking off control plane traffic in LISP may only affect some = endpoints in a mysterious way. >=20 > IMO, a feature and not a bug. And arguably harder to diagnose makes it = more secure. >=20 > Possibly. But being better or worse isn't my point, so much that it's = *different* in a material way from a security perspective. Those deltas = are where something proposing to supplant the prevailing mechanism for = DFZ routing needs to be clear to operators.=20 >=20 > Kyle >=20 From nobody Tue Sep 11 11:14:04 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B569C130EE7; Tue, 11 Sep 2018 11:13:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JWVjZoC4lbis; Tue, 11 Sep 2018 11:13:53 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 A63DB1292F1; Tue, 11 Sep 2018 11:13:53 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id s7-v6so12677831pgc.0; Tue, 11 Sep 2018 11:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U+5Q9dFq9A9CMe2Hinvh1wT0s40Nc4ikP9UNqEzDx+g=; b=sG1JdAxYqOOFOlc1viQubv6b7L84Cie0mCmHG2Tv77WD3sKAUIkxV/CVzCbbO28gut 2i4WTbJYJ2poUddobYww0jyZAUoqutdLXuwX/44jDfFHHgmROtnD+ZNzF2kT1qEMFR4C nVJEeQsP1pIGrNpSjqsnbF/mD7DeOti4+NLWC52MQYwu+Y9LgDi7UaKduYZNH5NhZ7gR Vre6MmU82WVWJeYI9vbIeUPwvp2I8IuA/hUjIpPzFVp+ETiFDMDcdw2wCPrNKxOpbdgs OkEvFbrQsVJRR6HPefCnI4ltkjX5TpZ2aBjmTaPqT44avb8mCT/qejpZ/jvzdHIYRh5Y pwkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U+5Q9dFq9A9CMe2Hinvh1wT0s40Nc4ikP9UNqEzDx+g=; b=q2S0MC5YzNcSJ52rEb9sUhti5ok7J4FvGrTZ/XC7ybThTHtXDmKg7vjpCruAmDHk5w 0pDZDZbVfGTxbVMimSd3bMq2pQVrSAJCWgr6SC2faeIMZAFThVccy4MkmbJtR7EPPJ77 IRHJDlssvakSURkrthq4ZgmnidjVtxJgNmoMxy4Vkjwu8Xdk3/UKsrAejaSvK1YemtdJ soo8twSBqQ/rvETjJN2l5yu1oXZKbjcNRbbow1rgxdrUaNXNmT7Rd9PpkiIS8s6XFwGC m+XbELa1QZfP3mYW2zagIg/tMfTLJxUnsGlwG2z9jFxKBP/9LDucMWOLuzmbUamdFHj0 MO8Q== X-Gm-Message-State: APzg51AJAcf1J6mDVWdKivS4NQ3etOj02aD9w6m4F5HBrv1qRp4B5BNa pTDb2y9Q1BY14U4VAD4ZnK4= X-Google-Smtp-Source: ANB0VdZIVXDXcOJa4AVoBJ5ei0+QxbIFGz+LMwArba8++pJj5+UAdpZUofB9XNto79D9asLTV8ZgAA== X-Received: by 2002:a62:9c17:: with SMTP id f23-v6mr30838228pfe.209.1536689633045; Tue, 11 Sep 2018 11:13:53 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id d24-v6sm23538163pgv.23.2018.09.11.11.13.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 11:13:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2018 11:13:51 -0700 Cc: The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, Dino Farinacci , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 18:13:57 -0000 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-lisp-rfc6833bis-13: 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 = https://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: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ Thanks again for your comments Mirja. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > 1) Versioning and backward compatibility >=20 > Section 5.2 says: "Support for requesting multiple EIDs in a single = Map-Request > message will be specified in a future version of the protocol." > However, there is no versioning mechanism for this protocol specified. = How is > versioning supposed to work? The multiple EID-record encoding is already spec=E2=80=99ed and is in = the protocol. And since Map-Requests are triggered by packet arrival or = network management tools, they tend to be sent for a single EID. What is = for further study is if a ITR would want the entire map-cache, so would = it request a set of aggregates and would a replier return all more = specifics for the aggregates requested. > Further given there is no new version, I wonder if the changes as = outlined in > section 10 are all backward-compatible? Especially for the = introduction of the > Message-Notify-Ack message, I guess there is no problem if a server = sends it, > however, as the sender of the Message-Notify message might not know if = the > other end supports sending of the Message-Notify-Ack it can't rely on = it. This > should be further discussed in the doc! Or is there another strategy = to achieve > backward compatibility? The Map-Notify-Ack has been there since day-1 in implementations. This = is just IETF catching up. And it took over 5 years. So we really don=E2=80= =99t have a compatibility situation. And didn=E2=80=99t want to create = one in the specifications. So consider it a day 1, version 1 message. It = really wasn=E2=80=99t added later. And big part of this push for standardization is to have the specs = =E2=80=9Ccatch up=E2=80=9D with the implementations. The implementations = are way further ahead than the specs. > 2) Size and MTU >=20 > As outlined in the TSV-ART review (Thanks Colin!) this document does = not > discuss fragmentation or Path MTU discovery. RFC8085 recommends to = either > perform Path MTU discovery or limit the message to 576 bytes for IPv4 = or 1280 > bytes for IPv6 (minus any static header). As this seems to be an = appropriate > size for LISP messages, I would recommend this approach. Relying on IP > fragmentation (as indicated in the reply to the TSV-ART review) is not > recommended by RFC8085 as this would lead to IP packet without a UDP = header, in > the case of LISP, which can cause problem and loss when NATs are = involved. In > any case the chosen approach needs to be further discussed in the doc. >=20 This is a data-plane feature so it is discussed in 6830bis and RFC6830. > 3) Rate-limiting and congestion control >=20 > Sec 5.3: "Map-Requests MUST be rate-limited. It is RECOMMENDED that a = Map- > Request for the same EID-Prefix be sent no more than once per = second." > As already noted by the TSV-ART review (Thanks Colin!), RFC8085 = actually > recommends to not send more the one packet per 3 seconds, and that is = a > restriction for all traffic not on a per-receiver base, or implement = congestion > control. This limit is meant to not only protect the receiver but also = the > network from overloading. Why do you use a smaller interval here? Also = if > (appropriate) rate limiting is used, this should either be a MUST or = more > explanation when it is okay to use a smaller rate limit should be = provided. > However, after all, I don't think you those the right approach here = for rate > limiting. A Map-Request is always expected to be followed by some = reply. For > these kind of communication pattern, RFC8085 recommends to limit the = number of > outstanding requests to 1 (see sec 3.1.1 of RFC8085 recommending one = packet per > RTT), also for all traffic and not only per receiver. However, this = would also > require to implement some simple mechanism to detect a message as lost = (see > also further below in point 4). We have referenced RFC8085 in the too be published -14 version of = 6833bis. > Similarly I'm not sure about the intent of this requirement in section = 5.5: > "Map-Replies SHOULD be sent for an EID-Prefix no more often than once > per second to the same requesting router. " > My understanding is that Replies are only sent when a request is = received. Why > is this additional rate limit needed? Again if used it should be 3 = seconds for > all traffic to be inline with RFC8085. Also again, why is that not a = MUST? > Further recommendation are needed here. Because the source is a bad-actor and sending new Map-Requests (with a = new nonce). > Further section 6.1 say "Both the SMR sender and the Map-Request = responder MUST > rate-limit > these messages. Rate-limiting can be implemented as a global rate- > limiter or one rate-limiter per SMR destination." > This seems to be the same rate limit as mention above, or not...? It = would > probably make sense to rate limit the SMR even further. Please clarify = and > provide more guidance, e.g. what should the value of a potential = additional > rate limit for SMR be? Some of this machinery is left to the implementor. But we have published = some map-cache management guidelines in the lisp-threat RFC. > Respectively the following sentence in section 6.1 is also unclear: > "The remote ITR MUST rate-limit the Map-Request until it gets a = Map-Reply" > Why is the rate-limit as currently proposed depend on the fact if a = Map-Reply > is received? Is the ITR supposed to retransmit the Map-Request=E2=80=A6?= If you are not getting answers to your Map-Requests because of packet = loss or MITM, sending them faster is not going to get you a Map-Reply. > And finally the Map-Register, Map-Notify and Map-Notify-Ack messages = does not > seem to have any rate-limits. Recommendations inline with RFC8085 = should be > provided for the total traffic and not only for a few message types. = Again, > Map-Notify and Map-Notify-Ack messages should be send only once per = RTT as > there is a feedback mechanism. We have added that in -14. > For Map-Register sec 8.2 say: "Map-Register messages are sent = periodically from > an ETR to a Map- > Server with a suggested interval between messages of one minute." > However, this a rather a low bound than an upper bound. A required = (MUST) rate > limit is still needed. That is not rate-limiting to avoid message reduction. It is a soft-state = way of keeping registration state alive in the map-server(s). > 4) Loss detection and retransmission >=20 > As also mention by the TSV-ART review (Once more thanks to Colin!), = this spec > has an ACK mechanism for Map-Requests and now also for Map-Notify, = however, it And Map-Notify are acks to Map-Registers when requested. > does not specify what to do if the ACK is not received (loss detection = and > retransmission scheduling). This makes the spec incomplete and needs = to be > further specified in the doc (and also has a relation to the point 3 = above of > course). We focus on why a Map-Request is being generated (to populate the = map-cache) and a Map-Reply not only provides information to be put in = the map-cache, but acts as an ackl now. If the Map-Request nonce is = being replied with a Map-Reply with the same nonce, Map-Requests no = longer need to be sent and the requestor is happy with the result (and = hence it was reliable). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Further comments: >=20 > 1) The example given in 5.5 should probably used IPv6 addresses and = use the IP > address space that is reserved for documentation purposes. I disagree. I think its simpler with IPv4 addresses and shouldn=E2=80=99t = matter. We want this complex concept to come across as clear as = possible. And I believe IPv6 doesn=E2=80=99t do that. This is not a v4 = versus v6 response. It is a notation preference. > 2) I find the security requirements in this doc very unsatisfying. = Most > important the doc requires the support of authentication mechanism but = not the > use of it. I would like to see more clear MUST requirements here. = Further, > today and at this stage of the protocol (moving from exp to PS) I find = it not > acceptable anymore to have certain security feature as optional and = outsourced > into a different work-in-process draft. However, I leave further = discussion to > the SEC ADs. Can you cite where this is a problem. Are you saying we are not = supplying enough MUST text? > 3) Given the following statement: > "Note that while this document assumes a LISP-ALT database mapping > infrastructure to illustrate certain aspects of Map-Server and Map- > Resolver operation..." > it seems that RFC6836 should be a normative reference, as it might not = be > possible to understand all details explained in this doc with knowing = ALT. I would like the lisp-chairs and/or Deborah to comment on this. > 4) Further I would also think that I-D.ietf-lisp-mn and = I-D.ietf-lisp-pubsub > should be normative references as the meaning of the respective bits = it not > further specified in this doc. Or can these bits just be ignored if > I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so = that > should be stated. I would like the lisp-chairs and/or Deborah to comment on this. > Clarification questions: > 1) Sec 5.3.: > "For the initial case, the destination IP > address used for the Map-Request is the data packet's destination > address (i.e., the destination EID) that had a mapping cache lookup > failure." > Does that mean that the Map-Request needs to use the IPv4 or IPv6 = depending on > the IP version used by the initial message from the EID. Is that = always the > case or just for this initial message? I would assume that for all = other cases > this is actually independent...? Because otherwise there would be a = constraint > on what needs to be requested. I would like t see further = clarification about > this in the doc. No it doesn=E2=80=99t. It depends on the address-family of the = map-resolver. And that is configured. > 2) In section 5.3: "The ITR MAY include all locally > configured Locators in this list or just provide one locator address > from each address family it supports." > Would it make sense to include a SHOULD requirement to at least the = address > family that is used to send the Request is included (to increase = chance to > enable a communication/get a reply)=E2=80=A6? But all address-families are used all the time. And in some ITRs, = usually there is no IPv6 at the edge.=20 > 3) Sec 5.4: "If all Weights for a Locator-Set are equal, > the receiver of the Map-Reply will decide how to load-split the > traffic. " > Shouldn't the receiver in this case split the traffic equally? = Otherwise how > would you signal that the traffic should be split equally? Maybe use = all zero > instead to let the receiver decide=E2=80=A6? It means the ITR will load-split according to hashing. Versus if the = priorities are not equal, it is the ETR deciding how packets ingress the = LISP site. > 4) sec 6.1: "When an ITR receives an SMR-based Map-Request for which = it does not > have a cached mapping for the EID in the SMR message, it may not = send > an SMR-invoked Map-Request." > I guess this should be normative and probably also a MUST NOT or at = least > SHOULD NOT. Yes, I changed to SHOULD NOT. Good catch. Don=E2=80=99t want to make it = a MUST NOT because both sides could be mobile and the remote side may = need to populate its map-cache. That would allow less packet loss if we = keep it SHOULD NOT versus MUST NOT. > 5) Section 7 seems to imply that if it is detected that no route is = available, > the ITR should basically do nothing and just drop any incoming packets = for that > ETR. Would it make sense for incremental deployability, to just = forward the > packet to the IP address of the EID instead...? This way the source = host would Well no. Because the EID most likely doesn=E2=80=99t have a route in the = underlying routing system. If there are PITRs out in the core, then the = ITR will be configured to know that, a negative map-reply causes those = PITRs to be used or PITRs are registering for coarse EID-prefixes. > not benefit in mobility cases but still gets connectivity otherwise. = Or is that > anyway not the implication? If that is the case, that should be = further > clarified in the doc. The point you are bringing up is discussed in the LISP interworking = document (RFC 6832), FYI. > 6) Section 8.2 says: "Note that the Map-Notify message > is sent to UDP destination port 4342, not to the source port > specified in the original Map-Register message." > Actually why is that? cisco interperability. > Some minor editorial comments: >=20 > 1) First sentence in intro: the pointer to ietf-lisp-introduction as = currently > introduced, makes this reference look very normative: "The Locator/ID > Separation Protocol [I-D.ietf-lisp-introduction] and = [I-D.ietf-lisp-rfc6830bis] > specifies..." I would recommend the following wording: "The Locator/ID > Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see also > [I-D.ietf-lisp-introduction]) specifies=E2=80=A6" Good recommendation. Thanks. Changed. > 2) Also in intro: Given that 6830bis is a normative reference "LISP = RFC > 6830bis" should be replaced with the new RFC number in the text. This = should be > noted to the RFC editor; probably this is more obvious if RFCXXX is = used > instead. What are you suggesting. A bracketed comment inline? > 3) Sec 5.4: "...for another way the R-bit MAY be used." > This looks like a lower case may would be more appropriate. We fixed a bunch of incorrect capitalized MAYs and SHOULDs. Thanks again, Dino From nobody Tue Sep 11 11:20:56 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66675130EDF for ; Tue, 11 Sep 2018 11:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MSvSS3zgaSLx for ; Tue, 11 Sep 2018 11:20:47 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 9FFAF1292F1 for ; Tue, 11 Sep 2018 11:20:47 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id l9-v6so12634717pff.9 for ; Tue, 11 Sep 2018 11:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=KGea5ye7Vfb8e219mJ7DijOQlUlLo79J0NMj74fYazc=; b=a2gOkvcWqfsMBmSoUITLYMmegCXkMlFWO8dUhOneUJ4Poa/Z7qYTz9uzyrr5QO+6Co T58uvYmglLDm4oJpvJtNR4847+if4UthOPLTc248yXjGbtU04arFYKIx0r2su4oUIQXE Pu52O0bk2VtOVoyHP06RZmrXetaJrD/LJAKUZR0mB4SQvakRB6GPvEkZyTTTDmLRta3k JKPOgFik2PjiYiPcl1aOr8is27ZVdlXQnFbS9S4yXNhF9HJ07lWM+HDA4o4P/3tEOjGW mbx4r2/ZO305Rq35lmOBnevYLXau5t142xkbxbZTyvmc/EfjElgaaJR0W0RPOxKhjhWL HanA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=KGea5ye7Vfb8e219mJ7DijOQlUlLo79J0NMj74fYazc=; b=QUiW010ZtLTACY/5B/iA7KeiL5BTjB4gC645nymJ5dcipI06ew5f77VBCdXLOWMC6y mddDZrMC3hRhBZ3Gd85h44H2d0kZuEXs4N+agnqRungHxm540RtfUOqqNVIGrXOnJJjO ff3iXsqBCs3AQZOAkW/J0/d76LynsStug/FXuD/Mn4ZWnbPFZr7GbGXkmkA7fei10crd hGcfPfRHfqkL56Kuz2PmRuJvOTv7ol8UR+8C/Qd49O0d3Rd46aTOR8biaXpdMbkikqt4 pS5dfVQVo2pE9Mb9MFsuYRiOmb+luZHu8rMjFmA5L/xehwKVQCZVxVmi8/CgApdUmrB/ W+6g== X-Gm-Message-State: APzg51D7anLPxnh5KvpJ8dQmLHDSHfadBc7LRfCvYBRKRoMIjKFHnCVl N+alPt09FKWPpHYZ358Z8HkGcBVb X-Google-Smtp-Source: ANB0VdYiYlBtKUfGMKXHGkis4+Uuo5/wph0hJeK+dJc5pXcclgm/w1at0M58+XhpSXImlTYs5FUBMw== X-Received: by 2002:a62:435c:: with SMTP id q89-v6mr31324557pfa.135.1536690046926; Tue, 11 Sep 2018 11:20:46 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id 193-v6sm43975435pgh.47.2018.09.11.11.20.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 11:20:46 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/mixed; boundary="Apple-Mail=_9607CC9D-FF29-46EE-B465-C40B49B27314" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <0807FD44-48AE-468B-A6D1-D63B4FB1C240@gmail.com> Date: Tue, 11 Sep 2018 11:20:45 -0700 To: "lisp@ietf.org list" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [lisp] Going to submit draft-ietf-lisp-rfc6833bis-14 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 18:20:54 -0000 --Apple-Mail=_9607CC9D-FF29-46EE-B465-C40B49B27314 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 After looking at all of Alvaro, Mirja, and Kyle=E2=80=99s comments which = I have made changes to address some of them (as well as other ones that = were pending) and since the telechat has been moved out 2 weeks, I=E2=80=99= m going to publish draft-ietf-lisp-rfc6833bis-14 so the latest changes = are cached. Here is an enclosed diff. Submitting now. Thanks, Dino --Apple-Mail=_9607CC9D-FF29-46EE-B465-C40B49B27314 Content-Disposition: attachment; filename=rfcdiff.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-13.txt - = draft-ietf-lisp-rfc6833bis-14.txt=20 =20 =20 =20 =20 =20 =20 =
< draft-ietf-lisp-rfc6833bis-13.txt  =  draft-ietf-lisp-rfc6833bis-14.txt >
=
Network Working = Group V. Fuller = Network Working Group = V. Fuller
Internet-Draft = D. Farinacci Internet-Draft = D. Farinacci
Obsoletes: 6833 = (if approved) Cisco Systems = Obsoletes: 6833 (if approved) = Cisco Systems
Intended status: = Standards Track A. Cabellos (Ed.) = Intended status: Standards Track = A. Cabellos (Ed.)
Expires: February 25, 2019 = UPC/BarcelonaTech Expires: March 15, 2019 = UPC/BarcelonaTech
= August = 24, 2018 = September = 11, 2018
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-13 = = draft-ietf-lisp-rfc6833bis-14
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = Control-Plane service interface and communicating with By using this Control-Plane service interface and = communicating with
Map-Resolvers = and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and = Map-Resolvers and Map-Servers, LISP Ingress = Tunnel Routers (ITRs) and
Egress Tunnel = Routers (ETRs) are not dependent on the details of Egress Tunnel Routers (ETRs) are not dependent on the = details of
mapping = database systems, which facilitates modularity with different = mapping database systems, which facilitates = modularity with different
database = designs. Since these devices implement the "edge" of the = database designs. Since these devices = implement the "edge" of the
LISP = Control-Plane infrastructure, connect directly to LISP-capable = LISP Control-Plane infrastructure, connect = directly to LISP-capable
Internet end = sites, and comprising the bulk of LISP-speaking devices, = Internet end sites, and comprising the bulk = of LISP-speaking devices,
reducing their = implementation and operational complexity should also reducing their implementation and operational = complexity should also
reduce the = overall cost and effort of deploying LISP. reduce the overall cost and effort of deploying = LISP.
=
This = document obsoletes RFC 6833. This = document obsoletes RFC 6830 and = 6833.
=
Status of This = Memo Status of This Memo
=
This = Internet-Draft is submitted in full conformance with the = This Internet-Draft is submitted in full = conformance with the
provisions of = BCP 78 and BCP 79. provisions of = BCP 78 and BCP 79.
=
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on February 25, = 2019. This Internet-Draft will = expire on March 15, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 3, line 10 =C2=B6 = skipping to change at page 3, line 10 =C2=B6
11.2. LISP = Packet Type Codes . . . . . . . . . . . . . . . . . 38 = 11.2. LISP Packet Type Codes . . . . . . = . . . . . . . . . . . 38
11.3. LISP = ACT and Flag Fields . . . . . . . . . . . . . . . . 39 = 11.3. LISP ACT and Flag Fields . . . . . = . . . . . . . . . . . 39
11.4. LISP = Address Type Codes . . . . . . . . . . . . . . . . 39 = 11.4. LISP Address Type Codes . . . . . = . . . . . . . . . . . 39
11.5. LISP = Algorithm ID Numbers . . . . . . . . . . . . . . . 40 = 11.5. LISP Algorithm ID Numbers . . . . = . . . . . . . . . . . 40
=
12. References = . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. References . . . . . . . . . . . . . . . . . . . = . . . . . . 40
12.1. = Normative References . . . . . . . . . . . . . . . . . . 40 = 12.1. Normative References . . . . . . . = . . . . . . . . . . . 40
12.2. = Informative References . . . . . . . . . . . . . . . . . 41 = 12.2. Informative References . . . . . . = . . . . . . . . . . . 41
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 45 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 45
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 45 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 45
B.1. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 45 B.1. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 45
B.2. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 45 B.2. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 45
B.3. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 45 B.3. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 45
B.4. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 45 B.4. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 45
B.5. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 46 B.5. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 46
B.6. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 46 B.6. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 46
B.7. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 46 B.7. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 46
B.8. = Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 47 B.8. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . = 46
B.9. = Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 47 B.9. = Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 47
B.10. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 47 B.10. = Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 47
B.11. = Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 47 B.11. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 47
B.12. = Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 48 B.12. = Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 48
B.13. = Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 48 B.13. = Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 48
B.14. = Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 48 B.14. = Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 48
B.15. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48 = B.15. Changes to = draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 48
= B.16. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 49
=
1. = Introduction 1. Introduction
=
The = Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and = The Locator/ID Separation Protocol = [I-D.ietf-lisp-rfc6830bis] (see
= [I-D.ietf-lisp-rfc6830bis] specifies an architecture and = mechanism = also [I-D.ietf-lisp-introduction]) specifies an architecture = and
for dynamic = tunnelling by logically separating the addresses mechanism for dynamic tunnelling by logically = separating the
currently = used by IP in two separate name spaces: Endpoint IDs addresses currently used by IP in two separate name = spaces: Endpoint
(EIDs), used = within sites; and Routing Locators (RLOCs), used on the = IDs (EIDs), used within sites; and Routing = Locators (RLOCs), used on
transit = networks that make up the Internet infrastructure. To the transit networks that make up the Internet = infrastructure. To
achieve this = separation, LISP defines protocol mechanisms for mapping = achieve this separation, LISP defines = protocol mechanisms for mapping
from EIDs to = RLOCs. In addition, LISP assumes the existence of a from EIDs to RLOCs. In addition, LISP assumes the = existence of a
database to = store and propagate those mappings globally. Several database to store and propagate those mappings = globally. Several
such databases = have been proposed; among them are the Content such databases have been proposed; among them are the = Content
distribution = Overlay Network Service for LISP-NERD (a Not-so-novel distribution Overlay Network Service for LISP-NERD (a = Not-so-novel
EID-to-RLOC = Database) [RFC6837], LISP Alternative Logical Topology EID-to-RLOC Database) [RFC6837], LISP Alternative = Logical Topology
(LISP-ALT) = [RFC6836], and LISP Delegated Database Tree (LISP-DDT) (LISP-ALT) [RFC6836], and LISP Delegated Database = Tree (LISP-DDT)
= [RFC8111]. [RFC8111].
=
The LISP = Mapping Service defines two new types of LISP-speaking The LISP Mapping Service defines two new types of = LISP-speaking
=
skipping to = change at = page 4, line 28 =C2=B6 = skipping to change at page 4, line 31 =C2=B6
infrastructure = to illustrate certain aspects of Map-Server and Map- infrastructure to illustrate certain aspects of = Map-Server and Map-
Resolver = operation, the Mapping Service interface can (and likely = Resolver operation, the Mapping Service = interface can (and likely
will) be used = by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other = mapping database
systems as the = LISP infrastructure evolves. = systems as the LISP infrastructure evolves.
=
The LISP = Mapping Service is an important component of the LISP The LISP Mapping Service is an important component of = the LISP
toolset. = Issues and concerns about the deployment of LISP for toolset. Issues and concerns about the deployment of = LISP for
Internet = traffic are discussed in [I-D.ietf-lisp-rfc6830bis], Internet traffic are discussed in = [I-D.ietf-lisp-rfc6830bis],
[RFC7215], and = [I-D.rodrigueznatal-lisp-oam]. = [RFC7215], and [I-D.rodrigueznatal-lisp-oam].
=
This = document obsoletes RFC 6833. This = document obsoletes RFC 6830 and = 6833.
=
2. Requirements = Notation 2. Requirements = Notation
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
"SHOULD", = "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = "SHOULD", "SHOULD NOT", "RECOMMENDED", = "MAY", and "OPTIONAL" in this
document are = to be interpreted as described in [RFC2119] and document are to be interpreted as described in = [RFC2119] and
= [RFC8174]. [RFC8174].
=
3. Definition of = Terms 3. Definition of Terms
=
=
skipping to = change at = page 8, line 18 =C2=B6 = skipping to change at page 8, line 18 =C2=B6
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
| = LISP Message | | LISP Message = |
| = | | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
When a UDP = Map-Request, Map-Register, or Map-Notify (when used as a = When a UDP Map-Request, Map-Register, or = Map-Notify (when used as a
notification = message) are sent, the UDP source port is chosen by the = notification message) are sent, the UDP = source port is chosen by the
sender and the = destination UDP port number is set to 4342. When a sender and the destination UDP port number is set to = 4342. When a
UDP = Map-Reply Map-Notify (when used as an acknowledgement to a Map- = UDP Map-Reply, = Map-Notify (when used as an acknowledgement to a Map-
Register), or = Map-Notify-Ack are sent, the source UDP port number is Register), or Map-Notify-Ack are sent, the source UDP = port number is
set to 4342 = and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is = copied from the
source port of = either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking = data packet.
= Implementations MUST be prepared to accept packets when either = the Implementations MUST be = prepared to accept packets when either the
source port or = destination UDP port is set to 4342 due to NATs source port or destination UDP port is set to 4342 = due to NATs
changing port = number values. changing port number = values.
=
The 'UDP = Length' field will reflect the length of the UDP header and = The 'UDP Length' field will reflect the = length of the UDP header and
the LISP = Message payload. the LISP Message = payload.
=
=
skipping to = change at = page 9, line 19 =C2=B6 = skipping to change at page 9, line 19 =C2=B6
completeness, = this document references the LISP Shared Extension completeness, this document references the LISP = Shared Extension
Message = assigned by [RFC8113]. Message type definitions are: Message assigned by [RFC8113]. Message type = definitions are:
=
Reserved: = 0 b'0000' = Reserved: 0 b'0000'
LISP = Map-Request: 1 b'0001' LISP Map-Request: 1 = b'0001'
LISP = Map-Reply: 2 b'0010' LISP Map-Reply: 2 = b'0010'
LISP = Map-Register: 3 b'0011' LISP Map-Register: 3 = b'0011'
LISP = Map-Notify: 4 b'0100' LISP Map-Notify: 4 = b'0100'
LISP = Map-Notify-Ack: 5 b'0101' LISP Map-Notify-Ack: 5 = b'0101'
LISP = Map-Referral: 6 b'0110' LISP Map-Referral: 6 = b'0110'
= Not Assigned = 7 b'0111'
LISP = Encapsulated Control Message: 8 b'1000' LISP Encapsulated Control Message: 8 = b'1000'
Not Assigned = 9-14 b'1001'- b'1110' Not Assigned 9-14 b'1001'- = b'1110'
LISP Shared = Extension Message: 15 b'1111' [RFC8113] = LISP Shared Extension Message: 15 = b'1111' [RFC8113]
=
Values in the = "Not Assigned" range can be assigned according to Values in the "Not Assigned" range can be assigned = according to
procedures in = [RFC8126]. Documents that request for a new LISP procedures in [RFC8126]. Documents that request for = a new LISP
packet type = MAY indicate a preferred value. = packet type may= indicate a preferred value.
=
Protocol = designers experimenting with new message formats SHOULD use = Protocol designers experimenting with new = message formats SHOULD use
the LISP = Shared Extension Message Type and request a [RFC8113] sub- = the LISP Shared Extension Message Type and = request a [RFC8113] sub-
type = assignment. type = assignment.
=
All LISP = Control-Plane messages use Address Family Identifiers (AFI) = All LISP Control-Plane messages use Address = Family Identifiers (AFI)
[AFI] or LISP = Canonical Address Format (LCAF) [RFC8060] formats to [AFI] or LISP Canonical Address Format (LCAF) = [RFC8060] formats to
encode either = fixed or variable length addresses. This includes encode either fixed or variable length addresses. = This includes
explicit = fields in each control message or part of EID-records or = explicit fields in each control message or = part of EID-records or
RLOC-records = in commonly formatted messages. = RLOC-records in commonly formatted messages.
=
skipping to = change at = page 17, line 46 =C2=B6 = skipping to change at page 17, line = 46 =C2=B6
= [I-D.ietf-lisp-6834bis] for more details. [I-D.ietf-lisp-6834bis] for more details.
=
= EID-Prefix-AFI: Address family of the EID-Prefix according to = [AFI] EID-Prefix-AFI: Address = family of the EID-Prefix according to [AFI]
and = [RFC8060]. and = [RFC8060].
=
EID-Prefix: = This prefix is 4 octets for an IPv4 address family and EID-Prefix: This prefix is 4 octets for an IPv4 = address family and
16 octets = for an IPv6 address family. 16 = octets for an IPv6 address family.
=
Priority: = Each RLOC is assigned a unicast Priority. Lower values = Priority: Each RLOC is assigned a unicast = Priority. Lower values
are more = preferable. When multiple RLOCs have the same Priority, = are more preferable. When multiple RLOCs = have the same Priority,
they = MAY be used in a load-split fashion. A = value of 255 means they may be used in a load-split fashion. A value of = 255 means
the RLOC = MUST NOT be used for unicast forwarding. the RLOC MUST NOT be used for unicast = forwarding.
=
Weight: When = priorities are the same for multiple RLOCs, the Weight Weight: When priorities are the same for multiple = RLOCs, the Weight
indicates = how to balance unicast traffic between them. Weight is = indicates how to balance unicast traffic = between them. Weight is
encoded as = a relative weight of total unicast packets that match encoded as a relative weight of total unicast = packets that match
the mapping = entry. For example, if there are 4 Locators in a the mapping entry. For example, if there are 4 = Locators in a
= Locator-Set, where the Weights assigned are 30, 20, 20, and 10, = Locator-Set, where the Weights assigned = are 30, 20, 20, and 10,
the first = Locator will get 37.5% of the traffic, the 2nd and 3rd the first Locator will get 37.5% of the traffic, = the 2nd and 3rd
Locators = will get 25% of the traffic, and the 4th Locator will get = Locators will get 25% of the traffic, and = the 4th Locator will get
12.5% of = the traffic. If all Weights for a Locator-Set are equal, = 12.5% of the traffic. If all Weights for = a Locator-Set are equal,
=
skipping to = change at = page 18, line 38 =C2=B6 = skipping to change at page 18, line = 38 =C2=B6
Unused Flags: = These are set to 0 when sending and ignored on Unused Flags: These are set to 0 when sending and = ignored on
= receipt. receipt.
=
L: When this = bit is set, the Locator is flagged as a local Locator to = L: When this bit is set, the Locator is = flagged as a local Locator to
the ETR = that is sending the Map-Reply. When a Map-Server is doing = the ETR that is sending the Map-Reply. = When a Map-Server is doing
proxy = Map-Replying for a LISP site, the L-bit is set to 0 for all = proxy Map-Replying for a LISP site, the = L-bit is set to 0 for all
Locators in = this Locator-Set. Locators in = this Locator-Set.
=
p: When this = bit is set, an ETR informs the RLOC-Probing ITR that the = p: When this bit is set, an ETR informs the = RLOC-Probing ITR that the
locator = address for which this bit is set is the one being RLOC- = locator address for which this bit is set = is the one being RLOC-
probed = and MAY be different from the source = address of the Map- probed and = may be different from the source address = of the Map-
Reply. An = ITR that RLOC-probes a particular Locator MUST use this = Reply. An ITR that RLOC-probes a = particular Locator MUST use this
Locator for = retrieving the data structure used to store the fact Locator for retrieving the data structure used to = store the fact
that the = Locator is reachable. The p-bit is set for a single that the Locator is reachable. The p-bit is set = for a single
Locator in = the same Locator-Set. If an implementation sets more Locator in the same Locator-Set. If an = implementation sets more
than one = p-bit erroneously, the receiver of the Map-Reply MUST than one p-bit erroneously, the receiver of the = Map-Reply MUST
select the = first Locator. The p-bit MUST NOT be set for Locator- select the first Locator. The p-bit MUST NOT be = set for Locator-
Set records = sent in Map-Request and Map-Register messages. Set records sent in Map-Request and Map-Register = messages.
=
R: This is set = when the sender of a Map-Reply has a route to the R: This is set when the sender of a Map-Reply has a = route to the
Locator = in the Locator data record. This receiver MAY find this = Locator in the Locator data record. This receiver may find this
useful to = know if the Locator is up but not necessarily reachable = useful to know if the Locator is up but = not necessarily reachable
from the = receiver's point of view. See also EID-Reachability from the receiver's point of view. See also = EID-Reachability
Section = 7.1 for another way the R-bit MAY be = used. Section 7.1 for another = way the R-bit may be used.
=
Locator: This = is an IPv4 or IPv6 address (as encoded by the 'Loc- Locator: This is an IPv4 or IPv6 address (as encoded = by the 'Loc-
AFI' field) = assigned to an ETR. Note that the destination RLOC AFI' field) assigned to an ETR. Note that the = destination RLOC
address MAY = be an anycast address. A source RLOC can be an address MAY be an anycast address. A source RLOC = can be an
anycast = address as well. The source or destination RLOC MUST NOT = anycast address as well. The source or = destination RLOC MUST NOT
be the = broadcast address (255.255.255.255 or any subnet broadcast = be the broadcast address (255.255.255.255 = or any subnet broadcast
address = known to the router) and MUST NOT be a link-local address known to the router) and MUST NOT be a = link-local
multicast = address. The source RLOC MUST NOT be a multicast multicast address. The source RLOC MUST NOT be a = multicast
address. = The destination RLOC SHOULD be a multicast address if it = address. The destination RLOC SHOULD be = a multicast address if it
is being = mapped from a multicast destination EID. is being mapped from a multicast destination = EID.
=
skipping to = change at = page 23, line 46 =C2=B6 = skipping to change at page 23, line = 46 =C2=B6
= message. message.
=
Record Count: = This is the number of records in this Map-Register Record Count: This is the number of records in this = Map-Register
message. A = record is comprised of that portion of the packet message. A record is comprised of that portion of = the packet
labeled = 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of = times equal to
Record = Count. Record Count.
=
Nonce: This = 8-octet 'Nonce' field is set to 0 in Map-Register Nonce: This 8-octet 'Nonce' field is set to 0 in = Map-Register
messages if = no Map-Notify message is expected to acknowledge it. messages if no Map-Notify message is expected to = acknowledge it.
Since the = Map-Register message is authenticated, the 'Nonce' field = Since the Map-Register message is = authenticated, the 'Nonce' field
is not = currently used for any security function but MAY be in the = is not currently used for any security function but may be in the
future as = part of an anti-replay solution. = future as part of an anti-replay solution.
=
Key ID: This = is a configured key-id value that corresponds to a Key ID: This is a configured key-id value that = corresponds to a
= shared-secret password that is used to authenticate the sender. = shared-secret password that is used to = authenticate the sender.
Multiple = shared-secrets can be used to roll over keys in a non- Multiple shared-secrets can be used to roll over = keys in a non-
disruptive = way. disruptive way.
=
Algorithm ID: = This is the configured Message Authentication Code Algorithm ID: This is the configured Message = Authentication Code
(MAC) = algorithm value used for the authentication function. See = (MAC) algorithm value used for the = authentication function. See
Algorithm = ID Numbers in the Section 11.5 for codepoint Algorithm ID Numbers in the Section 11.5 for = codepoint
=
skipping to = change at = page 28, line 28 =C2=B6 = skipping to change at page 28, line = 28 =C2=B6
6.1. = Solicit-Map-Request (SMR) 6.1. = Solicit-Map-Request (SMR)
=
Soliciting a = Map-Request is a selective way for ETRs, at the site Soliciting a Map-Request is a selective way for ETRs, = at the site
where mappings = change, to control the rate they receive requests for where mappings change, to control the rate they = receive requests for
Map-Reply = messages. SMRs are also used to tell remote ITRs to update = Map-Reply messages. SMRs are also used to = tell remote ITRs to update
the mappings = they have cached. the mappings they = have cached.
=
Since the ETRs = don't keep track of remote ITRs that have cached their Since the ETRs don't keep track of remote ITRs that = have cached their
mappings, they = do not know which ITRs need to have their mappings mappings, they do not know which ITRs need to have = their mappings
updated. As a = result, an ETR will solicit Map-Requests (called an updated. As a result, an ETR will solicit = Map-Requests (called an
SMR message) = from those sites to which it has been = sending SMR message) to those sites to which it has been sending = encapsulated
encapsulated = data for the last minute. In particular, an ETR will data for the last minute. In particular, an ETR = will send an SMR to
send an SMR = to an ITR to which it has recently sent encapsulated an ITR to which it has recently sent encapsulated = data. This can
data. This = can only occur when both ITR and ETR functionality reside = only occur when both ITR and ETR = functionality reside in the same
in the same = router. router.
=
An SMR message = is simply a bit set in a Map-Request message. An ITR An SMR message is simply a bit set in a Map-Request = message. An ITR
or PITR will = send a Map-Request when they receive an SMR message. or PITR will send a Map-Request when they receive an = SMR message.
Both the SMR = sender and the Map-Request responder MUST rate-limit Both the SMR sender and the Map-Request responder = MUST rate-limit
these = messages. Rate-limiting can be implemented as a global rate- = these messages. Rate-limiting can be = implemented as a global rate-
limiter or one = rate-limiter per SMR destination. = limiter or one rate-limiter per SMR destination.
=
The following = procedure shows how an SMR exchange occurs when a site The following procedure shows how an SMR exchange = occurs when a site
is doing = Locator-Set compaction for an EID-to-RLOC mapping: is doing Locator-Set compaction for an EID-to-RLOC = mapping:
=
=
skipping = to change at page 29, line = 37 =C2=B6 = skipping to change at page 29, line = 37 =C2=B6
Replies. To = avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a = third party, a
sender of an = SMR-based Map-Request MUST be verified. If an ITR sender of an SMR-based Map-Request MUST be verified. = If an ITR
receives an = SMR-based Map-Request and the source is not in the receives an SMR-based Map-Request and the source is = not in the
Locator-Set = for the stored Map-Cache entry, then the responding Map- = Locator-Set for the stored Map-Cache entry, = then the responding Map-
Request MUST = be sent with an EID destination to the mapping database = Request MUST be sent with an EID destination = to the mapping database
system. Since = the mapping database system is a more secure way to system. Since the mapping database system is a more = secure way to
reach an = authoritative ETR, it will deliver the Map-Request to the = reach an authoritative ETR, it will deliver = the Map-Request to the
authoritative = source of the mapping data. = authoritative source of the mapping data.
=
When an ITR = receives an SMR-based Map-Request for which it does not = When an ITR receives an SMR-based = Map-Request for which it does not
have a = cached mapping for the EID in the SMR message, it may not send = have a cached mapping for the EID in the SMR message, it SHOULD NOT
an = SMR-invoked Map-Request. This scenario can occur when an ETR = send an SMR-invoked Map-Request. This = scenario can occur when an ETR
sends SMR = messages to all Locators in the Locator-Set it has stored = sends SMR messages to all Locators in the = Locator-Set it has stored
in its = Map-Cache but the remote ITRs that receive the SMR may not be = in its Map-Cache but the remote ITRs that = receive the SMR may not be
sending = packets to the site. There is no point in updating the ITRs = sending packets to the site. There is no = point in updating the ITRs
until they = need to send, in which case they will send Map-Requests to = until they need to send, in which case they = will send Map-Requests to
obtain a = Map-Cache entry. obtain a Map-Cache = entry.
=
7. Routing = Locator Reachability 7. Routing = Locator Reachability
=
This document = defines several Control-Plane mechanisms for This document defines several Control-Plane = mechanisms for
determining = RLOC reachability. Please note that additional Data- determining RLOC reachability. Please note that = additional Data-
Plane = reachability mechanisms are defined in = Plane reachability mechanisms are defined in
= [I-D.ietf-lisp-rfc6830bis]. = [I-D.ietf-lisp-rfc6830bis].
=
1. An ITR = MAY receive an ICMP Network Unreachable or = Host 1. An ITR may receive an ICMP Network Unreachable or = Host
= Unreachable message for an RLOC it is using. This indicates = that Unreachable message for an = RLOC it is using. This indicates that
the RLOC = is likely down. Note that trusting ICMP messages may the RLOC is likely down. Note that trusting ICMP = messages may
not be = desirable, but neither is ignoring them completely. not be desirable, but neither is ignoring them = completely.
= Implementations are encouraged to follow current best practices = Implementations are encouraged to follow = current best practices
in = treating these conditions [I-D.ietf-opsec-icmp-filtering]. = in treating these conditions = [I-D.ietf-opsec-icmp-filtering].
=
2. When an = ITR participates in the routing protocol that operates in = 2. When an ITR participates in the routing = protocol that operates in
the = underlay routing system, it can determine that an RLOC is = the underlay routing system, it can = determine that an RLOC is
down when = no Routing Information Base (RIB) entry exists that down when no Routing Information Base (RIB) entry = exists that
matches = the RLOC IP address. matches = the RLOC IP address.
=
3. An ITR = MAY receive an ICMP Port Unreachable = message from a 3. An ITR may receive an ICMP Port Unreachable message = from a
= destination host. This occurs if an ITR attempts to use = destination host. This occurs if an ITR = attempts to use
= interworking [RFC6832] and LISP-encapsulated data is sent to a = interworking [RFC6832] and = LISP-encapsulated data is sent to a
= non-LISP-capable site. = non-LISP-capable site.
=
4. An ITR = MAY receive a Map-Reply from an ETR in = response to a 4. An ITR may receive a Map-Reply from an ETR in response = to a
previously = sent Map-Request. The RLOC source of the Map-Reply is previously sent Map-Request. The RLOC source of = the Map-Reply is
likely up, = since the ETR was able to send the Map-Reply to the likely up, since the ETR was able to send the = Map-Reply to the
= ITR. ITR.
=
5. An ITR/ETR = pair can use the 'RLOC-Probing' mechanism described 5. An ITR/ETR pair can use the 'RLOC-Probing' = mechanism described
= below. below.
=
When ITRs = receive ICMP Network Unreachable or Host Unreachable When ITRs receive ICMP Network Unreachable or Host = Unreachable
messages as a = method to determine unreachability, they will refrain messages as a method to determine unreachability, = they will refrain
from using = Locators that are described in Locator lists of Map- from using Locators that are described in Locator = lists of Map-
=
skipping = to change at page 33, line = 9 =C2=B6 = skipping to change at page 33, line = 9 =C2=B6
registered, = a 1-minute TTL is returned. If the requested EID registered, a 1-minute TTL is returned. If the = requested EID
matches a = non-delegated part of the authoritative EID-Prefix, then = matches a non-delegated part of the = authoritative EID-Prefix, then
it is not a = LISP EID and a 15-minute TTL is returned. See it is not a LISP EID and a 15-minute TTL is = returned. See
Section 8.2 = for discussion of aggregate EID-Prefixes and details Section 8.2 for discussion of aggregate = EID-Prefixes and details
of = Map-Server EID-Prefix matching. = of Map-Server EID-Prefix matching.
=
o A LISP = Map-Reply from the ETR that owns the EID-to-RLOC mapping or = o A LISP Map-Reply from the ETR that owns = the EID-to-RLOC mapping or
possibly = from a Map-Server answering on behalf of the ETR. See possibly from a Map-Server answering on behalf of = the ETR. See
Section 8.4 = for more details on Map-Resolver message processing. Section 8.4 for more details on Map-Resolver = message processing.
=
Note that an = ITR MAY be configured to both use a = Map-Resolver and to Note that an = ITR may be configured to both use a = Map-Resolver and to
participate in = a LISP-ALT logical network. In such a situation, the participate in a LISP-ALT logical network. In such a = situation, the
ITR SHOULD = send Map-Requests through the ALT network for any EID- ITR SHOULD send Map-Requests through the ALT network = for any EID-
Prefix learned = via ALT BGP. Such a configuration is expected to be Prefix learned via ALT BGP. Such a configuration is = expected to be
very rare, = since there is little benefit to using a Map-Resolver if = very rare, since there is little benefit to = using a Map-Resolver if
an ITR is = already using LISP-ALT. There would be, for example, no = an ITR is already using LISP-ALT. There = would be, for example, no
need for such = an ITR to send a Map-Request to a possibly non-existent = need for such an ITR to send a Map-Request = to a possibly non-existent
EID (and rely = on Negative Map-Replies) if it can consult the ALT EID (and rely on Negative Map-Replies) if it can = consult the ALT
database to = verify that an EID-Prefix is present before sending that = database to verify that an EID-Prefix is = present before sending that
= Map-Request. Map-Request.
=
=
skipping = to change at page 33, line = 33 =C2=B6 = skipping to change at page 33, line = 33 =C2=B6
Map-Register = messages. A Map-Register message includes Map-Register messages. A Map-Register message = includes
authentication = data, so prior to sending a Map-Register message, the authentication data, so prior to sending a = Map-Register message, the
ETR and = Map-Server SHOULD be configured with a shared secret or other = ETR and Map-Server SHOULD be configured with = a shared secret or other
relevant = authentication information. A Map-Server's configuration = relevant authentication information. A = Map-Server's configuration
SHOULD also = include a list of the EID-Prefixes for which each ETR is = SHOULD also include a list of the = EID-Prefixes for which each ETR is
authoritative. = Upon receipt of a Map-Register from an ETR, a Map- authoritative. Upon receipt of a Map-Register from = an ETR, a Map-
Server accepts = only EID-Prefixes that are configured for that ETR. Server accepts only EID-Prefixes that are configured = for that ETR.
Failure to = implement such a check would leave the mapping system Failure to implement such a check would leave the = mapping system
vulnerable to = trivial EID-Prefix hijacking attacks. As developers vulnerable to trivial EID-Prefix hijacking attacks. = As developers
and operators = gain experience with the mapping system, additional, and operators gain experience with the mapping = system, additional,
stronger = security measures MAY be added to the = registration process. stronger = security measures may be added to the = registration process.
=
In addition = to the set of EID-Prefixes defined for each ETR that MAY In = addition to the set of EID-Prefixes defined for each ETR that may
register, a = Map-Server is typically also configured with one or more = register, a Map-Server is typically also = configured with one or more
aggregate = prefixes that define the part of the EID numbering space = aggregate prefixes that define the part of = the EID numbering space
assigned to = it. When LISP-ALT is the database in use, aggregate EID- = assigned to it. When LISP-ALT is the = database in use, aggregate EID-
Prefixes are = implemented as discard routes and advertised into ALT Prefixes are implemented as discard routes and = advertised into ALT
BGP. The = existence of aggregate EID-Prefixes in a Map-Server's BGP. The existence of aggregate EID-Prefixes in a = Map-Server's
database = means that it MAY receive Map Requests for = EID-Prefixes that database means = that it may receive Map Requests for = EID-Prefixes that
match an = aggregate but do not match a registered prefix; Section 8.3 = match an aggregate but do not match a = registered prefix; Section 8.3
describes how = this is handled. describes how this = is handled.
=
Map-Register = messages are sent periodically from an ETR to a Map- Map-Register messages are sent periodically from an = ETR to a Map-
Server with a = suggested interval between messages of one minute. A Server with a suggested interval between messages of = one minute. A
Map-Server = SHOULD time out and remove an ETR's registration if it has = Map-Server SHOULD time out and remove an = ETR's registration if it has
not received a = valid Map-Register message within the past not received a valid Map-Register message within the = past
three minutes. = When first contacting a Map-Server after restart or three minutes. When first contacting a Map-Server = after restart or
changes to its = EID-to-RLOC database mappings, an ETR MAY initially changes to its EID-to-RLOC database mappings, an ETR = MAY initially
send = Map-Register messages at an increased frequency, up to one = every send Map-Register messages at = an increased frequency, up to one every
=
skipping = to change at page 34, line = 21 =C2=B6 = skipping to change at page 34, line = 21 =C2=B6
this flag by = an ETR would be to set it for Map-Register messages sent = this flag by an ETR would be to set it for = Map-Register messages sent
during the = initial "quick registration" with a Map-Server but then = during the initial "quick registration" with = a Map-Server but then
set it only = occasionally during steady-state maintenance of its set it only occasionally during steady-state = maintenance of its
association = with that Map-Server. Note that the Map-Notify message = association with that Map-Server. Note that = the Map-Notify message
is sent to UDP = destination port 4342, not to the source port is sent to UDP destination port 4342, not to the = source port
specified in = the original Map-Register message. = specified in the original Map-Register message.
=
Note that a = one-minute minimum registration interval during Note that a one-minute minimum registration interval = during
maintenance of = an ETR-Map-Server association places a lower bound on maintenance of an ETR-Map-Server association places a = lower bound on
how quickly = and how frequently a mapping database entry can be how quickly and how frequently a mapping database = entry can be
updated. = This MAY have implications for what sorts = of mobility can updated. This = may have implications for what sorts of = mobility can
be supported = directly by the mapping system; shorter registration be supported directly by the mapping system; shorter = registration
intervals or = other mechanisms might be needed to support faster intervals or other mechanisms might be needed to = support faster
mobility in = some cases. For a discussion on one way that faster mobility in some cases. For a discussion on one way = that faster
mobility = MAY be implemented for individual devices, = please see mobility may be implemented for individual devices, = please see
= [I-D.ietf-lisp-mn]. = [I-D.ietf-lisp-mn].
=
An ETR MAY = also request, by setting the "proxy Map-Reply" flag An ETR MAY also request, by setting the "proxy = Map-Reply" flag
(P-bit) in the = Map-Register message, that a Map-Server answer Map- (P-bit) in the Map-Register message, that a = Map-Server answer Map-
Requests = instead of forwarding them to the ETR. See Section 7.1 for = Requests instead of forwarding them to the = ETR. See Section 7.1 for
details on how = the Map-Server sets certain flags (such as those details on how the Map-Server sets certain flags = (such as those
indicating = whether the message is authoritative and how returned indicating whether the message is authoritative and = how returned
Locators = SHOULD be treated) when sending a Map-Reply on behalf of an = Locators SHOULD be treated) when sending a = Map-Reply on behalf of an
ETR. When an = ETR requests proxy reply service, it SHOULD include all = ETR. When an ETR requests proxy reply = service, it SHOULD include all
RLOCs for all = ETRs for the EID-Prefix being registered, along with RLOCs for all ETRs for the EID-Prefix being = registered, along with
=
skipping = to change at page 35, line = 17 =C2=B6 = skipping to change at page 35, line = 17 =C2=B6
=
8.3. Map-Server = Processing 8.3. Map-Server = Processing
=
Once a = Map-Server has EID-Prefixes registered by its client ETRs, it = Once a Map-Server has EID-Prefixes = registered by its client ETRs, it
can accept and = process Map-Requests for them. can = accept and process Map-Requests for them.
=
In response to = a Map-Request (received over the ALT if LISP-ALT is in In response to a Map-Request (received over the ALT = if LISP-ALT is in
use), the = Map-Server first checks to see if the destination EID use), the Map-Server first checks to see if the = destination EID
matches a = configured EID-Prefix. If there is no match, the Map- matches a configured EID-Prefix. If there is no = match, the Map-
Server returns = a Negative Map-Reply with action code "Natively- Server returns a Negative Map-Reply with action code = "Natively-
Forward" and = a 15-minute TTL. This MAY occur if a Map = Request is Forward" and a = 15-minute TTL. This can occur if a Map = Request is
received for a = configured aggregate EID-Prefix for which no more- received for a configured aggregate EID-Prefix for = which no more-
specific = EID-Prefix exists; it indicates the presence of a non-LISP = specific EID-Prefix exists; it indicates the = presence of a non-LISP
"hole" in the = aggregate EID-Prefix. "hole" in the = aggregate EID-Prefix.
=
Next, the = Map-Server checks to see if any ETRs have registered the = Next, the Map-Server checks to see if any = ETRs have registered the
matching = EID-Prefix. If none are found, then the Map-Server returns = matching EID-Prefix. If none are found, = then the Map-Server returns
a Negative = Map-Reply with action code "Natively-Forward" and a a Negative Map-Reply with action code = "Natively-Forward" and a
1-minute = TTL. 1-minute TTL.
=
If the = EID-prefix is either registered or not registered to the = If the EID-prefix is either registered or = not registered to the
=
skipping = to change at page 35, line = 47 =C2=B6 = skipping to change at page 35, line = 47 =C2=B6
If any of the = registered ETRs for the EID-Prefix have requested proxy = If any of the registered ETRs for the = EID-Prefix have requested proxy
reply service, = then the Map-Server answers the request instead of reply service, then the Map-Server answers the = request instead of
forwarding it. = It returns a Map-Reply with the EID-Prefix, RLOCs, forwarding it. It returns a Map-Reply with the = EID-Prefix, RLOCs,
and other = information learned through the registration process. and other information learned through the = registration process.
=
If none of the = ETRs have requested proxy reply service, then the Map- If none of the ETRs have requested proxy reply = service, then the Map-
Server = re-encapsulates and forwards the resulting Encapsulated Map- = Server re-encapsulates and forwards the = resulting Encapsulated Map-
Request to one = of the registered ETRs. It does not otherwise alter Request to one of the registered ETRs. It does not = otherwise alter
the = Map-Request, so any Map-Reply sent by the ETR is returned to = the the Map-Request, so any = Map-Reply sent by the ETR is returned to the
RLOC in the = Map-Request, not to the Map-Server. Unless also acting = RLOC in the Map-Request, not to the = Map-Server. Unless also acting
as a = Map-Resolver, a Map-Server SHOULD never = receive Map-Replies; any as a = Map-Resolver, a Map-Server should never = receive Map-Replies; any
such messages = SHOULD be discarded without response, perhaps such messages SHOULD be discarded without response, = perhaps
accompanied by = the logging of a diagnostic message if the rate of accompanied by the logging of a diagnostic message if = the rate of
Map-Replies is = suggestive of malicious traffic. = Map-Replies is suggestive of malicious traffic.
=
8.4. = Map-Resolver Processing 8.4. = Map-Resolver Processing
=
Upon receipt = of an Encapsulated Map-Request, a Map-Resolver Upon receipt of an Encapsulated Map-Request, a = Map-Resolver
decapsulates = the enclosed message and then searches for the requested = decapsulates the enclosed message and then = searches for the requested
EID in its = local database of mapping entries (statically configured = EID in its local database of mapping entries = (statically configured
or learned = from associated ETRs if the Map-Resolver is also a Map- = or learned from associated ETRs if the = Map-Resolver is also a Map-
=
skipping = to change at page 37, line = 26 =C2=B6 = skipping to change at page 37, line = 26 =C2=B6
messages does = not provide protection against "replay" attacks by a messages does not provide protection against "replay" = attacks by a
= "man-in-the-middle". Additional work is needed in this area. = "man-in-the-middle". Additional work is = needed in this area.
=
= [I-D.ietf-lisp-sec] defines a proposed mechanism for providing = origin [I-D.ietf-lisp-sec] defines = a proposed mechanism for providing origin
= authentication, integrity, anti-replay protection, and prevention = of authentication, integrity, = anti-replay protection, and prevention of
= man-in-the-middle and "overclaiming" attacks on the = Map-Request/Map- man-in-the-middle = and "overclaiming" attacks on the Map-Request/Map-
Reply = exchange. Work is ongoing on this and other proposals for = Reply exchange. Work is ongoing on this and = other proposals for
resolving = these open security issues. = resolving these open security issues.
=
While beyond = the scope of securing an individual Map-Server or Map- While beyond the scope of securing an individual = Map-Server or Map-
Resolver, it = SHOULD be noted that a BGP-based LISP-ALT = network (if Resolver, it should be noted that a BGP-based LISP-ALT = network (if
ALT is used as = the mapping database infrastructure) can take ALT is used as the mapping database infrastructure) = can take
advantage of = standards work on adding security to BGP. advantage of standards work on adding security to = BGP.
=
A complete = LISP threat analysis has been published in [RFC7835]. A complete LISP threat analysis has been published in = [RFC7835].
Please refer = to it for more security related details. Please refer to it for more security related = details.
=
10. Changes = since RFC 6833 10. Changes since RFC = 6833
=
For = implementation considerations, the following changes have been = For implementation considerations, the = following changes have been
made to this = document since RFC 6833 was published: = made to this document since RFC 6833 was published:
=
skipping = to change at page 38, line = 27 =C2=B6 = skipping to change at page 38, line = 27 =C2=B6
11. IANA = Considerations 11. IANA = Considerations
=
This section = provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet = Assigned Numbers
Authority = (IANA) regarding registration of values related to this = Authority (IANA) regarding registration of = values related to this
LISP = Control-Plane specification, in accordance with BCP 26 LISP Control-Plane specification, in accordance with = BCP 26
= [RFC8126]. [RFC8126].
=
There are = three namespaces (listed in the sub-sections below) in LISP = There are three namespaces (listed in the = sub-sections below) in LISP
that have been = registered. that have been = registered.
=
o LISP IANA = registry allocations SHOULD NOT be made = for purposes o LISP IANA registry = allocations should not be made for = purposes
unrelated = to LISP routing or transport protocols. = unrelated to LISP routing or transport protocols.
=
o The = following policies are used here with the meanings defined in = o The following policies are used here with = the meanings defined in
BCP 26: = "Specification Required", "IETF Review", "Experimental BCP 26: "Specification Required", "IETF Review", = "Experimental
Use", and = "First Come First Served". Use", = and "First Come First Served".
=
11.1. LISP UDP = Port Numbers 11.1. LISP UDP Port = Numbers
=
The IANA = registry has allocated UDP port number 4342 for the LISP = The IANA registry has allocated UDP port = number 4342 for the LISP
Control-Plane. = IANA has updated the description for UDP port 4342 as Control-Plane. IANA has updated the description for = UDP port 4342 as
=
skipping = to change at page 40, line = 30 =C2=B6 = skipping to change at page 40, line = 30 =C2=B6
Number values = are in the range of 0 to 255. The allocation of values = Number values are in the range of 0 to 255. = The allocation of values
is on a first = come first served basis. is on a = first come first served basis.
=
12. = References 12. References
=
12.1. Normative = References 12.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-00 (work in progress), July = 2018. = lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-14 = (work in progress), = (LISP)", draft-ietf-lisp-rfc6830bis-16 = (work in progress),
= July 2018. August = 2018.
=
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
=
skipping = to change at page 45, line = 19 =C2=B6 = skipping to change at page 45, line = 19 =C2=B6
Fabio Maino, = and members of the lisp@ietf.org mailing list for their = Fabio Maino, and members of the = lisp@ietf.org mailing list for their
feedback and = helpful suggestions. feedback and = helpful suggestions.
=
Special thanks = are due to Noel Chiappa for his extensive work and Special thanks are due to Noel Chiappa for his = extensive work and
thought about = caching in Map-Resolvers. thought = about caching in Map-Resolvers.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6833bis-13 B.1. = Changes to draft-ietf-lisp-rfc6833bis-14
=
= o Posted September = 2018.
=
= o Changes to = reflect comments from Genart, RTGarea, and Secdir
= = reviews.
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-13
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-12 B.3. Changes to = draft-ietf-lisp-rfc6833bis-12
=
o Posted late = July 2018. o Posted late July = 2018.
=
o Moved = RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative = References.
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-11 B.4. Changes to = draft-ietf-lisp-rfc6833bis-11
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for = RFC status and
ran through = IDNITs again. ran through IDNITs = again.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-10 B.5. Changes to = draft-ietf-lisp-rfc6833bis-10
=
o Posted = after LISP WG at IETF week March. o = Posted after LISP WG at IETF week March.
=
o Move AD = field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM = packet format
description = section. description = section.
=
o Say more = about when the new Drop actions should be sent. o Say more about when the new Drop actions should be = sent.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-09 B.6. Changes to = draft-ietf-lisp-rfc6833bis-09
=
o Posted = March IETF week 2018. o Posted = March IETF week 2018.
=
o Fixed = editorial comments submitted by document shepherd Luigi = o Fixed editorial comments submitted by = document shepherd Luigi
= Iannone. Iannone.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-08 B.7. Changes to = draft-ietf-lisp-rfc6833bis-08
=
o Posted = March 2018. o Posted March = 2018.
=
o Added = RLOC-probing algorithm. o Added = RLOC-probing algorithm.
=
o Added = Solicit-Map Request algorithm. o = Added Solicit-Map Request algorithm.
=
o Added = several mechanisms (from 6830bis) regarding Routing Locator = o Added several mechanisms (from 6830bis) = regarding Routing Locator
= Reachability. = Reachability.
=
o Added port = 4342 to IANA Considerations section. = o Added port 4342 to IANA Considerations section.
=
B.7. Changes to = draft-ietf-lisp-rfc6833bis-07 B.8. Changes to = draft-ietf-lisp-rfc6833bis-07
=
o Posted = December 2017. o Posted December = 2017.
=
o Make it = more clear in a couple of places that RLOCs are used to = o Make it more clear in a couple of places = that RLOCs are used to
locate ETRs = more so than for Map-Server Map-Request forwarding. locate ETRs more so than for Map-Server = Map-Request forwarding.
=
o Make it = clear that "encapsualted" for a control message is an ECM = o Make it clear that "encapsualted" for a = control message is an ECM
based = message. based message.
=
o Make it = more clear what messages use source-port 4342 and which = o Make it more clear what messages use = source-port 4342 and which
=
skipping = to change at page 47, line = 5 =C2=B6 = skipping to change at page 47, line = 13 =C2=B6
Can use = othe AFIs then IPv4 and IPv6. = Can use othe AFIs then IPv4 and IPv6.
=
o Many = editorial changes to clarify text. = o Many editorial changes to clarify text.
=
o Changed = some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to = capitalized.
=
o Added = definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply = messages.
=
o Ran = document through IDNITs. o Ran = document through IDNITs.
=
B.8. Changes to = draft-ietf-lisp-rfc6833bis-06 B.9. Changes to = draft-ietf-lisp-rfc6833bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Spec the = I-bit to include the xTR-ID in a Map-Request message to = o Spec the I-bit to include the xTR-ID in a = Map-Request message to
be = consistent with the Map-Register message and to anticipate the = be consistent with the Map-Register = message and to anticipate the
= introduction of pubsub functionality to allow Map-Requests to = introduction of pubsub functionality to = allow Map-Requests to
subscribe = to RLOC-set changes. subscribe = to RLOC-set changes.
=
o Updated = references for individual submissions that became working = o Updated references for individual = submissions that became working
group = documents. group = documents.
=
o Updated = references for working group documents that became RFCs. = o Updated references for working group = documents that became RFCs.
=
B.9. Changes to = draft-ietf-lisp-rfc6833bis-05 B.10. Changes to = draft-ietf-lisp-rfc6833bis-05
=
o Posted May = 2017. o Posted May 2017.
=
o Update IANA = Considerations section based on new requests from this o Update IANA Considerations section based on new = requests from this
document = and changes from what was requested in [RFC6830]. document and changes from what was requested in = [RFC6830].
=
B.10. Changes to = draft-ietf-lisp-rfc6833bis-04 B.11. Changes to = draft-ietf-lisp-rfc6833bis-04
=
o Posted May = 2017. o Posted May 2017.
=
o Clarify how = the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in = Map-Register and Map-
Notify = messages. Break the 16-bit field into a 8-bit Key-ID field = Notify messages. Break the 16-bit field = into a 8-bit Key-ID field
and a 8-bit = Algorithm-ID field. and a 8-bit = Algorithm-ID field.
=
o Move the = Control-Plane codepoints from the IANA Considerations o Move the Control-Plane codepoints from the IANA = Considerations
section of = RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations = section of this
= document. document.
=
o In the = "LISP Control Packet Type Allocations" section, indicate = o In the "LISP Control Packet Type = Allocations" section, indicate
how message = Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how = experimental RFC8113
sub-types = should be requested. sub-types = should be requested.
=
B.11. Changes to = draft-ietf-lisp-rfc6833bis-03 B.12. Changes to = draft-ietf-lisp-rfc6833bis-03
=
o Posted = April 2017. o Posted April = 2017.
=
o Add types = 9-14 and specify they are not assigned. = o Add types 9-14 and specify they are not assigned.
=
o Add the = "LISP Shared Extension Message" type and point to RFC8113. = o Add the "LISP Shared Extension Message" = type and point to RFC8113.
=
B.12. Changes to = draft-ietf-lisp-rfc6833bis-02 B.13. Changes to = draft-ietf-lisp-rfc6833bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Clarify = that the LISP Control-Plane document defines how the LISP = o Clarify that the LISP Control-Plane = document defines how the LISP
Data-Plane = uses Map-Requests with either the SMR-bit set or the Data-Plane uses Map-Requests with either the = SMR-bit set or the
P-bit set = supporting mapping updates and RLOC-probing. Indicating = P-bit set supporting mapping updates and = RLOC-probing. Indicating
that other = Data-Planes can use the same mechanisms or their own that other Data-Planes can use the same mechanisms = or their own
defined = mechanisms to achieve the same functionality. defined mechanisms to achieve the same = functionality.
=
B.13. Changes to = draft-ietf-lisp-rfc6833bis-01 B.14. Changes to = draft-ietf-lisp-rfc6833bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Remove = references to self. o Remove = references to self.
=
o Change = references from RFC6830 to RFC6830bis. = o Change references from RFC6830 to RFC6830bis.
=
o Add two new = action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has = posted to the LISP
WG mailing = list. WG mailing list.
=
o In intro = section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to = I-D.ietf-lisp-introduction.
=
o Removed = Open Issues section and references to "experimental". o Removed Open Issues section and references to = "experimental".
=
B.14. Changes to = draft-ietf-lisp-rfc6833bis-00 B.15. Changes to = draft-ietf-lisp-rfc6833bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6833-00 = individual submission. No other changes made. -rfc6833-00 individual submission. No other = changes made.
=
B.15. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.16. Changes to = draft-farinacci-lisp-rfc6833bis-00
=
o Posted = November 2016. o Posted November = 2016.
=
o This is the = initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into = RFC 6833bis.
=
o The = document name has changed from the "Locator/ID Separation = o The document name has changed from the = "Locator/ID Separation
Protocol = (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the = "Locator/ID
Separation = Protocol (LISP) Control-Plane". = Separation Protocol (LISP) Control-Plane".
=
o The = fundamental change was to move the Control-Plane messages from = o The fundamental change was to move the = Control-Plane messages from
 End of changes. 47 change blocks. 
72 lines changed or = deleted 81 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_9607CC9D-FF29-46EE-B465-C40B49B27314 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_9607CC9D-FF29-46EE-B465-C40B49B27314-- From nobody Tue Sep 11 11:29:10 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1B9130EDF for ; Tue, 11 Sep 2018 11:29:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 SrUYgBSSN3M7 for ; Tue, 11 Sep 2018 11:29:00 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 C7BE01292F1 for ; Tue, 11 Sep 2018 11:28:59 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id g44-v6so29268040qtb.12 for ; Tue, 11 Sep 2018 11:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uqfGIHyqdRJg9C/LgAfTR+iwx8At3KN+RnIb+avIy3U=; b=GuZZK0L2CmE8LYrs74YbN/rvqd/rRQgw8YwvKWKRZUm4/SjDgLfYG3Uu5eG3Vi98Sa hEuYitNEQmbv/T15CHhTkzE+5IPVRHnR7RkKM3Ao08i+amhnGtJ2JWDiydI0sAdbJyES AV75EOaw5zRL+j2XHBtvWwNyXzk0rq+YAfQ7w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uqfGIHyqdRJg9C/LgAfTR+iwx8At3KN+RnIb+avIy3U=; b=Zv+Bw9xeryWVc3BHCIOwdMiv1WiT+tzUPQqFH0RgdT+GB10TPZpyld553VYYRicyG8 w08/yOX1lCxQwfhRO+TCjjB9x0UtSUb3uKErGzUTc4zjieLw1mMfcRUvPn91rWyZYND1 6BGSPgvZM/EScS2VKzRWNmVnmdjGwxA5dNwaMsI3DJu6yOG5z9EdYUj4+BOlMpHeAw2U qdTBnqP65xoLtVBYQbavsPnZ0eYUpr3bzVkXXUPFW2T4Uxym6PuAnA1+GvDYgOkDvpHP gYygxbwvbmKuED+6g+I+BPta6r0GXshz329/yRGhOlYBqj+ZHoGSGm3DfusJ49EOuumV 9kQA== X-Gm-Message-State: APzg51BOpRtk32sWjW350R35oyjJThIWxDnX8ZN8hpOhOUSrlKyPqx2/ g4bzOXCJFQ78QvvygugbhD4vXNcS5GFr1TH1AgxEmXrZRRVVaQ== X-Google-Smtp-Source: ANB0VdZ36Pkhzwphir62bgtPqW5Pdwy2aKcS6V3Yv0MjDRjhWS2WVoVu7dTEUjVlB+qp9wXw9zeaFDhjH2si8HgDPyw= X-Received: by 2002:aed:3d48:: with SMTP id h8-v6mr20758589qtf.222.1536690538778; Tue, 11 Sep 2018 11:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 11:28:57 -0700 (PDT) X-Originating-IP: [2001:4878:a000:3000:65c5:5df1:11df:7dca] In-Reply-To: <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> From: Kyle Rose Date: Tue, 11 Sep 2018 14:28:57 -0400 Message-ID: To: Dino Farinacci Cc: IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary="000000000000b1a6ab05759ca579" Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 18:29:03 -0000 --000000000000b1a6ab05759ca579 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2018 at 12:56 PM, Dino Farinacci wrote: > On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci > wrote: > > > E.g., if entity A has pairwise trust with peer B, but needs an EID > mapping for peer C, it needs some way to establish that the replies it's > supposedly receiving from C are genuine. One popular model enabling > > > > The mapping system allows all of A-C to trust each other. > > > > Explain how with a detailed example, or point me to a detailed > explanation in a specific document. The mechanism is still not entirely > clear to me. If A and C don't have an established business relationship, > how does A know that the responses it's getting for EID mappings owned by= C > are genuine and not modified by B? This is a critical property of the > system, and so it needs to be made obvious to the reader. > > (1) A, B, and C register their mappings to the mapping system. They have = a > trust relationship with each of their respective map-servers. > (2) Those map-servers, who participate in the same mapping system and kno= w > about each other via LISP-DDT delegations, can sign referrals to tell > map-resolvers that A uses to look up mappings for B and C can trust the > map-servers of B and C. > (3) The map-servers can proxy-reply with the mappings for B and C to A. O= r > B and C can Map-Reply specifically with signed Map-Replies according to > draft-ietf-lisp-sec. > > Do I need to say more? > This is definitely clearer. The trust relationships appear to be: * A network trusts a particular map server to be authoritative for the entire EID/RLOC mapping. * The map servers trust the LISP-DDT root: they use LISP-DDT to publish and resolve EID/RLOC mappings, and can directly authenticate those mappings because they are signed in a hierarchical fashion (like DNSSEC). The first is a transitive trust relationship, but this is probably acceptable because it's only one hop (I'm trusting someone else to verify a piece of data that has been authenticated end-to-end) and there is a direct business relationship between the two entities. The second, if I have the general idea correct, is very much like DNSSEC or the web CA system in that a compromise of a node in the signature tree/forest leads to a loss of authenticity for that entire subtree. This is not disqualifying: clearly, many standardized systems have this property. But it's important to state it explicitly so we can at the very least make the properties clear to operators, and potentially recommend and/or develop mitigations. > > this complex. But the interfaces between the documents, by which I mean > the requirements they impose on each other, must be made explicit. When a > system achieves complexity warranting design modularity, it=E2=80=99s > > And they should be by how the reference each other. If you think there is > text that makes assumpiton without a reference to the particular draft, > then we can add it. > What I might recommend is either an augmentation of, or a new document analogous to (and informationally referencing), draft-ietf-lisp-introduction that covers the expected security properties of the overall design and the requirements for each of the subcomponents in a way that someone can understand without referring to any document other than the high-level architecture itself. draft-ietf-lisp-introduction is actually quite good at getting the general point of LISP across to someone new; I want to see something similar for LISP's security model. I think that's going to be better than inserting clarifying text here or there. I've actually read enough of this stuff at this point that I'm not sure I can enumerate exactly what's missing where. The threat model document could potentially be folded into that, but it has to start by painting a picture of the security that someone new to LISP can quickly understand. Kyle --000000000000b1a6ab05759ca579 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Sep 11, 2018 at 12:56 PM, Dino Farina= cci <farinacci@gmail.com> wrote:
On Tue, Sep 11, 2018 at = 11:29 AM, Dino Farinacci <farinac= ci@gmail.com> wrote:
> > E.g., if entity A has pairwise trust with peer B, but needs an EI= D mapping for peer C, it needs some way to establish that the replies it= 9;s supposedly receiving from C are genuine. One popular model enabling
>
> The mapping system allows all of A-C to trust each other.
>
> Explain how with a detailed example, or point me to a detailed explana= tion in a specific document. The mechanism is still not entirely clear to m= e. If A and C don't have an established business relationship, how does= A know that the responses it's getting for EID mappings owned by C are= genuine and not modified by B? This is a critical property of the system, = and so it needs to be made obvious to the reader.

(1) A, B, and C register their mappings to the mapping system. They = have a trust relationship with each of their respective map-servers.
(2) Those map-servers, who participate in the same mapping system and know = about each other via LISP-DDT delegations, can sign referrals to tell map-r= esolvers that A uses to look up mappings for B and C can trust the map-serv= ers of B and C.
(3) The map-servers can proxy-reply with the mappings for B and C to A. Or = B and C can Map-Reply specifically with signed Map-Replies according to dra= ft-ietf-lisp-sec.

Do I need to say more?

This is definite= ly clearer. The trust relationships appear to be:

= =C2=A0* A network trusts a particular map server to be authoritative for th= e entire EID/RLOC mapping.
=C2=A0* The map servers trust the = LISP-DDT root: they use LISP-DDT to publish and resolve EID/RLOC mappings, = and can directly authenticate those mappings because they are signed in a h= ierarchical fashion (like DNSSEC).

The first i= s a transitive trust relationship, but this is probably acceptable because = it's only one hop (I'm trusting someone else to verify a piece of d= ata that has been authenticated end-to-end) and there is a direct business = relationship between the two entities.

The sec= ond, if I have the general idea correct, is very much like DNSSEC or the we= b CA system in that a compromise of a node in the signature tree/forest lea= ds to a loss of authenticity for that entire subtree. This is not disqualif= ying: clearly, many standardized systems have this property. But it's i= mportant to state it explicitly so we can at the very least make the proper= ties clear to operators, and potentially recommend and/or develop mitigatio= ns.
=C2=A0
> this complex. But the interfaces between the documents, by which I mea= n the requirements they impose on each other, must be made explicit. When a= system achieves complexity warranting design modularity, it=E2=80=99s

And they should be by how the reference each other. If you think the= re is text that makes assumpiton without a reference to the particular draf= t, then we can add it.
=
What I might recommend is either an augmentation of, or a ne= w document analogous to (and informationally referencing), draft-ietf-lisp-= introduction that covers the expected security properties of the overall de= sign and the requirements for each of the subcomponents in a way that someo= ne can understand without referring to any document other than the high-lev= el architecture itself. draft-ietf-lisp-introduction is actually quite good= at getting the general point of LISP across to someone new; I want to see = something similar for LISP's security model. I think that's going t= o be better than inserting clarifying text here or there. I've actually= read enough of this stuff at this point that I'm not sure I can enumer= ate exactly what's missing where. The threat model document could poten= tially be folded into that, but it has to start by painting a picture of th= e security that someone new to LISP can quickly understand.

Kyle
--000000000000b1a6ab05759ca579-- From nobody Tue Sep 11 11:39:56 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E3B130F3F; Tue, 11 Sep 2018 11:39:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 o-PtNdBgFJfJ; Tue, 11 Sep 2018 11:39:37 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 9CF881310F3; Tue, 11 Sep 2018 11:39:37 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id v66-v6so12673163pgb.10; Tue, 11 Sep 2018 11:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AztiOreLFTVnp8qlmYs7d77Zo4hb46ypdV01KoBYNVM=; b=niJpgLRQAiLjfMqM5FCdsZwkhDG/SE3VUFbgENQM47PgCbFi2oQPrUs7TqEI6CWinC rJD7d7rsDsYa6VhthY3Vj6COPRrppc2JpxMh/ckWQB0foFVMz9zVTKMBrv3Oi6BepELC n8EDI3B01mLOUl09d56jDLv4Dc2ixX1e/hm+9VRb5OXfwADTCYO97okeqk0gUILIvTRY XSe7swH7rOU9jqsWyxXKy3IAb+rOW6w1VNSgyYnluWptvy5qJUqTiCcjLxE8ZBRBb43w tZpoTonYpCKclho7Pu8xDyoJbtmlsJe+ZLJ/MdiFCtOc0QzcvewpSRPPnBOHCXVKFQNC KwoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AztiOreLFTVnp8qlmYs7d77Zo4hb46ypdV01KoBYNVM=; b=ZFS6wRsUSGB1IE2QoBZesvi/WSJdve4xyyMxUV9qYg2dXJ5H+heHrzVRuhOdyG1U7L ygeslVeojp6lNN/ik19BoUP4txvb8tbrGxOPdmJVcyPpvasSbBv3Lu5y7IH/5LNzNLUI YMne3m95hEzO/1/swA4dnLHGYyT8ct3NV829xLJ69VZ5alk6ZD2TRLF19shT+9a/QbdW X/wjW021vgEGRw2Xt0SusXOSw2u9VL5TgzkrjNg0otD+cQCYUhCNR1FZLgbmA/YKku1k kgsk0+SEjz07HV11MMT6At2I22Lndl4cMGSZcOkOIzN37sxXmGDHQqofz0ZfSeDhjbGy 85kQ== X-Gm-Message-State: APzg51CFBmxYueS6Bz9/gve1hqziFI/zVNkAGNuC4IqfyIgj+x+nYbE5 gx0cQHDlYiIJ5h0h1U8WaV8= X-Google-Smtp-Source: ANB0Vdbz48U5j4hJzURxSoCc9bhaz5HViBv0nbqq84RFBq8MQ4UnssLN0IcIfDxlXtXX+LPFnXRCHw== X-Received: by 2002:a63:fa0c:: with SMTP id y12-v6mr30153378pgh.177.1536691177176; Tue, 11 Sep 2018 11:39:37 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id n83-v6sm36696042pfk.19.2018.09.11.11.39.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 11:39:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 11:39:35 -0700 Cc: IETF SecDir , draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk , =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Transfer-Encoding: quoted-printable Message-Id: <5655CB57-721B-4F9C-8F7F-0E38FBA60E0C@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> To: Kyle Rose X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 18:39:47 -0000 > This is definitely clearer. The trust relationships appear to be: >=20 > * A network trusts a particular map server to be authoritative for = the entire EID/RLOC mapping. Yes, a map-server is delegated part of the EID-prefix space for any more = specifics prefixes registered to it. That is what the parent of the = LISP-DDT sends referrals for. > * The map servers trust the LISP-DDT root: they use LISP-DDT to = publish and resolve EID/RLOC mappings, and can directly authenticate = those mappings because they are signed in a hierarchical fashion (like = DNSSEC). Yes. A delegated hierarchy where the parent provides the public-key in = referrals so when the child signs its referrals, it can be verified (by = the map-resolver). > The first is a transitive trust relationship, but this is probably = acceptable because it's only one hop (I'm trusting someone else to = verify a piece of data that has been authenticated end-to-end) and there = is a direct business relationship between the two entities. Right. > The second, if I have the general idea correct, is very much like = DNSSEC or the web CA system in that a compromise of a node in the = signature tree/forest leads to a loss of authenticity for that entire Yep, correct. > subtree. This is not disqualifying: clearly, many standardized systems = have this property. But it's important to state it explicitly so we can = at the very least make the properties clear to operators, and = potentially recommend and/or develop mitigations. Right, that is in the LISP-DDT spec on how map-servers should behave = when they run LISP-DDT. Remember that 6833bis is how the xTRs use the = mapping system to talk to map-resolvers and map-servers (as well as xTR = to xTR for probing and map-replying, etc). > > this complex. But the interfaces between the documents, by which I = mean the requirements they impose on each other, must be made explicit. = When a system achieves complexity warranting design modularity, it=E2=80=99= s >=20 > And they should be by how the reference each other. If you think there = is text that makes assumpiton without a reference to the particular = draft, then we can add it.=20 Do you think (need opinions from the chair), that if we put a document = tree in draft-ietf-lisp-introduction, would that be helpful? The only = drawback is that we may get a circular dependency. But could avoid it by = having: (1) Have lisp-intro point to 6830bis and 6833bis. (2) Have 6830bis and 6833bis point to 6830/6833 (3) And none of the 4 documents point to lisp-intro (obviously RFC6830 = and RFC6833 do not) but the new bis shoud not. But that is not good for the reader, because if someone picks up 6830bis = and realizes they do not want that level of detail, they don=E2=80=99t = know by reading it to go to draft-ietf-lisp-introduction. > What I might recommend is either an augmentation of, or a new document = analogous to (and informationally referencing), = draft-ietf-lisp-introduction that covers the expected security = properties of the overall design and the requirements for each of the = subcomponents in a way that someone can understand without referring to = any document other than the high-level architecture itself. = draft-ietf-lisp-introduction is actually quite good at getting the = general point of LISP across to someone new; I want to see something = similar for LISP's security model. I think that's going to be better = than inserting clarifying text here or there. I've actually read enough = of this stuff at this point that I'm not sure I can enumerate exactly = what's missing where. The threat model document could potentially be = folded into that, but it has to start by painting a picture of the = security that someone new to LISP can quickly understand. I=E2=80=99ll yield to the WG to respond to this. Dino From nobody Tue Sep 11 13:04:17 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA1F131134 for ; Tue, 11 Sep 2018 13:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BmwLkeGfPSdh for ; Tue, 11 Sep 2018 13:04:09 -0700 (PDT) Received: from mail-yw1-xc34.google.com (mail-yw1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (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 8043D1310F0 for ; Tue, 11 Sep 2018 13:04:09 -0700 (PDT) Received: by mail-yw1-xc34.google.com with SMTP id i144-v6so3956313ywc.3 for ; Tue, 11 Sep 2018 13:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mgVF6rwGOfWqWplkx9BB2IUYSs4oPefE6OtBjJJPj/A=; b=GCjk5Wj/l2dA8mvPuB6CkBcqvJUSoFauij5nsRj4XRcbOt2Nj4PQCLWH0C8VCWrUMP XnVHnmUhgDBuU9b5lTdnnycISQqMdIJwAeQoFPQdT97ezV0ITCGCAhQ72ZjqKPf4DTLI DqUItkAZ5q0twpSI73w/QqJXgbQFL4TliN8kKHaUutrTZjKt4lcuwcFZa34xhdB8QO/z tbnKr3Vd+cZo08zD4GKGhv9mCGrs7QzE8vS5K+XhA9XymWTwQXNPtxGkgDjYmN9rwySo uccAjzhIs7WuQgmxps0Z9U6Fk3wASEbYXfG2hOszoJPH/LbmqlLVEfzuhC1oIIbDI72v IQow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mgVF6rwGOfWqWplkx9BB2IUYSs4oPefE6OtBjJJPj/A=; b=aushtf8b782bUXGpPhStxOYdBldPnXcJGdqQtoE/ZEYQaJB85Qf9stTgshEmLxlcRn EChOMIlgODgaiO0oxplOhfeinwrPhrr5N9ODEqh0/1n8gitUIRcWw9usIIEbWeT9ZtHT Af8/RLO0FZHJfvWE5JEKb8HVzhPkx/8RPvGuwk8Ar428QDiD0dujHJvBRNCRMrm5PDDf 9D2WqdiuGoSzBlbmOdneL68rcGkvtML/8S0GR03imO7mMPgMuftiSAkwO6EHVUmIBs7E NNmGVNeMZCj/F/e+J9QSN4/gzv6zyuAKbty7KQgfqWegFL9KJ+edOHJYFObJ9lIkCWsU fP3w== X-Gm-Message-State: APzg51BcJ5Ggj0vsw7UKiciXOwxKXMfYroWcvo5oG/DG2ot0UHIxtFry N0v4ekQurn6uJ9QrlRfJbUgbx1tLs3dDB0kFKGhvAQ== X-Google-Smtp-Source: ANB0VdbOV4qybsFNntmOvNvzSknp9EQsJNOTKaj9vW+46/a4M+ylvWg76R59DsFigK9fFCvxOXqxgmCwpfAwnPygMxQ= X-Received: by 2002:a0d:d1c1:: with SMTP id t184-v6mr13352700ywd.241.1536696248571; Tue, 11 Sep 2018 13:04:08 -0700 (PDT) MIME-Version: 1.0 References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> <8A78EF35-B0E4-43EC-A6B7-EB7DED60210F@gmail.com> In-Reply-To: <8A78EF35-B0E4-43EC-A6B7-EB7DED60210F@gmail.com> From: Albert Cabellos Date: Tue, 11 Sep 2018 22:03:57 +0200 Message-ID: To: Dino Farinacci Cc: aretana.ietf@gmail.com, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000061a7305759dfa16" Archived-At: Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 20:04:16 -0000 --000000000000061a7305759dfa16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi I am not familiar with all the IETF procedures, but lisp-intro has been waiting for a missing reference for 1000+ days and the day it will become RFC it will be referencing an obsolete document. I think that we should make it right, if someone can shepherd me on what to do I=C2=B4ll be happy to work on it. Albert On Tue, Sep 11, 2018 at 6:37 PM Dino Farinacci wrote: > Right now there is no circular dependency. To summarize: > > (1) RFC6830 does not point to 6830bis or lisp-intro. > (2) lisp-intro points to RFC6830. > (3) 6860bis needs to point to RFC6830. > > Let=E2=80=99s please don=E2=80=99t change any this. Let=E2=80=99s not mak= e this more complciated > then it needs to be and let=E2=80=99s not confuse people, especially the = authors. > ;-) > > Dino > > > > On Sep 11, 2018, at 9:29 AM, Alvaro Retana > wrote: > > > > On September 11, 2018 at 9:50:29 AM, Joel M. Halpern ( > jmh@joelhalpern.com) wrote: > > > > Hi! > > > >> Any change to lisp-intro should be done by discussion with the RFC > >> Editor, as it is in the RFC Editor queue (pending reference completion= ). > >> If the working group considers it acceptable, we could easily ask them > >> to change the references to 6830 and 6833 to the bis documents (after > >> all, it is alreay blocked by documents which depend upon those.) > > The reference would still be circular: rfc6830bis would point at > lisp-introduction for architecture details, and that would point back her= e. > > > > If lisp-introduction was just that (an introduction) and the details > were in rfc6830 to start with=E2=80=A6. Maybe the easy fix is to just not= point to > lisp-introduction from rfc6830bis, because the details should be here (an= d > rfc6833bis) already. > > > > s/Finally, [I-D.ietf-lisp-introduction] describes the LISP > architecture.// > > > > Alvaro. > > > > > > > >> > >> > >> Yours, > >> Joel > >> > >> On 9/10/18 11:27 PM, Dino Farinacci wrote: > >> > If you guys have source for the intro doc, I could point it to bis > >> > documents? > >> > > >> > Dino > >> > > >> > > >> > Begin forwarded message: > >> > > >> >> *Resent-From:* alias-bounces@ietf.org>> > >> >> *From:* Alvaro Retana >> >> > > >> >> *Date:* September 10, 2018 at 2:22:21 PM PDT > >> >> *Resent-To:* farinacci@gmail.com , > >> >> vince.fuller@gmail.com , > dmm@1-4-5.net > >> >> , darlewis@cisco.com > >> >> , acabello@ac.upc.edu > >> >> > >> >> *To:* "The IESG" > > >> >> *Cc:* draft-ietf-lisp-rfc6830bis@ietf.org > >> >> , Luigi Iannone > >> >> >, lisp-chairs@ietf.org > >> >> , lisp@ietf.org > >> >> *Subject:* *Alvaro Retana's No Objection on > >> >> draft-ietf-lisp-rfc6830bis-16: (with COMMENT)* > >> >> > >> >> Alvaro Retana has entered the following ballot position for > >> >> draft-ietf-lisp-rfc6830bis-16: No Objection > >> >> > >> >> When responding, please keep the subject line intact and reply to a= ll > >> >> email addresses included in the To and CC lines. (Feel free to cut > this > >> >> introductory paragraph, however.) > >> >> > >> >> > >> >> Please refer to > https://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: > >> >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ > >> >> > >> >> > >> >> > >> >> > ---------------------------------------------------------------------- > >> >> COMMENT: > >> >> > ---------------------------------------------------------------------- > >> >> > >> >> Thanks for the work on this document! > >> >> > >> >> I have some relatively minor comments/nits: > >> >> > >> >> (1) =C2=A718: s/RFC8060/RFC8061 > >> >> > >> >> (2) =C2=A71: "Finally, [I-D.ietf-lisp-introduction] describes the L= ISP > >> >> architecture." First of all, it would seem to me that the > >> >> Architecture should > >> >> be a Normative reference...but I-D.ietf-lisp-introduction says that > it > >> >> "is used > >> >> for introductory purposes, more details can be found in RFC6830, th= e > >> >> protocol > >> >> specification." This document obsoletes rfc6830...so it seems to m= e > >> >> that there > >> >> is a failed circular dependency. > >> >> > >> >> (3) References to rfc2119/rfc8174 and rfc8126 should be Normative. > >> >> > >> >> > >> > >> _______________________________________________ > >> 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 > --000000000000061a7305759dfa16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

I am not familiar with all the IETF = procedures, but lisp-intro has been waiting for a missing reference for 100= 0+ days and the day it will become RFC it will be referencing an obsolete d= ocument.

I think that we should make it right, if = someone can shepherd me on what to do I=C2=B4ll be happy to work on it.

Albert

On Tue, Sep 11, 2018 at 6:37 PM Dino Farinacci <farinacci@gmail.com> wrote:
Right now there is no circular dependency. To s= ummarize:

(1) RFC6830 does not point to 6830bis or lisp-intro.
(2) lisp-intro points to RFC6830.
(3) 6860bis needs to point to RFC6830.

Let=E2=80=99s please don=E2=80=99t change any this. Let=E2=80=99s not make = this more complciated then it needs to be and let=E2=80=99s not confuse peo= ple, especially the authors. ;-)

Dino


> On Sep 11, 2018, at 9:29 AM, Alvaro Retana <aretana.ietf@gmail.com> wrote:<= br> >
> On September 11, 2018 at 9:50:29 AM, Joel M. Halpern (jmh@joelhalpern.com) wrote: >
> Hi!
>
>> Any change to lisp-intro should be done by discussion with the RFC=
>> Editor, as it is in the RFC Editor queue (pending reference comple= tion).
>> If the working group considers it acceptable, we could easily ask = them
>> to change the references to 6830 and 6833 to the bis documents (af= ter
>> all, it is alreay blocked by documents which depend upon those.) > The reference would still be circular: rfc6830bis would point at lisp-= introduction for architecture details, and that would point back here.
>
> If lisp-introduction was just that (an introduction) and the details w= ere in rfc6830 to start with=E2=80=A6. Maybe the easy fix is to just not po= int to lisp-introduction from rfc6830bis, because the details should be her= e (and rfc6833bis) already.
>
> s/Finally, [I-D.ietf-lisp-introduction] describes the LISP architectur= e.//
>
> Alvaro.
>
>
>
>>
>>
>> Yours,
>> Joel
>>
>> On 9/10/18 11:27 PM, Dino Farinacci wrote:
>> > If you guys have source for the intro doc, I could point it t= o bis
>> > documents?
>> >
>> > Dino
>> >
>> >
>> > Begin forwarded message:
>> >
>> >> *Resent-From:* <alias-bounces@ietf.org <mailto:alias-bounces@ietf.org>= >
>> >> *From:* Alvaro Retana <aretana.ietf@gmail.com
>> >> <mailto:aretana.ietf@gmail.com>>
>> >> *Date:* September 10, 2018 at 2:22:21 PM PDT
>> >> *Resent-To:* farinacci@gmail.com <mailto:farinacci@gmail.com>,
>> >> vince.fuller@gmail.com <mailto:vince.fuller@gmail.com>, dmm@1-4-5.net
>> >> <mailto:dmm@1-4-5.net>, darlewis@cisco.com
>> >> <mailto:darlewis@cisco.com>, acabello@ac.upc.edu
>> >> <mailto:acabello@ac.upc.edu>
>> >> *To:* "The IESG" <iesg@ietf.org <mailto:iesg@ietf.org>>
>> >> *Cc:* draft-ietf-lisp-rfc6830bis@ietf.org
>> >> <mailto:draft-ietf-lisp-rfc6830bis@ietf.org>, Lui= gi Iannone
>> >> <gg= x@gigix.net <mailto:ggx@gigix.net>>, lisp-chairs@ietf.org
>> >> <mailto:lisp-chairs@ietf.org>, lisp@ietf.org <mailto:lisp@ietf.org>
>> >> *Subject:* *Alvaro Retana's No Objection on
>> >> draft-ietf-lisp-rfc6830bis-16: (with COMMENT)*
>> >>
>> >> Alvaro Retana has entered the following ballot position f= or
>> >> draft-ietf-lisp-rfc6830bis-16: No Objection
>> >>
>> >> When responding, please keep the subject line intact and = reply to all
>> >> email addresses included in the To and CC lines. (Feel fr= ee to cut this
>> >> introductory paragraph, however.)
>> >>
>> >>
>> >> Please refer to https://w= ww.ietf.org/iesg/statement/discuss-criteria.html
>> >> for more information about IESG DISCUSS and COMMENT posit= ions.
>> >>
>> >>
>> >> The document, along with other ballot positions, can be f= ound here:
>> >> https://datatracker.ie= tf.org/doc/draft-ietf-lisp-rfc6830bis/
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------= -------------
>> >> COMMENT:
>> >> ---------------------------------------------------------= -------------
>> >>
>> >> Thanks for the work on this document!
>> >>
>> >> I have some relatively minor comments/nits:
>> >>
>> >> (1) =C2=A718: s/RFC8060/RFC8061
>> >>
>> >> (2) =C2=A71: "Finally, [I-D.ietf-lisp-introduction] = describes the LISP
>> >> architecture."=C2=A0 First of all, it would seem to = me that the
>> >> Architecture should
>> >> be a Normative reference...but I-D.ietf-lisp-introduction= says that it
>> >> "is used
>> >> for introductory purposes, more details can be found in R= FC6830, the
>> >> protocol
>> >> specification."=C2=A0 This document obsoletes rfc683= 0...so it seems to me
>> >> that there
>> >> is a failed circular dependency.
>> >>
>> >> (3) References to rfc2119/rfc8174 and rfc8126 should be N= ormative.
>> >>
>> >>
>>
>> _______________________________________________
>> 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
--000000000000061a7305759dfa16-- From nobody Tue Sep 11 13:52:02 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4828130DE4 for ; Tue, 11 Sep 2018 13:52:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 R1tXKLvZzC9p for ; Tue, 11 Sep 2018 13:51:57 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (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 727B8130DE5 for ; Tue, 11 Sep 2018 13:51:57 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id m11-v6so50003437oic.2 for ; Tue, 11 Sep 2018 13:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7YgSX8SoM6FDfuUG3FaSfNZOZjYL14O3cUBWGzO93dc=; b=TThq8ynYIs5YagmgvxKZhal0fPcpihAp0L1tNP8XiwjrEyFsDU5AP95EMuVBMAgP5p 9HTxFYNH01GbHRhNCAgbZ0p+wB8dNey1XtpBbOZU3PFmiuWVU5TB2JQ97zCNX7FmKwIC IxVjDrzwUSr/PcEy/nkp7jGoDSlNvXsA+nM7CqNFvsxq2r+6xPJHjTIKp4dSASr5rSBC VF5B0/PGoxJQHKXuGDFCVI+Ufatb4GOo/Hu1UhbnRXcNcshQifha9Ee/CHSrlwwMHNS8 aUGbxdB/J0IoTfEHaW6ICuXN7r0qULcJbqlYa/LFdr6Mhr7Bc1YsWKlu36giY3+48qK8 fc5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7YgSX8SoM6FDfuUG3FaSfNZOZjYL14O3cUBWGzO93dc=; b=GE0ROKQSDWTwIUAZY6gNxXXyqnGTkkAcP/2HxkdV97lzdMMe+RoMreRc2YYgjL26+5 Ay+kdvF1Sv33PXeEWhmAlDztClvVxVmuZc+kbHbMiSWoYzacEI0RBjStHTHuGNP9IbIA 7K53eEAOIF/ChesbkT836YKrizm8Ui4RWlzjp0ZVipcFkvLTE5du+snYQLV0vAsiKbp3 0cjALqT9Gj7KZFJj5v32/y77K8xlpbnbP4G8rd0PCGjv8Zp52lu7tnsVZNRK3nopX3A7 Ol/UZg9as4Lzyi1wgiBnAKy3IGye1nEdFTeEPNvADTeJ09AnSPhs9S7pwuVV8ZE/6DMz U2Bw== X-Gm-Message-State: APzg51CnhiSvP8/s43qpe2GyE91MwrbhyWbAEUOI8+fndvNs+LWs8CeM RQy/5Cc4OdGkL8CvUiFlPis= X-Google-Smtp-Source: ANB0VdZfGOE7xZISVZXiUeXXgEC4RMl7qUtRXQTtSw5dHQVsI5v6E0tWAsbuCObXKjjHcSgAKVCQoQ== X-Received: by 2002:aca:4dca:: with SMTP id a193-v6mr27527817oib.343.1536699116818; Tue, 11 Sep 2018 13:51:56 -0700 (PDT) Received: from dino-macbook.attlocal.net (adsl-108-94-2-123.dsl.pltn13.sbcglobal.net. [108.94.2.123]) by smtp.gmail.com with ESMTPSA id o9-v6sm16437258oia.21.2018.09.11.13.51.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 13:51:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 13:51:54 -0700 Cc: aretana.ietf@gmail.com, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <446E0FA7-359C-44EF-8855-01AA87C2CAFD@gmail.com> References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> <8A78EF35-B0E4-43EC-A6B7-EB7DED60210F@gmail.com> To: Albert Cabellos X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 20:52:01 -0000 The bottleneck is lisp-sec. So no matter what happens to 6830bis or = 6833bis, it may not change that. Yes, we should do the right thing. Dino > On Sep 11, 2018, at 1:03 PM, Albert Cabellos = wrote: >=20 > Hi >=20 > I am not familiar with all the IETF procedures, but lisp-intro has = been waiting for a missing reference for 1000+ days and the day it will = become RFC it will be referencing an obsolete document. >=20 > I think that we should make it right, if someone can shepherd me on = what to do I=C2=B4ll be happy to work on it. >=20 > Albert >=20 > On Tue, Sep 11, 2018 at 6:37 PM Dino Farinacci = wrote: > Right now there is no circular dependency. To summarize: >=20 > (1) RFC6830 does not point to 6830bis or lisp-intro. > (2) lisp-intro points to RFC6830. > (3) 6860bis needs to point to RFC6830. >=20 > Let=E2=80=99s please don=E2=80=99t change any this. Let=E2=80=99s not = make this more complciated then it needs to be and let=E2=80=99s not = confuse people, especially the authors. ;-) >=20 > Dino >=20 >=20 > > On Sep 11, 2018, at 9:29 AM, Alvaro Retana = wrote: > >=20 > > On September 11, 2018 at 9:50:29 AM, Joel M. Halpern = (jmh@joelhalpern.com) wrote: > >=20 > > Hi! > >=20 > >> Any change to lisp-intro should be done by discussion with the RFC=20= > >> Editor, as it is in the RFC Editor queue (pending reference = completion). > >> If the working group considers it acceptable, we could easily ask = them=20 > >> to change the references to 6830 and 6833 to the bis documents = (after=20 > >> all, it is alreay blocked by documents which depend upon those.) > > The reference would still be circular: rfc6830bis would point at = lisp-introduction for architecture details, and that would point back = here. > >=20 > > If lisp-introduction was just that (an introduction) and the details = were in rfc6830 to start with=E2=80=A6. Maybe the easy fix is to just = not point to lisp-introduction from rfc6830bis, because the details = should be here (and rfc6833bis) already. > >=20 > > s/Finally, [I-D.ietf-lisp-introduction] describes the LISP = architecture.// > >=20 > > Alvaro. > >=20 > >=20 > >=20 > >>=20 > >>=20 > >> Yours, > >> Joel > >>=20 > >> On 9/10/18 11:27 PM, Dino Farinacci wrote: > >> > If you guys have source for the intro doc, I could point it to = bis=20 > >> > documents? > >> >=20 > >> > Dino > >> >=20 > >> >=20 > >> > Begin forwarded message: > >> >=20 > >> >> *Resent-From:* > > >> >> *From:* Alvaro Retana >> >> > > >> >> *Date:* September 10, 2018 at 2:22:21 PM PDT > >> >> *Resent-To:* farinacci@gmail.com ,=20= > >> >> vince.fuller@gmail.com , = dmm@1-4-5.net=20 > >> >> , darlewis@cisco.com=20 > >> >> , acabello@ac.upc.edu=20 > >> >> > >> >> *To:* "The IESG" > > >> >> *Cc:* draft-ietf-lisp-rfc6830bis@ietf.org=20 > >> >> , Luigi Iannone=20 > >> >> >, lisp-chairs@ietf.org=20 > >> >> , lisp@ietf.org = > >> >> *Subject:* *Alvaro Retana's No Objection on=20 > >> >> draft-ietf-lisp-rfc6830bis-16: (with COMMENT)* > >> >> > >> >> Alvaro Retana has entered the following ballot position for > >> >> draft-ietf-lisp-rfc6830bis-16: No Objection > >> >> > >> >> 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 = https://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: > >> >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ > >> >> > >> >> > >> >> > >> >> = ---------------------------------------------------------------------- > >> >> COMMENT: > >> >> = ---------------------------------------------------------------------- > >> >> > >> >> Thanks for the work on this document! > >> >> > >> >> I have some relatively minor comments/nits: > >> >> > >> >> (1) =C2=A718: s/RFC8060/RFC8061 > >> >> > >> >> (2) =C2=A71: "Finally, [I-D.ietf-lisp-introduction] describes = the LISP > >> >> architecture." First of all, it would seem to me that the=20 > >> >> Architecture should > >> >> be a Normative reference...but I-D.ietf-lisp-introduction says = that it=20 > >> >> "is used > >> >> for introductory purposes, more details can be found in RFC6830, = the=20 > >> >> protocol > >> >> specification." This document obsoletes rfc6830...so it seems = to me=20 > >> >> that there > >> >> is a failed circular dependency. > >> >> > >> >> (3) References to rfc2119/rfc8174 and rfc8126 should be = Normative. > >> >> > >> >> > >>=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 Sep 11 13:58:58 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D64130DE4; Tue, 11 Sep 2018 13:58:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153669953045.16975.4688190807424189159@ietfa.amsl.com> Date: Tue, 11 Sep 2018 13:58:50 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 11 Sep 2018 20:58:51 -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 WG of the IETF. Title : Locator/ID Separation Protocol (LISP) Control-Plane Authors : Vince Fuller Dino Farinacci Albert Cabellos Filename : draft-ietf-lisp-rfc6833bis-14.txt Pages : 49 Date : 2018-09-11 Abstract: This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases. By using this Control-Plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems, which facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP Control-Plane infrastructure, connect directly to LISP-capable Internet end sites, and comprising the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. This document obsoletes RFC 6830 and 6833. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-14 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-14 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 Tue Sep 11 14:13:49 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23066130DE5 for ; Tue, 11 Sep 2018 14:13:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 x2pKusEXkr3v for ; Tue, 11 Sep 2018 14:13:46 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 A1708130DDE for ; Tue, 11 Sep 2018 14:13:46 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id l202-v6so50043431oig.7 for ; Tue, 11 Sep 2018 14:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e7TGgVNgT3fIsr/rqcyL3XUNOSVELWTDbZebMpuNoMk=; b=kkDYHqYEeMy9WwG416zUEjP8LRKHUiDq9CKAi3+KA5DwjTELlGVl5eL2+CKOtCpXNS STky7q7eJj3tX8cGjm3ybJuhDppSYdEpXgqZICAafcT6uXHImABDaroBQg1nT9ZQxpBw lRQt1fEbWC4nkMT/WyqSU/i73jGB7LJwEubdjYz2ZXYcxB1hQ9Eh5up8kT71qm3uO6eF RG2sp+npFWtagspG4m6VchbeFbzLB5ABBBz7pblj97WdJLb23IaBdlyI7d1MM6f4T8/+ VodBV4KJTSL/4PZFVi57JaFq61uqkDao+f1brFVBwXVDq81D5p6X6VwKPHRAgb4XXBgv txXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e7TGgVNgT3fIsr/rqcyL3XUNOSVELWTDbZebMpuNoMk=; b=Qofe95tMV+sty1gRU9Nk3CgWAglZfkY8ASd9MA7+kTkrXXdKOTgjbe6uvCh5SpqYA3 hHYYwEjAerNvO1wr7NZw+EMBu2021SBD8WLtqa7WRRMQ6XT6gEDfNP4+twZRPel88GLJ 9MZPy0+weCEjLhwUNsOIy7UFOL0LL1okXire4IThqhj0fUpg36M1l3MRQwvWAjnLqGB9 b0beu8rcM0i4Xgwd0CDQfKGI5lIYL++4ADK/C0H2glr4V3cvfSRJdAEEz4g1R+CMuPcF pdJgsK0ASp7yqXR8RoZJl2MoSDUPWXsqpICmvd7/T7st3Mqa323KZ9a0vT1Yoqov6DiF 4mRQ== X-Gm-Message-State: APzg51C2Vfiivf+hkDIW2lrBqoKqsnhiSihCPZ5xNJ3qDKQKqYiy5tLY 9kv7RUsaHPSOn08CL82DNPM= X-Google-Smtp-Source: ANB0Vdb75nOMNxD/pl2p5auVXvv5TOQFcvBg7fv45yHCCrdmPuUTU1Yy1Fqr17jILumzTppb9mKiiA== X-Received: by 2002:aca:1112:: with SMTP id 18-v6mr30419701oir.79.1536700425946; Tue, 11 Sep 2018 14:13:45 -0700 (PDT) Received: from dino-macbook.attlocal.net (adsl-108-94-2-123.dsl.pltn13.sbcglobal.net. [108.94.2.123]) by smtp.gmail.com with ESMTPSA id p7-v6sm25228886oif.35.2018.09.11.14.13.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 14:13:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 14:13:43 -0700 Cc: Albert Cabellos , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <7DD44D1F-06E5-494D-B760-B1462FD9DC01@gmail.com> References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> <8A78EF35-B0E4-43EC-A6B7-EB7DED60210F@gmail.com> To: "BRUNGARD, DEBORAH A" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 21:13:48 -0000 > I don=E2=80=99t see lisp-sec as essential to implementing lisp-intro. = I don=E2=80=99t know why it was listed as normative? To me, it is = providing additional information. I agree LISP-SEC is additional information for an introductory document. = You bring up a good point. > If the working group agrees, I can check with the RFC-Editor if can = move lisp-security to informative. I think the change will only need = author and AD approval. Does anyone have any concerns? Or is = lisp-security =E2=80=9Calmost done=E2=80=9D and should continue to wait? I agree with your proposal. But have another question. If we update the = lisp-intro to move this reference to Informative, do you at the same = time change all occurences of 6830/6833 to the bis document equivalents = or do you want to push lisp-intro through? I would say go for the latter since the information in 6830/6833 has not = changed when shuffling sections around into 6830bis/6833bis. So Albert, = the information in RFC6830 is not obsoleted but the document may be. What do you think? Dino= From nobody Tue Sep 11 14:29:41 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62AE130DDE; Tue, 11 Sep 2018 14:29:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6p-3hYcX0kGL; Tue, 11 Sep 2018 14:29:37 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 03042129C6B; Tue, 11 Sep 2018 14:29:37 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id b15-v6so50109656oib.10; Tue, 11 Sep 2018 14:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ryo7IxBDHlS78lfTDZXopTLzyPEMZVgvpKjCgLEToSU=; b=IUJm97doT/LyIo/Qr041Ra4WMkGrAZi/cAatkMIXTm8W3PQvPFtp/8LCps1Vhlufi/ pMAq5WFHtCmlMSHn1NSatyW8UnVNRAlDN4ty1H5qYv7y5BzUYQ0VzQ5jM3pXUkagAcXZ XWg51TlltLXX5ARF+Vq2+Jndze7ZWVV0r2mM+HtgazUDCcyFWw5vn5hKoOXxTWSxQFtE gISkTik0eToWQkxneA6wDUOfzXYvNPPcXhAN2iicJ/hZJQiwsUSHdvlDCEJnZqZZo+Bo lieRUbe3fy2EzhC5iy7FvlZLj6ZYeryBIF40UTscURsELvwUcXdXA68c8L1/NXLuJ2VX fhlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ryo7IxBDHlS78lfTDZXopTLzyPEMZVgvpKjCgLEToSU=; b=L0f8intDsZtddNZSkAA4aqEukOy1W7xQEUzpMIZxl+Q5+4vHfLm+gZvlHyty1CT1s0 ildimomc2T8nxRP8wC75puL3Wp7/+HyYvgXG6Q1ANBJyxwftvabJBlg9f49/H/l8+2Sb rTB3kjcu8rHxPweXsWQzPWcEQjMiXvlxdN51ZO8/Cfx0GujRi67TZoRIyskonVlTWH6B UpE42sUIqQVzEDZCkR35UkA02h21kS387jZrBMaOqvrHc3NLNZGLqrwm4G44gAsuLE2H YCp2thtXjO0bcL/JZRpzNz7w9GaDOfF/tMlnbuviR+j6nD52F1ry4DOZ+Hf3uEgRE3/v wb2A== X-Gm-Message-State: APzg51BlsG1Ej1R1KgWQLnNZzvNp0pKMZ0AU3MWqb/QbrTZITtjTCZ1A O4Zeosz+WodEXOpNY/4W8WY= X-Google-Smtp-Source: ANB0Vda3bJjwJIZQyOnC2J23PzmYrrYeEaKQ+00X0PRvlIXSsY4N7rDJfFVnXc8pRRHHW7TdBpPe+g== X-Received: by 2002:aca:bc54:: with SMTP id m81-v6mr30024058oif.308.1536701376402; Tue, 11 Sep 2018 14:29:36 -0700 (PDT) Received: from dino-macbook.attlocal.net (adsl-108-94-2-123.dsl.pltn13.sbcglobal.net. [108.94.2.123]) by smtp.gmail.com with ESMTPSA id c9-v6sm29425773oia.1.2018.09.11.14.29.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 14:29:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <9807BB97-D034-4169-9BBC-366D66164238@gigix.net> Date: Tue, 11 Sep 2018 14:29:32 -0700 Cc: "lisp@ietf.org list" , Erik Nordmark , lisp-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153608761426.14137.783984991533026116@ietfa.amsl.com> <9807BB97-D034-4169-9BBC-366D66164238@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 21:29:39 -0000 As an co-author, I support making this document a WG draft. Thanks, Dino > On Sep 5, 2018, at 12:48 AM, Luigi Iannone wrote: >=20 >=20 >=20 >> On 5 Sep 2018, at 09:46, Luigi Iannone wrote: >>=20 >> Folks, >>=20 >> As you can see from Dino=E2=80=99s email (below) the authors are = requesting that the document >>=20 >> https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ >>=20 >> be adopted as WG item. >>=20 >> This email starts the usual 14 days call for adoption, this call will = end on >> Thursday the 19th September, 2018. >=20 > Small typo in the ending date: Wednesday 19th September, 2018. >=20 > Ciao >=20 > L. >=20 >=20 >=20 >>=20 >> Please email the WG list stating whether or not you support = acceptance. >>=20 >> If you email to support the acceptance of this document as a WG item, = please >> also indicate if you are able and willing to either contribute to, or = review, (or both) the draft. >>=20 >> Sitting in silence does not indicate support, please respond = appropriately. >>=20 >> The Chairs >> Joel & Luigi >>=20 >>=20 >>> On 4 Sep 2018, at 21:05, Dino Farinacci wrote: >>>=20 >>> Folks, here is an update that reflects comments we received at the = Montreal presentation: >>>=20 >>> >>>=20 >>> A diff file is included for your convenience.=20 >>>=20 >>> At this time, I would like to request this document for working = group adoption. >>>=20 >>> Thanks, >>> Dino/Erik >>>=20 >>> >>>=20 >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> From: internet-drafts@ietf.org >>>> Subject: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt >>>> Date: September 4, 2018 at 12:00:14 PM PDT >>>> To: >>>> Reply-To: internet-drafts@ietf.org >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>=20 >>>>=20 >>>> Title : LISP Control-Plane ECDSA Authentication = and Authorization >>>> Authors : Dino Farinacci >>>> Erik Nordmark >>>> Filename : draft-farinacci-lisp-ecdsa-auth-03.txt >>>> Pages : 17 >>>> Date : 2018-09-04 >>>>=20 >>>> Abstract: >>>> This draft describes how LISP control-plane messages can be >>>> individually authenticated and authorized without a a priori = shared- >>>> key configuration. Public-key cryptography is used with no new = PKI >>>> infrastructure required. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ >>>>=20 >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03 >>>> = https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecdsa-auth-03 >>>>=20 >>>> A diff from the previous version is available at: >>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-ecdsa-auth-03 >>>>=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 >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 From nobody Tue Sep 11 14:56:15 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDB5130F39; Tue, 11 Sep 2018 14:56:06 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 EaRWa5dsPOMN; Tue, 11 Sep 2018 14:56:04 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0B9130F1F; Tue, 11 Sep 2018 14:56:04 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w8BLkKar031045; Tue, 11 Sep 2018 17:56:03 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 2memkgb9gp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Sep 2018 17:56:02 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8BLu1ft015276; Tue, 11 Sep 2018 17:56:01 -0400 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [135.66.87.31]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8BLtstJ015182; Tue, 11 Sep 2018 17:55:54 -0400 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [127.0.0.1]) by zlp27127.vci.att.com (Service) with ESMTP id C982640F6CEA; Tue, 11 Sep 2018 21:55:54 +0000 (GMT) Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (unknown [130.9.129.145]) by zlp27127.vci.att.com (Service) with ESMTPS id B5A2840F6CE9; Tue, 11 Sep 2018 21:55:54 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.139]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0415.000; Tue, 11 Sep 2018 17:55:53 -0400 From: "BRUNGARD, DEBORAH A" To: Dino Farinacci , Kyle Rose CC: IETF SecDir , "draft-ietf-lisp-rfc6830bis.all@ietf.org" , IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: Secdir last call review of draft-ietf-lisp-rfc6830bis-15 Thread-Index: AQHUO+Fnc6omHwFs2E2jTDlX3tDS/6TRQ7aAgAS5MACAAAgsgIAUsDQAgADel4CAABPTAIAABHeAgAAZvoCAAAL5gP//zXPg Date: Tue, 11 Sep 2018 21:55:53 +0000 Message-ID: References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> <5655CB57-721B-4F9C-8F7F-0E38FBA60E0C@gmail.com> In-Reply-To: <5655CB57-721B-4F9C-8F7F-0E38FBA60E0C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.164.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-11_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809110214 Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 21:56:07 -0000 VGhhbmtzIG11Y2ggS3lsZSBmb3IgeW91ciBjb21tZW50cyBhbmQgRGlubyBmb3IgcmVzb2x2aW5n IQ0KDQpDdXR0aW5nIHRvIHRoZSBlbmQgd2hlcmUgRGlubyBhc2tlZCBmb3IgaGVscC0NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lA Z21haWwuY29tPiANClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMSwgMjAxOCAyOjQwIFBNDQpU bzogS3lsZSBSb3NlIDxrcm9zZUBrcm9zZS5vcmc+DQpDYzogSUVURiBTZWNEaXIgPHNlY2RpckBp ZXRmLm9yZz47IGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMwYmlzLmFsbEBpZXRmLm9yZzsgSUVURiBE aXNjdXNzaW9uIE1haWxpbmcgTGlzdCA8aWV0ZkBpZXRmLm9yZz47IGxpc3BAaWV0Zi5vcmcgbGlz dCA8bGlzcEBpZXRmLm9yZz47IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PjsgTWlyamEg S8O8aGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5ldD4NClN1YmplY3Q6IFJlOiBTZWNkaXIgbGFz dCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWxpc3AtcmZjNjgzMGJpcy0xNQ0KDQoNCj4gV2hh dCBJIG1pZ2h0IHJlY29tbWVuZCBpcyBlaXRoZXIgYW4gYXVnbWVudGF0aW9uIG9mLCBvciBhIG5l dyBkb2N1bWVudCBhbmFsb2dvdXMgdG8gKGFuZCBpbmZvcm1hdGlvbmFsbHkgcmVmZXJlbmNpbmcp LCBkcmFmdC1pZXRmLWxpc3AtaW50cm9kdWN0aW9uIHRoYXQgY292ZXJzIHRoZSBleHBlY3RlZCBz ZWN1cml0eSBwcm9wZXJ0aWVzIG9mIHRoZSBvdmVyYWxsIGRlc2lnbiBhbmQgdGhlIHJlcXVpcmVt ZW50cyBmb3IgZWFjaCBvZiB0aGUgc3ViY29tcG9uZW50cyBpbiBhIHdheSB0aGF0IHNvbWVvbmUg Y2FuIHVuZGVyc3RhbmQgd2l0aG91dCByZWZlcnJpbmcgdG8gYW55IGRvY3VtZW50IG90aGVyIHRo YW4gdGhlIGhpZ2gtbGV2ZWwgYXJjaGl0ZWN0dXJlIGl0c2VsZi4gZHJhZnQtaWV0Zi1saXNwLWlu dHJvZHVjdGlvbiBpcyBhY3R1YWxseSBxdWl0ZSBnb29kIGF0IGdldHRpbmcgdGhlIGdlbmVyYWwg cG9pbnQgb2YgTElTUCBhY3Jvc3MgdG8gc29tZW9uZSBuZXc7IEkgd2FudCB0byBzZWUgc29tZXRo aW5nIHNpbWlsYXIgZm9yIExJU1AncyBzZWN1cml0eSBtb2RlbC4gSSB0aGluayB0aGF0J3MgZ29p bmcgdG8gYmUgYmV0dGVyIHRoYW4gaW5zZXJ0aW5nIGNsYXJpZnlpbmcgdGV4dCBoZXJlIG9yIHRo ZXJlLiBJJ3ZlIGFjdHVhbGx5IHJlYWQgZW5vdWdoIG9mIHRoaXMgc3R1ZmYgYXQgdGhpcyBwb2lu dCB0aGF0IEknbSBub3Qgc3VyZSBJIGNhbiBlbnVtZXJhdGUgZXhhY3RseSB3aGF0J3MgbWlzc2lu ZyB3aGVyZS4gVGhlIHRocmVhdCBtb2RlbCBkb2N1bWVudCBjb3VsZCBwb3RlbnRpYWxseSBiZSBm b2xkZWQgaW50byB0aGF0LCBidXQgaXQgaGFzIHRvIHN0YXJ0IGJ5IHBhaW50aW5nIGEgcGljdHVy ZSBvZiB0aGUgc2VjdXJpdHkgdGhhdCBzb21lb25lIG5ldyB0byBMSVNQIGNhbiBxdWlja2x5IHVu ZGVyc3RhbmQuDQoNCknigJlsbCB5aWVsZCB0byB0aGUgV0cgdG8gcmVzcG9uZCB0byB0aGlzLg0K DQpEaW5vDQoNCltkZWJvcmFoXSANCg0KSXQncyBkaWZmaWN1bHQgdG8gZG8gKm9uZSogb3ZlcnZp ZXcgZG9jdW1lbnQgb24gYW4gZXZvbHZpbmcgdGVjaG5vbG9neSwgZXNwZWNpYWxseSBpZiB0aGUg aW50ZW50aW9uIGlzIHRvIHByb3ZpZGUgcmVmZXJlbmNlIHRvIG90aGVyIGRvY3VtZW50cyB3aGlj aCBhcmUgYWxzbyBldm9sdmluZy4gTGlzcC1pbnRybyBpcyBhbHJlYWR5IGhhdmluZyBpdHMgcHJv YmxlbXMgYW5kIGl0IGlzIG5vdCBwdWJsaXNoZWQgeWV0Lg0KDQpBcyBNYXJrIE5vdHRpbmdoYW0g bm90ZWQgaW4gaGlzICJIb3cgdG8gUmVhZCBhbiBSRkMiIGJsb2csIHdoZW4gcmVhZGluZyBSRkNz LCBmb3IgYmV0dGVyIG9yIHdvcnNlIGFuZCB0aGUgcmVzdWx0aW5nIGZydXN0cmF0aW9uLCBpdCBp cyAibmVjZXNzYXJ5IHRvIHJlYWQgbm90IG9ubHkgdGhlIHJlbGV2YW50IHRleHQgYnV0IGFsc28g YW55dGhpbmcgdGhhdCBpdCByZWZlcmVuY2VzIjoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2Jsb2cv aG93LXJlYWQtcmZjLw0KDQpJJ2Qgc3VnZ2VzdCBhIHdpa2kgd291bGQgYmUgYSBiZXR0ZXIgdG9v bCB0byBjYXB0dXJlIHRoaXMgIm92ZXJ2aWV3IiBpbmZvcm1hdGlvbmFsIG1hdGVyaWFsLiBOb3Qg b25seSBjYW4gdGhlIGZvcm1hdCBiZSBlYXNpZXIgb24gdGhlIGV5ZSwgaXQgY2FuIGJlIGEgc2hh cmVkIGVmZm9ydCBhbmQgdGltZWx5IHVwZGF0ZWQuIFNpbWlsYXIgdG8gQmVub2l0J3Mgd29yayBv biBoaXMgWUFORyB0cmVlIGRlcGVuZGVuY2llcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiBhIHdv cmtpbmcgZ3JvdXAgcHJvdmlkZWQgYSB3b3JraW5nIGdyb3VwIHRyZWUgb2YgZG9jdW1lbnRzIGFu ZCBpdCBjb3VsZCBldmVuIHJlZmVyZW5jZSBvdGhlciB3b3JraW5nIGdyb3VwIGRvY3VtZW50cy4N Cg0K From nobody Tue Sep 11 15:04:40 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C785130F3C for ; Tue, 11 Sep 2018 15:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nexus-io.20150623.gappssmtp.com 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 8lHwMujtY3Gs for ; Tue, 11 Sep 2018 15:04:36 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 19F6E130F1F for ; Tue, 11 Sep 2018 15:04:35 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id l202-v6so50283207oig.7 for ; Tue, 11 Sep 2018 15:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexus-io.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KNko2N4gS8sKmsKBjkT3BG8XdZf9r26X7gDbQ81kIdc=; b=ND0BJERiRIcV49ClIh/TYWlDKUqzTr1Cn31TGHr5oHsHpZvdkjwneipqG7UBWfhG+k 6Sw8scCU6deRJyCsFDmC3BhC99zYoK2TtVV0gFnSsp1QhFDrWzj5O5hwyYJqVJRRdW4s fX4OVJpByaPH2uFUL+D1IPQxC0Mb7tp66WFJuDe5ua19Wwp0VGz4lptfWQRcVcKwq67q nULybNr+IBsKCKDxzMBpzST/zuaYWamJ1b8PGiNZ1mc6iZQyBchKpl8Xy02XQxYewyt6 yPh/8DUPJUXTr1qMS6dQLoGLupgG95J+prjFfX9dfQtx/PRX+0/k02/xcASG5Sd0U0tg 59tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KNko2N4gS8sKmsKBjkT3BG8XdZf9r26X7gDbQ81kIdc=; b=WHefuZtTi3w8n7Z0MUvZt2QLlD9TwPW++ZiIO+yXl8dv6SVKeGWtr4U+Jjb2tYH/iN hyrHPknwa9tkMhbzatEqpMxMjRyL5OwbFhu2MYcaT7a+WU6wezYvg8g1QhdmMn4hdK5r G2fMS4P4kw7jbPwLG1w6PEVXbOyvnD6b92Opbw2mKwbxfN437kiaje5I7+HOQfGYF+ls RRzuSPF+AWEFIfjYXOZbq8YoMW4o6UI+VXONocTQeMsY+a0T9mMehJrtMWIkLzhtWl4h TCW9W1xmTR6tvbcBNwhohhPOGy7FJnjjNRywRWWsomAi21CuRgiGshYU4z1OuNqECoBA OCPw== X-Gm-Message-State: APzg51DioJnAQwJUIti1SQOmwLWkcI2k1pX/LkxJYGh96Ykpa8Pwg4uk 3YK1VsHDbnhOR8zt0m+n2uXcnQ== X-Google-Smtp-Source: ANB0VdbVppEXZeTWoT4BtFw4aw2zI0Q/aZAz7RKpjfBc4FfdcT1GpiLKXzGhks9bpfEFWgLHWO7nBQ== X-Received: by 2002:aca:3d83:: with SMTP id k125-v6mr27107821oia.86.1536703475129; Tue, 11 Sep 2018 15:04:35 -0700 (PDT) Received: from [192.168.0.102] (24-156-94-99.sdoncmtk01.res.dyn.suddenlink.net. [24.156.94.99]) by smtp.gmail.com with ESMTPSA id w13-v6sm17840949oiw.51.2018.09.11.15.04.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 15:04:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Colin Cantrell X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Tue, 11 Sep 2018 15:04:33 -0700 Cc: Luigi Iannone , "lisp@ietf.org list" , Erik Nordmark , lisp-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <898DD6CB-C75D-45AD-A61A-8365AFE81B04@nexus.io> References: <153608761426.14137.783984991533026116@ietfa.amsl.com> <9807BB97-D034-4169-9BBC-366D66164238@gigix.net> To: Dino Farinacci Archived-At: Subject: Re: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 22:04:39 -0000 I support making this document a WG draft Cheers, Colin Cantrell > On Sep 11, 2018, at 2:29 PM, Dino Farinacci wrote: >=20 > As an co-author, I support making this document a WG draft. >=20 > Thanks, > Dino >=20 >> On Sep 5, 2018, at 12:48 AM, Luigi Iannone wrote: >>=20 >>=20 >>=20 >>> On 5 Sep 2018, at 09:46, Luigi Iannone wrote: >>>=20 >>> Folks, >>>=20 >>> As you can see from Dino=E2=80=99s email (below) the authors are request= ing that the document >>>=20 >>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ >>>=20 >>> be adopted as WG item. >>>=20 >>> This email starts the usual 14 days call for adoption, this call will en= d on >>> Thursday the 19th September, 2018. >>=20 >> Small typo in the ending date: Wednesday 19th September, 2018. >>=20 >> Ciao >>=20 >> L. >>=20 >>=20 >>=20 >>>=20 >>> Please email the WG list stating whether or not you support acceptance. >>>=20 >>> If you email to support the acceptance of this document as a WG item, pl= ease >>> also indicate if you are able and willing to either contribute to, or re= view, (or both) the draft. >>>=20 >>> Sitting in silence does not indicate support, please respond appropriate= ly. >>>=20 >>> The Chairs >>> Joel & Luigi >>>=20 >>>=20 >>>> On 4 Sep 2018, at 21:05, Dino Farinacci wrote: >>>>=20 >>>> Folks, here is an update that reflects comments we received at the Mont= real presentation: >>>>=20 >>>> >>>>=20 >>>> A diff file is included for your convenience.=20 >>>>=20 >>>> At this time, I would like to request this document for working group a= doption. >>>>=20 >>>> Thanks, >>>> Dino/Erik >>>>=20 >>>> >>>>=20 >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Subject: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt >>>>> Date: September 4, 2018 at 12:00:14 PM PDT >>>>> To: >>>>> Reply-To: internet-drafts@ietf.org >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>>>=20 >>>>>=20 >>>>> Title : LISP Control-Plane ECDSA Authentication and Au= thorization >>>>> Authors : Dino Farinacci >>>>> Erik Nordmark >>>>> Filename : draft-farinacci-lisp-ecdsa-auth-03.txt >>>>> Pages : 17 >>>>> Date : 2018-09-04 >>>>>=20 >>>>> Abstract: >>>>> This draft describes how LISP control-plane messages can be >>>>> individually authenticated and authorized without a a priori shared- >>>>> key configuration. Public-key cryptography is used with no new PKI >>>>> infrastructure required. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ >>>>>=20 >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03 >>>>> https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecdsa-auth-= 03 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-ecdsa-auth-03= >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of subm= ission >>>>> 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 >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>=20 >=20 From nobody Tue Sep 11 15:37:25 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3442130EF7 for ; Tue, 11 Sep 2018 15:37:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oaJjvCVsaIGK for ; Tue, 11 Sep 2018 15:37:20 -0700 (PDT) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 93CEB127AC2 for ; Tue, 11 Sep 2018 15:37:20 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id d34-v6so10097907yba.3 for ; Tue, 11 Sep 2018 15:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jxfFBwr/IDXC3IwfzQpxbVuU6oir+8N7mA95huarttI=; b=Og5JxBjvVLDInPbHX/n8I/15Q+0mn9w1Mm8KBPdC2JJjSGqQGuGHco/c2MnDMOzZZj psTq8jlmK4w8ZArc3G1Mx35i5PmyR5VojSUGfADw4tY9Q61QnMeQnP1q0iWgl+a3iGbR ncQNcfc9UHF9FQOQH8VQ5uvehPsHvELc30FWjmueFIZu0rOSu3x8rtowiNZ90nSY5KJR jY6JlxFoVj6n2LCywDv1hLeCtR4+Fydb1dzntb4x77c0zJD//pE/ukXyoJxiKKQAsSUS M405JC3jE2nRcelPFtHVFcR8hUdYuTqCymadMSJLeOBPZAs724juvGblRF20aC6+JiI2 FdnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jxfFBwr/IDXC3IwfzQpxbVuU6oir+8N7mA95huarttI=; b=ZudsnlFgxUCUFvjwIb1G3px9+6fEBpVNmzyGG9VP3sQpB1SysFDbg6m42OOu9HGgU6 vrxp+XJEV5pyKYV7FC95GgGkOVUq/KKU7YkNimRU+eYyKYB6spJYBgtjkwNGFiQXAajg cTcBErsdRPw/sR8B9kEDVfktO7Lq0syEJMGPx8NwAtcZ7SSLwbZRC9Ka+YrcuYOyX5UG 56Qn+zwhPZ4glbBzZa0nOfOfyhmJtSWLX69TQEZG2JOBWWJBUojDD7t6igOQNjhBp6hP 2aLo9x3u5RnDD6ZAO2lsmU27OF72UNPkdAbcjqxLaCZUJHfQcL+I+wTYlW1ALqj23evT O6Kg== X-Gm-Message-State: APzg51CK7c8E2onGwSqdmPCaxI0AcQewfKH1dquYkWtBjIoPmb2MMG5e KE5PTN7m/cYQYaT15u55QQOONFJ4y9N7kY1BZFI= X-Google-Smtp-Source: ANB0VdbBaElbIDwWYxgf3oWS8Ce/9+bq5ivKePJnA8wA/BRgKLDED/Vc/xmyGQNb6uNohtu+lIgoyMa/CZkUEdG9mmM= X-Received: by 2002:a81:578e:: with SMTP id l136-v6mr13672997ywb.396.1536705439544; Tue, 11 Sep 2018 15:37:19 -0700 (PDT) MIME-Version: 1.0 References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> <8A78EF35-B0E4-43EC-A6B7-EB7DED60210F@gmail.com> <7DD44D1F-06E5-494D-B760-B1462FD9DC01@gmail.com> In-Reply-To: From: Albert Cabellos Date: Wed, 12 Sep 2018 00:37:08 +0200 Message-ID: To: "BRUNGARD, DEBORAH A (ATTLABS)" Cc: Dino Farinacci , "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 22:37:23 -0000 Hi Thanks for the help. I was suggesting to change the references from 6830/6833 to 6830bis/6833bis, not to speed it up. If it is doable to wait for the bis documents and then change the references to the bis versions then I=C2=B4m all for it. Albert On Wed, Sep 12, 2018 at 12:01 AM BRUNGARD, DEBORAH A wrote= : > > If we want to get lisp-intro done now, we should leave the reference to R= FC6830. If change to the bis, we need to wait until they are published as t= hey also would be listed normatively. > > -----Original Message----- > From: Dino Farinacci > Sent: Tuesday, September 11, 2018 5:14 PM > To: BRUNGARD, DEBORAH A > Cc: Albert Cabellos ; lisp@ietf.org list > Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-= rfc6830bis-16: (with COMMENT) > > > I don=E2=80=99t see lisp-sec as essential to implementing lisp-intro. I= don=E2=80=99t know why it was listed as normative? To me, it is providing = additional information. > > I agree LISP-SEC is additional information for an introductory document. = You bring up a good point. > > > If the working group agrees, I can check with the RFC-Editor if can mov= e lisp-security to informative. I think the change will only need author an= d AD approval. Does anyone have any concerns? Or is lisp-security =E2=80=9C= almost done=E2=80=9D and should continue to wait? > > I agree with your proposal. But have another question. If we update the l= isp-intro to move this reference to Informative, do you at the same time ch= ange all occurences of 6830/6833 to the bis document equivalents or do you = want to push lisp-intro through? > > I would say go for the latter since the information in 6830/6833 has not = changed when shuffling sections around into 6830bis/6833bis. So Albert, the= information in RFC6830 is not obsoleted but the document may be. > > What do you think? > > Dino From nobody Tue Sep 11 15:41:18 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF9C130FB5 for ; Tue, 11 Sep 2018 15:41:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eTiC3RfWOJ0W for ; Tue, 11 Sep 2018 15:41:07 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 9873E130FEA for ; Tue, 11 Sep 2018 15:41:07 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id 8-v6so50515410oip.0 for ; Tue, 11 Sep 2018 15:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RprDFlXll9oVDVSbSMJ02besSPxESoII5I+TPXqIL3k=; b=uMyWe3oB60LkUN5qyCPuvnLPL4LBMEVmswn39vUUbLb8EWN4u1SfdL6ghDtRU6jS2x U0MSFNxrGIiVePD2X4QRkDy+CobOSlPfQn4dpuK2n3WzY4e4Wr6WTppQly+gfhqvyMDZ D56D/3uT+rnix5rEpEO5E9Fz7ySR8JQl90D0swpc2C+83mY41QbU4nQ/0MY6tUtBnPmk +OWL+YPZsHoRjDVplEdR4jcniDy2yx1oZuTaQQTlDksDqvnMF5X95MRZH2NCRs6EdD4p ffs9PeKXhxSQ0oYaOVkaebdE2dTArYBZPckze7ZnMA5BKNwaNwB6d+w/1tyneA9oGf2L /mqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RprDFlXll9oVDVSbSMJ02besSPxESoII5I+TPXqIL3k=; b=O0mw/tW8CxJ/EVMvTvqTzwrYmHhK+/OHDcoJEHtE2f456Te7iiTtbNa5NyPyzu95w8 +Uz9YYGp7HvSjWQglF3k3VeLI1eEppEUA3Q1P73VdtE4qpKxeYGludh0X0uc+5aPS88u nuZV05E4KHXccLebMxDgiy6O4wKYiQJVseEUdD6oe3mEs7pLWMHQeuqpCNQDP2m1DauQ NEWaH7n9TjDB7nE/S5SgZXkiezhSgN/bIZ2zh55Q60pYBOgygznf087WteC/1omOF2PA kprS7Er5vl0c5FQDUNp8vFubsOW4XZ5qk6AhmG8wyhQsvgaUDon+T+HK7Ir/AxHKo+N+ BYgw== X-Gm-Message-State: APzg51CohRo9jNb4YualWi0vDGwZsPPMLvVPZRtqtKn1LEQFISh1irYj GIuHJGF2QMsUbaR5tZlhETA= X-Google-Smtp-Source: ANB0VdbgPKtwGC5P0rcjmV/dYTv0hbDY1vY7m6eX3TmIHm9DrJMHNX5/sxgHpwxHY0cTQrK22+qkXw== X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr30114159oib.155.1536705667029; Tue, 11 Sep 2018 15:41:07 -0700 (PDT) Received: from dino-macbook.attlocal.net (adsl-108-94-2-123.dsl.pltn13.sbcglobal.net. [108.94.2.123]) by smtp.gmail.com with ESMTPSA id x5-v6sm19723857oix.3.2018.09.11.15.41.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 15:41:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 11 Sep 2018 15:41:04 -0700 Cc: Albert Cabellos , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <07784B97-4057-444E-8719-67DEAE5A56F7@gmail.com> References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> <8A78EF35-B0E4-43EC-A6B7-EB7DED60210F@gmail.com> <7DD44D1F-06E5-494D-B760-B1462FD9DC01@gmail.com> To: "BRUNGARD, DEBORAH A" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 22:41:17 -0000 Okay, now I understand fully with what you propose. I can go along with = it if Albert agrees. Dino > On Sep 11, 2018, at 3:00 PM, BRUNGARD, DEBORAH A = wrote: >=20 > If we want to get lisp-intro done now, we should leave the reference = to RFC6830. If change to the bis, we need to wait until they are = published as they also would be listed normatively. >=20 > -----Original Message----- > From: Dino Farinacci =20 > Sent: Tuesday, September 11, 2018 5:14 PM > To: BRUNGARD, DEBORAH A > Cc: Albert Cabellos ; lisp@ietf.org list = > Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on = draft-ietf-lisp-rfc6830bis-16: (with COMMENT) >=20 >> I don=E2=80=99t see lisp-sec as essential to implementing lisp-intro. = I don=E2=80=99t know why it was listed as normative? To me, it is = providing additional information. >=20 > I agree LISP-SEC is additional information for an introductory = document. You bring up a good point. >=20 >> If the working group agrees, I can check with the RFC-Editor if can = move lisp-security to informative. I think the change will only need = author and AD approval. Does anyone have any concerns? Or is = lisp-security =E2=80=9Calmost done=E2=80=9D and should continue to wait? >=20 > I agree with your proposal. But have another question. If we update = the lisp-intro to move this reference to Informative, do you at the same = time change all occurences of 6830/6833 to the bis document equivalents = or do you want to push lisp-intro through? >=20 > I would say go for the latter since the information in 6830/6833 has = not changed when shuffling sections around into 6830bis/6833bis. So = Albert, the information in RFC6830 is not obsoleted but the document may = be. >=20 > What do you think? >=20 > Dino From nobody Tue Sep 11 16:59:34 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F171130F47 for ; Tue, 11 Sep 2018 16:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 SgaUeHj-WYwP for ; Tue, 11 Sep 2018 16:59:30 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB2B130E0E for ; Tue, 11 Sep 2018 16:59:30 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w8BL6lRK004564; Tue, 11 Sep 2018 17:07:24 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 2memkg9sr1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Sep 2018 17:07:23 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8BL7LSG014644; Tue, 11 Sep 2018 17:07:22 -0400 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8BL7EA7014575; Tue, 11 Sep 2018 17:07:14 -0400 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id CC9DA16A3EF; Tue, 11 Sep 2018 21:07:14 +0000 (GMT) Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (unknown [130.9.129.149]) by zlp27125.vci.att.com (Service) with ESMTPS id B46A716A3EE; Tue, 11 Sep 2018 21:07:14 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.139]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0415.000; Tue, 11 Sep 2018 17:07:14 -0400 From: "BRUNGARD, DEBORAH A" To: Albert Cabellos , Dino Farinacci CC: "lisp@ietf.org list" Thread-Topic: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) Thread-Index: AQHUSUxnqYCQtt45cUGrQKtyQStbFKTqbE2xgADw4oCAACyCgIAAAhwAgAA5zYD//8IUwA== Date: Tue, 11 Sep 2018 21:07:13 +0000 Message-ID: References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> <8A78EF35-B0E4-43EC-A6B7-EB7DED60210F@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.164.245] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8884057A0MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-11_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809110207 Archived-At: Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 23:59:34 -0000 --_000_F64C10EAA68C8044B33656FA214632C8884057A0MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxiZXJ0LA0KDQpMSVNQLWludHJvIGlzIG9ubHkgYmxvY2tlZCBieSBvbmUgZG9jdW1lbnQs IGxpc3Atc2VjLiBPbmUgY291bGQgZG8gYW4gdXBkYXRlLCB0aG91Z2ggYXMgRGlubyBub3RlZCwg YmVjYXVzZSBSRkM2ODMwIGluY2x1ZGVkIGJvdGggNjgzMGJpcyBhbmQgNjgzM2Jpcywgb25lIHdv dWxkIG5lZWQgdG8gZ28gdGhydSB0aGUgZG9jdW1lbnQgYW5kIGNsZWFuIHVwIGFsbCB0aGUgcmVm ZXJlbmNlcyB0byBSRkM2ODMwLiBBbmQgdGhlbiBvbmUgd291bGQgbmVlZCB0byB3YWl0IGZvciB0 aGVzZSBkb2N1bWVudHMgdG8gcHJvZ3Jlc3MgYXMgdGhleSBhcmUgYm90aCBub3JtYXRpdmUuIFRo ZSBjdXJyZW50IHZlcnNpb24gaXMgb2sgYXMgaXMgLSBpdCBwb2ludHMgdG8gUkZDNjgzMCAoYW5k IGRhdGF0cmFja2VyIHdpbGwgcG9pbnQgYSByZWFkZXIgdG8gdGhlIGJpc+KAmXMpLg0KDQpJ4oCZ bSB3b25kZXJpbmcgb24gYW5vdGhlciBhcHByb2FjaC4gSWYgSSByZWNhbGwgY29ycmVjdGx5ICht eSBtZW1vcnkgbWF5IGhhdmUgZmFkZWQpLCB3ZSBoYWQgb3B0aW1pc20gdGhhdCBsaXNwLXNlYyB3 b3VsZCBiZSBkb25lIGJ5IG5vdywgYW5kIHNvIGhhZCB3YWl0ZWQgb24gaXQuIEJ1dCBpdCBpcyBu b3QuIExvb2tpbmcgYXQgdGhlIHJlZmVyZW5jZSB0byBpdCBpbiBsaXNwLWludHJvLCBpdCBpcyBp biB0aGUgc2VjdXJpdHkgc2VjdGlvbiBhcyDigJxhbmQgdGhlIGxpZ2h0d2VpZ2h0IGF1dGhlbnRp Y2F0aW9uIG1lY2hhbmlzbSBwcm9wb3NlZCBieSBMSVNQLVNlYyBbSS1ELmlldGYtbGlzcC1zZWNd IHJlZHVjZXPigJ0uIEkgd2FzbuKAmXQgaW52b2x2ZWQgYXQgdGhlIHRpbWUsIGJ1dCBJ4oCZbSB3 b25kZXJpbmcgd2h5IGEg4oCccHJvcG9zZWQgbWVjaGFuaXNt4oCdIG1lcml0ZWQgYSBub3JtYXRp dmUgcmVmZXJlbmNlIGluIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQ/DQoNClJGQzczMjIgUkZD IFN0eWxlIEd1aWRlIGhhczoNCuKAnFJlZmVyZW5jZSBsaXN0cyBtdXN0IGluZGljYXRlIHdoZXRo ZXIgZWFjaCByZWZlcmVuY2UgaXMgbm9ybWF0aXZlIG9yIGluZm9ybWF0aXZlLCB3aGVyZSBub3Jt YXRpdmUgcmVmZXJlbmNlcyBhcmUgZXNzZW50aWFsIHRvIGltcGxlbWVudGluZyBvciB1bmRlcnN0 YW5kaW5nIHRoZSBjb250ZW50IG9mIHRoZSBSRkMgYW5kIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMg cHJvdmlkZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9u4oCdLg0KDQpJIGRvbuKAmXQgc2VlIGxpc3At c2VjIGFzIGVzc2VudGlhbCB0byBpbXBsZW1lbnRpbmcgbGlzcC1pbnRyby4gSSBkb27igJl0IGtu b3cgd2h5IGl0IHdhcyBsaXN0ZWQgYXMgbm9ybWF0aXZlPyBUbyBtZSwgaXQgaXMgcHJvdmlkaW5n IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24uDQoNCklmIHRoZSB3b3JraW5nIGdyb3VwIGFncmVlcywg SSBjYW4gY2hlY2sgd2l0aCB0aGUgUkZDLUVkaXRvciBpZiBjYW4gbW92ZSBsaXNwLXNlY3VyaXR5 IHRvIGluZm9ybWF0aXZlLiBJIHRoaW5rIHRoZSBjaGFuZ2Ugd2lsbCBvbmx5IG5lZWQgYXV0aG9y IGFuZCBBRCBhcHByb3ZhbC4gRG9lcyBhbnlvbmUgaGF2ZSBhbnkgY29uY2VybnM/IE9yIGlzIGxp c3Atc2VjdXJpdHkg4oCcYWxtb3N0IGRvbmXigJ0gYW5kIHNob3VsZCBjb250aW51ZSB0byB3YWl0 Pw0KDQpEZWJvcmFoDQoNCg0KRnJvbTogbGlzcCA8bGlzcC1ib3VuY2VzQGlldGYub3JnPiBPbiBC ZWhhbGYgT2YgQWxiZXJ0IENhYmVsbG9zDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTEsIDIw MTggNDowNCBQTQ0KVG86IERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPg0KQ2M6 IGxpc3BAaWV0Zi5vcmcgbGlzdCA8bGlzcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbGlzcF0g RndkOiBBbHZhcm8gUmV0YW5hJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtbGlzcC1yZmM2 ODMwYmlzLTE2OiAod2l0aCBDT01NRU5UKQ0KDQpIaQ0KDQpJIGFtIG5vdCBmYW1pbGlhciB3aXRo IGFsbCB0aGUgSUVURiBwcm9jZWR1cmVzLCBidXQgbGlzcC1pbnRybyBoYXMgYmVlbiB3YWl0aW5n IGZvciBhIG1pc3NpbmcgcmVmZXJlbmNlIGZvciAxMDAwKyBkYXlzIGFuZCB0aGUgZGF5IGl0IHdp bGwgYmVjb21lIFJGQyBpdCB3aWxsIGJlIHJlZmVyZW5jaW5nIGFuIG9ic29sZXRlIGRvY3VtZW50 Lg0KDQpJIHRoaW5rIHRoYXQgd2Ugc2hvdWxkIG1ha2UgaXQgcmlnaHQsIGlmIHNvbWVvbmUgY2Fu IHNoZXBoZXJkIG1lIG9uIHdoYXQgdG8gZG8gScK0bGwgYmUgaGFwcHkgdG8gd29yayBvbiBpdC4N Cg0KQWxiZXJ0DQoNCk9uIFR1ZSwgU2VwIDExLCAyMDE4IGF0IDY6MzcgUE0gRGlubyBGYXJpbmFj Y2kgPGZhcmluYWNjaUBnbWFpbC5jb208bWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb20+PiB3cm90 ZToNClJpZ2h0IG5vdyB0aGVyZSBpcyBubyBjaXJjdWxhciBkZXBlbmRlbmN5LiBUbyBzdW1tYXJp emU6DQoNCigxKSBSRkM2ODMwIGRvZXMgbm90IHBvaW50IHRvIDY4MzBiaXMgb3IgbGlzcC1pbnRy by4NCigyKSBsaXNwLWludHJvIHBvaW50cyB0byBSRkM2ODMwLg0KKDMpIDY4NjBiaXMgbmVlZHMg dG8gcG9pbnQgdG8gUkZDNjgzMC4NCg0KTGV04oCZcyBwbGVhc2UgZG9u4oCZdCBjaGFuZ2UgYW55 IHRoaXMuIExldOKAmXMgbm90IG1ha2UgdGhpcyBtb3JlIGNvbXBsY2lhdGVkIHRoZW4gaXQgbmVl ZHMgdG8gYmUgYW5kIGxldOKAmXMgbm90IGNvbmZ1c2UgcGVvcGxlLCBlc3BlY2lhbGx5IHRoZSBh dXRob3JzLiA7LSkNCg0KRGlubw0KDQoNCj4gT24gU2VwIDExLCAyMDE4LCBhdCA5OjI5IEFNLCBB bHZhcm8gUmV0YW5hIDxhcmV0YW5hLmlldGZAZ21haWwuY29tPG1haWx0bzphcmV0YW5hLmlldGZA Z21haWwuY29tPj4gd3JvdGU6DQo+DQo+IE9uIFNlcHRlbWJlciAxMSwgMjAxOCBhdCA5OjUwOjI5 IEFNLCBKb2VsIE0uIEhhbHBlcm4gKGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20+KSB3cm90ZToNCj4NCj4gSGkhDQo+DQo+PiBBbnkgY2hhbmdlIHRvIGxpc3At aW50cm8gc2hvdWxkIGJlIGRvbmUgYnkgZGlzY3Vzc2lvbiB3aXRoIHRoZSBSRkMNCj4+IEVkaXRv ciwgYXMgaXQgaXMgaW4gdGhlIFJGQyBFZGl0b3IgcXVldWUgKHBlbmRpbmcgcmVmZXJlbmNlIGNv bXBsZXRpb24pLg0KPj4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgY29uc2lkZXJzIGl0IGFjY2VwdGFi bGUsIHdlIGNvdWxkIGVhc2lseSBhc2sgdGhlbQ0KPj4gdG8gY2hhbmdlIHRoZSByZWZlcmVuY2Vz IHRvIDY4MzAgYW5kIDY4MzMgdG8gdGhlIGJpcyBkb2N1bWVudHMgKGFmdGVyDQo+PiBhbGwsIGl0 IGlzIGFscmVheSBibG9ja2VkIGJ5IGRvY3VtZW50cyB3aGljaCBkZXBlbmQgdXBvbiB0aG9zZS4p DQo+IFRoZSByZWZlcmVuY2Ugd291bGQgc3RpbGwgYmUgY2lyY3VsYXI6IHJmYzY4MzBiaXMgd291 bGQgcG9pbnQgYXQgbGlzcC1pbnRyb2R1Y3Rpb24gZm9yIGFyY2hpdGVjdHVyZSBkZXRhaWxzLCBh bmQgdGhhdCB3b3VsZCBwb2ludCBiYWNrIGhlcmUuDQo+DQo+IElmIGxpc3AtaW50cm9kdWN0aW9u IHdhcyBqdXN0IHRoYXQgKGFuIGludHJvZHVjdGlvbikgYW5kIHRoZSBkZXRhaWxzIHdlcmUgaW4g cmZjNjgzMCB0byBzdGFydCB3aXRo4oCmLiBNYXliZSB0aGUgZWFzeSBmaXggaXMgdG8ganVzdCBu b3QgcG9pbnQgdG8gbGlzcC1pbnRyb2R1Y3Rpb24gZnJvbSByZmM2ODMwYmlzLCBiZWNhdXNlIHRo ZSBkZXRhaWxzIHNob3VsZCBiZSBoZXJlIChhbmQgcmZjNjgzM2JpcykgYWxyZWFkeS4NCj4NCj4g cy9GaW5hbGx5LCBbSS1ELmlldGYtbGlzcC1pbnRyb2R1Y3Rpb25dIGRlc2NyaWJlcyB0aGUgTElT UCBhcmNoaXRlY3R1cmUuLy8NCj4NCj4gQWx2YXJvLg0KPg0KPg0KPg0KPj4NCj4+DQo+PiBZb3Vy cywNCj4+IEpvZWwNCj4+DQo+PiBPbiA5LzEwLzE4IDExOjI3IFBNLCBEaW5vIEZhcmluYWNjaSB3 cm90ZToNCj4+ID4gSWYgeW91IGd1eXMgaGF2ZSBzb3VyY2UgZm9yIHRoZSBpbnRybyBkb2MsIEkg Y291bGQgcG9pbnQgaXQgdG8gYmlzDQo+PiA+IGRvY3VtZW50cz8NCj4+ID4NCj4+ID4gRGlubw0K Pj4gPg0KPj4gPg0KPj4gPiBCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCj4+ID4NCj4+ID4+ICpS ZXNlbnQtRnJvbToqIDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphbGlhcy1ib3VuY2Vz QGlldGYub3JnPiA8bWFpbHRvOmFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFsaWFzLWJv dW5jZXNAaWV0Zi5vcmc+Pj4NCj4+ID4+ICpGcm9tOiogQWx2YXJvIFJldGFuYSA8YXJldGFuYS5p ZXRmQGdtYWlsLmNvbTxtYWlsdG86YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4NCj4+ID4+IDxtYWls dG86YXJldGFuYS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4+ Pg0KPj4gPj4gKkRhdGU6KiBTZXB0ZW1iZXIgMTAsIDIwMTggYXQgMjoyMjoyMSBQTSBQRFQNCj4+ ID4+ICpSZXNlbnQtVG86KiBmYXJpbmFjY2lAZ21haWwuY29tPG1haWx0bzpmYXJpbmFjY2lAZ21h aWwuY29tPiA8bWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb208bWFpbHRvOmZhcmluYWNjaUBnbWFp bC5jb20+PiwNCj4+ID4+IHZpbmNlLmZ1bGxlckBnbWFpbC5jb208bWFpbHRvOnZpbmNlLmZ1bGxl ckBnbWFpbC5jb20+IDxtYWlsdG86dmluY2UuZnVsbGVyQGdtYWlsLmNvbTxtYWlsdG86dmluY2Uu ZnVsbGVyQGdtYWlsLmNvbT4+LCBkbW1AMS00LTUubmV0PG1haWx0bzpkbW1AMS00LTUubmV0Pg0K Pj4gPj4gPG1haWx0bzpkbW1AMS00LTUubmV0PG1haWx0bzpkbW1AMS00LTUubmV0Pj4sIGRhcmxl d2lzQGNpc2NvLmNvbTxtYWlsdG86ZGFybGV3aXNAY2lzY28uY29tPg0KPj4gPj4gPG1haWx0bzpk YXJsZXdpc0BjaXNjby5jb208bWFpbHRvOmRhcmxld2lzQGNpc2NvLmNvbT4+LCBhY2FiZWxsb0Bh Yy51cGMuZWR1PG1haWx0bzphY2FiZWxsb0BhYy51cGMuZWR1Pg0KPj4gPj4gPG1haWx0bzphY2Fi ZWxsb0BhYy51cGMuZWR1PG1haWx0bzphY2FiZWxsb0BhYy51cGMuZWR1Pj4NCj4+ID4+ICpUbzoq ICJUaGUgSUVTRyIgPGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+IDxtYWlsdG86 aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+Pg0KPj4gPj4gKkNjOiogZHJhZnQt aWV0Zi1saXNwLXJmYzY4MzBiaXNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbGlzcC1yZmM2 ODMwYmlzQGlldGYub3JnPg0KPj4gPj4gPG1haWx0bzpkcmFmdC1pZXRmLWxpc3AtcmZjNjgzMGJp c0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBiaXNAaWV0Zi5vcmc+Piwg THVpZ2kgSWFubm9uZQ0KPj4gPj4gPGdneEBnaWdpeC5uZXQ8bWFpbHRvOmdneEBnaWdpeC5uZXQ+ IDxtYWlsdG86Z2d4QGdpZ2l4Lm5ldDxtYWlsdG86Z2d4QGdpZ2l4Lm5ldD4+PiwgbGlzcC1jaGFp cnNAaWV0Zi5vcmc8bWFpbHRvOmxpc3AtY2hhaXJzQGlldGYub3JnPg0KPj4gPj4gPG1haWx0bzps aXNwLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bGlzcC1jaGFpcnNAaWV0Zi5vcmc+PiwgbGlzcEBp ZXRmLm9yZzxtYWlsdG86bGlzcEBpZXRmLm9yZz4gPG1haWx0bzpsaXNwQGlldGYub3JnPG1haWx0 bzpsaXNwQGlldGYub3JnPj4NCj4+ID4+ICpTdWJqZWN0OiogKkFsdmFybyBSZXRhbmEncyBObyBP YmplY3Rpb24gb24NCj4+ID4+IGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMwYmlzLTE2OiAod2l0aCBD T01NRU5UKSoNCj4+ID4+DQo+PiA+PiBBbHZhcm8gUmV0YW5hIGhhcyBlbnRlcmVkIHRoZSBmb2xs b3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPj4gPj4gZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBi aXMtMTY6IE5vIE9iamVjdGlvbg0KPj4gPj4NCj4+ID4+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNl IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPj4gPj4gZW1h aWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUg dG8gY3V0IHRoaXMNCj4+ID4+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPj4g Pj4NCj4+ID4+DQo+PiA+PiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVz Zy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX2llc2dfc3RhdGVtZW50 X2Rpc2N1c3MtMkRjcml0ZXJpYS5odG1sJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJ ZyZyPTZVaEdwVzlsd2k5ZE03allseFhEOHcmbT1ZSkQ5WmE5LTVNUzBuTy1hNHZKRzduamhRcU1N Mm1uUzczMG5CLVBjbFpBJnM9b1BadnJMeFNiTW1IQWtQVUVLY09FdWNfVzN5THY3OE1hdWVKMHZG bkk3MCZlPT4NCj4+ID4+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBh bmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IFRoZSBkb2N1bWVudCwg YWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4+ ID4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbGlzcC1yZmM2 ODMwYmlzLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkRsaXNwLTJEcmZjNjgz MGJpc18mZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdq WWx4WEQ4dyZtPVlKRDlaYTktNU1TMG5PLWE0dkpHN25qaFFxTU0ybW5TNzMwbkItUGNsWkEmcz1u VVBQb0IwT09QNDExcndKUUk0dldYYzAtaWxJUFo1Z0t3MnlhMDlIODVzJmU9Pg0KPj4gPj4NCj4+ ID4+DQo+PiA+Pg0KPj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gPj4gQ09NTUVOVDoNCj4+ID4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+ID4+DQo+PiA+PiBUaGFua3MgZm9yIHRoZSB3b3JrIG9uIHRoaXMgZG9j dW1lbnQhDQo+PiA+Pg0KPj4gPj4gSSBoYXZlIHNvbWUgcmVsYXRpdmVseSBtaW5vciBjb21tZW50 cy9uaXRzOg0KPj4gPj4NCj4+ID4+ICgxKSDCpzE4OiBzL1JGQzgwNjAvUkZDODA2MQ0KPj4gPj4N Cj4+ID4+ICgyKSDCpzE6ICJGaW5hbGx5LCBbSS1ELmlldGYtbGlzcC1pbnRyb2R1Y3Rpb25dIGRl c2NyaWJlcyB0aGUgTElTUA0KPj4gPj4gYXJjaGl0ZWN0dXJlLiIgIEZpcnN0IG9mIGFsbCwgaXQg d291bGQgc2VlbSB0byBtZSB0aGF0IHRoZQ0KPj4gPj4gQXJjaGl0ZWN0dXJlIHNob3VsZA0KPj4g Pj4gYmUgYSBOb3JtYXRpdmUgcmVmZXJlbmNlLi4uYnV0IEktRC5pZXRmLWxpc3AtaW50cm9kdWN0 aW9uIHNheXMgdGhhdCBpdA0KPj4gPj4gImlzIHVzZWQNCj4+ID4+IGZvciBpbnRyb2R1Y3Rvcnkg cHVycG9zZXMsIG1vcmUgZGV0YWlscyBjYW4gYmUgZm91bmQgaW4gUkZDNjgzMCwgdGhlDQo+PiA+ PiBwcm90b2NvbA0KPj4gPj4gc3BlY2lmaWNhdGlvbi4iICBUaGlzIGRvY3VtZW50IG9ic29sZXRl cyByZmM2ODMwLi4uc28gaXQgc2VlbXMgdG8gbWUNCj4+ID4+IHRoYXQgdGhlcmUNCj4+ID4+IGlz IGEgZmFpbGVkIGNpcmN1bGFyIGRlcGVuZGVuY3kuDQo+PiA+Pg0KPj4gPj4gKDMpIFJlZmVyZW5j ZXMgdG8gcmZjMjExOS9yZmM4MTc0IGFuZCByZmM4MTI2IHNob3VsZCBiZSBOb3JtYXRpdmUuDQo+ PiA+Pg0KPj4gPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gbGlzcCBtYWlsaW5nIGxpc3QNCj4+IGxpc3BAaWV0Zi5vcmc8bWFpbHRv Omxpc3BAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2xpc3A8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19saXNwJmQ9RHdNRmFRJmM9TEZZWi1vOV9I VU1lTVRTUWljdmpJZyZyPTZVaEdwVzlsd2k5ZE03allseFhEOHcmbT1ZSkQ5WmE5LTVNUzBuTy1h NHZKRzduamhRcU1NMm1uUzczMG5CLVBjbFpBJnM9dWdSVWo2WXhkbGNmcFdzTllFWC1vWlU3b2Iw cXp6Y2EwZlF0bWhEeU81QSZlPT4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCmxpc3AgbWFpbGluZyBsaXN0DQpsaXNwQGlldGYub3JnPG1haWx0bzps aXNwQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNw PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbGlzcCZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1U U1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3Jm09WUpEOVphOS01TVMwbk8tYTR2Skc3 bmpoUXFNTTJtblM3MzBuQi1QY2xaQSZzPXVnUlVqNll4ZGxjZnBXc05ZRVgtb1pVN29iMHF6emNh MGZRdG1oRHlPNUEmZT0+DQo= --_000_F64C10EAA68C8044B33656FA214632C8884057A0MISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSBBbGJlcnQsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxJU1AtaW50cm8gaXMgb25seSBibG9j a2VkIGJ5IG9uZSBkb2N1bWVudCwgbGlzcC1zZWMuIE9uZSBjb3VsZCBkbyBhbiB1cGRhdGUsIHRo b3VnaCBhcyBEaW5vIG5vdGVkLCBiZWNhdXNlIFJGQzY4MzAgaW5jbHVkZWQgYm90aCA2ODMwYmlz IGFuZCA2ODMzYmlzLCBvbmUgd291bGQgbmVlZCB0byBnbyB0aHJ1IHRoZSBkb2N1bWVudCBhbmQg Y2xlYW4gdXAgYWxsIHRoZSByZWZlcmVuY2VzIHRvIFJGQzY4MzAuIEFuZA0KIHRoZW4gb25lIHdv dWxkIG5lZWQgdG8gd2FpdCBmb3IgdGhlc2UgZG9jdW1lbnRzIHRvIHByb2dyZXNzIGFzIHRoZXkg YXJlIGJvdGggbm9ybWF0aXZlLiBUaGUgY3VycmVudCB2ZXJzaW9uIGlzIG9rIGFzIGlzIC0gaXQg cG9pbnRzIHRvIFJGQzY4MzAgKGFuZCBkYXRhdHJhY2tlciB3aWxsIHBvaW50IGEgcmVhZGVyIHRv IHRoZSBiaXPigJlzKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gd29uZGVyaW5nIG9u IGFub3RoZXIgYXBwcm9hY2guIElmIEkgcmVjYWxsIGNvcnJlY3RseSAobXkgbWVtb3J5IG1heSBo YXZlIGZhZGVkKSwgd2UgaGFkIG9wdGltaXNtIHRoYXQgbGlzcC1zZWMgd291bGQgYmUgZG9uZSBi eSBub3csIGFuZCBzbyBoYWQgd2FpdGVkIG9uIGl0LiBCdXQgaXQgaXMgbm90LiBMb29raW5nIGF0 IHRoZSByZWZlcmVuY2UgdG8gaXQgaW4gbGlzcC1pbnRybywgaXQgaXMgaW4gdGhlDQogc2VjdXJp dHkgc2VjdGlvbiBhcyDigJxhbmQgdGhlIGxpZ2h0d2VpZ2h0IGF1dGhlbnRpY2F0aW9uIG1lY2hh bmlzbSBwcm9wb3NlZCBieSBMSVNQLVNlYyBbSS1ELmlldGYtbGlzcC1zZWNdIHJlZHVjZXPigJ0u IEkgd2FzbuKAmXQgaW52b2x2ZWQgYXQgdGhlIHRpbWUsIGJ1dCBJ4oCZbSB3b25kZXJpbmcgd2h5 IGEg4oCccHJvcG9zZWQgbWVjaGFuaXNt4oCdIG1lcml0ZWQgYSBub3JtYXRpdmUgcmVmZXJlbmNl IGluIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQ/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UkZDNzMyMiBSRkMgU3R5bGUgR3VpZGUgaGFzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+4oCcUmVmZXJlbmNlIGxpc3RzIG11c3QgaW5kaWNhdGUgd2hldGhlciBlYWNoIHJl ZmVyZW5jZSBpcyBub3JtYXRpdmUgb3IgaW5mb3JtYXRpdmUsIHdoZXJlIG5vcm1hdGl2ZSByZWZl cmVuY2VzIGFyZSBlc3NlbnRpYWwgdG8gaW1wbGVtZW50aW5nIG9yIHVuZGVyc3RhbmRpbmcgdGhl IGNvbnRlbnQgb2YgdGhlIFJGQyBhbmQgaW5mb3JtYXRpdmUgcmVmZXJlbmNlcyBwcm92aWRlIGFk ZGl0aW9uYWwgaW5mb3JtYXRpb27igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZ dCBzZWUgbGlzcC1zZWMgYXMgZXNzZW50aWFsIHRvIGltcGxlbWVudGluZyBsaXNwLWludHJvLiBJ IGRvbuKAmXQga25vdyB3aHkgaXQgd2FzIGxpc3RlZCBhcyBub3JtYXRpdmU/IFRvIG1lLCBpdCBp cyBwcm92aWRpbmcgYWRkaXRpb25hbCBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SWYgdGhlIHdvcmtpbmcgZ3JvdXAgYWdyZWVzLCBJIGNhbiBjaGVjayB3aXRoIHRoZSBSRkMt RWRpdG9yIGlmIGNhbiBtb3ZlIGxpc3Atc2VjdXJpdHkgdG8gaW5mb3JtYXRpdmUuIEkgdGhpbmsg dGhlIGNoYW5nZSB3aWxsIG9ubHkgbmVlZCBhdXRob3IgYW5kIEFEIGFwcHJvdmFsLiBEb2VzIGFu eW9uZSBoYXZlIGFueSBjb25jZXJucz8gT3IgaXMgbGlzcC1zZWN1cml0eSDigJxhbG1vc3QgZG9u ZeKAnSBhbmQgc2hvdWxkDQogY29udGludWUgdG8gd2FpdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RGVib3JhaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBsaXNwICZsdDtsaXNwLWJvdW5jZXNA aWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpBbGJlcnQgQ2FiZWxsb3M8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgU2VwdGVtYmVyIDExLCAyMDE4IDQ6MDQgUE08YnI+DQo8Yj5U bzo8L2I+IERpbm8gRmFyaW5hY2NpICZsdDtmYXJpbmFjY2lAZ21haWwuY29tJmd0Ozxicj4NCjxi PkNjOjwvYj4gbGlzcEBpZXRmLm9yZyBsaXN0ICZsdDtsaXNwQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW2xpc3BdIEZ3ZDogQWx2YXJvIFJldGFuYSdzIE5vIE9iamVjdGlv biBvbiBkcmFmdC1pZXRmLWxpc3AtcmZjNjgzMGJpcy0xNjogKHdpdGggQ09NTUVOVCk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBmYW1pbGlhciB3aXRoIGFsbCB0aGUgSUVURiBwcm9j ZWR1cmVzLCBidXQgbGlzcC1pbnRybyBoYXMgYmVlbiB3YWl0aW5nIGZvciBhIG1pc3NpbmcgcmVm ZXJlbmNlIGZvciAxMDAwJiM0MzsgZGF5cyBhbmQgdGhlIGRheSBpdCB3aWxsIGJlY29tZSBSRkMg aXQgd2lsbCBiZSByZWZlcmVuY2luZyBhbiBvYnNvbGV0ZSBkb2N1bWVudC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0IHdl IHNob3VsZCBtYWtlIGl0IHJpZ2h0LCBpZiBzb21lb25lIGNhbiBzaGVwaGVyZCBtZSBvbiB3aGF0 IHRvIGRvIEnCtGxsIGJlIGhhcHB5IHRvIHdvcmsgb24gaXQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsYmVydDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIFNlcCAxMSwgMjAx OCBhdCA2OjM3IFBNIERpbm8gRmFyaW5hY2NpICZsdDs8YSBocmVmPSJtYWlsdG86ZmFyaW5hY2Np QGdtYWlsLmNvbSI+ZmFyaW5hY2NpQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmlnaHQgbm93 IHRoZXJlIGlzIG5vIGNpcmN1bGFyIGRlcGVuZGVuY3kuIFRvIHN1bW1hcml6ZTo8YnI+DQo8YnI+ DQooMSkgUkZDNjgzMCBkb2VzIG5vdCBwb2ludCB0byA2ODMwYmlzIG9yIGxpc3AtaW50cm8uPGJy Pg0KKDIpIGxpc3AtaW50cm8gcG9pbnRzIHRvIFJGQzY4MzAuPGJyPg0KKDMpIDY4NjBiaXMgbmVl ZHMgdG8gcG9pbnQgdG8gUkZDNjgzMC48YnI+DQo8YnI+DQpMZXTigJlzIHBsZWFzZSBkb27igJl0 IGNoYW5nZSBhbnkgdGhpcy4gTGV04oCZcyBub3QgbWFrZSB0aGlzIG1vcmUgY29tcGxjaWF0ZWQg dGhlbiBpdCBuZWVkcyB0byBiZSBhbmQgbGV04oCZcyBub3QgY29uZnVzZSBwZW9wbGUsIGVzcGVj aWFsbHkgdGhlIGF1dGhvcnMuIDstKTxicj4NCjxicj4NCkRpbm88YnI+DQo8YnI+DQo8YnI+DQom Z3Q7IE9uIFNlcCAxMSwgMjAxOCwgYXQgOToyOSBBTSwgQWx2YXJvIFJldGFuYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFyZXRhbmEuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5hcmV0YW5h LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIFNl cHRlbWJlciAxMSwgMjAxOCBhdCA5OjUwOjI5IEFNLCBKb2VsIE0uIEhhbHBlcm4gKDxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT4pIHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSE8YnI+DQomZ3Q7IDxi cj4NCiZndDsmZ3Q7IEFueSBjaGFuZ2UgdG8gbGlzcC1pbnRybyBzaG91bGQgYmUgZG9uZSBieSBk aXNjdXNzaW9uIHdpdGggdGhlIFJGQyA8YnI+DQomZ3Q7Jmd0OyBFZGl0b3IsIGFzIGl0IGlzIGlu IHRoZSBSRkMgRWRpdG9yIHF1ZXVlIChwZW5kaW5nIHJlZmVyZW5jZSBjb21wbGV0aW9uKS48YnI+ DQomZ3Q7Jmd0OyBJZiB0aGUgd29ya2luZyBncm91cCBjb25zaWRlcnMgaXQgYWNjZXB0YWJsZSwg d2UgY291bGQgZWFzaWx5IGFzayB0aGVtIDxicj4NCiZndDsmZ3Q7IHRvIGNoYW5nZSB0aGUgcmVm ZXJlbmNlcyB0byA2ODMwIGFuZCA2ODMzIHRvIHRoZSBiaXMgZG9jdW1lbnRzIChhZnRlciA8YnI+ DQomZ3Q7Jmd0OyBhbGwsIGl0IGlzIGFscmVheSBibG9ja2VkIGJ5IGRvY3VtZW50cyB3aGljaCBk ZXBlbmQgdXBvbiB0aG9zZS4pPGJyPg0KJmd0OyBUaGUgcmVmZXJlbmNlIHdvdWxkIHN0aWxsIGJl IGNpcmN1bGFyOiByZmM2ODMwYmlzIHdvdWxkIHBvaW50IGF0IGxpc3AtaW50cm9kdWN0aW9uIGZv ciBhcmNoaXRlY3R1cmUgZGV0YWlscywgYW5kIHRoYXQgd291bGQgcG9pbnQgYmFjayBoZXJlLjxi cj4NCiZndDsgPGJyPg0KJmd0OyBJZiBsaXNwLWludHJvZHVjdGlvbiB3YXMganVzdCB0aGF0IChh biBpbnRyb2R1Y3Rpb24pIGFuZCB0aGUgZGV0YWlscyB3ZXJlIGluIHJmYzY4MzAgdG8gc3RhcnQg d2l0aOKApi4gTWF5YmUgdGhlIGVhc3kgZml4IGlzIHRvIGp1c3Qgbm90IHBvaW50IHRvIGxpc3At aW50cm9kdWN0aW9uIGZyb20gcmZjNjgzMGJpcywgYmVjYXVzZSB0aGUgZGV0YWlscyBzaG91bGQg YmUgaGVyZSAoYW5kIHJmYzY4MzNiaXMpIGFscmVhZHkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHMv RmluYWxseSwgW0ktRC5pZXRmLWxpc3AtaW50cm9kdWN0aW9uXSBkZXNjcmliZXMgdGhlIExJU1Ag YXJjaGl0ZWN0dXJlLi8vPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFsdmFyby48YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyBZb3Vycyw8YnI+DQomZ3Q7Jmd0OyBKb2VsPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0 OyZndDsgT24gOS8xMC8xOCAxMToyNyBQTSwgRGlubyBGYXJpbmFjY2kgd3JvdGU6PGJyPg0KJmd0 OyZndDsgJmd0OyBJZiB5b3UgZ3V5cyBoYXZlIHNvdXJjZSBmb3IgdGhlIGludHJvIGRvYywgSSBj b3VsZCBwb2ludCBpdCB0byBiaXMgPGJyPg0KJmd0OyZndDsgJmd0OyBkb2N1bWVudHM/PGJyPg0K Jmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IERpbm88YnI+DQomZ3Q7Jmd0OyAmZ3Q7 IDxicj4NCiZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyZndDsgJmd0OyBCZWdpbiBmb3J3YXJkZWQg bWVzc2FnZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICpSZXNl bnQtRnJvbToqICZsdDs8YSBocmVmPSJtYWlsdG86YWxpYXMtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOmFsaWFzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hbGlhcy1i b3VuY2VzQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgKkZyb206 KiBBbHZhcm8gUmV0YW5hICZsdDs8YSBocmVmPSJtYWlsdG86YXJldGFuYS5pZXRmQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmFyZXRhbmEuaWV0ZkBnbWFpbC5jb208L2E+DQo8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzphcmV0YW5hLmlldGZAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YXJldGFuYS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICpEYXRlOiogU2VwdGVtYmVyIDEwLCAyMDE4IGF0IDI6 MjI6MjEgUE0gUERUPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgKlJlc2VudC1UbzoqIDxhIGhyZWY9 Im1haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZmFyaW5hY2NpQGdt YWlsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmZhcmluYWNjaUBnbWFpbC5jb208L2E+Jmd0OywNCjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzp2aW5jZS5mdWxsZXJAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+dmluY2UuZnVsbGVyQGdtYWlsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86dmluY2UuZnVsbGVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZpbmNl LmZ1bGxlckBnbWFpbC5jb208L2E+Jmd0OywNCjxhIGhyZWY9Im1haWx0bzpkbW1AMS00LTUubmV0 IiB0YXJnZXQ9Il9ibGFuayI+ZG1tQDEtNC01Lm5ldDwvYT4gPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZG1tQDEtNC01Lm5ldCIgdGFyZ2V0PSJfYmxh bmsiPmRtbUAxLTQtNS5uZXQ8L2E+Jmd0OywgPGEgaHJlZj0ibWFpbHRvOmRhcmxld2lzQGNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KZGFybGV3aXNAY2lzY28uY29tPC9hPiA8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkYXJsZXdpc0BjaXNjby5j b20iIHRhcmdldD0iX2JsYW5rIj5kYXJsZXdpc0BjaXNjby5jb208L2E+Jmd0OywNCjxhIGhyZWY9 Im1haWx0bzphY2FiZWxsb0BhYy51cGMuZWR1IiB0YXJnZXQ9Il9ibGFuayI+YWNhYmVsbG9AYWMu dXBjLmVkdTwvYT4gPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86YWNhYmVsbG9AYWMudXBjLmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmFjYWJlbGxvQGFjLnVw Yy5lZHU8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICpUbzoqICZxdW90O1RoZSBJRVNH JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pmllc2dAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5pZXNnQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgKkNjOiogPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbGlzcC1yZmM2ODMw YmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLWxpc3AtcmZjNjgzMGJp c0BpZXRmLm9yZzwvYT4gPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBiaXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5kcmFmdC1pZXRmLWxpc3AtcmZjNjgzMGJpc0BpZXRmLm9yZzwvYT4mZ3Q7LCBMdWlnaSBJ YW5ub25lDQo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdneEBn aWdpeC5uZXQiIHRhcmdldD0iX2JsYW5rIj5nZ3hAZ2lnaXgubmV0PC9hPiAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzpnZ3hAZ2lnaXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+Z2d4QGdpZ2l4Lm5l dDwvYT4mZ3Q7Jmd0OywNCjxhIGhyZWY9Im1haWx0bzpsaXNwLWNoYWlyc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmxpc3AtY2hhaXJzQGlldGYub3JnPC9hPiA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsaXNwLWNoYWlyc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmxpc3AtY2hhaXJzQGlldGYub3JnPC9hPiZndDssDQo8YSBocmVmPSJtYWls dG86bGlzcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxpc3BAaWV0Zi5vcmc8L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmxpc3BAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5saXNw QGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAqU3ViamVjdDoqICpBbHZh cm8gUmV0YW5hJ3MgTm8gT2JqZWN0aW9uIG9uIDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGRyYWZ0 LWlldGYtbGlzcC1yZmM2ODMwYmlzLTE2OiAod2l0aCBDT01NRU5UKSo8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEFsdmFybyBSZXRhbmEgaGFzIGVudGVyZWQg dGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg ZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBiaXMtMTY6IE5vIE9iamVjdGlvbjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Ug a2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGlu ZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpbnRyb2R1 Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgUGxlYXNlIHJlZmVyIHRvIDxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX2llc2dfc3RhdGVtZW50X2Rpc2N1c3MtMkRjcml0ZXJpYS5odG1sJmFt cDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPTZVaEdwVzlsd2k5 ZE03allseFhEOHcmYW1wO209WUpEOVphOS01TVMwbk8tYTR2Skc3bmpoUXFNTTJtblM3MzBuQi1Q Y2xaQSZhbXA7cz1vUFp2ckx4U2JNbUhBa1BVRUtjT0V1Y19XM3lMdjc4TWF1ZUowdkZuSTcwJmFt cDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRp b25zLCBjYW4gYmUgZm91bmQgaGVyZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0 cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkRsaXNwLTJEcmZjNjgzMGJpc18mYW1w O2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9NlVoR3BXOWx3aTlk TTdqWWx4WEQ4dyZhbXA7bT1ZSkQ5WmE5LTVNUzBuTy1hNHZKRzduamhRcU1NMm1uUzczMG5CLVBj bFpBJmFtcDtzPW5VUFBvQjBPT1A0MTFyd0pRSTR2V1hjMC1pbElQWjVnS3cyeWEwOUg4NXMmYW1w O2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWxpc3AtcmZjNjgzMGJpcy88L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IENPTU1FTlQ6PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgVGhhbmtzIGZvciB0aGUgd29yayBvbiB0aGlzIGRvY3Vt ZW50ITxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgSSBoYXZl IHNvbWUgcmVsYXRpdmVseSBtaW5vciBjb21tZW50cy9uaXRzOjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgKDEpIMKnMTg6IHMvUkZDODA2MC9SRkM4MDYxPGJy Pg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAoMikgwqcxOiAmcXVv dDtGaW5hbGx5LCBbSS1ELmlldGYtbGlzcC1pbnRyb2R1Y3Rpb25dIGRlc2NyaWJlcyB0aGUgTElT UDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGFyY2hpdGVjdHVyZS4mcXVvdDsmbmJzcDsgRmlyc3Qg b2YgYWxsLCBpdCB3b3VsZCBzZWVtIHRvIG1lIHRoYXQgdGhlIDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IEFyY2hpdGVjdHVyZSBzaG91bGQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBiZSBhIE5vcm1h dGl2ZSByZWZlcmVuY2UuLi5idXQgSS1ELmlldGYtbGlzcC1pbnRyb2R1Y3Rpb24gc2F5cyB0aGF0 IGl0IDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZxdW90O2lzIHVzZWQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyBmb3IgaW50cm9kdWN0b3J5IHB1cnBvc2VzLCBtb3JlIGRldGFpbHMgY2FuIGJlIGZv dW5kIGluIFJGQzY4MzAsIHRoZSA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBwcm90b2NvbDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IHNwZWNpZmljYXRpb24uJnF1b3Q7Jm5ic3A7IFRoaXMgZG9jdW1l bnQgb2Jzb2xldGVzIHJmYzY4MzAuLi5zbyBpdCBzZWVtcyB0byBtZSA8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyB0aGF0IHRoZXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgaXMgYSBmYWlsZWQgY2ly Y3VsYXIgZGVwZW5kZW5jeS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICgzKSBSZWZlcmVuY2VzIHRvIHJmYzIxMTkvcmZjODE3NCBhbmQgcmZjODEyNiBzaG91 bGQgYmUgTm9ybWF0aXZlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IGxpc3AgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmxpc3BAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5saXNwQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9fbGlzcCZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWlj dmpJZyZhbXA7cj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3JmFtcDttPVlKRDlaYTktNU1TMG5PLWE0 dkpHN25qaFFxTU0ybW5TNzMwbkItUGNsWkEmYW1wO3M9dWdSVWo2WXhkbGNmcFdzTllFWC1vWlU3 b2IwcXp6Y2EwZlF0bWhEeU81QSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcDwvYT48YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmxpc3AgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmxpc3BAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5s aXNwQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f bGlzcCZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj02VWhH cFc5bHdpOWRNN2pZbHhYRDh3JmFtcDttPVlKRDlaYTktNU1TMG5PLWE0dkpHN25qaFFxTU0ybW5T NzMwbkItUGNsWkEmYW1wO3M9dWdSVWo2WXhkbGNmcFdzTllFWC1vWlU3b2IwcXp6Y2EwZlF0bWhE eU81QSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2xpc3A8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F64C10EAA68C8044B33656FA214632C8884057A0MISOUT7MSGUSRDE_-- From nobody Tue Sep 11 17:16:09 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D074130F47 for ; Tue, 11 Sep 2018 17:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_DKIMWL_WL_HIGH=-0.01, T_TVD_FUZZY_SECURITIES=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 TMOKLp3WhNVx for ; Tue, 11 Sep 2018 17:16:06 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD2B12F1A6 for ; Tue, 11 Sep 2018 17:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1770; q=dns/txt; s=iport; t=1536711366; x=1537920966; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SBAwvpZmLAODblX/y4eAFGx2P00wCe8Cfbm5+XjRh+4=; b=FpI69lhbbAXzOiwwCmyI5Di7812k5CzrBJApkvjKpQ8ZPgjh5VNV/Jnm IwWf1qYMWmyaV73UJ4m1qsCuMg8ZvoMmx1Bmc0pSLi2IuAzqqI4Bm9YYJ zGQAFHqN2duizrbCz1k0Ob0h6Rj75xIRiEIcrsi8w27jg1pngtqwoiOG6 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgAgAhWphb/4kNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNOgWQoCoNoiBOMJoFoJYM9kn2BeguEbAIXgxkhNBgBAgE?= =?us-ascii?q?BAgEBAm0ohTgBAQEBAgEjEUUFCwIBCBgCAiYCAgIwFRACBA4FG4MGgXoIpTW?= =?us-ascii?q?BLooHgQuJXBeBQT+BEicME4JMh38xgiYCnBEJApAEF451k3ECERSBJR04gVV?= =?us-ascii?q?wFWUBgkGCJRcRjgZvjQmBHgEB?= X-IronPort-AV: E=Sophos;i="5.53,362,1531785600"; d="scan'208";a="449016105" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2018 00:16:05 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id w8C0G5vU013548 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Sep 2018 00:16:05 GMT Received: from xch-rcd-018.cisco.com (173.37.102.28) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Sep 2018 19:16:05 -0500 Received: from xch-rcd-018.cisco.com ([173.37.102.28]) by XCH-RCD-018.cisco.com ([173.37.102.28]) with mapi id 15.00.1395.000; Tue, 11 Sep 2018 19:16:05 -0500 From: "Darrel Lewis (darlewis)" To: "BRUNGARD, DEBORAH A" CC: "Darrel Lewis (darlewis)" , Albert Cabellos , Dino Farinacci , "lisp@ietf.org list" Thread-Topic: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) Thread-Index: AQHUSi3LZEX62SFjO0CB0vQumKdzBw== Date: Wed, 12 Sep 2018 00:16:04 +0000 Message-ID: References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> <8A78EF35-B0E4-43EC-A6B7-EB7DED60210F@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.253.181] Content-Type: text/plain; charset="utf-8" Content-ID: <17595E594C5A2247B9259F3DE7D27C84@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 00:16:09 -0000 DQoNCj4gT24gU2VwIDExLCAyMDE4LCBhdCAyOjA3IFBNLCBCUlVOR0FSRCwgREVCT1JBSCBBIDxk YjM1NDZAYXR0LmNvbT4gd3JvdGU6DQo+IA0KPiBJ4oCZbSB3b25kZXJpbmcgb24gYW5vdGhlciBh cHByb2FjaC4gSWYgSSByZWNhbGwgY29ycmVjdGx5IChteSBtZW1vcnkgbWF5IGhhdmUgZmFkZWQp LCB3ZSBoYWQgb3B0aW1pc20gdGhhdCBsaXNwLXNlYyB3b3VsZCBiZSBkb25lIGJ5IG5vdywgYW5k IHNvIGhhZCB3YWl0ZWQgb24gaXQuIEJ1dCBpdCBpcyBub3QuIExvb2tpbmcgYXQgdGhlIHJlZmVy ZW5jZSB0byBpdCBpbiBsaXNwLWludHJvLCBpdCBpcyBpbiB0aGUgc2VjdXJpdHkgc2VjdGlvbiBh cyDigJxhbmQgdGhlIGxpZ2h0d2VpZ2h0IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBwcm9wb3Nl ZCBieSBMSVNQLVNlYyBbSS1ELmlldGYtbGlzcC1zZWNdIHJlZHVjZXPigJ0uIEkgd2FzbuKAmXQg aW52b2x2ZWQgYXQgdGhlIHRpbWUsIGJ1dCBJ4oCZbSB3b25kZXJpbmcgd2h5IGEg4oCccHJvcG9z ZWQgbWVjaGFuaXNt4oCdIG1lcml0ZWQgYSBub3JtYXRpdmUgcmVmZXJlbmNlIGluIGFuIGluZm9y bWF0aW9uYWwgZG9jdW1lbnQ/DQo+ICANCg0KSXTigJlzIG15IHJlY29sbGVjdGlvbiB0aGF0IHRo ZXJlIHdhcyBmZWVkYmFjayBmcm9tIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSAoYXMgd2VsbCBh cyBtYW55IGluZGl2aWR1YWxzIGJleW9uZCB0aGF0IGFyZWEpIHRoYXQgdGhlIGV4aXN0aW5nLCBz cGVjaWZpZWQsIG1lY2hhbmlzbSBvZiBtYXAtcmVxdWVzdChub25jZSkvbWFwLXJlcGx5IHNlY3Vy aXR5IChlc3NlbnRpYWxseSB0aGUgdXNlIG9mIGEgbm9uY2UgYW5hbG9nb3VzIHRvIEROUykgd2Fz IG5vdCBzdWZmaWNpZW50bHkgc2VjdXJlIHRvIGJlIGRlcGxveWVkIG9uIGFuIEludGVybmV0IGNv bnRyb2wgcGxhbmUgcHJvdG9jb2wuIExJU1AtU0VDIHdhcyBhIGxpZ2h0d2VpZ2h0IHJlc3BvbnNl IHRvIHRoZSByZXF1aXJlbWVudCBvZiBwcm92aWRpbmcgYXV0aGVudGljYXRpb24gb2YgdGhlIHNl bmRlciAvIHJlcGxpZXIgY29udmVyc2F0aW9uIHRoYXQgZGlkIG5vdCByZXF1aXJlIGEgUEtJIGJh c2VkIHNvbHV0aW9uLiAgTElTUCwgdG8gZGF0ZSwgaGFzIGJlZW4gZGVwbG95ZWQgZm9yIG1hbnkg dXNlIGNhc2VzIGJleW9uZCBpbnRlcm5ldCByb3V0ZS1zY2FsaW5nLCBzb21lIG9mIHdoaWNoIHRh a2UgYWR2YW50YWdlIG9mIExJU1AtU0VDLCBhbmQgc29tZSBvZiB3aGljaCBoYXZlIG5vIG5lZWQg Zm9yIGl0cyBiZW5lZml0Lg0KDQpSZWdhcmRzLA0KDQotRGFycmVs From nobody Tue Sep 11 17:27:08 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5495130F47 for ; Tue, 11 Sep 2018 17:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 NIQzWjq8es_C for ; Tue, 11 Sep 2018 17:27:03 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF06130EC4 for ; Tue, 11 Sep 2018 17:27:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 559BD44074E; Tue, 11 Sep 2018 17:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1536712023; bh=vVACdPpCmvAGiajxwvhwbPdgt+joRBYUFHXQf/XA/gw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GkpUKr1GFaYNHeGQAzU1uwQCKYrSVcmjFtxbKH4zYleFFd2w/GEeJCPJ1sQaLpcJ+ XbYch2hvnvdu7Z3Ii0IdPFX6NMLJxZmuhFpIf+eXupnCdR2cPUK5Gdc+2e/4rqnVbj TX6wmPLmm7JzmbKjCkDAFDmuBCaSlm3yxRmx+SBs= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [207.96.227.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 639394405F6; Tue, 11 Sep 2018 17:27:02 -0700 (PDT) To: Alvaro Retana , Dino Farinacci , Luigi Iannone , "BRUNGARD, DEBORAH A, ATTLABS" Cc: "lisp@ietf.org" References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 11 Sep 2018 20:27:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 00:27:06 -0000 I just went and looked again at draft-ietf-lisp-rfc6830bis and draft-ietf-lisp-introduction. I do not see a circularity problem. 6833bis says, as you quote, that "draft-ietf-lisp-introduction describes the LISP archtiecture." And draft-ietf-lisp-introduction says "this document introduces the Locator/ID Separation Protocol ... architecture". (Yes, I elided the reference to 6830, because it is essentially meaninglss in that sentence. It is, the protocol definition.) Seems quite consistent. I do not see any need to change what is the the bis draft in this regard. In a perfect world, the introduction draft (in the rfc editor queue) would point to 6830bis and 6833 bis. If the ADs agree that is appropriate, they can direct the RFC Editor to make thaqt change. I do not consider this to be substantive, as the protocol behavior is not different between the documents (unlike the ongoing controversy about ICE.) I do not consider such a change necessary. On 9/11/18 12:29 PM, Alvaro Retana wrote: > On September 11, 2018 at 9:50:29 AM, Joel M. Halpern > (jmh@joelhalpern.com ) wrote: > > Hi! > >> Any change to lisp-intro should be done by discussion with the RFC >> Editor, as it is in the RFC Editor queue (pending reference completion). >> If the working group considers it acceptable, we could easily ask them >> to change the references to 6830 and 6833 to the bis documents (after >> all, it is alreay blocked by documents which depend upon those.) > > The reference would still be circular: rfc6830bis would point at > lisp-introduction for architecture details, and that would point back here. > > If lisp-introduction was just that (an introduction) and the details > were in rfc6830 to start with…. Maybe the easy fix is to just not point > to lisp-introduction from rfc6830bis, because the details should be here > (and rfc6833bis) already. > > s/Finally, [I-D.ietf-lisp-introduction] describes the LISP architecture.// > > Alvaro. > > >> >> >> Yours, >> Joel >> >> On 9/10/18 11:27 PM, Dino Farinacci wrote: >> > If you guys have source for the intro doc, I could point it to bis >> > documents? >> > >> > Dino >> > >> > >> > Begin forwarded message: >> > >> >> *Resent-From:* >> >> >> >> *From:* Alvaro Retana >> >> >> >> >> *Date:* September 10, 2018 at 2:22:21 PM PDT >> >> *Resent-To:* farinacci@gmail.com >> >, >> >> vince.fuller@gmail.com >> >, >> dmm@1-4-5.net >> >> >, darlewis@cisco.com >> >> >> >, acabello@ac.upc.edu >> >> >> > >> >> *To:* "The IESG" > >> >> >> *Cc:* draft-ietf-lisp-rfc6830bis@ietf.org >> >> >> > >, Luigi Iannone >> >> > >>, lisp-chairs@ietf.org >> >> >> >, lisp@ietf.org >> > >> >> *Subject:* *Alvaro Retana's No Objection on >> >> draft-ietf-lisp-rfc6830bis-16: (with COMMENT)* >> >> >> >> Alvaro Retana has entered the following ballot position for >> >> draft-ietf-lisp-rfc6830bis-16: No Objection >> >> >> >> 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 https://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: >> >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >> >> COMMENT: >> >> ---------------------------------------------------------------------- >> >> >> >> Thanks for the work on this document! >> >> >> >> I have some relatively minor comments/nits: >> >> >> >> (1) §18: s/RFC8060/RFC8061 >> >> >> >> (2) §1: "Finally, [I-D.ietf-lisp-introduction] describes the LISP >> >> architecture."  First of all, it would seem to me that the >> >> Architecture should >> >> be a Normative reference...but I-D.ietf-lisp-introduction says that it >> >> "is used >> >> for introductory purposes, more details can be found in RFC6830, the >> >> protocol >> >> specification."  This document obsoletes rfc6830...so it seems to me >> >> that there >> >> is a failed circular dependency. >> >> >> >> (3) References to rfc2119/rfc8174 and rfc8126 should be Normative. >> >> >> >> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > From nobody Tue Sep 11 17:44:27 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FA2130DE1 for ; Tue, 11 Sep 2018 17:44:26 -0700 (PDT) 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 autolearn_force=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 GF6SkxsrhSeD for ; Tue, 11 Sep 2018 17:44:24 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D494126CC7 for ; Tue, 11 Sep 2018 17:44:24 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w8BM0Kqn002695; Tue, 11 Sep 2018 18:01:05 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 2mep4b00w3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Sep 2018 18:01:04 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8BM11YK027179; Tue, 11 Sep 2018 18:01:03 -0400 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8BM0vNS026968; Tue, 11 Sep 2018 18:00:57 -0400 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id 7FBAD16A3EE; Tue, 11 Sep 2018 22:00:57 +0000 (GMT) Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (unknown [130.9.129.147]) by zlp27125.vci.att.com (Service) with ESMTPS id 6D56716A3EC; Tue, 11 Sep 2018 22:00:57 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.139]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0415.000; Tue, 11 Sep 2018 18:00:56 -0400 From: "BRUNGARD, DEBORAH A" To: Dino Farinacci CC: Albert Cabellos , "lisp@ietf.org list" Thread-Topic: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) Thread-Index: AQHUSUxnqYCQtt45cUGrQKtyQStbFKTqbE2xgADw4oCAACyCgIAAAhwAgAA5zYD//8IUwIAAUWqA///Jx+A= Date: Tue, 11 Sep 2018 22:00:56 +0000 Message-ID: References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> <8A78EF35-B0E4-43EC-A6B7-EB7DED60210F@gmail.com> <7DD44D1F-06E5-494D-B760-B1462FD9DC01@gmail.com> In-Reply-To: <7DD44D1F-06E5-494D-B760-B1462FD9DC01@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.164.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-11_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809110216 Archived-At: Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 00:44:26 -0000 SWYgd2Ugd2FudCB0byBnZXQgbGlzcC1pbnRybyBkb25lIG5vdywgd2Ugc2hvdWxkIGxlYXZlIHRo ZSByZWZlcmVuY2UgdG8gUkZDNjgzMC4gSWYgY2hhbmdlIHRvIHRoZSBiaXMsIHdlIG5lZWQgdG8g d2FpdCB1bnRpbCB0aGV5IGFyZSBwdWJsaXNoZWQgYXMgdGhleSBhbHNvIHdvdWxkIGJlIGxpc3Rl ZCBub3JtYXRpdmVseS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpbm8g RmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPiANClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJl ciAxMSwgMjAxOCA1OjE0IFBNDQpUbzogQlJVTkdBUkQsIERFQk9SQUggQSA8ZGIzNTQ2QGF0dC5j b20+DQpDYzogQWxiZXJ0IENhYmVsbG9zIDxhbGJlcnQuY2FiZWxsb3NAZ21haWwuY29tPjsgbGlz cEBpZXRmLm9yZyBsaXN0IDxsaXNwQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtsaXNwXSBGd2Q6 IEFsdmFybyBSZXRhbmEncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBi aXMtMTY6ICh3aXRoIENPTU1FTlQpDQoNCj4gSSBkb27igJl0IHNlZSBsaXNwLXNlYyBhcyBlc3Nl bnRpYWwgdG8gaW1wbGVtZW50aW5nIGxpc3AtaW50cm8uIEkgZG9u4oCZdCBrbm93IHdoeSBpdCB3 YXMgbGlzdGVkIGFzIG5vcm1hdGl2ZT8gVG8gbWUsIGl0IGlzIHByb3ZpZGluZyBhZGRpdGlvbmFs IGluZm9ybWF0aW9uLg0KDQpJIGFncmVlIExJU1AtU0VDIGlzIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24gZm9yIGFuIGludHJvZHVjdG9yeSBkb2N1bWVudC4gWW91IGJyaW5nIHVwIGEgZ29vZCBwb2lu dC4NCg0KPiBJZiB0aGUgd29ya2luZyBncm91cCBhZ3JlZXMsIEkgY2FuIGNoZWNrIHdpdGggdGhl IFJGQy1FZGl0b3IgaWYgY2FuIG1vdmUgbGlzcC1zZWN1cml0eSB0byBpbmZvcm1hdGl2ZS4gSSB0 aGluayB0aGUgY2hhbmdlIHdpbGwgb25seSBuZWVkIGF1dGhvciBhbmQgQUQgYXBwcm92YWwuIERv ZXMgYW55b25lIGhhdmUgYW55IGNvbmNlcm5zPyBPciBpcyBsaXNwLXNlY3VyaXR5IOKAnGFsbW9z dCBkb25l4oCdIGFuZCBzaG91bGQgY29udGludWUgdG8gd2FpdD8NCg0KSSBhZ3JlZSB3aXRoIHlv dXIgcHJvcG9zYWwuIEJ1dCBoYXZlIGFub3RoZXIgcXVlc3Rpb24uIElmIHdlIHVwZGF0ZSB0aGUg bGlzcC1pbnRybyB0byBtb3ZlIHRoaXMgcmVmZXJlbmNlIHRvIEluZm9ybWF0aXZlLCBkbyB5b3Ug YXQgdGhlIHNhbWUgdGltZSBjaGFuZ2UgYWxsIG9jY3VyZW5jZXMgb2YgNjgzMC82ODMzIHRvIHRo ZSBiaXMgZG9jdW1lbnQgZXF1aXZhbGVudHMgb3IgZG8geW91IHdhbnQgdG8gcHVzaCBsaXNwLWlu dHJvIHRocm91Z2g/DQoNCkkgd291bGQgc2F5IGdvIGZvciB0aGUgbGF0dGVyIHNpbmNlIHRoZSBp bmZvcm1hdGlvbiBpbiA2ODMwLzY4MzMgaGFzIG5vdCBjaGFuZ2VkIHdoZW4gc2h1ZmZsaW5nIHNl Y3Rpb25zIGFyb3VuZCBpbnRvIDY4MzBiaXMvNjgzM2Jpcy4gU28gQWxiZXJ0LCB0aGUgaW5mb3Jt YXRpb24gaW4gUkZDNjgzMCBpcyBub3Qgb2Jzb2xldGVkIGJ1dCB0aGUgZG9jdW1lbnQgbWF5IGJl Lg0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KRGlubw0K From nobody Tue Sep 11 23:41:20 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DD6130EC4 for ; Tue, 11 Sep 2018 23:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.079 X-Spam-Level: X-Spam-Status: No, score=0.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 tYl4AFW2b-io for ; Tue, 11 Sep 2018 23:41:14 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 2EFAB127148 for ; Tue, 11 Sep 2018 23:41:14 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id t25-v6so1019794wmi.3 for ; Tue, 11 Sep 2018 23:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yQztQ1DuO6J5SmkO6Nq7YjhEtPht/Tk0RXTo77p/hxg=; b=BeKloV3z9ryuVV4QvPiSzXShbj3PL1AvkRfBSbJ5Emzj50OR9IfrwJxUzOSEewcWpa Fh0MkjQcMS7hZ9IaJvNtUuMp0HeOIFe/bCS5DJ7/BCbAfVdG11TklKCxqlJ1JeTQ1Daj 35XlzSdirKxSvwka/qHhAhiidnFuEV2pSDLnMwYYWIyOnZ0TZRx+zn73lRVQBurPJqHy uP23B2ACZfSJTKWj7wua6a7/eWnQzHJc9Z/NyXvLXAQwNIGqCVckbq7ko5mN3CaMh4Yg Ke+CDGI7Pf2XUbqsdsMIgyubp1DRdSLtt9DJE7QLm5TGO1NR3+dowFKK0Nv1GL9NJQP6 sEbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yQztQ1DuO6J5SmkO6Nq7YjhEtPht/Tk0RXTo77p/hxg=; b=ifTBE1e7n/XrhGn+JmuWVsxBSzxC0/CWqcEsyKWJSL0kVXAbWsQZvSKBWVAwyO7wj7 iPgSyLRiFVr6/oR7I42RnLVcfTmJr/iGiDA8F3diO/SShA8IRfG98V239f3VpaoMY1nc YBvAPJWLKi6hcUGYjXfmMtoDOjmcgI4H+PrkfMQnfSlN/ciUmwaKmgSTBBXTW+3AEqru xQHPH31qPlPE3vQfyCShd+zsdGVJ0PD6ou0va3YXU2WqHDfJMsG0pVYWKIkxTNy5TqBI MPzSPJF0TbKd38n7pBYR6VCcKWcLPe8ZlJVeJi7RU9b+kCWWCNjKKKY6fLSrjXymFhDu Kf/A== X-Gm-Message-State: APzg51BVgYHKM1GaWwUwrZDvgFrOig8qDdbzk3nnG6TwuWMx0MYGgq1U 8Ll26o3dFl0w5JmtbWnXaNQTaQ== X-Google-Smtp-Source: ANB0VdYv0klCgE/Cs9pmPJYj88YoYjecFP5u4CtS72BOgykxfRrWaCHbHxZdqN/0DlL8Vl9YGSAqXw== X-Received: by 2002:a1c:dcf:: with SMTP id 198-v6mr517239wmn.131.1536734472384; Tue, 11 Sep 2018 23:41:12 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:dc2d:473b:4ed7:e2e8? ([2001:660:330f:a4:dc2d:473b:4ed7:e2e8]) by smtp.gmail.com with ESMTPSA id 94-v6sm179531wrc.10.2018.09.11.23.41.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 23:41:11 -0700 (PDT) From: Luigi Iannone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_830CC6DF-7A0C-4867-BB22-9475EC4B5DEF" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 12 Sep 2018 08:41:10 +0200 In-Reply-To: Cc: Albert Cabellos , Dino Farinacci , "lisp@ietf.org list" To: "BRUNGARD, DEBORAH A" References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> <8A78EF35-B0E4-43EC-A6B7-EB7DED60210F@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 06:41:19 -0000 --Apple-Mail=_830CC6DF-7A0C-4867-BB22-9475EC4B5DEF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Deborah, LISP-Sec is pretty much done. Once are moved forward we just need to = make LISP-Sec standard track, double check consistency with the bis = documents (as a shepherd I=E2=80=99ll do it), and then go for WGLC. = There are good chances that we can wrap it up before IETF 103. Having said the above, I agree with you that LISP-Sec does not need to = be a normative reference in the Intro document. Ciao L. > On 11 Sep 2018, at 23:07, BRUNGARD, DEBORAH A wrote: >=20 > Hi Albert, > =20 > LISP-intro is only blocked by one document, lisp-sec. One could do an = update, though as Dino noted, because RFC6830 included both 6830bis and = 6833bis, one would need to go thru the document and clean up all the = references to RFC6830. And then one would need to wait for these = documents to progress as they are both normative. The current version is = ok as is - it points to RFC6830 (and datatracker will point a reader to = the bis=E2=80=99s). > =20 > I=E2=80=99m wondering on another approach. If I recall correctly (my = memory may have faded), we had optimism that lisp-sec would be done by = now, and so had waited on it. But it is not. Looking at the reference to = it in lisp-intro, it is in the security section as =E2=80=9Cand the = lightweight authentication mechanism proposed by LISP-Sec = [I-D.ietf-lisp-sec] reduces=E2=80=9D. I wasn=E2=80=99t involved at the = time, but I=E2=80=99m wondering why a =E2=80=9Cproposed mechanism=E2=80=9D= merited a normative reference in an informational document? > =20 > RFC7322 RFC Style Guide has: > =E2=80=9CReference lists must indicate whether each reference is = normative or informative, where normative references are essential to = implementing or understanding the content of the RFC and informative = references provide additional information=E2=80=9D. > =20 > I don=E2=80=99t see lisp-sec as essential to implementing lisp-intro. = I don=E2=80=99t know why it was listed as normative? To me, it is = providing additional information. > =20 > If the working group agrees, I can check with the RFC-Editor if can = move lisp-security to informative. I think the change will only need = author and AD approval. Does anyone have any concerns? Or is = lisp-security =E2=80=9Calmost done=E2=80=9D and should continue to wait? > =20 > Deborah > =20 > =20 > From: lisp On Behalf Of Albert Cabellos > Sent: Tuesday, September 11, 2018 4:04 PM > To: Dino Farinacci > Cc: lisp@ietf.org list > Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on = draft-ietf-lisp-rfc6830bis-16: (with COMMENT) > =20 > Hi > =20 > I am not familiar with all the IETF procedures, but lisp-intro has = been waiting for a missing reference for 1000+ days and the day it will = become RFC it will be referencing an obsolete document. > =20 > I think that we should make it right, if someone can shepherd me on = what to do I=C2=B4ll be happy to work on it. > =20 > Albert > =20 > On Tue, Sep 11, 2018 at 6:37 PM Dino Farinacci > wrote: > Right now there is no circular dependency. To summarize: >=20 > (1) RFC6830 does not point to 6830bis or lisp-intro. > (2) lisp-intro points to RFC6830. > (3) 6860bis needs to point to RFC6830. >=20 > Let=E2=80=99s please don=E2=80=99t change any this. Let=E2=80=99s not = make this more complciated then it needs to be and let=E2=80=99s not = confuse people, especially the authors. ;-) >=20 > Dino >=20 >=20 > > On Sep 11, 2018, at 9:29 AM, Alvaro Retana > wrote: > >=20 > > On September 11, 2018 at 9:50:29 AM, Joel M. Halpern = (jmh@joelhalpern.com ) wrote: > >=20 > > Hi! > >=20 > >> Any change to lisp-intro should be done by discussion with the RFC=20= > >> Editor, as it is in the RFC Editor queue (pending reference = completion). > >> If the working group considers it acceptable, we could easily ask = them=20 > >> to change the references to 6830 and 6833 to the bis documents = (after=20 > >> all, it is alreay blocked by documents which depend upon those.) > > The reference would still be circular: rfc6830bis would point at = lisp-introduction for architecture details, and that would point back = here. > >=20 > > If lisp-introduction was just that (an introduction) and the details = were in rfc6830 to start with=E2=80=A6. Maybe the easy fix is to just = not point to lisp-introduction from rfc6830bis, because the details = should be here (and rfc6833bis) already. > >=20 > > s/Finally, [I-D.ietf-lisp-introduction] describes the LISP = architecture.// > >=20 > > Alvaro. > >=20 > >=20 > >=20 > >>=20 > >>=20 > >> Yours, > >> Joel > >>=20 > >> On 9/10/18 11:27 PM, Dino Farinacci wrote: > >> > If you guys have source for the intro doc, I could point it to = bis=20 > >> > documents? > >> >=20 > >> > Dino > >> >=20 > >> >=20 > >> > Begin forwarded message: > >> >=20 > >> >> *Resent-From:* >> > >> >> *From:* Alvaro Retana =20 > >> >> >> > >> >> *Date:* September 10, 2018 at 2:22:21 PM PDT > >> >> *Resent-To:* farinacci@gmail.com = >,=20 > >> >> vince.fuller@gmail.com = >, = dmm@1-4-5.net =20 > >> >> >, = darlewis@cisco.com =20 > >> >> >, = acabello@ac.upc.edu =20 > >> >> > > >> >> *To:* "The IESG" = >> > >> >> *Cc:* draft-ietf-lisp-rfc6830bis@ietf.org = =20 > >> >> >, Luigi Iannone=20 > >> >> >>, lisp-chairs@ietf.org = =20 > >> >> >, = lisp@ietf.org > > >> >> *Subject:* *Alvaro Retana's No Objection on=20 > >> >> draft-ietf-lisp-rfc6830bis-16: (with COMMENT)* > >> >> > >> >> Alvaro Retana has entered the following ballot position for > >> >> draft-ietf-lisp-rfc6830bis-16: No Objection > >> >> > >> >> 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 = https://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: > >> >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ = > >> >> > >> >> > >> >> > >> >> = ---------------------------------------------------------------------- > >> >> COMMENT: > >> >> = ---------------------------------------------------------------------- > >> >> > >> >> Thanks for the work on this document! > >> >> > >> >> I have some relatively minor comments/nits: > >> >> > >> >> (1) =C2=A718: s/RFC8060/RFC8061 > >> >> > >> >> (2) =C2=A71: "Finally, [I-D.ietf-lisp-introduction] describes = the LISP > >> >> architecture." First of all, it would seem to me that the=20 > >> >> Architecture should > >> >> be a Normative reference...but I-D.ietf-lisp-introduction says = that it=20 > >> >> "is used > >> >> for introductory purposes, more details can be found in RFC6830, = the=20 > >> >> protocol > >> >> specification." This document obsoletes rfc6830...so it seems = to me=20 > >> >> that there > >> >> is a failed circular dependency. > >> >> > >> >> (3) References to rfc2119/rfc8174 and rfc8126 should be = Normative. > >> >> > >> >> > >>=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 = _______________________________________= ________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_830CC6DF-7A0C-4867-BB22-9475EC4B5DEF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Deborah,

LISP-Sec= is pretty much done. Once are moved forward we just need to make = LISP-Sec standard track, double check consistency with the bis documents = (as a shepherd I=E2=80=99ll do it), and then go for WGLC. There are good = chances that we can wrap it up before IETF 103.

Having said the above, I agree with you that = LISP-Sec does not need to be a normative reference in the Intro = document.

Ciao

L.



On 11 Sep 2018, at 23:07, BRUNGARD, DEBORAH A = <db3546@att.com> = wrote:

Hi = Albert,
 
LISP-intro is only blocked by one document, lisp-sec. One = could do an update, though as Dino noted, because RFC6830 included both = 6830bis and 6833bis, one would need to go thru the document and clean up = all the references to RFC6830. And then one would need to wait for these = documents to progress as they are both normative. The current version is = ok as is - it points to RFC6830 (and datatracker will point a reader to = the bis=E2=80=99s).
 
I=E2=80=99m wondering on another approach. If I recall = correctly (my memory may have faded), we had optimism that lisp-sec = would be done by now, and so had waited on it. But it is not. Looking at = the reference to it in lisp-intro, it is in the security section as = =E2=80=9Cand the lightweight authentication mechanism proposed by = LISP-Sec [I-D.ietf-lisp-sec] reduces=E2=80=9D. I wasn=E2=80=99t involved = at the time, but I=E2=80=99m wondering why a =E2=80=9Cproposed = mechanism=E2=80=9D merited a normative reference in an informational = document?
 
RFC7322 RFC Style Guide has:
=E2=80=9CReference lists must indicate = whether each reference is normative or informative, where normative = references are essential to implementing or understanding the content of = the RFC and informative references provide additional = information=E2=80=9D.
 
I don=E2=80=99t see lisp-sec as essential to implementing = lisp-intro. I don=E2=80=99t know why it was listed as normative? To me, = it is providing additional information.
 
If the working group agrees, I can = check with the RFC-Editor if can move lisp-security to informative. I = think the change will only need author and AD approval. Does anyone have = any concerns? Or is lisp-security =E2=80=9Calmost done=E2=80=9D and = should continue to wait?
 
Deborah
 
 
From: lisp <lisp-bounces@ietf.org> On Behalf = Of Albert = Cabellos
Sent: Tuesday, September 11, 2018 = 4:04 PM
To: Dino Farinacci <farinacci@gmail.com>
Cc: lisp@ietf.org list <lisp@ietf.org>
Subject: Re: [lisp] Fwd: Alvaro = Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with = COMMENT)
 
Hi
 
I am not familiar with all the IETF procedures, but = lisp-intro has been waiting for a missing reference for 1000+ days and = the day it will become RFC it will be referencing an obsolete = document.
 
I think that we should make it right, if someone can shepherd = me on what to do I=C2=B4ll be happy to work on it.
 
Albert
 
On Tue, Sep 11, 2018 at = 6:37 PM Dino Farinacci <farinacci@gmail.com> wrote:
Right now there is = no circular dependency. To summarize:

(1) = RFC6830 does not point to 6830bis or lisp-intro.
(2) = lisp-intro points to RFC6830.
(3) 6860bis needs to point = to RFC6830.

Let=E2=80=99s please don=E2=80=99= t change any this. Let=E2=80=99s not make this more complciated then it = needs to be and let=E2=80=99s not confuse people, especially the = authors. ;-)

Dino


> On Sep 11, 2018, at 9:29 AM, Alvaro = Retana <aretana.ietf@gmail.com> wrote:
> 
> On = September 11, 2018 at 9:50:29 AM, Joel M. Halpern (jmh@joelhalpern.com) = wrote:
> 
> Hi!
> 
>> Any change to lisp-intro should be done by = discussion with the RFC 
>> = Editor, as it is in the RFC Editor queue (pending reference = completion).
>> If the working group considers it = acceptable, we could easily ask them 
>> to = change the references to 6830 and 6833 to the bis documents (after 
>> = all, it is alreay blocked by documents which depend upon those.)
> The reference would still be circular: rfc6830bis would = point at lisp-introduction for architecture details, and that would = point back here.
> 
> If = lisp-introduction was just that (an introduction) and the details were = in rfc6830 to start with=E2=80=A6. Maybe the easy fix is to just not = point to lisp-introduction from rfc6830bis, because the details should = be here (and rfc6833bis) already.
> 
> = s/Finally, [I-D.ietf-lisp-introduction] describes the LISP = architecture.//
> 
> = Alvaro.
> 
> 
> 
>> 
>> 
>> = Yours,
>> Joel
>> 
>> On = 9/10/18 11:27 PM, Dino Farinacci wrote:
>> > If = you guys have source for the intro doc, I could point it to bis 
>> = > documents?
>> > 
>> = > Dino
>> > 
>> = > 
>> > Begin forwarded message:
>> = > 
>> >> *Resent-From:* <alias-bounces@ietf.org <mailto:alias-bounces@ietf.org>>
>> = >> *From:* Alvaro Retana <aretana.ietf@gmail.com 
>> = >> <mailto:aretana.ietf@gmail.com>>
>> = >> *Date:* September 10, 2018 at 2:22:21 PM PDT
>> >> *Resent-To:* farinacci@gmail.com <mailto:farinacci@gmail.com>, 
>> = >> vince.fuller@gmail.com <mailto:vince.fuller@gmail.com>, dmm@1-4-5.net 
>> = >> <mailto:dmm@1-4-5.net>, darlewis@cisco.com 
>> = >> <mailto:darlewis@cisco.com>, acabello@ac.upc.edu 
>> = >> <mailto:acabello@ac.upc.edu>
>> >> = *To:* "The IESG" <iesg@ietf.org <mailto:iesg@ietf.org>>
>> >> *Cc:* draft-ietf-lisp-rfc6830bis@ietf.org 
>> = >> <mailto:draft-ietf-lisp-rfc6830bis@ietf.org>, Luigi = Iannone 
>> >> <ggx@gigix.net <mailto:ggx@gigix.net>>, lisp-chairs@ietf.org 
>> = >> <mailto:lisp-chairs@ietf.org>, lisp@ietf.org <mailto:lisp@ietf.org>
>> >> *Subject:* *Alvaro Retana's No Objection = on 
>> >> draft-ietf-lisp-rfc6830bis-16: (with = COMMENT)*
>> >>
>> = >> Alvaro Retana has entered the following ballot position for
>> >> draft-ietf-lisp-rfc6830bis-16: No = Objection
>> >>
>> = >> 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 https://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:
>> >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
>> >>
>> >>
>> >>
>> >> = ----------------------------------------------------------------------
>> >> COMMENT:
>> >> = ----------------------------------------------------------------------
>> >>
>> >> Thanks for = the work on this document!
>> >>
>> >> I have some relatively minor = comments/nits:
>> >>
>> = >> (1) =C2=A718: s/RFC8060/RFC8061
>> = >>
>> >> (2) =C2=A71: "Finally, = [I-D.ietf-lisp-introduction] describes the LISP
>> = >> architecture."  First of all, it would seem to me that = the 
>> >> Architecture should
>> = >> be a Normative reference...but I-D.ietf-lisp-introduction says = that it 
>> >> "is used
>> >> = for introductory purposes, more details can be found in RFC6830, = the 
>> >> protocol
>> >> = specification."  This document obsoletes rfc6830...so it seems to = me 
>> >> that there
>> >> = is a failed circular dependency.
>> >>
>> >> (3) References to rfc2119/rfc8174 and = rfc8126 should be Normative.
>> >>
>> >>
>> 
>> = _______________________________________________
>> = 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

= --Apple-Mail=_830CC6DF-7A0C-4867-BB22-9475EC4B5DEF-- From nobody Tue Sep 11 23:50:18 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7860F130DD6 for ; Tue, 11 Sep 2018 23:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 UF0Pwttx5rod for ; Tue, 11 Sep 2018 23:50:14 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 64EC7127148 for ; Tue, 11 Sep 2018 23:50:14 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id e1-v6so743253wrt.3 for ; Tue, 11 Sep 2018 23:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2WUSA/GhU5T4ON9Vl0b5JjaOkMN5ZPuBCGaqBZgSNaQ=; b=LntwAFz15XGweL37FOvLIoRqO5mTAAnDdqh6+7U6Ho8UWoq6luBOJK7Deg67V4BkmO ZNjvps8f7hyn5dG4whbJmwRFmv/cBg0cZzERpWv1af65pZIvTqNkiYAhvStV9svyFGyU ActoM0htblszz0/sdra2tZU29o5bvye2oREIAbjgwpgUlMZ6DiZ0FturtSIkna2CTBDB +wy42n57b+uvWYrZJFnNvr3/FPMdXCAdWm8i+igIEbNCDXj0Oa5YuuT+papzZyEWcckI 3qijAReFqVTYJRlUBQ4vnZVLuhW9ReQUyY866RTbVZaOe+gkohUttBQeRI3KhebakzIt YrRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2WUSA/GhU5T4ON9Vl0b5JjaOkMN5ZPuBCGaqBZgSNaQ=; b=RcRLPeR8KmOhW4eTPv2jW1eAskizOj34rkwRuX8WO2ngJ4k9gHkh9M4fO2o4euLOjn ioWV2OmU0eJvwGQOL5KPUQDddeyTEC0YsEIWi5xe/CdL4SyJHAL4Q33Mqh8U/+HAmCkb A82zSFAbpWLhXpRoi1OZJ2skz92/hFBKf4FVwKwbcmWRQdc4Mv98CRhvDzG567cBib73 i5YRQAlxL1kHVV4oeETL1VOix2JDqMFE08hHcemmOuJmE8PYmM8oux3gCGKSH4unjExZ n4zSPK1AaTAKkjUCotBuQ9+l00+7Rissa9l5IMlgY3yenpi79SKGtI9ZtPBioaagpuCv 8nnA== X-Gm-Message-State: APzg51Cgb67aUl0PurGw6uy0cLkFiV8IYjtXjI6FR08pI0ziLuIIGVr6 GkUPFYTw4f/GC3bHPSJeCOE8gw== X-Google-Smtp-Source: ANB0VdZrKfBUFYp7x2XpStUFlBw1rHnwHHcv3cVQFxxyFw0OqB8sC25MobLNXpjL6eq2pmsCuvSa+w== X-Received: by 2002:adf:d1c1:: with SMTP id m1-v6mr376236wri.138.1536735012675; Tue, 11 Sep 2018 23:50:12 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:dc2d:473b:4ed7:e2e8? ([2001:660:330f:a4:dc2d:473b:4ed7:e2e8]) by smtp.gmail.com with ESMTPSA id l24-v6sm303456wrb.65.2018.09.11.23.50.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 23:50:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Luigi Iannone In-Reply-To: Date: Wed, 12 Sep 2018 08:50:05 +0200 Cc: Alvaro Retana , Dino Farinacci , "BRUNGARD, DEBORAH A, ATTLABS" , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <46E19071-C691-4644-A3D8-5C52FFA7BFB9@gigix.net> References: <153661454107.16021.14181238567935017697.idtracker@ietfa.amsl.com> <82C0DF7A-E661-48DF-ABCE-7C830E875E70@gmail.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 06:50:17 -0000 Hi, _IF_ we go for references update in the Intro document, we should proof = read the whole document because some things have been moved around. For instance: lisp-intro states SMR is defined in 6830, we cannot = replace it with 6830bis, because now it is defined in 6833bis. Ciao L. > On 12 Sep 2018, at 02:27, Joel M. Halpern wrote: >=20 > I just went and looked again at draft-ietf-lisp-rfc6830bis and = draft-ietf-lisp-introduction. >=20 > I do not see a circularity problem. >=20 > 6833bis says, as you quote, that "draft-ietf-lisp-introduction = describes the LISP archtiecture." > And draft-ietf-lisp-introduction says "this document introduces the = Locator/ID Separation Protocol ... architecture". > (Yes, I elided the reference to 6830, because it is essentially = meaninglss in that sentence. It is, the protocol definition.) > Seems quite consistent. >=20 > I do not see any need to change what is the the bis draft in this = regard. >=20 > In a perfect world, the introduction draft (in the rfc editor queue) = would point to 6830bis and 6833 bis. > If the ADs agree that is appropriate, they can direct the RFC Editor = to make thaqt change. I do not consider this to be substantive, as the = protocol behavior is not different between the documents (unlike the = ongoing controversy about ICE.) I do not consider such a change = necessary. >=20 >=20 >=20 > On 9/11/18 12:29 PM, Alvaro Retana wrote: >> On September 11, 2018 at 9:50:29 AM, Joel M. Halpern = (jmh@joelhalpern.com ) wrote: >> Hi! >>> Any change to lisp-intro should be done by discussion with the RFC >>> Editor, as it is in the RFC Editor queue (pending reference = completion). >>> If the working group considers it acceptable, we could easily ask = them >>> to change the references to 6830 and 6833 to the bis documents = (after >>> all, it is alreay blocked by documents which depend upon those.) >> The reference would still be circular: rfc6830bis would point at = lisp-introduction for architecture details, and that would point back = here. >> If lisp-introduction was just that (an introduction) and the details = were in rfc6830 to start with=E2=80=A6. Maybe the easy fix is to just = not point to lisp-introduction from rfc6830bis, because the details = should be here (and rfc6833bis) already. >> s/Finally, [I-D.ietf-lisp-introduction] describes the LISP = architecture.// >> Alvaro. >>>=20 >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 9/10/18 11:27 PM, Dino Farinacci wrote: >>> > If you guys have source for the intro doc, I could point it to bis >>> > documents? >>> > >>> > Dino >>> > >>> > >>> > Begin forwarded message: >>> > >>> >> *Resent-From:* >> >>> >> *From:* Alvaro Retana >>> >> >> >>> >> *Date:* September 10, 2018 at 2:22:21 PM PDT >>> >> *Resent-To:* farinacci@gmail.com = >, >>> >> vince.fuller@gmail.com = >, = dmm@1-4-5.net >>> >> >, darlewis@cisco.com = >>> >> >, = acabello@ac.upc.edu >>> >> > >>> >> *To:* "The IESG" = >> >>> >> *Cc:* draft-ietf-lisp-rfc6830bis@ietf.org = >>> >> >, Luigi Iannone >>> >> >>, lisp-chairs@ietf.org = >>> >> >, = lisp@ietf.org > >>> >> *Subject:* *Alvaro Retana's No Objection on >>> >> draft-ietf-lisp-rfc6830bis-16: (with COMMENT)* >>> >> >>> >> Alvaro Retana has entered the following ballot position for >>> >> draft-ietf-lisp-rfc6830bis-16: No Objection >>> >> >>> >> 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 = https://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: >>> >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >>> >> >>> >> >>> >> >>> >> = ---------------------------------------------------------------------- >>> >> COMMENT: >>> >> = ---------------------------------------------------------------------- >>> >> >>> >> Thanks for the work on this document! >>> >> >>> >> I have some relatively minor comments/nits: >>> >> >>> >> (1) =C2=A718: s/RFC8060/RFC8061 >>> >> >>> >> (2) =C2=A71: "Finally, [I-D.ietf-lisp-introduction] describes the = LISP >>> >> architecture." First of all, it would seem to me that the >>> >> Architecture should >>> >> be a Normative reference...but I-D.ietf-lisp-introduction says = that it >>> >> "is used >>> >> for introductory purposes, more details can be found in RFC6830, = the >>> >> protocol >>> >> specification." This document obsoletes rfc6830...so it seems to = me >>> >> that there >>> >> is a failed circular dependency. >>> >> >>> >> (3) References to rfc2119/rfc8174 and rfc8126 should be = Normative. >>> >> >>> >> >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Sep 12 00:30:50 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77D3130ED8 for ; Wed, 12 Sep 2018 00:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 MA8UBxgSC6Ds for ; Wed, 12 Sep 2018 00:30:47 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 F32A9130ECB for ; Wed, 12 Sep 2018 00:30:46 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id v17-v6so846903wrr.9 for ; Wed, 12 Sep 2018 00:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dNF039tQD7g06BARKEh/SyB9vcu6isubrXw3lkxT7Qo=; b=Bs7n95bhxVASOhQXeS/rzeoPj3tF2AZd7r3Oqe8Eh6166mRy24aWnC1dxGgczh2Y+g pySfVw2kde1cBWoFBSzamN8fWJFhbay2EM1RdpIxT/CdT+deBUbi181rg+Tfrb3MhPR5 b5HCZRxlhOiWPM1sy3oqp7Tq79U2O6Yc05b8N9r5iyzxgE7oX5OYo6UxRiMz3bo/Wy2r e6GDZrY4KkZ7Wu88JRoXJTdfxl8X6Y+Iz6f7+DqjfeLv5siaSw1Zlc8Qr6tH1tPc1y1h YH41okfAMY5ZyRqnNGx9IN/Pk1ibh98t0T4X7LY3RYe8BgO/ak0MlrqbWsxUOGYNovdo kWww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dNF039tQD7g06BARKEh/SyB9vcu6isubrXw3lkxT7Qo=; b=sDDaJVJ1FRu4v1YGtC1c3BDw52b/Uk9CmcwAt5ruCAVzSmWp/Xy5C5NLvi9ePWdfjp SR+xaQ7hWMsFV8TqfTfdSPDD9KgLLOjY+HWNKWMpNp4VfiLb8YbG96uhZgYfGYFhFxfH zF3k+zDoty2V+seRetzxvSHcxMX7k/m5Ef5oqaScciX/FdSi3S5mk0n4aRxCKElk/Y0r WdnJqUeDTSUDH7Fqm9PK3eJjGrtdVwGJSJueEAYWsOPyMFy5Nxr0l7MUjw1bxghOrj1Y oMVVfK9B9GHlzQm/GMuk4Eh2+MtBQhXqugzDxJRSniCU3Zj0AC8ykaUQEpd3Jg7jTj1q rK7w== X-Gm-Message-State: APzg51CdJzZgy8aoZ7RJYaM/5B5TQVoJeXQfTopT2N7Xl9k+vjJIXy0L Pxnfb5OV0OS6C5LYbOZAeNMY0g== X-Google-Smtp-Source: ANB0VdaDFU9s93u1XT4OiKy3lWSi7XCZyJLkZQmacoHFHfK5GfNruYIDH+W6MvEwOXGIRRUzwpiRGg== X-Received: by 2002:adf:ce90:: with SMTP id r16-v6mr453948wrn.112.1536737445358; Wed, 12 Sep 2018 00:30:45 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:dc2d:473b:4ed7:e2e8? ([2001:660:330f:a4:dc2d:473b:4ed7:e2e8]) by smtp.gmail.com with ESMTPSA id l130-v6sm552237wmd.16.2018.09.12.00.30.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 00:30:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Luigi Iannone In-Reply-To: <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> Date: Wed, 12 Sep 2018 09:30:43 +0200 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <00DCC7FC-096E-4822-A702-2EE4C70327EB@gigix.net> References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 07:30:49 -0000 Hi, two quick comments inline. > On 11 Sep 2018, at 20:13, Dino Farinacci wrote: >=20 >> 3) Given the following statement: >> "Note that while this document assumes a LISP-ALT database mapping >> infrastructure to illustrate certain aspects of Map-Server and Map- >> Resolver operation..." >> it seems that RFC6836 should be a normative reference, as it might = not be >> possible to understand all details explained in this doc with knowing = ALT. >=20 > I would like the lisp-chairs and/or Deborah to comment on this. >=20 IMO We can completely delete that sentence. The documents does a pretty = good job to talk in general terms about the mapping system and the use = of its front-end Map-Servers/Map-Resolvers. In the few cases where something specific to ALT and DDT can be said the = document actually does it. >> 4) Further I would also think that I-D.ietf-lisp-mn and = I-D.ietf-lisp-pubsub >> should be normative references as the meaning of the respective bits = it not >> further specified in this doc. Or can these bits just be ignored if >> I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so = that >> should be stated. >=20 > I would like the lisp-chairs and/or Deborah to comment on this. >=20 Those bits can be ignored if an implementer choses not to support those = mechanisms. Hence, the documents do not really need to be normative. Ciao L. From nobody Wed Sep 12 03:17:41 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D56130E6C for ; Wed, 12 Sep 2018 03:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 EnD3ZjzFctz0 for ; Wed, 12 Sep 2018 03:17:38 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3623130E6A for ; Wed, 12 Sep 2018 03:17:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=EvXL58qX4qm+WxAhHZr8rD020q56WNkJq3Tqstn0CBVc+P0wi7+QCc8opP1rnr7IYuzEbr+cEfjHswZaaTzb0g34vNU706TaY6VcEmOGygzWESrH1uBVm14SvPh0TSwfSQ1wRgkPKq5BsUy09hbX6Or6/ZGehsMKN6vGcvs5hEo=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 19900 invoked from network); 12 Sep 2018 12:17:35 +0200 Received: from mue-88-130-61-212.dsl.tropolys.de (HELO ?192.168.178.24?) (88.130.61.212) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Sep 2018 12:17:35 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 12 Sep 2018 12:17:33 +0200 Cc: Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" , The IESG , draft-ietf-lisp-rfc6830bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) X-PPP-Message-ID: <20180912101735.19891.80281@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 10:17:40 -0000 Hi again, please see below. > Am 11.09.2018 um 18:45 schrieb Dino Farinacci : >=20 >=20 >>> Well it doesn=E2=80=99t have to be. I am a bit hesitant to just = point to another long complicated RFC. This text has gone through review = for quite a long time and many ECN experts decided we should write it = this way. And this text did go through IESG review when RFC6830 was made = experimental RFC. >>=20 >> Procedere explained in RFC6040 are actually not that complicated. = It=E2=80=99s mainly the table provided in section 3.2. Please have a = look at the draft. However, I disagree that it =E2=80=9Enegative=E2=80=9C = to point for this part to another RFC. This is not a unique problem, = that=E2=80=99s why we have RFC6040 and all approaches that face this = problem should point to RFC6040 and implement the same strategy. >=20 > I am just worried it will be ignored because there are implementations = out there that do what they already do. If we want to suggest to = consider the procedures in RFC6040, I am okay with that, but you need to = provide the wording because I certainly don=E2=80=99t want it too = strong. Actually the behavior as currently described in the lisp draft is not = even complainant with rfc3138, however, rfc3168 is updated by rfc6040. = The encapsulation in the lisp draft behavior is already what RFC6040 = described; so that=E2=80=99s good. However, the decapsulation is neither = what RFC3168 nor rfc6040 says. Therefore this must be fixed and I guess = a bis doc is also the best chance we get to fix these incorrect = implementation then. If you are worried that this will be ignored, you = should mention it explicitly in section 18 (Changes since RFC 6830). There is no matter about the wording being too strong or whatever, = RFC6040 is very clear about the correct behavior and that is exactly = what needs to be implemented. Please go ahead and read RFC6040. If you = need further help, please ask an ECN expert for help, e.g. Bob Briscoe = who is the author of RFC6040. Please note that I actually pointer to a wrong section in RFC6040 above. = It should of course be 4.2 (and not 3.2). >=20 >>>=20 >>>=20 >>>> 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while >>>> "IPv4-encapsulated packet with the DF bit set to 1" should be = addressed as well. >>>=20 >>> This is discussed in length. I don=E2=80=99t know how you could have = missed this. >>=20 >> I didn't miss that discussion but the text got fixed incorrectly = because it doesn=E2=80=99t not address IPv4 through the whole text. = Please have a look and fix that as well. I think this is mainly an = editorial issue but and important one to fix. >=20 > I am sorry. I don=E2=80=99t know what you think is wrong. Please point = to the text specifically. Sec 7.2: " 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet with the DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMPv6 "Packet Too Big" message to the ITR. The ITR will parse ^^^^^^^^^^^^^^^^^^^^^^ there will be no ICMPv6 message is the packet was IPv4 the ICMPv6 message to determine which Locator is affected by the effective MTU change and then record the new effective MTU value in the Map-Cache entry. 3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the Map-Cache entry associated with the destination EID the packet is for, the ITR will send an ICMPv6 "Packet Too ^^^^^^^^^^^^^^^^^^^ Big" message back to the source. The packet size advertised by the ITR in the ICMPv6 message is the effective MTU minus the LISP encapsulation length." >=20 >>>=20 >>>> 6) And now the more-discussion-needed point: >>>> So my underlying concern is the same as brought up by the TSV-ART = review that >>>> lisp information are not end-to-end integrity protected or = authenticated. >>>=20 >>> I would like you to be more specific. Beacuse there is a lot of = security in the protocol and we believe the current drafts, in their = entirety, inicdate so. >>=20 >> I was thinking about the option to add an authenticated hash, = anyway=E2=80=A6 >=20 > LISP uses lisp-crypto (RFC8061) which uses AEAD. I think the pity here is that RFC8061 is still a separate optional RFC. = I would have expected to have this integrated into rfc6830bis and make = it mandatory to implement if not mandatory to use. >=20 >>>=20 >>>> However, while briefly thinking about how this could be eventually = realized, I >>>> noticed that there is actually no mechanism to extend the LISP = header in any >>>=20 >>> Right, by design so it is efficient for hardware AND software = forwarding. But we do have the LISP-GPE header that can be used for = extensions. But that has limited deployment. >>>=20 >>>> way. There is no version, no option and the LISP header seems to = have a fixed, >>>=20 >>> We decdied as a working group that the UDP port number would = indicate what header follows and therefore what LISP version is used. >>=20 >> Okay, that needs to be explained in the doc! >>=20 >> Mirja >=20 > The document says that UDP port 4341 is assigned and when so, the LISP = header as docmented is used. We shouldn=E2=80=99t just encourage = versioning if the philosophy it not to churn often. Okay, that is actually not possible based on the recommendation in = RFC6335: " o IANA strives to assign only one assigned port number for all variants of a service (e.g., for updated versions of a = service).=E2=80=9C That means it is not possible to get another port number for a new = version of lisp. You need a different version approach. Mirja >=20 > Dino >=20 >=20 >=20 From nobody Wed Sep 12 03:51:26 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FC6130E6D for ; Wed, 12 Sep 2018 03:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 vcfeU93r5Yqz for ; Wed, 12 Sep 2018 03:51:21 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4972D130E28 for ; Wed, 12 Sep 2018 03:51:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=Hlxa3sgKDTcj3NparYOoRZYI7gk5NU58p2Tf5CW8Q7W4u1INoHOQsdHMpCmvYf/SPsLvxBvDO1IPZPXNYU1BG8NDYINnLw5dmm9dvwZvc5YP0MUpfpbviCxtPknMn4uJEX7K8mWfC6jZYpLG/4S5HXPud1MELYuxQXai83d+j4M=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 20808 invoked from network); 12 Sep 2018 12:44:38 +0200 Received: from mue-88-130-61-212.dsl.tropolys.de (HELO ?192.168.178.24?) (88.130.61.212) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Sep 2018 12:44:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> Date: Wed, 12 Sep 2018 12:44:36 +0200 Cc: lisp-chairs@ietf.org, "lisp@ietf.org list" , The IESG , Luigi Iannone , draft-ietf-lisp-rfc6833bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9086A458-31C0-4EB2-BC5B-D9CB7B22469E@kuehlewind.net> References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) X-PPP-Message-ID: <20180912104438.20799.67559@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 10:51:24 -0000 Hi Dino, please see below. > Am 11.09.2018 um 20:13 schrieb Dino Farinacci : >=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-lisp-rfc6833bis-13: 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 = https://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: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ >=20 > Thanks again for your comments Mirja. >=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> 1) Versioning and backward compatibility >>=20 >> Section 5.2 says: "Support for requesting multiple EIDs in a single = Map-Request >> message will be specified in a future version of the protocol." >> However, there is no versioning mechanism for this protocol = specified. How is >> versioning supposed to work? >=20 > The multiple EID-record encoding is already spec=E2=80=99ed and is in = the protocol. And since Map-Requests are triggered by packet arrival or = network management tools, they tend to be sent for a single EID. What is = for further study is if a ITR would want the entire map-cache, so would = it request a set of aggregates and would a replier return all more = specifics for the aggregates requested. I guess this sentence should be revised then. >=20 >> Further given there is no new version, I wonder if the changes as = outlined in >> section 10 are all backward-compatible? Especially for the = introduction of the >> Message-Notify-Ack message, I guess there is no problem if a server = sends it, >> however, as the sender of the Message-Notify message might not know = if the >> other end supports sending of the Message-Notify-Ack it can't rely on = it. This >> should be further discussed in the doc! Or is there another strategy = to achieve >> backward compatibility? >=20 > The Map-Notify-Ack has been there since day-1 in implementations. This = is just IETF catching up. And it took over 5 years. So we really don=E2=80= =99t have a compatibility situation. And didn=E2=80=99t want to create = one in the specifications. So consider it a day 1, version 1 message. It = really wasn=E2=80=99t added later. This should be stated in section 18. >=20 > And big part of this push for standardization is to have the specs = =E2=80=9Ccatch up=E2=80=9D with the implementations. The implementations = are way further ahead than the specs. >=20 >> 2) Size and MTU >>=20 >> As outlined in the TSV-ART review (Thanks Colin!) this document does = not >> discuss fragmentation or Path MTU discovery. RFC8085 recommends to = either >=20 >> perform Path MTU discovery or limit the message to 576 bytes for IPv4 = or 1280 >> bytes for IPv6 (minus any static header). As this seems to be an = appropriate >> size for LISP messages, I would recommend this approach. Relying on = IP >> fragmentation (as indicated in the reply to the TSV-ART review) is = not >> recommended by RFC8085 as this would lead to IP packet without a UDP = header, in >> the case of LISP, which can cause problem and loss when NATs are = involved. In >> any case the chosen approach needs to be further discussed in the = doc. >>=20 >=20 > This is a data-plane feature so it is discussed in 6830bis and = RFC6830. This is a different issue. The control plane protocol as specified in = this doc also needs to consider fragmentation and MTU. Please read = RFC8085 accordingly. >=20 >> 3) Rate-limiting and congestion control >>=20 >> Sec 5.3: "Map-Requests MUST be rate-limited. It is RECOMMENDED that = a Map- >> Request for the same EID-Prefix be sent no more than once per = second." >> As already noted by the TSV-ART review (Thanks Colin!), RFC8085 = actually >> recommends to not send more the one packet per 3 seconds, and that is = a >> restriction for all traffic not on a per-receiver base, or implement = congestion >> control. This limit is meant to not only protect the receiver but = also the >> network from overloading. Why do you use a smaller interval here? = Also if >> (appropriate) rate limiting is used, this should either be a MUST or = more >> explanation when it is okay to use a smaller rate limit should be = provided. >> However, after all, I don't think you those the right approach here = for rate >> limiting. A Map-Request is always expected to be followed by some = reply. For >> these kind of communication pattern, RFC8085 recommends to limit the = number of >> outstanding requests to 1 (see sec 3.1.1 of RFC8085 recommending one = packet per >> RTT), also for all traffic and not only per receiver. However, this = would also >> require to implement some simple mechanism to detect a message as = lost (see >> also further below in point 4). >=20 > We have referenced RFC8085 in the too be published -14 version of = 6833bis. I didn=E2=80=99t find a reference in -14. However a reference is not = enough, the specified behavior is not appropriate and needs to change. = If you need further help, please consult the respective transport = experts, e.g. Gorry Fairhurst who is an author of RFC8085. >=20 >> Similarly I'm not sure about the intent of this requirement in = section 5.5: >> "Map-Replies SHOULD be sent for an EID-Prefix no more often than once >> per second to the same requesting router. " >> My understanding is that Replies are only sent when a request is = received. Why >> is this additional rate limit needed? Again if used it should be 3 = seconds for >> all traffic to be inline with RFC8085. Also again, why is that not a = MUST? >> Further recommendation are needed here. >=20 > Because the source is a bad-actor and sending new Map-Requests (with a = new nonce). Not sure if that is the right choice because it may interact badly with = loss detection. However, as I said the specified behavior need to be = refined at various places in the doc. >=20 >> Further section 6.1 say "Both the SMR sender and the Map-Request = responder MUST >> rate-limit >> these messages. Rate-limiting can be implemented as a global rate- >> limiter or one rate-limiter per SMR destination." >> This seems to be the same rate limit as mention above, or not...? It = would >> probably make sense to rate limit the SMR even further. Please = clarify and >> provide more guidance, e.g. what should the value of a potential = additional >> rate limit for SMR be? >=20 > Some of this machinery is left to the implementor. But we have = published some map-cache management guidelines in the lisp-threat RFC. I think clear default guidance must be given in this document. My main = problem is that the guidance here is not clear (in relation to other = rate limits). >=20 >> Respectively the following sentence in section 6.1 is also unclear: >> "The remote ITR MUST rate-limit the Map-Request until it gets a = Map-Reply" >> Why is the rate-limit as currently proposed depend on the fact if a = Map-Reply >> is received? Is the ITR supposed to retransmit the Map-Request=E2=80=A6= ? >=20 > If you are not getting answers to your Map-Requests because of packet = loss or MITM, sending them faster is not going to get you a Map-Reply. If you detect loss, you should send slower not faster for congestion = collapse avoidance. >=20 >> And finally the Map-Register, Map-Notify and Map-Notify-Ack messages = does not >> seem to have any rate-limits. Recommendations inline with RFC8085 = should be >> provided for the total traffic and not only for a few message types. = Again, >> Map-Notify and Map-Notify-Ack messages should be send only once per = RTT as >> there is a feedback mechanism. >=20 > We have added that in -14. >=20 >> For Map-Register sec 8.2 say: "Map-Register messages are sent = periodically from >> an ETR to a Map- >> Server with a suggested interval between messages of one minute." >> However, this a rather a low bound than an upper bound. A required = (MUST) rate >> limit is still needed. >=20 > That is not rate-limiting to avoid message reduction. It is a = soft-state way of keeping registration state alive in the map-server(s). That fine but you also need to specify normatively an upper bound. >=20 >> 4) Loss detection and retransmission >>=20 >> As also mention by the TSV-ART review (Once more thanks to Colin!), = this spec >> has an ACK mechanism for Map-Requests and now also for Map-Notify, = however, it >=20 > And Map-Notify are acks to Map-Registers when requested. >=20 >> does not specify what to do if the ACK is not received (loss = detection and >> retransmission scheduling). This makes the spec incomplete and needs = to be >> further specified in the doc (and also has a relation to the point 3 = above of >> course). >=20 > We focus on why a Map-Request is being generated (to populate the = map-cache) and a Map-Reply not only provides information to be put in = the map-cache, but acts as an ackl now. If the Map-Request nonce is = being replied with a Map-Reply with the same nonce, Map-Requests no = longer need to be sent and the requestor is happy with the result (and = hence it was reliable). That all fine. However, you don=E2=80=99t specify the behavior if the = ack is not received. How/when is the message assumed to be lost? When = should it be retransmitted? How often? When to give up? Should = exponential backoff be used? This whole part s completely missing in the = spec. >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Further comments: >>=20 >> 1) The example given in 5.5 should probably used IPv6 addresses and = use the IP >> address space that is reserved for documentation purposes. >=20 > I disagree. I think its simpler with IPv4 addresses and shouldn=E2=80=99= t matter. We want this complex concept to come across as clear as = possible. And I believe IPv6 doesn=E2=80=99t do that. This is not a v4 = versus v6 response. It is a notation preference. I will let the INT AD to give further guidance, however, general = guidance in the iETF is that IPV6 should also be provided in examples to = avoid a bias towards IPv4. I disagree that an IPv6 example would be an = more complicated than an IPv4 example. >=20 >> 2) I find the security requirements in this doc very unsatisfying. = Most >> important the doc requires the support of authentication mechanism = but not the >> use of it. I would like to see more clear MUST requirements here. = Further, >> today and at this stage of the protocol (moving from exp to PS) I = find it not >> acceptable anymore to have certain security feature as optional and = outsourced >> into a different work-in-process draft. However, I leave further = discussion to >> the SEC ADs. >=20 > Can you cite where this is a problem. Are you saying we are not = supplying enough MUST text? In section 8.2 a few SHOULDs are used but no discussion about when it = would be appropriate to not follow these SHOULDs. Further these SHOULDs = mainly just say what should be implemented and provided, however there = is no normative language that these endpoint SHOULD/MUST actually be = authenticated or that the configured EID-Prefixes list MUST be enforced. >=20 >> 3) Given the following statement: >> "Note that while this document assumes a LISP-ALT database mapping >> infrastructure to illustrate certain aspects of Map-Server and Map- >> Resolver operation..." >> it seems that RFC6836 should be a normative reference, as it might = not be >> possible to understand all details explained in this doc with knowing = ALT. >=20 > I would like the lisp-chairs and/or Deborah to comment on this. >=20 >> 4) Further I would also think that I-D.ietf-lisp-mn and = I-D.ietf-lisp-pubsub >> should be normative references as the meaning of the respective bits = it not >> further specified in this doc. Or can these bits just be ignored if >> I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so = that >> should be stated. >=20 > I would like the lisp-chairs and/or Deborah to comment on this. >=20 >> Clarification questions: >> 1) Sec 5.3.: >> "For the initial case, the destination IP >> address used for the Map-Request is the data packet's destination >> address (i.e., the destination EID) that had a mapping cache lookup >> failure." >> Does that mean that the Map-Request needs to use the IPv4 or IPv6 = depending on >> the IP version used by the initial message from the EID. Is that = always the >> case or just for this initial message? I would assume that for all = other cases >> this is actually independent...? Because otherwise there would be a = constraint >> on what needs to be requested. I would like t see further = clarification about >> this in the doc. >=20 > No it doesn=E2=80=99t. It depends on the address-family of the = map-resolver. And that is configured. Okay, if the map-resolver is IPv6 and I receive an IPv4 packet, how can = I copy the "the data packet's destination address=E2=80=9C which is IPv4 = in to the "destination IP address used for the Map-Request=E2=80=9C = which is IPv6? Or even worse, the other way around. >=20 >> 2) In section 5.3: "The ITR MAY include all locally >> configured Locators in this list or just provide one locator address >> from each address family it supports." >> Would it make sense to include a SHOULD requirement to at least the = address >> family that is used to send the Request is included (to increase = chance to >> enable a communication/get a reply)=E2=80=A6? >=20 > But all address-families are used all the time. And in some ITRs, = usually there is no IPv6 at the edge.=20 What? You say all address families are used all the time but not in some = ITRs=E2=80=A6? I don=E2=80=99t understand what you want to say. However, = if e.g. an IPv4 packet is received and processed, it probably doesn=E2=80=99= t make sense to only include the IPv6 locator address (and not the IPv4 = locator address), especially as it is unknown if the ITR support IPV6 = (while it has been proven to support IPv4). Currently the spec however = would allow that. I=E2=80=99m saying it should to make sure there is no = unnecessary failure case her. >=20 >> 3) Sec 5.4: "If all Weights for a Locator-Set are equal, >> the receiver of the Map-Reply will decide how to load-split the >> traffic. " >> Shouldn't the receiver in this case split the traffic equally? = Otherwise how >> would you signal that the traffic should be split equally? Maybe use = all zero >> instead to let the receiver decide=E2=80=A6? >=20 > It means the ITR will load-split according to hashing. Versus if the = priorities are not equal, it is the ETR deciding how packets ingress the = LISP site. This is not what the text says. Please clarify in the doc. >=20 >> 4) sec 6.1: "When an ITR receives an SMR-based Map-Request for which = it does not >> have a cached mapping for the EID in the SMR message, it may not = send >> an SMR-invoked Map-Request." >> I guess this should be normative and probably also a MUST NOT or at = least >> SHOULD NOT. >=20 > Yes, I changed to SHOULD NOT. Good catch. Don=E2=80=99t want to make = it a MUST NOT because both sides could be mobile and the remote side may = need to populate its map-cache. That would allow less packet loss if we = keep it SHOULD NOT versus MUST NOT. >=20 >> 5) Section 7 seems to imply that if it is detected that no route is = available, >> the ITR should basically do nothing and just drop any incoming = packets for that >> ETR. Would it make sense for incremental deployability, to just = forward the >> packet to the IP address of the EID instead...? This way the source = host would >=20 > Well no. Because the EID most likely doesn=E2=80=99t have a route in = the underlying routing system. If there are PITRs out in the core, then = the ITR will be configured to know that, a negative map-reply causes = those PITRs to be used or PITRs are registering for coarse EID-prefixes. >=20 >> not benefit in mobility cases but still gets connectivity otherwise. = Or is that >> anyway not the implication? If that is the case, that should be = further >> clarified in the doc. >=20 > The point you are bringing up is discussed in the LISP interworking = document (RFC 6832), FYI. >=20 >> 6) Section 8.2 says: "Note that the Map-Notify message >> is sent to UDP destination port 4342, not to the source port >> specified in the original Map-Register message." >> Actually why is that? >=20 > cisco interperability. I would expect to still see more reasoning in the doc. >=20 >> Some minor editorial comments: >>=20 >> 1) First sentence in intro: the pointer to ietf-lisp-introduction as = currently >> introduced, makes this reference look very normative: "The Locator/ID >> Separation Protocol [I-D.ietf-lisp-introduction] and = [I-D.ietf-lisp-rfc6830bis] >> specifies..." I would recommend the following wording: "The = Locator/ID >> Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see also >> [I-D.ietf-lisp-introduction]) specifies=E2=80=A6" >=20 > Good recommendation. Thanks. Changed. >=20 >> 2) Also in intro: Given that 6830bis is a normative reference "LISP = RFC >> 6830bis" should be replaced with the new RFC number in the text. This = should be >> noted to the RFC editor; probably this is more obvious if RFCXXX is = used >> instead. >=20 > What are you suggesting. A bracketed comment inline? That or Deborah can note in in the RFC editor note. Thanks! Mirja >=20 >> 3) Sec 5.4: "...for another way the R-bit MAY be used." >> This looks like a lower case may would be more appropriate. >=20 > We fixed a bunch of incorrect capitalized MAYs and SHOULDs. >=20 > Thanks again, > Dino >=20 >=20 >=20 >=20 From nobody Wed Sep 12 03:55:31 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E444F1294D7 for ; Wed, 12 Sep 2018 03:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 ayTHhBhE_Wci for ; Wed, 12 Sep 2018 03:55:22 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D52130E28 for ; Wed, 12 Sep 2018 03:55:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=DlJKPoVrV+nxcljrdahJSILXD5HmRTEptntk54OjPlcZxFJWIRQacOa4jxEcXrqcAwxyaF31M1W8dMtsx+jjn9rkq0oY9Uch4sILuNdrIILdTs8R2mX6hTiYCFx68vqn2ramtEtDIEWls41TmK62VCvRjRdeelPKfDQwLkGRbd8=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 21056 invoked from network); 12 Sep 2018 12:48:39 +0200 Received: from mue-88-130-61-212.dsl.tropolys.de (HELO ?192.168.178.24?) (88.130.61.212) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Sep 2018 12:48:39 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <00DCC7FC-096E-4822-A702-2EE4C70327EB@gigix.net> Date: Wed, 12 Sep 2018 12:48:38 +0200 Cc: Dino Farinacci , The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <0F740BE5-63AF-4D18-BD79-D7D6A352B40A@kuehlewind.net> References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <00DCC7FC-096E-4822-A702-2EE4C70327EB@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) X-PPP-Message-ID: <20180912104839.21047.88549@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 10:55:25 -0000 Hi Luigi, please see below. > Am 12.09.2018 um 09:30 schrieb Luigi Iannone : >=20 > Hi, >=20 > two quick comments inline. >=20 >=20 >> On 11 Sep 2018, at 20:13, Dino Farinacci wrote: >>=20 >>> 3) Given the following statement: >>> "Note that while this document assumes a LISP-ALT database mapping >>> infrastructure to illustrate certain aspects of Map-Server and Map- >>> Resolver operation..." >>> it seems that RFC6836 should be a normative reference, as it might = not be >>> possible to understand all details explained in this doc with = knowing ALT. >>=20 >> I would like the lisp-chairs and/or Deborah to comment on this. >>=20 >=20 > IMO We can completely delete that sentence. The documents does a = pretty good job to talk in general terms about the mapping system and = the use of its front-end Map-Servers/Map-Resolvers. >=20 > In the few cases where something specific to ALT and DDT can be said = the document actually does it. Actually I brought this up because there were more cases where I found = that ALT knowledge is needed. If you don=E2=80=99t want this to be a = normative reference and remove the sentence above (which I=E2=80=99m not = sure is helpful), please also double-check all other occurrences of ALT = and make sure the discussed case is also understandable without ALT = knowledge. >=20 >=20 >=20 >>> 4) Further I would also think that I-D.ietf-lisp-mn and = I-D.ietf-lisp-pubsub >>> should be normative references as the meaning of the respective bits = it not >>> further specified in this doc. Or can these bits just be ignored if >>> I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so = that >>> should be stated. >>=20 >> I would like the lisp-chairs and/or Deborah to comment on this. >>=20 >=20 > Those bits can be ignored if an implementer choses not to support = those mechanisms. > Hence, the documents do not really need to be normative. Okay, that these bits can be ignored should be stated in the doc! Mirja >=20 > Ciao >=20 > L. >=20 >=20 From nobody Wed Sep 12 05:44:10 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EEC130E25; Wed, 12 Sep 2018 05:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Axn6XJbvS-wH; Wed, 12 Sep 2018 05:44:06 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE7C130E48; Wed, 12 Sep 2018 05:44:05 -0700 (PDT) Received: from [130.209.157.49] (port=40301 helo=glaroam2-191-147.wireless.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1g04Ux-0002fZ-RH; Wed, 12 Sep 2018 13:44:04 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: Date: Wed, 12 Sep 2018 13:43:53 +0100 Cc: tsv-art@ietf.org, draft-ietf-lisp-rfc6833bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: References: <153597929696.13392.8265627120055145654@ietfa.amsl.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 12:44:09 -0000 > On 4 Sep 2018, at 17:33, Dino Farinacci wrote: >> Reviewer: Colin Perkins >> Review result: On the Right Track >>=20 >> I've reviewed this document as part of the transport area review = team's ongoing >> effort to review key IETF documents. These comments were written = primarily for >> the transport area directors, but are copied to the document's = authors for >> their information and to allow them to address any issues raised. = When done at >> the time of IETF Last Call, the authors should consider this review = together >> with any other last-call comments they receive. Please always CC >> tsv-art@ietf.org if you reply to or forward this review. >=20 > Thanks a lot for the review Colin. Apologies for the slow follow-up. >> I have several concerns with the transport aspects of this draft. = Many of these >> appear to be present in RFC 6833 also, but I note that while RFC 6833 = is an >> Experimental, this draft is targeted at the Standards Track. Some of = these >> issues may not be of practical concern, depending on the way LISP is = used, and >> might just need clarifications in the draft to make it clear they do = not occur >> in practice. >=20 > Let me try helping with the clarification and if we need to add = clarification text, by all means, we will do so. >=20 >> The draft defines the LISP control plane. It updates and greatly = extends RFC >> 6833. The control plane runs over UDP, and this draft defines the = format of >=20 > I hope you understand why it greatly updates RFC6833. It was due to = the working group=E2=80=99s decision to move the control-plane elements = out of RFC 6830 into RFC 6833bis. So the procedures and protocols are = not new just re-located. >=20 >> LISP control plane messages and rules for processing such messages. = The packet >> formats generally contain lists of records, the length of which is = indicated by >> an 8-bit Record Count field located in a common sub-header. The = format allows >> packets that are larger than the typical path MTUs seen in the = Internet, but >> the draft doesn=E2=80=99t mention Path MTU discovery to determine the = largest packet >> that can be sent, or how large packets are fragmented. Perhaps the = messages are >> small enough that this is not a practical issue? In which case the = draft should >> explain and justify this for each message type (and perhaps put = limits on the >> Record Count to ensure it). Alternatively, then the draft should = specify how >> path MTU discovery is to be performed, and how protocol messages = should be >> fragmented (or subdivided) to fit the path MTU. Section 3.2 of RFC = 8085 has >> some further discussion and suggestions for how to address this = issue. >=20 > The control-plane does=E2=80=99t try to send MTU size packets. It = depends on IP fragmentation/reassembly. But an implementation should = know it cannot build a LISP message larger than 65535 bytes. I=E2=80=99m not convinced relying on IP fragmentation is a good idea. In = the best case, loss of a fragment results in loss of the entire packet, = multiplying the effective loss rate. There can also be middleboxes that = drop fragments. It would be better if the control place could fragment = to MTU size packets (either the actual MTU, or a typical MTU =E2=80=93 = 1280 octets perhaps). >> The draft does not mention congestion control, but many of the = messages are >> rate limited. If the intent of the rate limits is that no further = congestion >> control is needed, then it needs to be made explicit that this is the = case, and >=20 > Yes, that is the intent. >=20 >> some justification needs to be added to explain why it is safe. This = could, >> perhaps, take the form of an appendix that analyses the expected = control plane >> traffic that will flow over a particular path when the protocol is in = use, and >> demonstrates that this will be low enough rate not to be problematic. = In any >> case, the draft needs some discussion of how congestion control is = addressed. >=20 > The flow-control is coupled with protecting caches as well as request = and register load on map-resolvers and map-servers. Sure, but as I mentioned, the draft needs some justification for why = this is safe from a congestion control viewpoint. >> It=E2=80=99s unclear what messages need to be retransmitted if = they=E2=80=99re lost, and how to >> determine if a message is lost (e.g., what is the timeout) and what = is the >> retransmission schedule. This may be clear to a reader with an = in-depth >> understanding of LISP, but it would be helpful to provide more = explicit >> statements about loss detection and retransmission. >=20 > Map-Registers are sent periodically but the text says that if = Map-Notify messages are desired for acknowledgement, the Map-Registers = can be transmitted more quickly in the case of loss. >=20 > Map-Notify messages are obviously acknowledgement by Map-Notify-Ack. = That was an added message to RFC6833bis. >=20 > Map-Requests and Map-Replies are reliability sent for cache = population. And the nonce is used for both security purproses and to = associated a Map-Reply to a previous sent Map-Request, which is = rate-limited. >=20 > That is pretty much it and I think is explained in pretty much detail. = So if you have any specific comments, please provide them. Thanks. I perhaps missed it, but didn=E2=80=99t see any discussion of timeouts = to detect loss, retransmission frequency, how often retransmissions = should be retried before giving up, and what might happen if the = retransmissions fail. It=E2=80=99s not sufficient to just say a response = is retransmitted, without saying how loss is detected and how = retransmissions work. >> Many of these issues could perhaps be addressed by running the = control plane >> over TCP rather than UDP, as is beginning to happen with the DNS. I = understand >> that this would be a significant late change to the protocol. >=20 > We have a draft that is considering running the LISP control-plane = over TCP/QUIC with the addition of encryped security TLS/QUIC. But not = as a replacement to UDP but so an LISP control-plane implementation cam = be simplfied. I=E2=80=99d encourage this work, with the goal of eventually replacing = the UDP-based transport. >> The control plane messages contain embedded IP addresses. Does this = cause any >> issues in the presence of NAT boxes, either by leaking information = about >> private addressing or by distributing addresses that are unreachable = outside >> their realm? I noticed there is a mention of an individual draft on = LISP NAT >> Traversal in Section 5.6, but the embedded addresses are included in = more >> places. >=20 > We want private addresses to be inside of LISP control-plane packet = payload because there are cases where two xTRs want to determine if they = are behind the same NAT, so they can encapsulate directly to each other = with those private addresses. For xTRs that are not behind this common = NAT, RLOC-probing will tell them they cannot reach the private address. That=E2=80=99s fine, there should be some discussion of the privacy = implications of exposing those addresses. The WebRTC community has run = into considerable issues due to leaking IP addressing information =E2=80=93= perhaps this is not a concern for LISP, but the issue should be = considered, if only to add a note explaining why it=E2=80=99s not a = concern. Is there a need to protect the addresses? STUN uses XOR-mapping of = embedded IP addresses, because NATs were found that tried to translate = embedded IP addresses, outside of the IP header, and broke the protocol. = Does LISP need something similar? > Yes, there is a NAT-traversal draft that has been a alive for quite a = long time. Many of us are trying to simplify the operation of LISP = NAT-traversal with implementation and deployment experience. >=20 > Thanks again, > Dino >=20 >>=20 >> Regards, >> Colin >>=20 >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Wed Sep 12 09:07:13 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA07A130E88; Wed, 12 Sep 2018 09:07:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francis Dupont To: Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153676843185.9522.11137271632475375952@ietfa.amsl.com> Date: Wed, 12 Sep 2018 09:07:11 -0700 Archived-At: Subject: [lisp] Genart telechat review of draft-ietf-lisp-rfc6830bis-16 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 12 Sep 2018 16:07:12 -0000 Reviewer: Francis Dupont Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lisp-rfc6830bis-?? Reviewer: Francis Dupont Review Date: 2018-09-12 IETF LC End Date: 2018-08-29 IESG Telechat date: 2018-09-27 Summary: Ready with Nits Major issues: None Minor issues: None Nits/editorial comments: I have a few concerns about wording (e.g. things too hard to understand). I'll send a more complete message before the end of the week in the case they are not solved in version 17 I didn't read yet. From nobody Wed Sep 12 11:58:20 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E11128D0C; Wed, 12 Sep 2018 11:58:18 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hYVYMP53NyLm; Wed, 12 Sep 2018 11:58:17 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 053F4128BAC; Wed, 12 Sep 2018 11:58:17 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id w14-v6so1412519plp.6; Wed, 12 Sep 2018 11:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fY5F+6L4zQpnbZ4aXQMFPefD6zYu/8E+ZQhTnHdic5c=; b=eL7EeBnEUd99sLlRKczl6BIVU4OTTM0I0kBFYuPQaPl+xTrm4qHfiu/5hFJFkG0vUn /FbEM247f3Hnur20nftYb8AgDPlK91MO17oUZi1bBdpBmXwedIy9kuLn6dvaSGULo14u bAN6JeQqkGtYqcnTaTjqbmnDYUCEkATDpwdHw0cG0e75dPUZLjvSdX6gt8Nqzn0RnXBO SZJKkjfB3ArI2l/sD+z1lNIRNtV9GZWAJWDcROZWw788PPQ4ZzfsxOk31TsaAnK884fK lyHHgmocPJu/FmU1sWVEjT/ooCJq0TcFiYlVzaeh77Agn+rrfLrHSCV58RGGymlNW6kZ Fi8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fY5F+6L4zQpnbZ4aXQMFPefD6zYu/8E+ZQhTnHdic5c=; b=dp471+MRb9jzl2OKmtaddL6g3Mg7/PthzcNrG5EHfaihz25+LRFmyfyGK7ARcAYqWV WZM+E0rolM14/Cu/U4w8enqWGXvgf+0aOnF0FWsIjYk27I4HUlQueXx5ps2lBvvkQUXn YsNoB8/TY1Bu7CugsaQO4oV9WQhdqDOggsTakSwFrLB/T3RKLSVdMC7pzCa/iWda69ch HUADLtLkBf1DAUh6iayL//3zmJbE97ieblC/tMHMEt+QopW1NT/6OUfKZ+08wpo7nlzy bsQ5XUq298aO9FUQN6H/s/AkgZ5IMTio9W3tKs2p7dp/wEN7xYWu6ubpbddePjQ+ucwN crjg== X-Gm-Message-State: APzg51AwVZWW+iSYOa1AHHsqEulwr8IiHf3OGhNMsMAWsVLYEatd/w6x s4zrOBKnmlNINsMIoWuBxmtyuAHd X-Google-Smtp-Source: ANB0VdZ+TKSXqoShIiX6a5XZBgDSQx2sApwGP4FAtqDYh9xlGk2dRaVISzll/7M8xa2/z6CmG2bmSQ== X-Received: by 2002:a17:902:4e:: with SMTP id 72-v6mr3790872pla.318.1536778696447; Wed, 12 Sep 2018 11:58:16 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id j22-v6sm2627826pfh.45.2018.09.12.11.58.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 11:58:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Wed, 12 Sep 2018 11:58:13 -0700 Cc: tsv-art@ietf.org, draft-ietf-lisp-rfc6833bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" , Dino Farinacci Content-Transfer-Encoding: quoted-printable Message-Id: References: <153597929696.13392.8265627120055145654@ietfa.amsl.com> To: Colin Perkins X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 18:58:19 -0000 Thanks for the response, no worries on the slow follow-up. I have cut = out some email text. >>>=20 >>=20 >> The control-plane does=E2=80=99t try to send MTU size packets. It = depends on IP fragmentation/reassembly. But an implementation should = know it cannot build a LISP message larger than 65535 bytes. >=20 > I=E2=80=99m not convinced relying on IP fragmentation is a good idea. = In the best case, loss of a fragment results in loss of the entire = packet, multiplying the effective loss rate. There can also be = middleboxes that drop fragments. It would be better if the control place = could fragment to MTU size packets (either the actual MTU, or a typical = MTU =E2=80=93 1280 octets perhaps). Well an implementation can certainly build messages of effective MTU = length which in most cases is 1280/1500 as well. >=20 >>> The draft does not mention congestion control, but many of the = messages are >>> rate limited. If the intent of the rate limits is that no further = congestion >>> control is needed, then it needs to be made explicit that this is = the case, and >>=20 >> Yes, that is the intent. >>=20 >>> some justification needs to be added to explain why it is safe. This = could, >>> perhaps, take the form of an appendix that analyses the expected = control plane >>> traffic that will flow over a particular path when the protocol is = in use, and >>> demonstrates that this will be low enough rate not to be = problematic. In any >>> case, the draft needs some discussion of how congestion control is = addressed. >>=20 >> The flow-control is coupled with protecting caches as well as request = and register load on map-resolvers and map-servers. >=20 > Sure, but as I mentioned, the draft needs some justification for why = this is safe from a congestion control viewpoint. Can you suggest some simple text that would be sufficient. We have done = the analysis in other drafts. Would simply pointing a reference to them = be sufficient you think? >=20 >>> It=E2=80=99s unclear what messages need to be retransmitted if = they=E2=80=99re lost, and how to >>> determine if a message is lost (e.g., what is the timeout) and what = is the >>> retransmission schedule. This may be clear to a reader with an = in-depth >>> understanding of LISP, but it would be helpful to provide more = explicit >>> statements about loss detection and retransmission. >>=20 >> Map-Registers are sent periodically but the text says that if = Map-Notify messages are desired for acknowledgement, the Map-Registers = can be transmitted more quickly in the case of loss. >>=20 >> Map-Notify messages are obviously acknowledgement by Map-Notify-Ack. = That was an added message to RFC6833bis. >>=20 >> Map-Requests and Map-Replies are reliability sent for cache = population. And the nonce is used for both security purproses and to = associated a Map-Reply to a previous sent Map-Request, which is = rate-limited. >>=20 >> That is pretty much it and I think is explained in pretty much = detail. So if you have any specific comments, please provide them. = Thanks. >=20 > I perhaps missed it, but didn=E2=80=99t see any discussion of timeouts = to detect loss, retransmission frequency, how often retransmissions = should be retried before giving up, and what might happen if the = retransmissions fail. It=E2=80=99s not sufficient to just say a response = is retransmitted, without saying how loss is detected and how = retransmissions work. >=20 >>> Many of these issues could perhaps be addressed by running the = control plane >>> over TCP rather than UDP, as is beginning to happen with the DNS. I = understand >>> that this would be a significant late change to the protocol. >>=20 >> We have a draft that is considering running the LISP control-plane = over TCP/QUIC with the addition of encryped security TLS/QUIC. But not = as a replacement to UDP but so an LISP control-plane implementation cam = be simplfied. >=20 > I=E2=80=99d encourage this work, with the goal of eventually replacing = the UDP-based transport. Fabio and Marc have been working on it. A draft expired, so I don=E2=80=99= t know their status. I agree with you. >=20 >>> The control plane messages contain embedded IP addresses. Does this = cause any >>> issues in the presence of NAT boxes, either by leaking information = about >>> private addressing or by distributing addresses that are unreachable = outside >>> their realm? I noticed there is a mention of an individual draft on = LISP NAT >>> Traversal in Section 5.6, but the embedded addresses are included in = more >>> places. >>=20 >> We want private addresses to be inside of LISP control-plane packet = payload because there are cases where two xTRs want to determine if they = are behind the same NAT, so they can encapsulate directly to each other = with those private addresses. For xTRs that are not behind this common = NAT, RLOC-probing will tell them they cannot reach the private address. >=20 > That=E2=80=99s fine, there should be some discussion of the privacy = implications of exposing those addresses. The WebRTC community has run = into considerable issues due to leaking IP addressing information =E2=80=93= perhaps this is not a concern for LISP, but the issue should be = considered, if only to add a note explaining why it=E2=80=99s not a = concern. This only happens in the NAT-traversal cases. I think it should go in = the Security Consideration section of that draft. Not this draft. The = standardization effort at this point in time is not including = NAT-traversal mechanisms because that draft has not been accepted as a = working group draft yet. > Is there a need to protect the addresses? STUN uses XOR-mapping of = embedded IP addresses, because NATs were found that tried to translate = embedded IP addresses, outside of the IP header, and broke the protocol. = Does LISP need something similar? No it doesn=E2=80=99t but as we evolved the NAT-traversal draft, we will = consider this. Thanks for the heads-up. Thanks again, Dino From nobody Wed Sep 12 14:30:55 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0006A130DFA; Wed, 12 Sep 2018 14:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uYxYbdWnIDma; Wed, 12 Sep 2018 14:30:43 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 AB4A4130DEF; Wed, 12 Sep 2018 14:30:43 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id s13-v6so1627474pfi.7; Wed, 12 Sep 2018 14:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oPxqsmcgt5Lca9tapER3XiSZuirRa0XbIF5m7lMMWxQ=; b=p1mzm9KwT7WWmkfCLF+dOkpw0PRhilXLBoT4P/DD7W1+13vo3Ddimt6eSqa+PBHMXD 4QMyPhxoWWwY8UxhoyVvIPPdqHFB5i/hrZqWnrtcTxfjkAGFj7BRyir3X1VKRA1bzmt8 Y6v89udn4o1oqRlT/fFR2i4VHBCzYdj4Pgvu3YuIzKwgzq4sCLzmA14IBq3MQSUdSwms MI4Tv/Actcr7hacpF02grR2W2NQArv2KXonzpqKEhMsshDM6UBtQEL5/ib8cMC1uXKe4 vZTfCRvhr8uV2F5vHpAv7qfhUlWjSsezc904gKrN+5+sYgCfnyqnjNg/EUyCyu42rQoO NNww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oPxqsmcgt5Lca9tapER3XiSZuirRa0XbIF5m7lMMWxQ=; b=cUDJsuVd2G3tS6SQgnRJVi5ap0GPgU746Vmu/rUUdjjvIzpAEpu/O9tsaW8Y0HFaV1 FVL8hh0NMERBrjkalO8gGpaR2SHRSe5Kwr1x0ueyRuvHWlX2bUWfkMw5qDFIVR0UU42l teeRd/k4MQyKOpvS2uhRPQ0fD2y/SGXLf+aXTEJna4Zq01RfsenH4Q54GRUY14BfApNL aaTm24u2gfQIqZcwazzB42w3EsXXv11vjJf6fGt7WJS7gIkQUraq1cPkunHs9FGklz6L lhRxEh2EObfd+KSqaxZ0msYX+N0Ct8gRfbE4TvY7wIOZdPF9sy90vA3GGsy7BiLIhPAf h2Zw== X-Gm-Message-State: APzg51D0vYGJdiTkon1bs8qj4SIVycq1zYweVndHK0cqSP4NAsB5tlWd CocEwrDzj7oxJxguyu7ndhU= X-Google-Smtp-Source: ANB0Vdbvw7xdRluVm2hdhlt8+P13lDxdfYVIYkQ79AIgSxGsoPvl7vK9bzRcVRykOGxLTLqqCcHYig== X-Received: by 2002:a62:71c4:: with SMTP id m187-v6mr4338587pfc.232.1536787843028; Wed, 12 Sep 2018 14:30:43 -0700 (PDT) Received: from [172.31.99.184] (96-86-164-193-static.hfc.comcastbusiness.net. [96.86.164.193]) by smtp.gmail.com with ESMTPSA id p4-v6sm2988502pfd.65.2018.09.12.14.30.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 14:30:42 -0700 (PDT) From: Dino Farinacci Message-Id: <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_B112AF8B-FE29-48F1-A536-9C01435EA38C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 12 Sep 2018 14:30:40 -0700 In-Reply-To: <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> Cc: Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" , The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Dino Farinacci To: "Mirja Kuehlewind (IETF)" References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 21:30:49 -0000 --Apple-Mail=_B112AF8B-FE29-48F1-A536-9C01435EA38C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Hi again, >=20 > please see below. Thanks for the ongoing discussion Mirja. See a new diff file enclosed as = a proposed -18 update. Let me know if the text I added to address your = comments are sufficient. I believe (but could be wrong) that this should be the last set of = comments to 6830bis. But I have not seen any acks from Alvaro if we = addressed all his comments (specifically for 6830bis). >=20 >> Am 11.09.2018 um 18:45 schrieb Dino Farinacci : >>=20 >>=20 >>>> Well it doesn=E2=80=99t have to be. I am a bit hesitant to just = point to another long complicated RFC. This text has gone through review = for quite a long time and many ECN experts decided we should write it = this way. And this text did go through IESG review when RFC6830 was made = experimental RFC. >>>=20 >>> Procedere explained in RFC6040 are actually not that complicated. = It=E2=80=99s mainly the table provided in section 3.2. Please have a = look at the draft. However, I disagree that it =E2=80=9Enegative=E2=80=9C = to point for this part to another RFC. This is not a unique problem, = that=E2=80=99s why we have RFC6040 and all approaches that face this = problem should point to RFC6040 and implement the same strategy. >>=20 >> I am just worried it will be ignored because there are = implementations out there that do what they already do. If we want to = suggest to consider the procedures in RFC6040, I am okay with that, but = you need to provide the wording because I certainly don=E2=80=99t want = it too strong. >=20 > Actually the behavior as currently described in the lisp draft is not = even complainant with rfc3138, however, rfc3168 is updated by rfc6040. = The encapsulation in the lisp draft behavior is already what RFC6040 = described; so that=E2=80=99s good. However, the decapsulation is neither = what RFC3168 nor rfc6040 says. Therefore this must be fixed and I guess = a bis doc is also the best chance we get to fix these incorrect = implementation then. If you are worried that this will be ignored, you = should mention it explicitly in section 18 (Changes since RFC 6830). The working group made this decsision back in 2009 when the LISP WG was = formed. Actually earlier when we did the initial work in the IRTF RRG. = RFC3168 was published in Sep 2001. But note one of the authors, David = Black, offered the text you see in the document rewgarding ECN handling. So by doing this update, we ARE going to create a implementation = incompatibility. > There is no matter about the wording being too strong or whatever, = RFC6040 is very clear about the correct behavior and that is exactly = what needs to be implemented. Please go ahead and read RFC6040. If you = need further help, please ask an ECN expert for help, e.g. Bob Briscoe = who is the author of RFC6040. Check the diff file to see if you are okay with the new text added. It = WAS NOT simple because there are a number of cases that need to be = described that doesn=E2=80=99t contradict RFC6040 that I do not want to = repeat. > Please note that I actually pointer to a wrong section in RFC6040 = above. It should of course be 4.2 (and not 3.2). Okay, that makes more sense now. I was confused. =20 >>>>=20 >>>>=20 >>>>> 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while >>>>> "IPv4-encapsulated packet with the DF bit set to 1" should be = addressed as well. >>>>=20 >>>> This is discussed in length. I don=E2=80=99t know how you could = have missed this. >>>=20 >>> I didn't miss that discussion but the text got fixed incorrectly = because it doesn=E2=80=99t not address IPv4 through the whole text. = Please have a look and fix that as well. I think this is mainly an = editorial issue but and important one to fix. >>=20 >> I am sorry. I don=E2=80=99t know what you think is wrong. Please = point to the text specifically. >=20 > Sec 7.2: > " 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated = packet > with the DF bit set to 1, exceeds what the core network can > deliver, one of the intermediate routers on the path will send = an > ICMPv6 "Packet Too Big" message to the ITR. The ITR will parse > ^^^^^^^^^^^^^^^^^^^^^^ > there will be no ICMPv6 message is the packet was IPv4 >=20 > the ICMPv6 message to determine which Locator is affected by the > effective MTU change and then record the new effective MTU value > in the Map-Cache entry. >=20 > 3. When a packet is received by the ITR from a source inside of the > site and the size of the packet is greater than the effective = MTU > stored with the Map-Cache entry associated with the destination > EID the packet is for, the ITR will send an ICMPv6 "Packet Too > ^^^^^^^^^^^^^^^^^^^ >=20 > Big" message back to the source. The packet size advertised by > the ITR in the ICMPv6 message is the effective MTU minus the = LISP > encapsulation length.=E2=80=9D This is now fixed. I now understand your comment. Please check the diff = file enclosed. >>=20 >>>>=20 >>>>> 6) And now the more-discussion-needed point: >>>>> So my underlying concern is the same as brought up by the TSV-ART = review that >>>>> lisp information are not end-to-end integrity protected or = authenticated. >>>>=20 >>>> I would like you to be more specific. Beacuse there is a lot of = security in the protocol and we believe the current drafts, in their = entirety, inicdate so. >>>=20 >>> I was thinking about the option to add an authenticated hash, = anyway=E2=80=A6 >>=20 >> LISP uses lisp-crypto (RFC8061) which uses AEAD. >=20 > I think the pity here is that RFC8061 is still a separate optional = RFC. I would have expected to have this integrated into rfc6830bis and = make it mandatory to implement if not mandatory to use. Agree. I don=E2=80=99t know what to tell you. But as you might now, = there is a tradeoff between privacy and monitoring/lawful intercept that = is being made and we know there are strong camps on each side. You might have heard me say it at a recent IETF plenary =E2=80=9Ceverythin= g should be encrypted, period=E2=80=9D. So you know what camp I=E2=80=99m = in. ;-) >=20 >>=20 >>>>=20 >>>>> However, while briefly thinking about how this could be eventually = realized, I >>>>> noticed that there is actually no mechanism to extend the LISP = header in any >>>>=20 >>>> Right, by design so it is efficient for hardware AND software = forwarding. But we do have the LISP-GPE header that can be used for = extensions. But that has limited deployment. >>>>=20 >>>>> way. There is no version, no option and the LISP header seems to = have a fixed, >>>>=20 >>>> We decdied as a working group that the UDP port number would = indicate what header follows and therefore what LISP version is used. >>>=20 >>> Okay, that needs to be explained in the doc! >>>=20 >>> Mirja >>=20 >> The document says that UDP port 4341 is assigned and when so, the = LISP header as docmented is used. We shouldn=E2=80=99t just encourage = versioning if the philosophy it not to churn often. >=20 > Okay, that is actually not possible based on the recommendation in = RFC6335: >=20 > " o IANA strives to assign only one assigned port number for all > variants of a service (e.g., for updated versions of a = service).=E2=80=9C >=20 > That means it is not possible to get another port number for a new = version of lisp. You need a different version approach. >=20 > Mirja The working group made this decsision back in 2009 when the LISP WG was = formed. Actually earlier when we did the initial work in the IRTF RRG. = RFC3168 was published in Aug 2011. LISP-GPE is a variant of the the LISP data-plane, and it is using the = same UDP port 4341. So we actually accomplished the reuse. Dino --Apple-Mail=_B112AF8B-FE29-48F1-A536-9C01435EA38C Content-Disposition: attachment; filename=rfcdiff-6830bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6830bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6830bis-17.txt - = draft-ietf-lisp-rfc6830bis-18.txt=20 =20 =20 =20 =20 =20 =20 = =
< draft-ietf-lisp-rfc6830bis-17.txt  =  draft-ietf-lisp-rfc6830bis-18.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = V. Fuller Internet-Draft = V. Fuller
Obsoletes: 6830 = (if approved) D. Meyer = Obsoletes: 6830 (if approved) = D. Meyer
Intended status: = Standards Track D. Lewis = Intended status: Standards Track = D. Lewis
Expires: March = 15, 2019 = Cisco Systems Expires: March 16, 2019 Cisco = Systems
= A. Cabellos (Ed.) = A. Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= September 11, 2018 = September 12, 2018
=
= The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol = (LISP)
= draft-ietf-lisp-rfc6830bis-17 = = draft-ietf-lisp-rfc6830bis-18
=
Abstract = Abstract
=
This document = describes the Data-Plane protocol for the Locator/ID This document describes the Data-Plane protocol for = the Locator/ID
Separation = Protocol (LISP). LISP defines two namespaces, End-point = Separation Protocol (LISP). LISP defines = two namespaces, End-point
Identifiers = (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and = Routing Locators
(RLOCs) that = identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. = With this, LISP
effectively = separates control from data, and allows routers to create = effectively separates control from data, and = allows routers to create
overlay = networks. LISP-capable routers exchange encapsulated packets = overlay networks. LISP-capable routers = exchange encapsulated packets
according to = EID-to-RLOC mappings stored in a local Map-Cache. according to EID-to-RLOC mappings stored in a local = Map-Cache.
=
skipping to = change at = page 1, line 46 =C2=B6 = skipping to change at page 1, line 46 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on March 15, = 2019. This Internet-Draft will = expire on March 16, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 43 =C2=B6 = skipping to change at page 2, line 43 =C2=B6
7.1. A = Stateless Solution to MTU Handling . . . . . . . . . . 21 = 7.1. A Stateless Solution to MTU Handling = . . . . . . . . . . 21
7.2. A = Stateful Solution to MTU Handling . . . . . . . . . . . 22 = 7.2. A Stateful Solution to MTU Handling = . . . . . . . . . . . 22
8. Using = Virtualization and Segmentation with LISP . . . . . . . 22 = 8. Using Virtualization and Segmentation = with LISP . . . . . . . 22
9. Routing = Locator Selection . . . . . . . . . . . . . . . . . . 23 = 9. Routing Locator Selection . . . . . . . = . . . . . . . . . . . 23
10. Routing = Locator Reachability . . . . . . . . . . . . . . . . 25 = 10. Routing Locator Reachability . . . . . = . . . . . . . . . . . 25
10.1. Echo = Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 = 10.1. Echo Nonce Algorithm . . . . . . . = . . . . . . . . . . . 26
11. EID = Reachability within a LISP Site . . . . . . . . . . . . . 27 = 11. EID Reachability within a LISP Site . . = . . . . . . . . . . . 27
12. Routing = Locator Hashing . . . . . . . . . . . . . . . . . . . 28 = 12. Routing Locator Hashing . . . . . . . . = . . . . . . . . . . . 28
13. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 29 = 13. Changing the Contents of EID-to-RLOC = Mappings . . . . . . . . 29
13.1. = Database Map-Versioning . . . . . . . . . . . . . . . . 30 = 13.1. Database Map-Versioning . . . . . = . . . . . . . . . . . 30
14. = Multicast Considerations . . . . . . . . . . . . . . . . . . 30 14. = Multicast Considerations . . . . . . . . . . . . . . . . . . 31
15. Router = Performance Considerations . . . . . . . . . . . . . . 31 = 15. Router Performance Considerations . . . = . . . . . . . . . . . 31
16. Security = Considerations . . . . . . . . . . . . . . . . . . . 32 = 16. Security Considerations . . . . . . . . = . . . . . . . . . . . 32
17. Network = Management Considerations . . . . . . . . . . . . . . 33 = 17. Network Management Considerations . . . = . . . . . . . . . . . 33
18. Changes = since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 = 18. Changes since RFC 6830 . . . . . . . . = . . . . . . . . . . . 33
19. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 33 = 19. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 33
19.1. = LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 33 19.1. = LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 34
20. References = . . . . . . . . . . . . . . . . . . . . . . . . . 34 20. References . . . . . . . . . . . . . . . . . . . = . . . . . . 34
20.1. = Normative References . . . . . . . . . . . . . . . . . . 34 = 20.1. Normative References . . . . . . . = . . . . . . . . . . . 34
20.2. = Informative References . . . . . . . . . . . . . . . . . 35 = 20.2. Informative References . . . . . . = . . . . . . . . . . . 35
=
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 39 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 39 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 39
B.1. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 40 B.1. = Changes to draft-ietf-lisp-rfc6830bis-18 = . . . . . . . . 40
B.2. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 40 B.2. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 40
B.3. = Changes to draft-ietf-lisp-rfc6830bis-15 = . . . . . . . . 40 B.3. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 40
B.4. = Changes to draft-ietf-lisp-rfc6830bis-14 = . . . . . . . . 40 B.4. = Changes to draft-ietf-lisp-rfc6830bis-15 = . . . . . . . . 40
B.5. = Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 40 B.5. = Changes to draft-ietf-lisp-rfc6830bis-14 = . . . . . . . . 40
B.6. = Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 41 = B.6. Changes to draft-ietf-lisp-rfc6830bis-13 . . . . . . . . = 40
B.7. Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 41 B.7. Changes to = draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 41
B.8. Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 41 B.8. Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 41
B.9. Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 41 B.9. Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 41
B.10. Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 42 B.10. Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 41
B.11. Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 42 B.11. Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 42
B.12. Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 42 B.12. Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 42
B.13. Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 42 B.13. Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 42
B.14. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 43 B.14. Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 42
B.15. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 43 B.15. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 43
B.16. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 43 B.16. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 43
B.17. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 43 B.17. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 43
B.18. Changes to draft-ietf-lisp-rfc6830bis-00 = . . . . . . . . 43 B.18. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 43
= B.19. = Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 43
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 43
=
1. = Introduction 1. Introduction
=
This document = describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier = Separation Protocol
(LISP). LISP = is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built = around the
fundamental = idea of separating the topological location of a network = fundamental idea of separating the = topological location of a network
attachment = point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. = As a result
LISP creates = two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers = (EIDs), that are
used to = identify end-hosts (e.g., nodes or Virtual Machines) and = used to identify end-hosts (e.g., nodes or = Virtual Machines) and
=
skipping to = change at = page 18, line 49 =C2=B6 = skipping to change at page 18, line = 49 =C2=B6
the case of = IPv6) SHOULD be copied from the inner-header 'Time to the case of IPv6) SHOULD be copied from the = inner-header 'Time to
Live' = field. Live' field.
=
o The = outer-header 'Differentiated Services Code Point' (DSCP) field = o The outer-header 'Differentiated Services = Code Point' (DSCP) field
(or the = 'Traffic Class' field, in the case of IPv6) SHOULD be (or the 'Traffic Class' field, in the case of = IPv6) SHOULD be
copied from = the inner-header DSCP field ('Traffic Class' field, in copied from the inner-header DSCP field ('Traffic = Class' field, in
the case of = IPv6) considering the exception listed below. the case of IPv6) considering the exception listed = below.
=
o The = 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 = o The 'Explicit Congestion Notification' = (ECN) field (bits 6 and 7
of the IPv6 = 'Traffic Class' field) requires special treatment in of the IPv6 'Traffic Class' field) requires = special treatment in
order to = avoid discarding indications of congestion [RFC3168]. = order to avoid discarding indications of congestion [RFC6040].
ITR = encapsulation MUST copy the 2-bit 'ECN' field from the inner = ITR encapsulation MUST copy the 2-bit = 'ECN' field from the inner
header to = the outer header. Re-encapsulation MUST copy the 2-bit = header to the outer header. = Re-encapsulation MUST copy the 2-bit
'ECN' field = from the stripped outer header to the new outer 'ECN' field from the stripped outer header to the = new outer
= header. header.
=
When doing = ETR/PETR decapsulation: When doing = ETR/PETR decapsulation:
=
o The = inner-header 'Time to Live' field (or 'Hop Limit' field, in = o The inner-header 'Time to Live' field (or = 'Hop Limit' field, in
the case of = IPv6) SHOULD be copied from the outer-header 'Time to the case of IPv6) SHOULD be copied from the = outer-header 'Time to
Live' = field, when the Time to Live value of the outer header is = Live' field, when the Time to Live value = of the outer header is
=
skipping to = change at = page 19, line 25 =C2=B6 = skipping to change at page 19, line = 25 =C2=B6
check is = also performed when doing initial encapsulation, when a = check is also performed when doing = initial encapsulation, when a
packet = comes to an ITR or PITR destined for a LISP site. packet comes to an ITR or PITR destined for a LISP = site.
=
o The = inner-header 'Differentiated Services Code Point' (DSCP) field = o The inner-header 'Differentiated Services = Code Point' (DSCP) field
(or the = 'Traffic Class' field, in the case of IPv6) SHOULD be (or the 'Traffic Class' field, in the case of = IPv6) SHOULD be
copied from = the outer-header DSCP field ('Traffic Class' field, in copied from the outer-header DSCP field ('Traffic = Class' field, in
the case of = IPv6) to the inner-header. the = case of IPv6) to the inner-header.
=
o The = 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 = o The 'Explicit Congestion Notification' = (ECN) field (bits 6 and 7
of the IPv6 = 'Traffic Class' field) requires special treatment in of the IPv6 'Traffic Class' field) requires = special treatment in
order to = avoid discarding indications of congestion [RFC3168]. If = order to avoid discarding indications of congestion [RFC6040]. If
the 'ECN' = field contains a congestion indication codepoint (the the 'ECN' field contains a congestion indication = codepoint (the
value is = '11', the Congestion Experienced (CE) codepoint), then value is '11', the Congestion Experienced (CE) = codepoint), then
ETR = decapsulation MUST copy the 2-bit 'ECN' field from the ETR decapsulation MUST copy the 2-bit 'ECN' field = from the
stripped = outer header to the surviving inner header that is used = stripped outer header to the surviving = inner header that is used
to forward = the packet beyond the ETR. These requirements preserve = to forward the packet beyond the ETR. = These requirements preserve
CE = indications when a packet that uses ECN traverses a LISP tunnel = CE indications when a packet that uses = ECN traverses a LISP tunnel
and becomes = marked with a CE indication due to congestion between and becomes marked with a CE indication due to = congestion between
the = tunnel endpoints. the tunnel = endpoints. Implementations exist that copy the = 'ECN'
= field from the = outer header to the inner header even though
= [RFC6040] does = not recommend this behavior. It is RECOMMENDED
= that = implementations change to support the behavior in = [RFC6040].
=
Note that if = an ETR/PETR is also an ITR/PITR and chooses to re- Note that if an ETR/PETR is also an ITR/PITR and = chooses to re-
encapsulate = after decapsulating, the net effect of this is that the = encapsulate after decapsulating, the net = effect of this is that the
new outer = header will carry the same Time to Live as the old outer = new outer header will carry the same Time to = Live as the old outer
header minus = 1. header minus 1.
=
Copying the = Time to Live (TTL) serves two purposes: first, it Copying the Time to Live (TTL) serves two purposes: = first, it
preserves the = distance the host intended the packet to travel; preserves the distance the host intended the packet = to travel;
second, and = more importantly, it provides for suppression of looping = second, and more importantly, it provides = for suppression of looping
packets in the = event there is a loop of concatenated tunnels due to packets in the event there is a loop of concatenated = tunnels due to
= misconfiguration. = misconfiguration.
=
The Explicit = Congestion Notification ('ECN') field occupies bits 6 The Explicit Congestion Notification ('ECN') field = occupies bits 6
and 7 of both = the IPv4 'Type of Service' field and the IPv6 'Traffic and 7 of both the IPv4 'Type of Service' field and = the IPv6 'Traffic
Class' field = [RFC3168]. The 'ECN' field requires = special treatment Class' field = [RFC6040]. The 'ECN' field requires = special treatment
in order to = avoid discarding indications of congestion [RFC3168]. An = in order to avoid discarding indications of congestion [RFC6040]. An
ITR/PITR = encapsulation MUST copy the 2-bit 'ECN' field from the inner = ITR/PITR encapsulation MUST copy the 2-bit = 'ECN' field from the inner
header to the = outer header. Re-encapsulation MUST copy the 2-bit header to the outer header. Re-encapsulation MUST = copy the 2-bit
'ECN' field = from the stripped outer header to the new outer header. = 'ECN' field from the stripped outer header = to the new outer header.
If the 'ECN' = field contains a congestion indication codepoint (the If the 'ECN' field contains a congestion indication = codepoint (the
value is '11', = the Congestion Experienced (CE) codepoint), then ETR/ value is '11', the Congestion Experienced (CE) = codepoint), then ETR/
PETR = decapsulation MUST copy the 2-bit 'ECN' field from the stripped = PETR decapsulation MUST copy the 2-bit 'ECN' = field from the stripped
outer header = to the surviving inner header that is used to forward outer header to the surviving inner header that is = used to forward
the packet = beyond the ETR. These requirements preserve CE the packet beyond the ETR. These requirements = preserve CE
indications = when a packet that uses ECN traverses a LISP tunnel and = indications when a packet that uses ECN = traverses a LISP tunnel and
becomes marked = with a CE indication due to congestion between the becomes marked with a CE indication due to congestion = between the
=
skipping to = change at = page 22, line 22 =C2=B6 = skipping to change at page 22, line = 25 =C2=B6
An ITR = stateful solution to handle MTU issues is described as follows = An ITR stateful solution to handle MTU = issues is described as follows
and was first = introduced in [OPENLISP]: and was = first introduced in [OPENLISP]:
=
1. The ITR = will keep state of the effective MTU for each Locator per = 1. The ITR will keep state of the effective = MTU for each Locator per
Map-Cache = entry. The effective MTU is what the core network can Map-Cache entry. The effective MTU is what the = core network can
deliver = along the path between the ITR and ETR. = deliver along the path between the ITR and ETR.
=
2. When an = IPv6-encapsulated packet, or an IPv4-encapsulated packet = 2. When an IPv6-encapsulated packet, or an = IPv4-encapsulated packet
with the = DF bit set to 1, exceeds what the core network can with the DF bit set to 1, exceeds what the core = network can
deliver, = one of the intermediate routers on the path will send an = deliver, one of the intermediate routers = on the path will send an
ICMPv6 = "Packet Too Big" message to the ITR. The = ITR will parse ICMPv6 "Packet = Too Big" message or an ICMPv4 = Unreachable/
the = ICMPv6 message to determine which Locator = is affected by the Fragmentation-Needed to the ITR, respectively. The ITR will
= effective MTU change and then record the new effective MTU = value parse the ICMP message to determine which Locator is = affected by
in the = Map-Cache entry. the effective = MTU change and then record the new effective MTU
= value in the Map-Cache entry.
=
3. When a = packet is received by the ITR from a source inside of the = 3. When a packet is received by the ITR = from a source inside of the
site and = the size of the packet is greater than the effective MTU = site and the size of the packet is = greater than the effective MTU
stored = with the Map-Cache entry associated with the destination = stored with the Map-Cache entry = associated with the destination
EID the = packet is for, the ITR will send an ICMPv6 "Packet Too EID the packet is for, the ITR will send an = ICMPv4 ICMP
Big" = message back to the source. The packet size advertised by = = Unreachable/Fragmentation-Needed or ICMPv6 "Packet Too = Big"
the ITR = in the ICMPv6 message is the effective MTU = minus the LISP message back to = the source. The packet size advertised by the
= ITR in the ICMP message is the effective MTU minus the = LISP
= encapsulation length. = encapsulation length.
=
Even though = this mechanism is stateful, it has advantages over the Even though this mechanism is stateful, it has = advantages over the
stateless IP = fragmentation mechanism, by not involving the stateless IP fragmentation mechanism, by not = involving the
destination = host with reassembly of ITR fragmented packets. destination host with reassembly of ITR fragmented = packets.
=
8. Using = Virtualization and Segmentation with LISP 8. Using Virtualization and Segmentation with = LISP
=
There are = several cases where segregation is needed at the EID level. = There are several cases where segregation is = needed at the EID level.
For instance, = this is the case for deployments containing overlapping = For instance, this is the case for = deployments containing overlapping
=
skipping to = change at = page 34, line 19 =C2=B6 = skipping to change at page 34, line = 25 =C2=B6
20.1. Normative = References 20.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6833bis] = [I-D.ietf-lisp-rfc6833bis]
= Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. = Cabellos-Aparicio,
= "Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) = Control-Plane",
= draft-ietf-lisp-rfc6833bis-13 (work in = progress), August draft-ietf-lisp-rfc6833bis-14 (work in = progress),
= 2018. September 2018.
=
[RFC0768] = Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD = 6, RFC 768,
DOI = 10.17487/RFC0768, August 1980, = DOI 10.17487/RFC0768, August 1980,
= <https://www.rfc-editor.org/info/rfc768>. = <https://www.rfc-editor.org/info/rfc768>.
=
[RFC0791] = Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, = RFC 791,
DOI = 10.17487/RFC0791, September 1981, = DOI 10.17487/RFC0791, September 1981,
= <https://www.rfc-editor.org/info/rfc791>. = <https://www.rfc-editor.org/info/rfc791>.
=
[RFC2119] = Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to = Indicate
= Requirement Levels", BCP 14, RFC 2119, = Requirement Levels", BCP 14, RFC 2119,
DOI = 10.17487/RFC2119, March 1997, = DOI 10.17487/RFC2119, March 1997,
= <https://www.rfc-editor.org/info/rfc2119>. = <https://www.rfc-editor.org/info/rfc2119>.
=
[RFC2474] = Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. = Black,
= "Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services = Field (DS
= Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC = 2474,
DOI = 10.17487/RFC2474, December 1998, = DOI 10.17487/RFC2474, December 1998,
= <https://www.rfc-editor.org/info/rfc2474>. = <https://www.rfc-editor.org/info/rfc2474>.
=
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, = "The Addition [RFC6040] Briscoe, B., "Tunnelling of Explicit = Congestion
= of Explicit Congestion Notification (ECN) to = IP", Notification", RFC 6040, DOI 10.17487/RFC6040,= November
= RFC 3168, DOI 10.17487/RFC3168, September 2001, = 2010, = <https://www.rfc-editor.org/info/rfc6040>.
= <https://www.rfc-editor.org/info/rfc3168>. =
=
[RFC8126] = Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, = "Guidelines for
= Writing an IANA Considerations Section in RFCs", BCP 26, = Writing an IANA Considerations = Section in RFCs", BCP 26,
RFC = 8126, DOI 10.17487/RFC8126, June 2017, = RFC 8126, DOI 10.17487/RFC8126, June 2017,
= <https://www.rfc-editor.org/info/rfc8126>. = <https://www.rfc-editor.org/info/rfc8126>.
=
[RFC8174] = Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs = Lowercase in RFC
= 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, = 2119 Key Words", BCP 14, RFC = 8174, DOI 10.17487/RFC8174,
May = 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, = <https://www.rfc-editor.org/info/rfc8174>.
=
=
skipping to = change at = page 40, line 5 =C2=B6 = skipping to change at page 40, line 5 =C2=B6
The LISP = working group would like to give a special thanks to Jari = The LISP working group would like to give a = special thanks to Jari
Arkko, the = Internet Area AD at the time that the set of LISP Arkko, the Internet Area AD at the time that the set = of LISP
documents were = being prepared for IESG last call, and for his documents were being prepared for IESG last call, and = for his
meticulous = reviews and detailed commentaries on the 7 working group = meticulous reviews and detailed commentaries = on the 7 working group
last call = documents progressing toward standards-track RFCs. last call documents progressing toward = standards-track RFCs.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6830bis-17 B.1. = Changes to draft-ietf-lisp-rfc6830bis-18
=
= o Posted = mid-September 2018.
=
= o Changes to = reflect comments from Secdir review (Mirja).
=
= B.2. Changes to = draft-ietf-lisp-rfc6830bis-17
=
o Posted = September 2018. o Posted September = 2018.
=
o Indicate in = the "Changes since RFC 6830" section why the document o Indicate in the "Changes since RFC 6830" section = why the document
has been = shortened in length. has been = shortened in length.
=
o Make = reference to RFC 8085 about UDP congestion control. o Make reference to RFC 8085 about UDP congestion = control.
=
o More = editorial changes from multiple IESG reviews. o More editorial changes from multiple IESG = reviews.
=
B.2. Changes to = draft-ietf-lisp-rfc6830bis-16 B.3. Changes to = draft-ietf-lisp-rfc6830bis-16
=
o Posted late = August 2018. o Posted late August = 2018.
=
o Distinguish = the message type names between ICMP for IPv4 and ICMP o Distinguish the message type names between ICMP = for IPv4 and ICMP
for IPv6 = for handling MTU issues. for = IPv6 for handling MTU issues.
=
B.3. Changes to = draft-ietf-lisp-rfc6830bis-15 B.4. Changes to = draft-ietf-lisp-rfc6830bis-15
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6830" so implementators are o Added section "Changes since RFC 6830" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.4. Changes to = draft-ietf-lisp-rfc6830bis-14 B.5. Changes to = draft-ietf-lisp-rfc6830bis-14
=
o Posted July = 2018 IETF week. o Posted July 2018 = IETF week.
=
o Put = obsolete of RFC 6830 in Intro section in addition to abstract. = o Put obsolete of RFC 6830 in Intro section = in addition to abstract.
=
B.5. Changes to = draft-ietf-lisp-rfc6830bis-13 B.6. Changes to = draft-ietf-lisp-rfc6830bis-13
=
o Posted = March IETF Week 2018. o Posted = March IETF Week 2018.
=
o Clarified = that a new nonce is required per RLOC. = o Clarified that a new nonce is required per RLOC.
=
o Removed = 'Clock Sweep' section. This text must be placed in a new = o Removed 'Clock Sweep' section. This text = must be placed in a new
OAM = document. OAM document.
=
o Some = references changed from normative to informative o Some references changed from normative to = informative
=
B.6. Changes to = draft-ietf-lisp-rfc6830bis-12 B.7. Changes to = draft-ietf-lisp-rfc6830bis-12
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status. o Fixed Luigi editorial comments to ready draft for = RFC status.
=
B.7. Changes to = draft-ietf-lisp-rfc6830bis-11 B.8. Changes to = draft-ietf-lisp-rfc6830bis-11
=
o Posted = March 2018. o Posted March = 2018.
=
o Removed = sections 16, 17 and 18 (Mobility, Deployment and o Removed sections 16, 17 and 18 (Mobility, = Deployment and
Traceroute = considerations). This text must be placed in a new OAM = Traceroute considerations). This text = must be placed in a new OAM
= document. document.
=
B.8. Changes to = draft-ietf-lisp-rfc6830bis-10 B.9. Changes to = draft-ietf-lisp-rfc6830bis-10
=
o Posted = March 2018. o Posted March = 2018.
=
o Updated = section 'Router Locator Selection' stating that the Data- = o Updated section 'Router Locator = Selection' stating that the Data-
Plane MUST = follow what's stored in the Map-Cache (priorities and Plane MUST follow what's stored in the Map-Cache = (priorities and
= weights). weights).
=
o Section = 'Routing Locator Reachability': Removed bullet point 2 o Section 'Routing Locator Reachability': Removed = bullet point 2
(ICMP = Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port = (ICMP Network/Host Unreachable),3 (hints = from BGP),4 (ICMP Port
= Unreachable),5 (receive a Map-Reply as a response) and RLOC = Unreachable),5 (receive a Map-Reply as a = response) and RLOC
= probing probing
=
o Removed = 'Solicit-Map Request'. o Removed = 'Solicit-Map Request'.
=
B.9. Changes to = draft-ietf-lisp-rfc6830bis-09 B.10. Changes to = draft-ietf-lisp-rfc6830bis-09
=
o Posted = January 2018. o Posted January = 2018.
=
o Add more = details in section 5.3 about DSCP processing during o Add more details in section 5.3 about DSCP = processing during
= encapsulation and decapsulation. = encapsulation and decapsulation.
=
o Added = clarity to definitions in the Definition of Terms section = o Added clarity to definitions in the = Definition of Terms section
from = various commenters. from various = commenters.
=
o Removed PA = and PI definitions from Definition of Terms section. o Removed PA and PI definitions from Definition of = Terms section.
=
o More = editorial changes. o More = editorial changes.
=
o Removed = 4342 from IANA section and move to RFC6833 IANA section. = o Removed 4342 from IANA section and move = to RFC6833 IANA section.
=
B.10. Changes to = draft-ietf-lisp-rfc6830bis-08 B.11. Changes to = draft-ietf-lisp-rfc6830bis-08
=
o Posted = January 2018. o Posted January = 2018.
=
o Remove = references to research work for any protocol mechanisms. = o Remove references to research work for = any protocol mechanisms.
=
o Document = scanned to make sure it is RFC 2119 compliant. o Document scanned to make sure it is RFC 2119 = compliant.
=
o Made = changes to reflect comments from document WG shepherd Luigi = o Made changes to reflect comments from = document WG shepherd Luigi
= Iannone. Iannone.
=
o Ran IDNITs = on the document. o Ran IDNITs on = the document.
=
B.11. Changes to = draft-ietf-lisp-rfc6830bis-07 B.12. Changes to = draft-ietf-lisp-rfc6830bis-07
=
o Posted = November 2017. o Posted November = 2017.
=
o Rephrase = how Instance-IDs are used and don't refer to [RFC1918] o Rephrase how Instance-IDs are used and don't refer = to [RFC1918]
= addresses. addresses.
=
B.12. Changes to = draft-ietf-lisp-rfc6830bis-06 B.13. Changes to = draft-ietf-lisp-rfc6830bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Put RTR = definition before it is used. o = Put RTR definition before it is used.
=
o Rename = references that are now working group drafts. o Rename references that are now working group = drafts.
=
o Remove = "EIDs MUST NOT be used as used by a host to refer to other = o Remove "EIDs MUST NOT be used as used by = a host to refer to other
hosts. = Note that EID blocks MAY LISP RLOCs". = hosts. Note that EID blocks MAY LISP RLOCs".
=
=
skipping to = change at = page 42, line 48 =C2=B6 = skipping to change at page 42, line = 48 =C2=B6
o ETRs may, = rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send = Map-Replies.
=
o Recommend, = rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation = headers to 2.
=
o Reference = VPN draft when introducing Instance-ID. = o Reference VPN draft when introducing Instance-ID.
=
o Indicate = that SMRs can be sent when ITR/ETR are in the same node. = o Indicate that SMRs can be sent when = ITR/ETR are in the same node.
=
o Clarify = when private addreses can be used. = o Clarify when private addreses can be used.
=
B.13. Changes to = draft-ietf-lisp-rfc6830bis-05 B.14. Changes to = draft-ietf-lisp-rfc6830bis-05
=
o Posted = August 2017. o Posted August = 2017.
=
o Make it = clear that a Reencapsulating Tunnel Router is an RTR. o Make it clear that a Reencapsulating Tunnel Router = is an RTR.
=
B.14. Changes to = draft-ietf-lisp-rfc6830bis-04 B.15. Changes to = draft-ietf-lisp-rfc6830bis-04
=
o Posted July = 2017. o Posted July 2017.
=
o Changed = reference of IPv6 RFC2460 to RFC8200. = o Changed reference of IPv6 RFC2460 to RFC8200.
=
o Indicate = that the applicability statement for UDP zero checksums = o Indicate that the applicability statement = for UDP zero checksums
over IPv6 = adheres to RFC6936. over IPv6 = adheres to RFC6936.
=
B.15. Changes to = draft-ietf-lisp-rfc6830bis-03 B.16. Changes to = draft-ietf-lisp-rfc6830bis-03
=
o Posted May = 2017. o Posted May 2017.
=
o Move the = control-plane related codepoints in the IANA o Move the control-plane related codepoints in the = IANA
= Considerations section to RFC6833bis. = Considerations section to RFC6833bis.
=
B.16. Changes to = draft-ietf-lisp-rfc6830bis-02 B.17. Changes to = draft-ietf-lisp-rfc6830bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Reflect = some editorial comments from Damien Sausez. o Reflect some editorial comments from Damien = Sausez.
=
B.17. Changes to = draft-ietf-lisp-rfc6830bis-01 B.18. Changes to = draft-ietf-lisp-rfc6830bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Change = references from RFC6833 to RFC6833bis. = o Change references from RFC6833 to RFC6833bis.
=
o Clarified = LCAF text in the IANA section. o = Clarified LCAF text in the IANA section.
=
o Remove = references to "experimental". o = Remove references to "experimental".
=
B.18. Changes to = draft-ietf-lisp-rfc6830bis-00 B.19. Changes to = draft-ietf-lisp-rfc6830bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6830-00 = individual submission. No other changes made. -rfc6830-00 individual submission. No other = changes made.
=
Authors' = Addresses Authors' Addresses
Dino = Farinacci Dino Farinacci
Cisco = Systems Cisco Systems
Tasman = Drive Tasman Drive
 End of changes. 33 change blocks. 
60 lines changed or = deleted 71 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_B112AF8B-FE29-48F1-A536-9C01435EA38C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_B112AF8B-FE29-48F1-A536-9C01435EA38C-- From nobody Wed Sep 12 15:04:11 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CADD130EC8; Wed, 12 Sep 2018 15:04:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HIdiigiGNPj3; Wed, 12 Sep 2018 15:03:59 -0700 (PDT) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 C57F7130DFA; Wed, 12 Sep 2018 15:03:59 -0700 (PDT) Received: by mail-pg1-x543.google.com with SMTP id l63-v6so1723781pga.7; Wed, 12 Sep 2018 15:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PI1nJRHNevTPlLcRL78x4qwd0wzC+A9VuiOAAhGmBH8=; b=jorxbxUaG0bHOYxlQjMfg0lCprZkTEQl2zk1wdqW9ZMpc5RLMDyxFG8CjLWklj3x5a OCIqtqSuBh8IKeNBBztsP8Woa7b5PFEh9Ce5sN+widMuuXBTpjgIvPpi4P6FYPLQB7JW scjzPFWKWo6dh/qGtyOerlgTvy1GDyCUxfwY/F53IQGe8XpR6x2fTdJTTmCl7MHHEkXK 4qjZd+4PP7RZm1YDB+SyZKnQ6pLWfVx0VwK3SdPxzgxmhvekyw/P9yC3is0KsFNTRGBh UypIgKhvXFkYo1nw01t0CzWNlUxChayUotOFSqc02ZDaXXqJgBXZ2Yx7186jWpNP78uL DWfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PI1nJRHNevTPlLcRL78x4qwd0wzC+A9VuiOAAhGmBH8=; b=f6fuFB9UYNCVushqv+uhvxgVl1VcThqwYPPTGonkdvDN1V5C0hHjPCQi1Szy+XDCJA U+g626RfEOxtEH8uUkmGQ6luigR6E0D7a7wlOpEm/wwmkc6e52XG63tGJ3e+14LAt8g8 s212RBH127a4O5pKkB7hOkhYwgwRGrOFEPsZNnrTZrMJfFUKwUFM4DOZiyBN7kH4oSMo WVfYbH7kXCLOtTN/GXaD6d6PbWv/kaW9gXZ1cuVs1tdYQ/G8unSG8Mnx7JPoWRPdG/KZ o3Tkj57SWkNyM0YygCz69A7MnCTNlcrFmFeDT1eUMT1jsst6h9X6QQ/WxlRbHsx++iGM kUWQ== X-Gm-Message-State: APzg51Cj/GTh30tYXMH6pFdKwtG5HbB3dn1Xrg2tK8iJr/FAJH3/6E18 Ul+3YH15/IU7E3KE9P19s6o= X-Google-Smtp-Source: ANB0VdaPpYFkOOfp1k17Uwsvc6iWFNKX5VOmBe4Ecpn7plyRteQRJk+k2tJxXWt4uT6CjZQpbXa1MA== X-Received: by 2002:a63:5055:: with SMTP id q21-v6mr4252075pgl.397.1536789839394; Wed, 12 Sep 2018 15:03:59 -0700 (PDT) Received: from [172.31.99.184] (96-86-164-193-static.hfc.comcastbusiness.net. [96.86.164.193]) by smtp.gmail.com with ESMTPSA id o62-v6sm2915528pfb.0.2018.09.12.15.03.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 15:03:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <0F740BE5-63AF-4D18-BD79-D7D6A352B40A@kuehlewind.net> Date: Wed, 12 Sep 2018 15:03:57 -0700 Cc: Luigi Iannone , The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <2A356E01-FD24-4F6E-9800-4718BCA907F8@gmail.com> References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <00DCC7FC-096E-4822-A702-2EE4C70327EB@gigix.net> <0F740BE5-63AF-4D18-BD79-D7D6A352B40A@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 12 Sep 2018 22:04:03 -0000 Hi Luigi, >=20 > please see below. >=20 >> Am 12.09.2018 um 09:30 schrieb Luigi Iannone : >>=20 >> Hi, >>=20 >> two quick comments inline. >>=20 >>=20 >>> On 11 Sep 2018, at 20:13, Dino Farinacci = wrote: >>>=20 >>>> 3) Given the following statement: >>>> "Note that while this document assumes a LISP-ALT database mapping >>>> infrastructure to illustrate certain aspects of Map-Server and Map- >>>> Resolver operation..." >>>> it seems that RFC6836 should be a normative reference, as it might = not be >>>> possible to understand all details explained in this doc with = knowing ALT. >>>=20 >>> I would like the lisp-chairs and/or Deborah to comment on this. >>>=20 >>=20 >> IMO We can completely delete that sentence. The documents does a = pretty good job to talk in general terms about the mapping system and = the use of its front-end Map-Servers/Map-Resolvers. >>=20 >> In the few cases where something specific to ALT and DDT can be said = the document actually does it. >=20 > Actually I brought this up because there were more cases where I found = that ALT knowledge is needed. If you don=E2=80=99t want this to be a = normative reference and remove the sentence above (which I=E2=80=99m not = sure is helpful), please also double-check all other occurrences of ALT = and make sure the discussed case is also understandable without ALT = knowledge. I think it should left in and we should add LISP-DDT to the paragraph. = Since the two mapping transport systems that have moved forward to RFC = are ALT and DDT. And I believe they should both be Normative References. >=20 >>=20 >>=20 >>=20 >>>> 4) Further I would also think that I-D.ietf-lisp-mn and = I-D.ietf-lisp-pubsub >>>> should be normative references as the meaning of the respective = bits it not >>>> further specified in this doc. Or can these bits just be ignored if >>>> I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If = so that >>>> should be stated. >>>=20 >>> I would like the lisp-chairs and/or Deborah to comment on this. >>>=20 >>=20 >> Those bits can be ignored if an implementer choses not to support = those mechanisms. >> Hence, the documents do not really need to be normative. >=20 > Okay, that these bits can be ignored should be stated in the doc! I will add text for this. Dino >=20 > Mirja >=20 >=20 >=20 >>=20 >> Ciao >>=20 >> L. >>=20 >>=20 >=20 From nobody Wed Sep 12 20:59:26 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4D6130E12; Wed, 12 Sep 2018 20:59:23 -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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 c8DgpVlRR2qu; Wed, 12 Sep 2018 20:59:21 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A26130E11; Wed, 12 Sep 2018 20:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6192; q=dns/txt; s=iport; t=1536811161; x=1538020761; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aGqPwsSKRqFlUIkfnPxJ8GsqhCg3exAuztMVk56qQlw=; b=Q0V43nKF9idopNN0lzDY/HumoCiMcMer8qoo5vLQ7WDWAWU7Lg+NHKLT xEGfLvRYkQRWgfbAAWFwNruX7WLI+Q2gPWt3cmErha1yMWPq5OzIZsqaR TygeJX/QALGnHsZLUWhOaBFPFbIl50J9RYam9b38p92DmJ+HyzWmHEXLi Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AABe35lb/4kNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYFOgghlfyiDcogVjimDPYUhjV8UgWYLGA2ERwIXgzYhNBg?= =?us-ascii?q?BAgEBAgEBAm0cDIU4AQEBAQIBAQEbBhE6CwULAgEIEQMBAgECAhkNAgICHwY?= =?us-ascii?q?LFAEICAIEDgUJgxgBgWkDDQgPpiyBLoQpAoMHDYJPgQuJXBeBQT+BEicfgky?= =?us-ascii?q?CVjoLAQEBAQEBFoEUARIBHwczgkcxgiYCm3QsCQKGOYY7gxQXgUFJg3qId4h?= =?us-ascii?q?PgnZneoZTAhEUgSUdOGRxcBUaISoBgkEJiwyFPm8BjD6CPQEB?= X-IronPort-AV: E=Sophos;i="5.53,367,1531785600"; d="scan'208";a="441223804" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 03:59:20 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id w8D3xJnt027609 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Sep 2018 03:59:20 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Sep 2018 22:59:19 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1395.000; Wed, 12 Sep 2018 22:59:19 -0500 From: "Victor Moreno (vimoreno)" To: Colin Cantrell CC: Dino Farinacci , "lisp-chairs@ietf.org" , "lisp@ietf.org list" , Erik Nordmark Thread-Topic: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt Thread-Index: AQHUROyibESi1xEuBU6+Duc+rH63wqTho4EAgApThQCAAAnJgIABoaIH Date: Thu, 13 Sep 2018 03:59:19 +0000 Message-ID: <2410D245-66A6-4B7D-A675-5E2921B7BB5B@cisco.com> References: <153608761426.14137.783984991533026116@ietfa.amsl.com> <9807BB97-D034-4169-9BBC-366D66164238@gigix.net> , <898DD6CB-C75D-45AD-A61A-8365AFE81B04@nexus.io> In-Reply-To: <898DD6CB-C75D-45AD-A61A-8365AFE81B04@nexus.io> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 03:59:24 -0000 SSBzdXBwb3J0IG1ha2luZyB0aGlzIGEgV0cgZG9jdW1lbnQuIFdlIG11c3QgY29tcGxlbWVudCB0 aGUgc2VjdXJpdHkgcHJvdmlkZWQgZm9yIG1hcCByZXBsaWVzIGluIExJU1Atc2VjIHdpdGggbWVj aGFuaXNtcyB0byBzZWN1cmUgbWFwLXJlcXVlc3RzIGFuZCBtYXAtcmVnaXN0ZXJzIHN1Y2ggYXMg dGhvc2UgcHJvcG9zZWQgaW4gZWNkc2EtYXV0aC4NCg0KVmljdG9yDQoNCj4gT24gU2VwIDExLCAy MDE4LCBhdCA2OjA0IFBNLCBDb2xpbiBDYW50cmVsbCA8Y29saW5AbmV4dXMuaW8+IHdyb3RlOg0K PiANCj4gSSBzdXBwb3J0IG1ha2luZyB0aGlzIGRvY3VtZW50IGEgV0cgZHJhZnQNCj4gDQo+IENo ZWVycywNCj4gQ29saW4gQ2FudHJlbGwNCj4gDQo+PiBPbiBTZXAgMTEsIDIwMTgsIGF0IDI6Mjkg UE0sIERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPiB3cm90ZToNCj4+IA0KPj4g QXMgYW4gY28tYXV0aG9yLCBJIHN1cHBvcnQgbWFraW5nIHRoaXMgZG9jdW1lbnQgYSBXRyBkcmFm dC4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gRGlubw0KPj4gDQo+Pj4gT24gU2VwIDUsIDIwMTgsIGF0 IDEyOjQ4IEFNLCBMdWlnaSBJYW5ub25lIDxnZ3hAZ2lnaXgubmV0PiB3cm90ZToNCj4+PiANCj4+ PiANCj4+PiANCj4+Pj4gT24gNSBTZXAgMjAxOCwgYXQgMDk6NDYsIEx1aWdpIElhbm5vbmUgPGdn eEBnaWdpeC5uZXQ+IHdyb3RlOg0KPj4+PiANCj4+Pj4gRm9sa3MsDQo+Pj4+IA0KPj4+PiBBcyB5 b3UgY2FuIHNlZSBmcm9tIERpbm/igJlzIGVtYWlsIChiZWxvdykgdGhlIGF1dGhvcnMgYXJlIHJl cXVlc3RpbmcgdGhhdCB0aGUgZG9jdW1lbnQNCj4+Pj4gDQo+Pj4+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZhcmluYWNjaS1saXNwLWVjZHNhLWF1dGgvDQo+Pj4+IA0K Pj4+PiBiZSBhZG9wdGVkIGFzIFdHIGl0ZW0uDQo+Pj4+IA0KPj4+PiBUaGlzIGVtYWlsIHN0YXJ0 cyB0aGUgdXN1YWwgMTQgZGF5cyBjYWxsIGZvciBhZG9wdGlvbiwgdGhpcyBjYWxsIHdpbGwgZW5k IG9uDQo+Pj4+IFRodXJzZGF5IHRoZSAxOXRoIFNlcHRlbWJlciwgMjAxOC4NCj4+PiANCj4+PiBT bWFsbCB0eXBvIGluIHRoZSBlbmRpbmcgZGF0ZTogV2VkbmVzZGF5IDE5dGggU2VwdGVtYmVyLCAy MDE4Lg0KPj4+IA0KPj4+IENpYW8NCj4+PiANCj4+PiBMLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+ PiANCj4+Pj4gUGxlYXNlIGVtYWlsIHRoZSBXRyBsaXN0IHN0YXRpbmcgd2hldGhlciBvciBub3Qg eW91IHN1cHBvcnQgYWNjZXB0YW5jZS4NCj4+Pj4gDQo+Pj4+IElmIHlvdSBlbWFpbCB0byBzdXBw b3J0IHRoZSBhY2NlcHRhbmNlIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBXRyBpdGVtLCBwbGVhc2UN Cj4+Pj4gYWxzbyBpbmRpY2F0ZSBpZiB5b3UgYXJlIGFibGUgYW5kIHdpbGxpbmcgdG8gZWl0aGVy IGNvbnRyaWJ1dGUgdG8sIG9yIHJldmlldywgKG9yIGJvdGgpIHRoZSBkcmFmdC4NCj4+Pj4gDQo+ Pj4+IFNpdHRpbmcgaW4gc2lsZW5jZSBkb2VzIG5vdCBpbmRpY2F0ZSBzdXBwb3J0LCBwbGVhc2Ug cmVzcG9uZCBhcHByb3ByaWF0ZWx5Lg0KPj4+PiANCj4+Pj4gVGhlIENoYWlycw0KPj4+PiBKb2Vs ICYgTHVpZ2kNCj4+Pj4gDQo+Pj4+IA0KPj4+Pj4gT24gNCBTZXAgMjAxOCwgYXQgMjE6MDUsIERp bm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4g Rm9sa3MsIGhlcmUgaXMgYW4gdXBkYXRlIHRoYXQgcmVmbGVjdHMgY29tbWVudHMgd2UgcmVjZWl2 ZWQgYXQgdGhlIE1vbnRyZWFsIHByZXNlbnRhdGlvbjoNCj4+Pj4+IA0KPj4+Pj4gPFBhc3RlZEdy YXBoaWMtMS5wbmc+DQo+Pj4+PiANCj4+Pj4+IEEgZGlmZiBmaWxlIGlzIGluY2x1ZGVkIGZvciB5 b3VyIGNvbnZlbmllbmNlLiANCj4+Pj4+IA0KPj4+Pj4gQXQgdGhpcyB0aW1lLCBJIHdvdWxkIGxp a2UgdG8gcmVxdWVzdCB0aGlzIGRvY3VtZW50IGZvciB3b3JraW5nIGdyb3VwIGFkb3B0aW9uLg0K Pj4+Pj4gDQo+Pj4+PiBUaGFua3MsDQo+Pj4+PiBEaW5vL0VyaWsNCj4+Pj4+IA0KPj4+Pj4gPHJm Y2RpZmYtZWNkc2EuaHRtbD4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gQmVnaW4gZm9yd2FyZGVk IG1lc3NhZ2U6DQo+Pj4+Pj4gDQo+Pj4+Pj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn DQo+Pj4+Pj4gU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtZmFyaW5hY2NpLWxpc3AtZWNkc2Et YXV0aC0wMy50eHQNCj4+Pj4+PiBEYXRlOiBTZXB0ZW1iZXIgNCwgMjAxOCBhdCAxMjowMDoxNCBQ TSBQRFQNCj4+Pj4+PiBUbzogPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCj4+Pj4+PiBSZXBseS1U bzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzIGRpcmVjdG9yaWVzLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+ICAgICAgVGl0bGUg ICAgICAgICAgIDogTElTUCBDb250cm9sLVBsYW5lIEVDRFNBIEF1dGhlbnRpY2F0aW9uIGFuZCBB dXRob3JpemF0aW9uDQo+Pj4+Pj4gICAgICBBdXRob3JzICAgICAgICAgOiBEaW5vIEZhcmluYWNj aQ0KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgRXJpayBOb3JkbWFyaw0KPj4+Pj4+ICAg RmlsZW5hbWUgICAgICAgIDogZHJhZnQtZmFyaW5hY2NpLWxpc3AtZWNkc2EtYXV0aC0wMy50eHQN Cj4+Pj4+PiAgIFBhZ2VzICAgICAgICAgICA6IDE3DQo+Pj4+Pj4gICBEYXRlICAgICAgICAgICAg OiAyMDE4LTA5LTA0DQo+Pj4+Pj4gDQo+Pj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+Pj4gVGhpcyBkcmFm dCBkZXNjcmliZXMgaG93IExJU1AgY29udHJvbC1wbGFuZSBtZXNzYWdlcyBjYW4gYmUNCj4+Pj4+ PiBpbmRpdmlkdWFsbHkgYXV0aGVudGljYXRlZCBhbmQgYXV0aG9yaXplZCB3aXRob3V0IGEgYSBw cmlvcmkgc2hhcmVkLQ0KPj4+Pj4+IGtleSBjb25maWd1cmF0aW9uLiAgUHVibGljLWtleSBjcnlw dG9ncmFwaHkgaXMgdXNlZCB3aXRoIG5vIG5ldyBQS0kNCj4+Pj4+PiBpbmZyYXN0cnVjdHVyZSBy ZXF1aXJlZC4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1mYXJpbmFjY2ktbGlzcC1lY2RzYS1hdXRoLw0KPj4+Pj4+IA0K Pj4+Pj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4+ Pj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmFyaW5hY2NpLWxpc3AtZWNk c2EtYXV0aC0wMw0KPj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv ZHJhZnQtZmFyaW5hY2NpLWxpc3AtZWNkc2EtYXV0aC0wMw0KPj4+Pj4+IA0KPj4+Pj4+IEEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZmFyaW5hY2NpLWxpc3AtZWNkc2Et YXV0aC0wMw0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4+ Pj4+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPj4+Pj4+IA0KPj4+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+Pj4+IA0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gSS1ELUFubm91bmNlIG1haWxpbmcg bGlzdA0KPj4+Pj4+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+Pj4+Pj4gSW50ZXJuZXQtRHJh ZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4+Pj4+PiBv ciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4+Pj4gDQo+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4g bGlzcCBtYWlsaW5nIGxpc3QNCj4+Pj4+IGxpc3BAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KPj4+PiANCj4+PiANCj4+IA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbGlzcCBt YWlsaW5nIGxpc3QNCj4gbGlzcEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xpc3ANCg== From nobody Wed Sep 12 21:01:52 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C137130E14 for ; Wed, 12 Sep 2018 21:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 FODi__v1niLJ for ; Wed, 12 Sep 2018 21:01:46 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E92E130E12 for ; Wed, 12 Sep 2018 21:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18419; q=dns/txt; s=iport; t=1536811306; x=1538020906; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=eREl8Qno4QOIAFvaN/XJsGsJjDHRZNv0ebWlA/Fe+z8=; b=lwQxdI0NRnWDnhytoWJQxVrblwIelBHJnHs6sVk2poUAk/WWJMM5cum+ hSbp88WWSRk8rqYs3lHNJTgQ1P6OXUlIg0uaFWmLngTGnKF9t0o1mSI6H 4rHWnAZRLa5Hvay45+jSNT8n6rBfw92drTEibWG/f3BxtfPmhWnqA2D3i I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArBQBw4Jlb/4cNJK0YAUIbAQEBAQM?= =?us-ascii?q?BAQEJAQEBgU6CCGV/KINyiBWNfC2DOYUljV8UgWYLGAEMhEcCg00hNBgBAgE?= =?us-ascii?q?BAgEBAm0cDIU4AQEBAQMBARsGSxsJAhEDAQIBJwMCAiEGHwkIEwYCAQEFgxg?= =?us-ascii?q?BgWkDFQ+JKYE2m0uBLh+ECgJHgkANgk+KZxeBQT+BEieCa4JWOgsBAQEBAQE?= =?us-ascii?q?WgRQBEgE/FoJLglcCjjuEYYhYLAmGO4Y7gw4GF4FBSYN6gluGHIhPgnZneoZ?= =?us-ascii?q?6gUI4ZHEzGggbFRohgmwJiwyFXh8wAYw+gj0BAQ?= X-IronPort-AV: E=Sophos;i="5.53,367,1531785600"; d="scan'208,217";a="170408401" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 04:01:45 +0000 Received: from [10.24.77.250] ([10.24.77.250]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w8D41ibn008731 for ; Thu, 13 Sep 2018 04:01:44 GMT To: lisp@ietf.org References: <153608761426.14137.783984991533026116@ietfa.amsl.com> From: Fabio Maino Message-ID: <4ed29516-5c4b-1bb1-575c-0c6d5913cb96@cisco.com> Date: Wed, 12 Sep 2018 21:01:43 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A63E65CAC9A697B2142BBADB" Content-Language: en-US X-Outbound-SMTP-Client: 10.24.77.250, [10.24.77.250] X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 04:01:50 -0000 This is a multi-part message in MIME format. --------------A63E65CAC9A697B2142BBADB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit support. Fabio On 9/5/18 12:46 AM, Luigi Iannone wrote: > Folks, > > As you can see from Dino’s email (below) the authors are requesting > that the document > > https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ > > be adopted as WG item. > > This email starts the usual 14 days call for adoption, this call will > end on > Thursday the 19th September, 2018. > > Please email the WG list stating whether or not you support acceptance. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, > or review, (or both) the draft. > > Sitting in silence does not indicate support, please respond > appropriately. > > The Chairs > Joel & Luigi > > >> On 4 Sep 2018, at 21:05, Dino Farinacci > > wrote: >> >> Folks, here is an update that reflects comments we received at the >> Montreal presentation: >> >> >> >> A diff file is included for your convenience. >> >> At this time, I would like to request this document for working group >> adoption. >> >> Thanks, >> Dino/Erik >> >> >> >> >>> Begin forwarded message: >>> >>> *From: *internet-drafts@ietf.org >>> *Subject: **I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt* >>> *Date: *September 4, 2018 at 12:00:14 PM PDT >>> *To: *> >>> *Reply-To: *internet-drafts@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>>        Title           : LISP Control-Plane ECDSA Authentication and >>> Authorization >>>        Authors         : Dino Farinacci >>>                          Erik Nordmark >>> Filename        : draft-farinacci-lisp-ecdsa-auth-03.txt >>> Pages           : 17 >>> Date            : 2018-09-04 >>> >>> Abstract: >>>   This draft describes how LISP control-plane messages can be >>>   individually authenticated and authorized without a a priori shared- >>>   key configuration.  Public-key cryptography is used with no new PKI >>>   infrastructure required. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03 >>> https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecdsa-auth-03 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-farinacci-lisp-ecdsa-auth-03 >>> >>> >>> 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/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --------------A63E65CAC9A697B2142BBADB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
support.

Fabio

On 9/5/18 12:46 AM, Luigi Iannone wrote:
Folks,

As you can see from Dino’s email (below) the authors are requesting that the document


be adopted as WG item.

This email starts the usual 14 days call for adoption, this call will end on
Thursday the 19th September, 2018.

Please email the WG list stating whether or not you support acceptance.

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

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

The Chairs
Joel & Luigi


On 4 Sep 2018, at 21:05, Dino Farinacci <farinacci@gmail.com> wrote:

Folks, here is an update that reflects comments we received at the Montreal presentation:

<PastedGraphic-1.png>

A diff file is included for your convenience. 

At this time, I would like to request this document for working group adoption.

Thanks,
Dino/Erik

<rfcdiff-ecdsa.html>


Begin forwarded message:

Subject: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt
Date: September 4, 2018 at 12:00:14 PM PDT


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


       Title           : LISP Control-Plane ECDSA Authentication and Authorization
       Authors         : Dino Farinacci
                         Erik Nordmark
Filename        : draft-farinacci-lisp-ecdsa-auth-03.txt
Pages           : 17
Date            : 2018-09-04

Abstract:
  This draft describes how LISP control-plane messages can be
  individually authenticated and authorized without a a priori shared-
  key configuration.  Public-key cryptography is used with no new PKI
  infrastructure required.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03
https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecdsa-auth-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-farinacci-lisp-ecdsa-auth-03


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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



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


--------------A63E65CAC9A697B2142BBADB-- From nobody Thu Sep 13 00:59:01 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4915C130E2B for ; Thu, 13 Sep 2018 00:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 C7H_IU-2pE48 for ; Thu, 13 Sep 2018 00:58:51 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 42FC8130E2D for ; Thu, 13 Sep 2018 00:58:51 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id 207-v6so5053742wme.5 for ; Thu, 13 Sep 2018 00:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kpT/BGJlPjSthNloly9D8JygqOPf4LOTQ1QHOyYpj0o=; b=c2WkrOHXJKnrRwLYqZa4QsB0xVREP1nE72R4NsLKiuQp9WaLbQ9Jc1e441BmVmUI9E 3hx6W1GXI85BTWxQanU7mmscfSy93iQI2/Aue99fEdK5LkcqlHIkcYIcCqamaUSbXY0D roWLlJ7xFfsxYCitfIArU/MGFklZDHjN04JBGmjBZjK5vLNwAHtmOL2FWG4LLLlmAWCc BgjgDpHsmkIWnP9cOHeGq3Rmhmzg6VeGpNgy95lLgFmxp/5EcKG9mPSSLo4zFHcJEXtX IbHp6/BIicUg4lLOCTG4HHfIZoJQrzMZbb0WwmYgx33PtGSyCxa4BKUg4JEwnktx51gJ KX8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kpT/BGJlPjSthNloly9D8JygqOPf4LOTQ1QHOyYpj0o=; b=fEhw9iR+YSHE6Y85N0qq2dnPJxHG8G+oCLWbP8/UBH9NAS55gvcxpFX1x22MRQso3R miwhXKa8PQdfmicFxvWJSrpEQgov+QsqJyBNqVzpe7WXdWVDcOm+biDTsOtRh3ywNft9 Ex2Rfrks23LX5qlTiEgrdJZ6Jlb90IyzagIPx/WChURFqKFI++T4UB9NFgZRpaN8SbY5 oYi9pYIBBvNv9Lk80vibe8poQYujgB5qkOx1SRcI4ZSlUgep6HKY/lo+ZxRSxEOnls/F lz3DAWTuOZbcR7iLNqmAmGtQKjDyghbudPr9wo21oUE3RqZTVLsTym++pElEtZDhb6eb Q+Tg== X-Gm-Message-State: APzg51CleRhgKxMT0El74J0mvq7BNhKmHbt1Es/IRXyTjADALdMgmrk+ Gbqes7tllgbTUJ0BC3HBqa+6Kg== X-Google-Smtp-Source: ANB0VdZu2pBTWRcoYlScCs+2pMVUvawVkevokPdvMmJqhYdLRomDBI5+06sSVhqY40ui6ih/T9DPVw== X-Received: by 2002:a1c:b4d:: with SMTP id 74-v6mr4305165wml.15.1536825529626; Thu, 13 Sep 2018 00:58:49 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:9888:25a8:b930:841b? ([2001:660:330f:a4:9888:25a8:b930:841b]) by smtp.gmail.com with ESMTPSA id 75-v6sm7710025wml.21.2018.09.13.00.58.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 00:58:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Luigi Iannone In-Reply-To: <2A356E01-FD24-4F6E-9800-4718BCA907F8@gmail.com> Date: Thu, 13 Sep 2018 09:58:47 +0200 Cc: "Mirja Kuehlewind (IETF)" , The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <18BB371C-58BB-48ED-B7D2-568412A7890F@gigix.net> References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <00DCC7FC-096E-4822-A702-2EE4C70327EB@gigix.net> <0F740BE5-63AF-4D18-BD79-D7D6A352B40A@kuehlewind.net> <2A356E01-FD24-4F6E-9800-4718BCA907F8@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 07:58:54 -0000 Hi Dino, > On 13 Sep 2018, at 00:03, Dino Farinacci wrote: >=20 >>=20 >> Actually I brought this up because there were more cases where I = found that ALT knowledge is needed. If you don=E2=80=99t want this to be = a normative reference and remove the sentence above (which I=E2=80=99m = not sure is helpful), please also double-check all other occurrences of = ALT and make sure the discussed case is also understandable without ALT = knowledge. >=20 I disagree on the approach. IMO it makes more sense to me that this = document describes just the Map-Server/Map-Resolver front end.=20 How the front-end works with the actual mapping system is a matter of = the specific mapping system. In other words, how Map-Server/Map-Resolver works with LISP-DDT should = be in the LISP-DDT document. Ditto for LISP+ALT. > I think it should left in and we should add LISP-DDT to the paragraph. = Since the two mapping transport systems that have moved forward to RFC = are ALT and DDT. And I believe they should both be Normative References. >=20 This means two downrefs. We will need to move them to PS. I really do not see the need for this but YMMV. Ciao L. From nobody Thu Sep 13 04:01:16 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB10130E45; Thu, 13 Sep 2018 04:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ADyHNbJJKcmb; Thu, 13 Sep 2018 04:01:13 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5413C130E2E; Thu, 13 Sep 2018 04:01:13 -0700 (PDT) Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id w8DB16M5012070; Thu, 13 Sep 2018 13:01:07 +0200 Received: from [147.83.35.183] (dync-35-183.ac.upc.es [147.83.35.183]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id C56C830A; Thu, 13 Sep 2018 13:01:00 +0200 (CEST) To: "Victor Moreno (vimoreno)" , Colin Cantrell Cc: Erik Nordmark , "lisp-chairs@ietf.org" , "lisp@ietf.org list" References: <153608761426.14137.783984991533026116@ietfa.amsl.com> <9807BB97-D034-4169-9BBC-366D66164238@gigix.net> <898DD6CB-C75D-45AD-A61A-8365AFE81B04@nexus.io> <2410D245-66A6-4B7D-A675-5E2921B7BB5B@cisco.com> From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= Message-ID: <749a4360-4670-3ac7-6071-4a02317156d7@ac.upc.edu> Date: Thu, 13 Sep 2018 13:01:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2410D245-66A6-4B7D-A675-5E2921B7BB5B@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 11:01:16 -0000 Support. Jordi El 13/09/18 a les 05:59, Victor Moreno (vimoreno) ha escrit: > I support making this a WG document. We must complement the security provided for map replies in LISP-sec with mechanisms to secure map-requests and map-registers such as those proposed in ecdsa-auth. > > Victor > >> On Sep 11, 2018, at 6:04 PM, Colin Cantrell wrote: >> >> I support making this document a WG draft >> >> Cheers, >> Colin Cantrell >> >>> On Sep 11, 2018, at 2:29 PM, Dino Farinacci wrote: >>> >>> As an co-author, I support making this document a WG draft. >>> >>> Thanks, >>> Dino >>> >>>> On Sep 5, 2018, at 12:48 AM, Luigi Iannone wrote: >>>> >>>> >>>> >>>>> On 5 Sep 2018, at 09:46, Luigi Iannone wrote: >>>>> >>>>> Folks, >>>>> >>>>> As you can see from Dino’s email (below) the authors are requesting that the document >>>>> >>>>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ >>>>> >>>>> be adopted as WG item. >>>>> >>>>> This email starts the usual 14 days call for adoption, this call will end on >>>>> Thursday the 19th September, 2018. >>>> Small typo in the ending date: Wednesday 19th September, 2018. >>>> >>>> Ciao >>>> >>>> L. >>>> >>>> >>>> >>>>> Please email the WG list stating whether or not you support acceptance. >>>>> >>>>> If you email to support the acceptance of this document as a WG item, please >>>>> also indicate if you are able and willing to either contribute to, or review, (or both) the draft. >>>>> >>>>> Sitting in silence does not indicate support, please respond appropriately. >>>>> >>>>> The Chairs >>>>> Joel & Luigi >>>>> >>>>> >>>>>> On 4 Sep 2018, at 21:05, Dino Farinacci wrote: >>>>>> >>>>>> Folks, here is an update that reflects comments we received at the Montreal presentation: >>>>>> >>>>>> >>>>>> >>>>>> A diff file is included for your convenience. >>>>>> >>>>>> At this time, I would like to request this document for working group adoption. >>>>>> >>>>>> Thanks, >>>>>> Dino/Erik >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>> From: internet-drafts@ietf.org >>>>>>> Subject: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt >>>>>>> Date: September 4, 2018 at 12:00:14 PM PDT >>>>>>> To: >>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>>> >>>>>>> >>>>>>> Title : LISP Control-Plane ECDSA Authentication and Authorization >>>>>>> Authors : Dino Farinacci >>>>>>> Erik Nordmark >>>>>>> Filename : draft-farinacci-lisp-ecdsa-auth-03.txt >>>>>>> Pages : 17 >>>>>>> Date : 2018-09-04 >>>>>>> >>>>>>> Abstract: >>>>>>> This draft describes how LISP control-plane messages can be >>>>>>> individually authenticated and authorized without a a priori shared- >>>>>>> key configuration. Public-key cryptography is used with no new PKI >>>>>>> infrastructure required. >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ >>>>>>> >>>>>>> There are also htmlized versions available at: >>>>>>> https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03 >>>>>>> https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecdsa-auth-03 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> https://www.ietf.org/rfcdiff?url2=draft-farinacci-lisp-ecdsa-auth-03 >>>>>>> >>>>>>> >>>>>>> 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/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> I-D-Announce mailing list >>>>>>> I-D-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >> _______________________________________________ >> 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 Thu Sep 13 05:56:50 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1111277BB; Thu, 13 Sep 2018 05:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 q4Vy9nxzU4sg; Thu, 13 Sep 2018 05:56:47 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DE7127333; Thu, 13 Sep 2018 05:56:47 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 429zDt0z4cz2y4f; Thu, 13 Sep 2018 14:56:46 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 429zDt017lz5vN2; Thu, 13 Sep 2018 14:56:46 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0415.000; Thu, 13 Sep 2018 14:56:44 +0200 From: To: "lisp-chairs@ietf.org" , "lisp@ietf.org" Thread-Topic: New Version Notification for draft-boucadair-lisp-rfc8113bis-00.txt Thread-Index: AQHUS2B1QitzReApdkacMEXF0iepTKTuKkAw Date: Thu, 13 Sep 2018 12:56:43 +0000 Message-ID: References: <153684307267.8477.17218186869514342204.idtracker@ietfa.amsl.com> In-Reply-To: <153684307267.8477.17218186869514342204.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [lisp] TR: New Version Notification for draft-boucadair-lisp-rfc8113bis-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 12:56:50 -0000 RGVhciBjaGFpcnMsIGFsbCwgDQoNCkZXSVcsIHdlIHN1Ym1pdHRlZCBhIC1iaXMgdmVyc2lvbiBv ZiA4MTEzIHRvIHVwZGF0ZSB0aGUgc3RhdHVzIGZyb20gRXhwIHRvIFN0YW5kYXJkIHRyYWNrLiAN Cg0KV2UgbWFkZSBzb21lIGNoYW5nZXMgdG8gdGhlIHRleHQgcHVibGlzaGVkIGluIDgxMTMgdGhh dCB5b3UgY2FuIHRyYWNrIGF0OiBodHRwczovL2dpdGh1Yi5jb20vYm91Y2FkYWlyL3JmYzgxMTNi aXMvYmxvYi9tYXN0ZXIvd2RpZmYlMjByZmM4MTEzLnR4dCUyMGRyYWZ0LWJvdWNhZGFpci1saXNw LXJmYzgxMTNiaXMtMDAucGRmIA0KDQpQbGVhc2UgbGV0IHVzIGtub3cgaWYgYW55IGFjdGlvbiBp cyBzdGlsbCByZXF1aXJlZCBmcm9tIHVzLiBUaGFuayB5b3UuDQoNCkNoZWVycywNCk1lZA0KDQo+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IEVudm95w6nCoDogamV1 ZGkgMTMgc2VwdGVtYnJlIDIwMTggMTQ6NTENCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1U L09MTjsgSkFDUVVFTkVUIENocmlzdGlhbiBJTVQvT0xODQo+IE9iamV0wqA6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYm91Y2FkYWlyLWxpc3AtcmZjODExM2Jpcy0wMC50eHQN Cj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm91Y2FkYWlyLWxpc3AtcmZj ODExM2Jpcy0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNb2hh bWVkIEJvdWNhZGFpciBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0K PiBOYW1lOgkJZHJhZnQtYm91Y2FkYWlyLWxpc3AtcmZjODExM2Jpcw0KPiBSZXZpc2lvbjoJMDAN Cj4gVGl0bGU6CQlMb2NhdG9yL0lEIFNlcGFyYXRpb24gUHJvdG9jb2wgKExJU1ApOiBTaGFyZWQg RXh0ZW5zaW9uDQo+IE1lc3NhZ2UgJiBJQU5BIFJlZ2lzdHJ5IGZvciBQYWNrZXQgVHlwZSBBbGxv Y2F0aW9ucw0KPiBEb2N1bWVudCBkYXRlOgkyMDE4LTA5LTEzDQo+IEdyb3VwOgkJSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJNQ0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJvdWNhZGFpci1saXNwLQ0KPiByZmM4MTEz YmlzLTAwLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtYm91Y2FkYWlyLWxpc3AtDQo+IHJmYzgxMTNiaXMvDQo+IEh0bWxpemVkOiAg ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91Y2FkYWlyLWxpc3AtcmZj ODExM2Jpcy0NCj4gMDANCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYm91Y2FkYWlyLWxpc3AtDQo+IHJmYzgxMTNiaXMNCj4gDQo+ IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBMb2NhdG9yL0lE IFNlcGFyYXRpb24gUHJvdG9jb2wgKExJU1ApDQo+ICAgIHNoYXJlZCBtZXNzYWdlIHR5cGUgZm9y IGRlZmluaW5nIGZ1dHVyZSBleHRlbnNpb25zIGFuZCBjb25kdWN0aW5nDQo+ICAgIGV4cGVyaW1l bnRzIHdpdGhvdXQgY29uc3VtaW5nIGEgTElTUCBwYWNrZXQgdHlwZSBjb2RlcG9pbnQgZm9yIGVh Y2gNCj4gICAgZXh0ZW5zaW9uLiAgSXQgYWxzbyBkZWZpbmVzIGEgcmVnaXN0cnkgZm9yIExJU1Ag UGFja2V0IFR5cGUNCj4gICAgYWxsb2NhdGlvbnMuDQo+IA0KPiAgICBUaGlzIGRvY3VtZW50IG9i c29sZXRlcyBSRkMgODExMy4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N Cj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Sep 13 08:17:09 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1810130DD3; Thu, 13 Sep 2018 08:17:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dTYXYwFVEk2r; Thu, 13 Sep 2018 08:17:06 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 F0D9F130DC8; Thu, 13 Sep 2018 08:17:05 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id d4-v6so2831214pfn.0; Thu, 13 Sep 2018 08:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j7bXDjvc92YlBuAnw6Fcty2e6Z8f3400/9Vyro/L9Fo=; b=BwufuBKOvAw4YoE8QEt2dr4Vr72asJM+ENKczO1mJHofOFZqqI4RqoBI0dCsEe97TT a5ekTBNoHRpfbqm8BwexnZ+SPDJHM1FCO/niw76SWrUuzLdRxXFkWSXUy/WnsqnLEVFR 717wX4MtaLK/RabV+sEEI5SUZCLWlrtGZxgxhSQZoYTUUFMORWFCFp7Hx6fINNOkEVBW vEjcXRkzRCTBXwsiSI3ZWv/Sed5WswgHVSSQ8bBOYefs7iByxeTVcpieh1DCznDyae0C L2MSpl/LMllPpXcwgOdjwCqH/tqThCVAjiq6NAgNwbOrMKEyUy5+CokrKnd0jblJa8jw 6otQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j7bXDjvc92YlBuAnw6Fcty2e6Z8f3400/9Vyro/L9Fo=; b=i0Mb/Ac6oo83AXe8ptrNzLjqx6NoWGVSXDDlHl80OfQc9kqa4wI+8IQuVKMIX0gDkd ZeJgjlGwAsdEwxFNqpFBlX4ZVvlXK1C5iNFtstpJUgytqwKkHXg6JUkPfdpGxiNCJFZs rQjpw2b6TnOu7RhUeFOGt4ydPQ4u1acI771AcNeSN0ESqPuctZOYST7vs0enEN0w5IBH K+l4B0T5dYwhgN6H9cEtNv39a5KptXMgEpFRo6KGPSAWROsDAUHGQMDwAjOpsg2ocH4B PQtmaPPDQbBB9yjQr1/0h3eYosieqE3c9LI80sIo0n8gO1kUrmmjCES5R8QOkAxGyd2l JHqg== X-Gm-Message-State: APzg51AFKT5ai94B1J2w9tmNTJlDDQIWLXJ6n6mOMPKDxa+r0tiG/zbs djtOygNm/l+VaVUdAoS0T9pfsq87 X-Google-Smtp-Source: ANB0VdYQZT0CNBwhFZ4epouj5312JMsGM3coxVhl22064x1u6EDy4rlEQ7NzT7JzWADciHat+vFUCA== X-Received: by 2002:a62:8a4f:: with SMTP id y76-v6mr7894736pfd.233.1536851825521; Thu, 13 Sep 2018 08:17:05 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id o10-v6sm8142741pfk.76.2018.09.13.08.17.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 08:17:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <18BB371C-58BB-48ED-B7D2-568412A7890F@gigix.net> Date: Thu, 13 Sep 2018 08:17:02 -0700 Cc: "Mirja Kuehlewind (IETF)" , The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <00DCC7FC-096E-4822-A702-2EE4C70327EB@gigix.net> <0F740BE5-63AF-4D18-BD79-D7D6A352B40A@kuehlewind.net> <2A356E01-FD24-4F6E-9800-4718BCA907F8@gmail.com> <18BB371C-58BB-48ED-B7D2-568412A7890F@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 15:17:08 -0000 > On Sep 13, 2018, at 12:58 AM, Luigi Iannone wrote: >=20 > Hi Dino, >=20 >> On 13 Sep 2018, at 00:03, Dino Farinacci wrote: >>=20 >>>=20 >>> Actually I brought this up because there were more cases where I = found that ALT knowledge is needed. If you don=E2=80=99t want this to be = a normative reference and remove the sentence above (which I=E2=80=99m = not sure is helpful), please also double-check all other occurrences of = ALT and make sure the discussed case is also understandable without ALT = knowledge. >>=20 >=20 > I disagree on the approach. IMO it makes more sense to me that this = document describes just the Map-Server/Map-Resolver front end.=20 > How the front-end works with the actual mapping system is a matter of = the specific mapping system. > In other words, how Map-Server/Map-Resolver works with LISP-DDT should = be in the LISP-DDT document. Ditto for LISP+ALT. I can go along with this. I have wordsmithed that paragraph to not = mention LISP-ALT. >=20 >> I think it should left in and we should add LISP-DDT to the = paragraph. Since the two mapping transport systems that have moved = forward to RFC are ALT and DDT. And I believe they should both be = Normative References. >>=20 >=20 > This means two downrefs. We will need to move them to PS. > I really do not see the need for this but YMMV. I will keep then as Informative references. And to address Mirja=E2=80=99s= comment about believing that a reader would need to know more about ALT = and DDT, I would respond to say, that the documentation is saying that a = map-server and map-resolver are last-hops/first-hops to ANY mapping = database transport system. So you can treat it as a black box. The = operation of these nodes are discussed in the approprorate mapping = database transport systems (such as LISP-ALT and LISP-DDT). There are also refernces to LISP-ALT (and LISP-DDT) when we have the = option for xTRs to be directlry part of the mapping system. This may be = a choice for LISP deployers when they want a less centralized mapping = system. Again, there are just references that in this case, the xTRs are = =E2=80=9Cfirst-hop/last-hop=E2=80=9D nodes of these mapping database = systems. How does that sound Mirja? Dino >=20 > Ciao >=20 > L. >=20 From nobody Thu Sep 13 08:29:52 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F339D128CB7; Thu, 13 Sep 2018 08:29:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 w2Uw7FfIRJx4; Thu, 13 Sep 2018 08:29:49 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 2522E1200D7; Thu, 13 Sep 2018 08:29:49 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id b129-v6so2900392pga.13; Thu, 13 Sep 2018 08:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rm5l181VbTTLQ1MHV+ZYbkmZWnYuyqRHb/yvkrdYC2Y=; b=nuAxQZ2gfUTTRImN9sTeYmO66+GZ5oZT/2nT6/3lFNcFVqQ5hWUXQBdWi/zh6hdm1v TtG+kPvp2QFwN0PCQWgP8AvC+BRVRtX/J7WSgZs7qVJDTcm6RzfQaihQAXm2jL82fM6j 3vGfM0tMkx9ceD0QIzG3G7URIe7Y4IHKO5VeOdldXLg6RY7szAYhSBbJMwF6Od6u6vVa sSnMypVj/lOUNgcUPC70Kerlf7DIf1CygaNkDNSTn9Pg0xRUBZAt+KWcRpfu4tVEyEqN NQnc2LWc8HR6GFHsWJ4eoMtednCwZVzjDLqXcPJmwvYTGrGM+tat7t+HC2+nqk2QNUs3 LCSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rm5l181VbTTLQ1MHV+ZYbkmZWnYuyqRHb/yvkrdYC2Y=; b=Y1ilrV/PjPzPvSbhcHi3LHZt2m8wrrs8Z0n6UTlW5/q/67yWxknFRL4giEIdSNd9/I 42Yft0ohVqfuhIsW9K1k70SFu2iwUaguK5Lcw12lRdXpyndTfN9nXapePadvEj6QTHNn s6W/sCgyspJUOSg2HsTeQuPhAzFKNgpdGqlAV4eY8Vg2kFeeAECuuuCMlS3yGqPQgKYb M+nFmE6dLnUl+M9d81QELs0N5clQRf1Z4ci6c4elCZ6pIq1xPLc2cBjuHGk8NvlquqiM h0Gteo7cLmF35U+Xft+W/opcO1IHxZqgrj47lN112CCGXtPpNrnUo/jsC4s6rF87a7FA v+Dw== X-Gm-Message-State: APzg51Bxr2DYkSNtPdvXxxAVrO9I6UjMKqzDJwjuFbAJ4ljP9QIdj+0f A1dvK1MZW/Dc3AhEDGpzQ6c1v1Rm X-Google-Smtp-Source: ANB0VdZuK+T9gBW7gteCRTtlUiOfPrEWnyaKYqSw6z1bNyggObH25cKwJzP9tCyqksjTxuuwJuO3Qw== X-Received: by 2002:a63:e001:: with SMTP id e1-v6mr7725303pgh.380.1536852588711; Thu, 13 Sep 2018 08:29:48 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id e73-v6sm7336250pfb.153.2018.09.13.08.29.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 08:29:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <81DEE14D-5CDE-4B9E-BE67-1774E3268AEB@kuehlewind.net> Date: Thu, 13 Sep 2018 08:29:47 -0700 Cc: Luigi Iannone , The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <098EEA23-A9EE-43E0-B69E-CFF9F7704AF0@gmail.com> References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <00DCC7FC-096E-4822-A702-2EE4C70327EB@gigix.net> <0F740BE5-63AF-4D18-BD79-D7D6A352B40A@kuehlewind.net> <2A356E01-FD24-4F6E-9800-4718BCA907F8@gmail.com> <18BB371C-58BB-48ED-B7D2-568412A7890F@gigix.net> <81DEE14D-5CDE-4B9E-BE67-1774E3268AEB@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 15:29:51 -0000 Okay, I will do that. I=E2=80=99m working through your other comments = today, as well as Colin=E2=80=99s. I=E2=80=99ll send a diff before = submitting so we don=E2=80=99t churn too much. Thanks again! Dino > On Sep 13, 2018, at 8:28 AM, Mirja Kuehlewind (IETF) = wrote: >=20 > This sounds all fine to me. Please just make sure that the text = reflects that accordingly everywhere where ALT is mentioned at the = moment and respectively make it more generic if needed. I trust you, you = will edit this correctly! >=20 >> Am 13.09.2018 um 17:17 schrieb Dino Farinacci : >>=20 >>=20 >>=20 >>> On Sep 13, 2018, at 12:58 AM, Luigi Iannone wrote: >>>=20 >>> Hi Dino, >>>=20 >>>> On 13 Sep 2018, at 00:03, Dino Farinacci = wrote: >>>>=20 >>>>>=20 >>>>> Actually I brought this up because there were more cases where I = found that ALT knowledge is needed. If you don=E2=80=99t want this to be = a normative reference and remove the sentence above (which I=E2=80=99m = not sure is helpful), please also double-check all other occurrences of = ALT and make sure the discussed case is also understandable without ALT = knowledge. >>>>=20 >>>=20 >>> I disagree on the approach. IMO it makes more sense to me that this = document describes just the Map-Server/Map-Resolver front end.=20 >>> How the front-end works with the actual mapping system is a matter = of the specific mapping system. >>> In other words, how Map-Server/Map-Resolver works with LISP-DDT = should be in the LISP-DDT document. Ditto for LISP+ALT. >>=20 >> I can go along with this. I have wordsmithed that paragraph to not = mention LISP-ALT. >>=20 >>>=20 >>>> I think it should left in and we should add LISP-DDT to the = paragraph. Since the two mapping transport systems that have moved = forward to RFC are ALT and DDT. And I believe they should both be = Normative References. >>>>=20 >>>=20 >>> This means two downrefs. We will need to move them to PS. >>> I really do not see the need for this but YMMV. >>=20 >> I will keep then as Informative references. And to address Mirja=E2=80=99= s comment about believing that a reader would need to know more about = ALT and DDT, I would respond to say, that the documentation is saying = that a map-server and map-resolver are last-hops/first-hops to ANY = mapping database transport system. So you can treat it as a black box. = The operation of these nodes are discussed in the approprorate mapping = database transport systems (such as LISP-ALT and LISP-DDT). >>=20 >> There are also refernces to LISP-ALT (and LISP-DDT) when we have the = option for xTRs to be directlry part of the mapping system. This may be = a choice for LISP deployers when they want a less centralized mapping = system. Again, there are just references that in this case, the xTRs are = =E2=80=9Cfirst-hop/last-hop=E2=80=9D nodes of these mapping database = systems. >>=20 >> How does that sound Mirja? >>=20 >> Dino >>=20 >>>=20 >>> Ciao >>>=20 >>> L. >>>=20 >>=20 >=20 From nobody Thu Sep 13 08:35:46 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188C8128CB7 for ; Thu, 13 Sep 2018 08:35:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 i24fYkRB_N8W for ; Thu, 13 Sep 2018 08:35:36 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E2D130DDA for ; Thu, 13 Sep 2018 08:35:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=UzPBWhl5ppV16ScvGhNeMVBYmurXqLcInHdUjHtV74i96GfG1S2h9Cwt+gEuFhv2KNLCJZXbYRG2blZ6tjCfeU7K3aw+HUe+uf0wLNcyjSDqE4S07nTz/EVIrbe99Q8KdxKCuxHCLzzMHCoc/lgu7mm9HEfB87d0CJueYjJ47d4=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 22889 invoked from network); 13 Sep 2018 17:28:52 +0200 Received: from i577bceed.versanet.de (HELO ?192.168.178.24?) (87.123.206.237) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Sep 2018 17:28:51 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Thu, 13 Sep 2018 17:28:50 +0200 Cc: Luigi Iannone , The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <81DEE14D-5CDE-4B9E-BE67-1774E3268AEB@kuehlewind.net> References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <00DCC7FC-096E-4822-A702-2EE4C70327EB@gigix.net> <0F740BE5-63AF-4D18-BD79-D7D6A352B40A@kuehlewind.net> <2A356E01-FD24-4F6E-9800-4718BCA907F8@gmail.com> <18BB371C-58BB-48ED-B7D2-568412A7890F@gigix.net> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) X-PPP-Message-ID: <20180913152852.22880.46507@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 15:35:37 -0000 This sounds all fine to me. Please just make sure that the text reflects = that accordingly everywhere where ALT is mentioned at the moment and = respectively make it more generic if needed. I trust you, you will edit = this correctly! > Am 13.09.2018 um 17:17 schrieb Dino Farinacci : >=20 >=20 >=20 >> On Sep 13, 2018, at 12:58 AM, Luigi Iannone wrote: >>=20 >> Hi Dino, >>=20 >>> On 13 Sep 2018, at 00:03, Dino Farinacci = wrote: >>>=20 >>>>=20 >>>> Actually I brought this up because there were more cases where I = found that ALT knowledge is needed. If you don=E2=80=99t want this to be = a normative reference and remove the sentence above (which I=E2=80=99m = not sure is helpful), please also double-check all other occurrences of = ALT and make sure the discussed case is also understandable without ALT = knowledge. >>>=20 >>=20 >> I disagree on the approach. IMO it makes more sense to me that this = document describes just the Map-Server/Map-Resolver front end.=20 >> How the front-end works with the actual mapping system is a matter of = the specific mapping system. >> In other words, how Map-Server/Map-Resolver works with LISP-DDT = should be in the LISP-DDT document. Ditto for LISP+ALT. >=20 > I can go along with this. I have wordsmithed that paragraph to not = mention LISP-ALT. >=20 >>=20 >>> I think it should left in and we should add LISP-DDT to the = paragraph. Since the two mapping transport systems that have moved = forward to RFC are ALT and DDT. And I believe they should both be = Normative References. >>>=20 >>=20 >> This means two downrefs. We will need to move them to PS. >> I really do not see the need for this but YMMV. >=20 > I will keep then as Informative references. And to address Mirja=E2=80=99= s comment about believing that a reader would need to know more about = ALT and DDT, I would respond to say, that the documentation is saying = that a map-server and map-resolver are last-hops/first-hops to ANY = mapping database transport system. So you can treat it as a black box. = The operation of these nodes are discussed in the approprorate mapping = database transport systems (such as LISP-ALT and LISP-DDT). >=20 > There are also refernces to LISP-ALT (and LISP-DDT) when we have the = option for xTRs to be directlry part of the mapping system. This may be = a choice for LISP deployers when they want a less centralized mapping = system. Again, there are just references that in this case, the xTRs are = =E2=80=9Cfirst-hop/last-hop=E2=80=9D nodes of these mapping database = systems. >=20 > How does that sound Mirja? >=20 > Dino >=20 >>=20 >> Ciao >>=20 >> L. >>=20 >=20 From nobody Thu Sep 13 14:46:36 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B68130E7C; Thu, 13 Sep 2018 14:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 b1e_IDNlPpPY; Thu, 13 Sep 2018 14:46:19 -0700 (PDT) Received: from mail-yw1-xc44.google.com (mail-yw1-xc44.google.com [IPv6:2607:f8b0:4864:20::c44]) (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 1CE4B130E05; Thu, 13 Sep 2018 14:46:19 -0700 (PDT) Received: by mail-yw1-xc44.google.com with SMTP id 14-v6so1817346ywe.2; Thu, 13 Sep 2018 14:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=senuIEqyYPLTu8SwZ3o4bR4TZw3q9ieDRY0/WPHsCgE=; b=AAUXkXFe88KAzf/Pck7kJ/+OOmUxNOitkLThgeTpRJmDrjEgT1GazC958QiPtpp7kz kvDI9IfCL/tiz7KzXdphr4By9+cdtSsO1//HDGIFmngIFixIs3GGy0SLrGhqSY2B1v08 F2SkydGd1V2lANT4eIM+0xv7rFbpc9hVVl3uYZLXZ+HCoyBZwHvzJzSJ6sNnWAWbgORn KMykamTiLN4/dZ01bpMbMUXqhGt7q8CwCQhbtrRRQwhHXERP5gzMHusaYKUTsWf89OHk YmCdREtAzzKpc7PvjGZuXPyqHUFhdib7Yj3YLpxcwxZF29qr5wR/+3cog1bwaW8AOI3s 8O5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=senuIEqyYPLTu8SwZ3o4bR4TZw3q9ieDRY0/WPHsCgE=; b=L5GqMM5+TwH110sLH1PnvRp5fhjZpZBmK2lWH3GpvIEsgHgO4YGWTkKgFULm3AJv31 2idesVI9WDBp3d2y7V4D3ba6D/6Y32isIy4tIDJ4BaUAPLa1fMQAeRqjdiyYStHx4Qao 06tu+gWKcqvTBQG7bR9+TO6VzeYoMiRZE+7L6+6ZyI7TcXjCZGj4yfnWRqKhloThPYQU 8Z9iIoXMtpwzciWKnbtsFNR0DAbwXPmmo6EeSJqcAdpxlWYQZRc4n5BIb0pqEv7x4YiL uHQrd2xL2mpL4qdCBzVePeVMEMXUQb7rrOicWvEwUWeRcFBOh0NGjip2yuQIk1sKdS2M 5utw== X-Gm-Message-State: APzg51AhbTPzQF8YvWpjMjBHKCsAMvP2/ppiFOAf+c2jNa9YT4KZlNNI Z4y0JEu/FKaezs9NOsduGps= X-Google-Smtp-Source: ANB0VdYY+LNXrjoMRhs6ST9XjbqyxvA3wKsf2XuIXh4Q070+8InmlepGnBRSOS5zjbdRatMIksKhjg== X-Received: by 2002:a81:a48e:: with SMTP id b136-v6mr4355826ywh.77.1536875178238; Thu, 13 Sep 2018 14:46:18 -0700 (PDT) Received: from dino-macbook.attlocal.net (adsl-108-94-2-123.dsl.pltn13.sbcglobal.net. [108.94.2.123]) by smtp.gmail.com with ESMTPSA id u67-v6sm1875324ywa.56.2018.09.13.14.46.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 14:46:17 -0700 (PDT) From: Dino Farinacci Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_EE553457-4FD2-4AF8-9260-03301B364B00" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 13 Sep 2018 14:46:03 -0700 In-Reply-To: <9086A458-31C0-4EB2-BC5B-D9CB7B22469E@kuehlewind.net> Cc: lisp-chairs@ietf.org, "lisp@ietf.org list" , The IESG , Luigi Iannone , draft-ietf-lisp-rfc6833bis@ietf.org, Dino Farinacci , Colin Perkins To: "Mirja Kuehlewind (IETF)" References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <9086A458-31C0-4EB2-BC5B-D9CB7B22469E@kuehlewind.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 21:46:27 -0000 --Apple-Mail=_EE553457-4FD2-4AF8-9260-03301B364B00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have a new diff file for -15 of 6833bis. I have included changes from = your emails and from Colin=E2=80=99s. See my responses inline. I have = trimmed a bit of text to hopefully make it more readable for others. I will only submit the new revision if you agree with the changes and = there are no objections from the LISP working group. Thanks in = advance. >>>=20 >> The multiple EID-record encoding is already spec=E2=80=99ed and is in = the protocol. And since Map-Requests are triggered by packet arrival or = network management tools, they tend to be sent for a single EID. What is = for further study is if a ITR would want the entire map-cache, so would = it request a set of aggregates and would a replier return all more = specifics for the aggregates requested. >=20 > I guess this sentence should be revised then. Fixed. >=20 >>=20 >>> Further given there is no new version, I wonder if the changes as = outlined in >>> section 10 are all backward-compatible? Especially for the = introduction of the >>> Message-Notify-Ack message, I guess there is no problem if a server = sends it, >>> however, as the sender of the Message-Notify message might not know = if the >>> other end supports sending of the Message-Notify-Ack it can't rely = on it. This >>> should be further discussed in the doc! Or is there another strategy = to achieve >>> backward compatibility? >>=20 >> The Map-Notify-Ack has been there since day-1 in implementations. = This is just IETF catching up. And it took over 5 years. So we really = don=E2=80=99t have a compatibility situation. And didn=E2=80=99t want to = create one in the specifications. So consider it a day 1, version 1 = message. It really wasn=E2=80=99t added later. >=20 > This should be stated in section 18. Done. >=20 >>=20 >> And big part of this push for standardization is to have the specs = =E2=80=9Ccatch up=E2=80=9D with the implementations. The implementations = are way further ahead than the specs. >>=20 >>> 2) Size and MTU >>>=20 >>> As outlined in the TSV-ART review (Thanks Colin!) this document does = not >>> discuss fragmentation or Path MTU discovery. RFC8085 recommends to = either >>=20 >>> perform Path MTU discovery or limit the message to 576 bytes for = IPv4 or 1280 >>> bytes for IPv6 (minus any static header). As this seems to be an = appropriate >>> size for LISP messages, I would recommend this approach. Relying on = IP >>> fragmentation (as indicated in the reply to the TSV-ART review) is = not >>> recommended by RFC8085 as this would lead to IP packet without a UDP = header, in >>> the case of LISP, which can cause problem and loss when NATs are = involved. In >>> any case the chosen approach needs to be further discussed in the = doc. >>>=20 >>=20 >> This is a data-plane feature so it is discussed in 6830bis and = RFC6830. >=20 > This is a different issue. The control plane protocol as specified in = this doc also needs to consider fragmentation and MTU. Please read = RFC8085 accordingly. I have added text per Colin=E2=80=99s comments. >>=20 >>> 3) Rate-limiting and congestion control >>>=20 >>> Sec 5.3: "Map-Requests MUST be rate-limited. It is RECOMMENDED that = a Map- >>> Request for the same EID-Prefix be sent no more than once per = second." >>> As already noted by the TSV-ART review (Thanks Colin!), RFC8085 = actually >>> recommends to not send more the one packet per 3 seconds, and that = is a >>> restriction for all traffic not on a per-receiver base, or implement = congestion >>> control. This limit is meant to not only protect the receiver but = also the >>> network from overloading. Why do you use a smaller interval here? = Also if >>> (appropriate) rate limiting is used, this should either be a MUST or = more >>> explanation when it is okay to use a smaller rate limit should be = provided. >>> However, after all, I don't think you those the right approach here = for rate >>> limiting. A Map-Request is always expected to be followed by some = reply. For >>> these kind of communication pattern, RFC8085 recommends to limit the = number of >>> outstanding requests to 1 (see sec 3.1.1 of RFC8085 recommending one = packet per >>> RTT), also for all traffic and not only per receiver. However, this = would also >>> require to implement some simple mechanism to detect a message as = lost (see >>> also further below in point 4). >>=20 >> We have referenced RFC8085 in the too be published -14 version of = 6833bis. >=20 > I didn=E2=80=99t find a reference in -14. However a reference is not = enough, the specified behavior is not appropriate and needs to change. = If you need further help, please consult the respective transport = experts, e.g. Gorry Fairhurst who is an author of RFC8085. I have added text. We have a smaller interval because 3 seconds is way = too long (arguably 1 seond is too) to populate a map-cache. Note during = that time, packets that arrive to the ITR are discarded. So this occurs = if just one Map-Request is lost. >=20 >>=20 >>> Similarly I'm not sure about the intent of this requirement in = section 5.5: >>> "Map-Replies SHOULD be sent for an EID-Prefix no more often than = once >>> per second to the same requesting router. " >>> My understanding is that Replies are only sent when a request is = received. Why >>> is this additional rate limit needed? Again if used it should be 3 = seconds for >>> all traffic to be inline with RFC8085. Also again, why is that not a = MUST? >>> Further recommendation are needed here. >>=20 >> Because the source is a bad-actor and sending new Map-Requests (with = a new nonce). >=20 > Not sure if that is the right choice because it may interact badly = with loss detection. However, as I said the specified behavior need to = be refined at various places in the doc. Well there is not many choices. >=20 >>=20 >>> Further section 6.1 say "Both the SMR sender and the Map-Request = responder MUST >>> rate-limit >>> these messages. Rate-limiting can be implemented as a global rate- >>> limiter or one rate-limiter per SMR destination." >>> This seems to be the same rate limit as mention above, or not...? It = would >>> probably make sense to rate limit the SMR even further. Please = clarify and >>> provide more guidance, e.g. what should the value of a potential = additional >>> rate limit for SMR be? >>=20 >> Some of this machinery is left to the implementor. But we have = published some map-cache management guidelines in the lisp-threat RFC. >=20 > I think clear default guidance must be given in this document. My main = problem is that the guidance here is not clear (in relation to other = rate limits). I have tightened it up. >>=20 >>> Respectively the following sentence in section 6.1 is also unclear: >>> "The remote ITR MUST rate-limit the Map-Request until it gets a = Map-Reply" >>> Why is the rate-limit as currently proposed depend on the fact if a = Map-Reply >>> is received? Is the ITR supposed to retransmit the Map-Request=E2=80=A6= ? >>=20 >> If you are not getting answers to your Map-Requests because of packet = loss or MITM, sending them faster is not going to get you a Map-Reply. >=20 > If you detect loss, you should send slower not faster for congestion = collapse avoidance. That was my point. >=20 >>=20 >>> And finally the Map-Register, Map-Notify and Map-Notify-Ack messages = does not >>> seem to have any rate-limits. Recommendations inline with RFC8085 = should be >>> provided for the total traffic and not only for a few message types. = Again, >>> Map-Notify and Map-Notify-Ack messages should be send only once per = RTT as >>> there is a feedback mechanism. >>=20 >> We have added that in -14. >>=20 >>> For Map-Register sec 8.2 say: "Map-Register messages are sent = periodically from >>> an ETR to a Map- >>> Server with a suggested interval between messages of one minute." >>> However, this a rather a low bound than an upper bound. A required = (MUST) rate >>> limit is still needed. >>=20 >> That is not rate-limiting to avoid message reduction. It is a = soft-state way of keeping registration state alive in the map-server(s). >=20 > That fine but you also need to specify normatively an upper bound. The recommended upper bound is 1 minute. If you are not getting your = point across, please be more specific. >=20 >>=20 >>> 4) Loss detection and retransmission >>>=20 >>> As also mention by the TSV-ART review (Once more thanks to Colin!), = this spec >>> has an ACK mechanism for Map-Requests and now also for Map-Notify, = however, it >>=20 >> And Map-Notify are acks to Map-Registers when requested. >>=20 >>> does not specify what to do if the ACK is not received (loss = detection and >>> retransmission scheduling). This makes the spec incomplete and needs = to be >>> further specified in the doc (and also has a relation to the point 3 = above of >>> course). >>=20 >> We focus on why a Map-Request is being generated (to populate the = map-cache) and a Map-Reply not only provides information to be put in = the map-cache, but acts as an ackl now. If the Map-Request nonce is = being replied with a Map-Reply with the same nonce, Map-Requests no = longer need to be sent and the requestor is happy with the result (and = hence it was reliable). >=20 > That all fine. However, you don=E2=80=99t specify the behavior if the = ack is not received. How/when is the message assumed to be lost? When = should it be retransmitted? How often? When to give up? Should = exponential backoff be used? This whole part s completely missing in the = spec. Have added text. >=20 >>> 2) I find the security requirements in this doc very unsatisfying. = Most >>> important the doc requires the support of authentication mechanism = but not the >>> use of it. I would like to see more clear MUST requirements here. = Further, >>> today and at this stage of the protocol (moving from exp to PS) I = find it not >>> acceptable anymore to have certain security feature as optional and = outsourced >>> into a different work-in-process draft. However, I leave further = discussion to >>> the SEC ADs. >>=20 >> Can you cite where this is a problem. Are you saying we are not = supplying enough MUST text? >=20 > In section 8.2 a few SHOULDs are used but no discussion about when it = would be appropriate to not follow these SHOULDs. Further these SHOULDs = mainly just say what should be implemented and provided, however there = is no normative language that these endpoint SHOULD/MUST actually be = authenticated or that the configured EID-Prefixes list MUST be enforced. >=20 >>=20 >>> Clarification questions: >>> 1) Sec 5.3.: >>> "For the initial case, the destination IP >>> address used for the Map-Request is the data packet's destination >>> address (i.e., the destination EID) that had a mapping cache lookup >>> failure." >>> Does that mean that the Map-Request needs to use the IPv4 or IPv6 = depending on >>> the IP version used by the initial message from the EID. Is that = always the >>> case or just for this initial message? I would assume that for all = other cases >>> this is actually independent...? Because otherwise there would be a = constraint >>> on what needs to be requested. I would like t see further = clarification about >>> this in the doc. >>=20 >> No it doesn=E2=80=99t. It depends on the address-family of the = map-resolver. And that is configured. >=20 > Okay, if the map-resolver is IPv6 and I receive an IPv4 packet, how = can I copy the "the data packet's destination address=E2=80=9C which is = IPv4 in to the "destination IP address used for the Map-Request=E2=80=9C = which is IPv6? Or even worse, the other way around. Because a Map-Request going to the mapping system is =E2=80=9CECM=E2=80=99= ed=E2=80=9D =E2=80=9CEncapsulated Control Message=E2=80=9D with the = header address-family as the EID being requested. >=20 >>=20 >>> 2) In section 5.3: "The ITR MAY include all locally >>> configured Locators in this list or just provide one locator address >>> from each address family it supports." >>> Would it make sense to include a SHOULD requirement to at least the = address >>> family that is used to send the Request is included (to increase = chance to >>> enable a communication/get a reply)=E2=80=A6? >>=20 >> But all address-families are used all the time. And in some ITRs, = usually there is no IPv6 at the edge.=20 >=20 > What? You say all address families are used all the time but not in = some ITRs=E2=80=A6? I don=E2=80=99t understand what you want to say. = However, if e.g. an IPv4 packet is received and processed, it probably = doesn=E2=80=99t make sense to only include the IPv6 locator address (and = not the IPv4 locator address), especially as it is unknown if the ITR = support IPV6 (while it has been proven to support IPv4). Currently the = spec however would allow that. I=E2=80=99m saying it should to make sure = there is no unnecessary failure case her. RLOCs for an xTR can be a collection of IPv4 and IPv6 addresses. They = are tested by remote ITRs to see if they are reachable. When they are, = they may be used. When they are not, no packets get encapsulated to = those RLOCs. The Routing Locator Reachability section explains this. >=20 >>=20 >>> 3) Sec 5.4: "If all Weights for a Locator-Set are equal, >>> the receiver of the Map-Reply will decide how to load-split the >>> traffic. " >>> Shouldn't the receiver in this case split the traffic equally? = Otherwise how >>> would you signal that the traffic should be split equally? Maybe use = all zero >>> instead to let the receiver decide=E2=80=A6? >>=20 >> It means the ITR will load-split according to hashing. Versus if the = priorities are not equal, it is the ETR deciding how packets ingress the = LISP site. >=20 > This is not what the text says. Please clarify in the doc. It says it in RFC6830bis since this decision is done by the data-plane. >=20 >>=20 >>> 4) sec 6.1: "When an ITR receives an SMR-based Map-Request for which = it does not >>> have a cached mapping for the EID in the SMR message, it may not = send >>> an SMR-invoked Map-Request." >>> I guess this should be normative and probably also a MUST NOT or at = least >>> SHOULD NOT. >>=20 >> Yes, I changed to SHOULD NOT. Good catch. Don=E2=80=99t want to make = it a MUST NOT because both sides could be mobile and the remote side may = need to populate its map-cache. That would allow less packet loss if we = keep it SHOULD NOT versus MUST NOT. While trying to change it, I noticed its already there: When an ITR receives an SMR-based Map-Request for = =20 which it does not have a cached mapping for the EID in = =20 >>>> the SMR message, it SHOULD NOT send an SMR-invoked = =20 Map-Request. This scenario can occur when an ETR sends = =20 SMR messages to all Locators in the Locator-Set it has = =20 stored in its Map-Cache but the remote ITRs that receive the = =20 SMR may not be sending packets to the site. There is no = =20 point in updating the ITRs until they need to send, in = =20 which case they will send Map-Requests to obtain a = =20 Map-Cache entry. >>=20 >>> 6) Section 8.2 says: "Note that the Map-Notify message >>> is sent to UDP destination port 4342, not to the source port >>> specified in the original Map-Register message." >>> Actually why is that? >>=20 >> cisco interperability. >=20 > I would expect to still see more reasoning in the doc. Sorry, I was wrong in my reply. I read Map-Reply. For Map-Registers this = is normal behavior that a request is sent to a well-known port and a = reply is sent *from* the well known port. Thanks again for all the effort, Dino --Apple-Mail=_EE553457-4FD2-4AF8-9260-03301B364B00 Content-Disposition: attachment; filename=rfcdiff-6833bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6833bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-14.txt - = draft-ietf-lisp-rfc6833bis-15.txt=20 =20 =20 =20 =20 =20 =20 = = =
< draft-ietf-lisp-rfc6833bis-14.txt  =  draft-ietf-lisp-rfc6833bis-15.txt >
=
Network Working = Group V. Fuller = Network Working Group = V. Fuller
Internet-Draft = D. Farinacci Internet-Draft = D. Farinacci
Obsoletes: 6833 = (if approved) Cisco Systems = Obsoletes: 6833 (if approved) = Cisco Systems
Intended status: = Standards Track A. Cabellos (Ed.) = Intended status: Standards Track = A. Cabellos (Ed.)
Expires: March = 15, 2019 = UPC/BarcelonaTech Expires: March = 17, 2019 = UPC/BarcelonaTech
= September 11, 2018 = September 13, 2018
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-14 = = draft-ietf-lisp-rfc6833bis-15
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = Control-Plane service interface and communicating with By using this Control-Plane service interface and = communicating with
=
skipping to = change at = page 1, line 48 =C2=B6 = skipping to change at page 1, line 48 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on March 15, = 2019. This Internet-Draft will = expire on March 17, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 34 =C2=B6 = skipping to change at page 2, line 34 =C2=B6
3. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
4. Basic = Overview . . . . . . . . . . . . . . . . . . . . . . . 6 = 4. Basic Overview . . . . . . . . . . . . = . . . . . . . . . . . 6
5. LISP IPv4 = and IPv6 Control-Plane Packet Formats . . . . . . . 7 = 5. LISP IPv4 and IPv6 Control-Plane Packet = Formats . . . . . . . 7
5.1. LISP = Control Packet Type Allocations . . . . . . . . . . 9 = 5.1. LISP Control Packet Type Allocations = . . . . . . . . . . 9
5.2. = Map-Request Message Format . . . . . . . . . . . . . . . 10 = 5.2. Map-Request Message Format . . . . = . . . . . . . . . . . 10
5.3. = EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 = 5.3. EID-to-RLOC UDP Map-Request Message = . . . . . . . . . . . 13
5.4. = Map-Reply Message Format . . . . . . . . . . . . . . . . 15 = 5.4. Map-Reply Message Format . . . . . = . . . . . . . . . . . 15
5.5. = EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 = 5.5. EID-to-RLOC UDP Map-Reply Message . = . . . . . . . . . . . 19
5.6. = Map-Register Message Format . . . . . . . . . . . . . . . 22 = 5.6. Map-Register Message Format . . . . = . . . . . . . . . . . 22
5.7. = Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 = 5.7. Map-Notify/Map-Notify-Ack Message = Format . . . . . . . . 25
5.8. = Encapsulated Control Message Format . . . . . . . . . . . 26 5.8. = Encapsulated Control Message Format . . . . . . . . . . . 27
6. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 28 6. = Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 29
6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28 6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 29
7. Routing = Locator Reachability . . . . . . . . . . . . . . . . 29 7. = Routing Locator Reachability . . . . . . . . . . . . . . . . 30
7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31 7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 32
8. = Interactions with Other LISP Components . . . . . . . . . . . 32 8. = Interactions with Other LISP Components . . . . . . . . . . . 33
8.1. ITR = EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32 8.1. = ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 33
8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 33 8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 34
8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 35 8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 36
8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 36 8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 37
8.4.1. = Anycast Map-Resolver Operation . . . . . . . . . . . 36 = 8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 37
9. Security = Considerations . . . . . . . . . . . . . . . . . . . 36 9. = Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. Changes = since RFC 6833 . . . . . . . . . . . . . . . . . . . 37 10. = Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 38
11. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 38 11. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.1. = LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 38 11.1. = LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 39
11.2. = LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 11.2. = LISP Packet Type Codes . . . . . . . . . . . . . . . . . 39
11.3. = LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 39 11.3. = LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 40
11.4. = LISP Address Type Codes . . . . . . . . . . . . . . . . 39 11.4. = LISP Address Type Codes . . . . . . . . . . . . . . . . 40
11.5. = LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 40 11.5. = LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 41
=
12. = References . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. = References . . . . . . . . . . . . . . . . . . . . . . . . . 41
12.1. = Normative References . . . . . . . . . . . . . . . . . . 40 12.1. = Normative References . . . . . . . . . . . . . . . . . . 41
12.2. = Informative References . . . . . . . . . . . . . . . . . 41 12.2. = Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 45 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 46
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 45 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 46
B.1. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 45 B.1. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . = 46
B.2. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 45 B.2. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . = 46
B.3. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 45 B.3. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . = 46
B.4. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 45 B.4. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . = 46
B.5. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 46 B.5. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 46
B.6. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 46 B.6. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . = 47
B.7. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 46 B.7. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . = 47
B.8. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 46 B.8. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . = 47
B.9. = Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 47 B.9. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 47
B.10. = Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 47 B.10. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . = 48
B.11. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 47 B.11. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . = 48
B.12. = Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 48 B.12. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 48
B.13. = Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 48 B.13. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . = 49
B.14. = Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 48 B.14. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . = 49
B.15. = Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 48 B.15. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . = 49
B.16. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48 B.16. = Changes to draft-ietf-lisp-rfc6833bis-00 . . . . = . . . . 49
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 B.17. Changes to = draft-farinacci-lisp-rfc6833bis-00 . . . . . . 49
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 50
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol = [I-D.ietf-lisp-rfc6830bis] (see
also = [I-D.ietf-lisp-introduction]) specifies an architecture and = also [I-D.ietf-lisp-introduction]) specifies = an architecture and
mechanism = for dynamic tunnelling by logically = separating the mechanism for = dynamic tunneling by logically separating = the addresses
addresses = currently used by IP in two separate name spaces: Endpoint = currently used by IP in two separate name = spaces: Endpoint IDs
IDs (EIDs), = used within sites; and Routing Locators (RLOCs), used on = (EIDs), used within sites; and Routing = Locators (RLOCs), used on the
the transit = networks that make up the Internet infrastructure. To transit networks that make up the Internet = infrastructure. To
achieve this = separation, LISP defines protocol mechanisms for mapping = achieve this separation, LISP defines = protocol mechanisms for mapping
from EIDs to = RLOCs. In addition, LISP assumes the existence of a from EIDs to RLOCs. In addition, LISP assumes the = existence of a
database to = store and propagate those mappings globally. Several database to store and propagate those mappings = globally. Several
such databases = have been proposed; among them are the Content such databases have been proposed; among them are the = Content
distribution = Overlay Network Service for LISP-NERD (a Not-so-novel distribution Overlay Network Service for LISP-NERD (a = Not-so-novel
EID-to-RLOC = Database) [RFC6837], LISP Alternative Logical Topology EID-to-RLOC Database) [RFC6837], LISP Alternative = Logical Topology
(LISP-ALT) = [RFC6836], and LISP Delegated Database Tree (LISP-DDT) (LISP-ALT) [RFC6836], and LISP Delegated Database = Tree (LISP-DDT)
= [RFC8111]. [RFC8111].
=
The LISP = Mapping Service defines two new types of LISP-speaking The LISP Mapping Service defines two new types of = LISP-speaking
=
skipping to = change at = page 4, line 20 =C2=B6 = skipping to change at page 4, line 20 =C2=B6
[GTP-3GPP], = ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6) = [GTP-3GPP], ILA [I-D.herbert-intarea-ila], = and Segment Routing (SRv6)
= [RFC8402]. [RFC8402].
=
Conceptually, = LISP Map-Servers share some of the same basic Conceptually, LISP Map-Servers share some of the same = basic
configuration = and maintenance properties as Domain Name System (DNS) configuration and maintenance properties as Domain = Name System (DNS)
[RFC1035] = servers; likewise, Map-Resolvers are conceptually similar = [RFC1035] servers; likewise, Map-Resolvers = are conceptually similar
to DNS caching = resolvers. With this in mind, this specification to DNS caching resolvers. With this in mind, this = specification
borrows = familiar terminology (resolver and server) from the DNS = borrows familiar terminology (resolver and = server) from the DNS
= specifications. = specifications.
=
Note that while this document assumes a LISP-ALT = database mapping Note this document doesn't assume any particular = database mapping
infrastructure = to illustrate certain aspects of Map-Server and Map- infrastructure to illustrate certain aspects of = Map-Server and Map-
Resolver = operation, the Mapping Service interface can (and likely = Resolver operation, the Mapping Service = interface can (and likely
will) be used = by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other = mapping database
systems as the = LISP infrastructure evolves. = systems as the LISP infrastructure evolves.
=
The LISP = Mapping Service is an important component of the LISP The LISP Mapping Service is an important component of = the LISP
toolset. = Issues and concerns about the deployment of LISP for toolset. Issues and concerns about the deployment of = LISP for
Internet = traffic are discussed in [I-D.ietf-lisp-rfc6830bis], Internet traffic are discussed in = [I-D.ietf-lisp-rfc6830bis],
[RFC7215], and = [I-D.rodrigueznatal-lisp-oam]. = [RFC7215], and [I-D.rodrigueznatal-lisp-oam].
=
=
skipping to = change at = page 8, line 27 =C2=B6 = skipping to change at page 8, line 27 =C2=B6
sender and the = destination UDP port number is set to 4342. When a sender and the destination UDP port number is set to = 4342. When a
UDP Map-Reply, = Map-Notify (when used as an acknowledgement to a Map- UDP Map-Reply, Map-Notify (when used as an = acknowledgement to a Map-
Register), or = Map-Notify-Ack are sent, the source UDP port number is Register), or Map-Notify-Ack are sent, the source UDP = port number is
set to 4342 = and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is = copied from the
source port of = either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking = data packet.
= Implementations MUST be prepared to accept packets when either = the Implementations MUST be = prepared to accept packets when either the
source port or = destination UDP port is set to 4342 due to NATs source port or destination UDP port is set to 4342 = due to NATs
changing port = number values. changing port number = values.
=
The 'UDP = Length' field will reflect the length of the UDP header and = The 'UDP Length' field will reflect the = length of the UDP header and
the LISP = Message payload. the LISP Message = payload. Implementations should follow = the
= procedures from = [RFC8085] to determine the maximum size used for any
= LISP control = message.
=
The UDP = checksum is computed and set to non-zero for all messages = The UDP checksum is computed and set to = non-zero for all messages
sent to or = from port 4342. It MUST be checked on receipt, and if the = sent to or from port 4342. It MUST be = checked on receipt, and if the
checksum = fails, the control message MUST be dropped [RFC1071]. checksum fails, the control message MUST be dropped = [RFC1071].
=
The format of = control messages includes the UDP header so the The format of control messages includes the UDP = header so the
checksum and = length fields can be used to protect and delimit message = checksum and length fields can be used to = protect and delimit message
= boundaries. boundaries.
=
5.1. LISP = Control Packet Type Allocations 5.1. = LISP Control Packet Type Allocations
=
skipping to = change at = page 11, line 13 =C2=B6 = skipping to change at page 11, line = 13 =C2=B6
Request = (SMRs) Section 6.1 for details. = Request (SMRs) Section 6.1 for details.
=
p: This is the = PITR bit. This bit is set to 1 when a PITR sends a p: This is the PITR bit. This bit is set to 1 when a = PITR sends a
= Map-Request. = Map-Request.
=
s: This is the = SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 = when an xTR is
sending a = Map-Request in response to a received SMR-based Map- sending a Map-Request in response to a received = SMR-based Map-
= Request. Request.
=
m: This is the = LISP mobile-node m-bit. This bit is set by xTRs that m: This is the LISP mobile-node m-bit. This bit is = set by xTRs that
operate = as a mobile node as defined in [I-D.ietf-lisp-mn]. operate as a mobile node as defined in = [I-D.ietf-lisp-mn]. This
= bit can be = ignored if an implementation does not support
= = [I-D.ietf-lisp-mn].
=
I: This is the = xTR-ID bit. When this bit is set, what is appended to I: This is the xTR-ID bit. When this bit is set, = what is appended to
the = Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage = the Map-Request is a 128-bit xTR = router-ID. See LISP PubSub usage
= procedures in [I-D.ietf-lisp-pubsub] for details. procedures in [I-D.ietf-lisp-pubsub] for details. = This bit can be
= ignored if an = implementation does not support
= = [I-D.ietf-lisp-pubsub]
=
Rsvd: This = field MUST be set to 0 on transmit and MUST be ignored on = Rsvd: This field MUST be set to 0 on = transmit and MUST be ignored on
= receipt. receipt.
=
L: This is the = local-xtr bit. It is used by an xTR in a LISP site to L: This is the local-xtr bit. It is used by an xTR = in a LISP site to
tell other = xTRs in the same site that it is part of the RLOC-set tell other xTRs in the same site that it is part = of the RLOC-set
for the = LISP site. The L-bit is set to 1 when the RLOC is the for the LISP site. The L-bit is set to 1 when the = RLOC is the
sender's IP = address. sender's IP = address.
=
D: This is the = dont-map-reply bit. It is used in the SMR procedure D: This is the dont-map-reply bit. It is used in the = SMR procedure
=
skipping to = change at = page 11, line 48 =C2=B6 = skipping to change at page 12, line 4 =C2=B6
value of 0, = there is 1 ITR-RLOC address encoded; for a value of 1, value of 0, there is 1 ITR-RLOC address encoded; = for a value of 1,
there are 2 = ITR-RLOC addresses encoded, and so on up to 31, which there are 2 ITR-RLOC addresses encoded, and so on = up to 31, which
encodes a = total of 32 ITR-RLOC addresses. = encodes a total of 32 ITR-RLOC addresses.
=
Record Count: = This is the number of records in this Map-Request Record Count: This is the number of records in this = Map-Request
message. A = record is comprised of the portion of the packet that message. A record is comprised of the portion of = the packet that
is labeled = 'Rec' above and occurs the number of times equal to is labeled 'Rec' above and occurs the number of = times equal to
Record = Count. For this version of the protocol, a receiver MUST = Record Count. For this version of the = protocol, a receiver MUST
accept and = process Map-Requests that contain one or more records, accept and process Map-Requests that contain one = or more records,
but a = sender MUST only send Map-Requests containing one record. = but a sender MUST only send Map-Requests = containing one record.
Support = for requesting multiple EIDs in a single = Map-Request =
= Support for processing multiple EIDs in a single = Map-Request
message = will be specified in a future version of the protocol. message will be specified in a future version of = the protocol.
=
Nonce: This = is an 8-octet random value created by the sender of the = Nonce: This is an 8-octet random value = created by the sender of the
= Map-Request. This nonce will be returned in the Map-Reply. = The Map-Request. This nonce = will be returned in the Map-Reply. The
security of = the LISP mapping protocol critically depends on the security of the LISP mapping protocol critically = depends on the
strength of = the nonce in the Map-Request message. The nonce strength of the nonce in the Map-Request message. = The nonce
SHOULD be = generated by a properly seeded pseudo-random (or strong = SHOULD be generated by a properly seeded = pseudo-random (or strong
random) = source. See [RFC4086] for advice on generating security- = random) source. See [RFC4086] for advice = on generating security-
sensitive = random data. sensitive random = data.
=
=
skipping to = change at = page 13, line 41 =C2=B6 = skipping to change at page 13, line = 43 =C2=B6
=
Map-Requests = can also be LISP encapsulated using UDP destination Map-Requests can also be LISP encapsulated using UDP = destination
port 4342 with = a LISP Type value set to "Encapsulated Control port 4342 with a LISP Type value set to "Encapsulated = Control
Message", when = sent from an ITR to a Map-Resolver. Likewise, Map- Message", when sent from an ITR to a Map-Resolver. = Likewise, Map-
Requests are = LISP encapsulated the same way from a Map-Server to an Requests are LISP encapsulated the same way from a = Map-Server to an
ETR. Details = on Encapsulated Map-Requests and Map-Resolvers can be ETR. Details on Encapsulated Map-Requests and = Map-Resolvers can be
found in = Section 5.8. found in Section = 5.8.
=
Map-Requests = MUST be rate-limited. It is RECOMMENDED that a Map- Map-Requests MUST be rate-limited. It is RECOMMENDED = that a Map-
Request for = the same EID-Prefix be sent no more than once per second. = Request for the same EID-Prefix be sent no = more than once per second.
= However, = recommendations from [RFC8085] SHOULD be considered.
=
An ITR that is = configured with mapping database information (i.e., it An ITR that is configured with mapping database = information (i.e., it
is also an = ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings = in a Map-
Request. When = an ETR configured to accept and verify such Request. When an ETR configured to accept and verify = such
"piggybacked" = mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a = Map-Request and it does
not have this = mapping in the Map-Cache, it MAY originate a "verifying = not have this mapping in the Map-Cache, it = MAY originate a "verifying
Map-Request", = addressed to the map-requesting ITR and the ETR MAY add = Map-Request", addressed to the = map-requesting ITR and the ETR MAY add
a Map-Cache = entry. If the ETR has a Map-Cache entry that matches the = a Map-Cache entry. If the ETR has a = Map-Cache entry that matches the
"piggybacked" = EID and the RLOC is in the Locator-Set for the entry, "piggybacked" EID and the RLOC is in the Locator-Set = for the entry,
then it MAY = send the "verifying Map-Request" directly to the then it MAY send the "verifying Map-Request" directly = to the
=
skipping to = change at = page 23, line 30 =C2=B6 = skipping to change at page 23, line = 30 =C2=B6
T: This is the = use-TTL for timeout bit. When set to 1, the xTR wants T: This is the use-TTL for timeout bit. When set to = 1, the xTR wants
the = Map-Server to time out registrations based on the value in the = the Map-Server to time out registrations = based on the value in the
"Record = TTL" field of this message. = "Record TTL" field of this message.
=
a: This is the = merge-request bit. When set to 1, the xTR requests to a: This is the merge-request bit. When set to 1, the = xTR requests to
merge = RLOC-records from different xTRs registering the same EID- = merge RLOC-records from different xTRs = registering the same EID-
record. = See signal-free multicast [RFC8378] for one use case record. See signal-free multicast [RFC8378] for = one use case
= example. example.
=
m: This is the = mobile-node bit. When set to 1, the registering xTR m: This is the mobile-node bit. When set to 1, the = registering xTR
supports = the procedures in [I-D.ietf-lisp-mn]. = supports the procedures in [I-D.ietf-lisp-mn]. This bit can be
= ignored if an = implementation does not support [I-D.ietf-lisp-mn]
=
M: This is the = want-map-notify bit. When set to 1, an ETR is M: This is the want-map-notify bit. When set to 1, = an ETR is
requesting = a Map-Notify message to be returned in response to requesting a Map-Notify message to be returned in = response to
sending a = Map-Register message. The Map-Notify message sent by a = sending a Map-Register message. The = Map-Notify message sent by a
Map-Server = is used to acknowledge receipt of a Map-Register Map-Server is used to acknowledge receipt of a = Map-Register
= message. message.
=
Record Count: = This is the number of records in this Map-Register Record Count: This is the number of records in this = Map-Register
message. A = record is comprised of that portion of the packet message. A record is comprised of that portion of = the packet
labeled = 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of = times equal to
=
skipping = to change at page 26, line = 5 =C2=B6 = skipping to change at page 26, line = 5 =C2=B6
Type: 4/5 = (Map-Notify/Map-Notify-Ack) Type: = 4/5 (Map-Notify/Map-Notify-Ack)
=
The Map-Notify = message has the same contents as a Map-Register The Map-Notify message has the same contents as a = Map-Register
message. See = the Map-Register section for field descriptions. message. See the Map-Register section for field = descriptions.
=
The = Map-Notify-Ack message has the same contents as a Map-Notify = The Map-Notify-Ack message has the same = contents as a Map-Notify
message. It = is used to acknowledge the receipt of a Map-Notify and message. It is used to acknowledge the receipt of a = Map-Notify and
for the sender = to stop retransmitting a Map-Notify with the same for the sender to stop retransmitting a Map-Notify = with the same
= nonce. nonce.
=
= A sender of an = unsolicited Map-Notify message (one that is not used
= as an acknowledgment = to a Map-Register message) will follow the
= Congestion Control = And Relability Guideline sections of [RFC8085]. A
= Map-Notify is = retransmitted until a Map-Notify-Ack with the same
= nonce from ther = Map-Notify message is received. If a Map-Notify-Ack
= is never received, a = log message is issued. An implementation SHOULD
= retransmit up to 3 = times at 3 second retransmission intervals, after
= which time the = retransmission interval is exponentially backed-off
= for anthoer 3 = retransmission attempts. After this time, the Map-
= Notify sender can = only get the RLOC-set change by later querying the
= mapping system or by = RLOC-probing one of the RLOCs of the existing
= cached RLOC-set to = get the new RLOC-set.
= =
5.8. = Encapsulated Control Message Format 5.8.= Encapsulated Control Message Format
=
An = Encapsulated Control Message (ECM) is used to encapsulate = control An Encapsulated Control = Message (ECM) is used to encapsulate control
packets sent = between xTRs and the mapping database system. packets sent between xTRs and the mapping database = system.
=
0 = 1 2 3 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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = IPv4 or IPv6 Header | / | IPv4 or IPv6 Header = |
OH | = (uses RLOC addresses) | OH | (uses RLOC addresses) = |
=
skipping = to change at page 29, line = 16 =C2=B6 = skipping to change at page 30, line = 16 =C2=B6
accept the = Map-Request. accept the = Map-Request.
=
3. The remote = ITR MUST rate-limit the Map-Request until it gets a 3. The remote ITR MUST rate-limit the Map-Request = until it gets a
Map-Reply = while continuing to use the cached mapping. When Map-Reply while continuing to use the cached = mapping. When
= Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, = Map-Versioning as described in = [I-D.ietf-lisp-6834bis] is used,
an SMR = sender can detect if an ITR is using the most up-to-date = an SMR sender can detect if an ITR is = using the most up-to-date
database = mapping. database = mapping.
=
4. The ETRs = at the site with the changed mapping will reply to the 4. The ETRs at the site with the changed mapping = will reply to the
= Map-Request with a Map-Reply message that has a nonce from the = Map-Request with a Map-Reply message = that has a nonce from the
= SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- SMR-invoked Map-Request. The Map-Reply messages = MUST be rate-
limited. This is important to avoid Map-Reply = implosion. limited according to procedures in [RFC8085]. = This is important
= to avoid Map-Reply implosion.
=
5. The ETRs = at the site with the changed mapping record the fact 5. The ETRs at the site with the changed mapping = record the fact
that the = site that sent the Map-Request has received the new that the site that sent the Map-Request has = received the new
mapping = data in the Map-Cache entry for the remote site so the mapping data in the Map-Cache entry for the = remote site so the
= Locator-Status-Bits are reflective of the new mapping for = packets Locator-Status-Bits are = reflective of the new mapping for packets
going to = the remote site. The ETR then stops sending SMR going to the remote site. The ETR then stops = sending SMR
= messages. messages.
=
For security = reasons, an ITR MUST NOT process unsolicited Map- For security reasons, an ITR MUST NOT process = unsolicited Map-
Replies. To = avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a = third party, a
=
skipping = to change at page 35, line = 35 =C2=B6 = skipping to change at page 36, line = 35 =C2=B6
1-minute = TTL. 1-minute TTL.
=
If the = EID-prefix is either registered or not registered to the = If the EID-prefix is either registered or = not registered to the
mapping system = and there is a policy in the Map-Server to have the mapping system and there is a policy in the = Map-Server to have the
requestor drop = packets for the matching EID-prefix, then a Drop/ requestor drop packets for the matching EID-prefix, = then a Drop/
Policy-Denied = action is returned. If the EID-prefix is registered or = Policy-Denied action is returned. If the = EID-prefix is registered or
not registered = and there is a authentication failure, then a Drop/ not registered and there is a authentication failure, = then a Drop/
= Authentication- failure action is returned. If either of these = Authentication- failure action is returned. = If either of these
actions result = as a temporary state in policy or authentication then actions result as a temporary state in policy or = authentication then
a = Send-Map-Request action with 1-minute TTL MAY be returned to = allow a Send-Map-Request action = with 1-minute TTL MAY be returned to allow
the reqeustor to retry the Map-Request. = the requestor = to retry the Map-Request.
=
If any of the = registered ETRs for the EID-Prefix have requested proxy = If any of the registered ETRs for the = EID-Prefix have requested proxy
reply service, = then the Map-Server answers the request instead of reply service, then the Map-Server answers the = request instead of
forwarding it. = It returns a Map-Reply with the EID-Prefix, RLOCs, forwarding it. It returns a Map-Reply with the = EID-Prefix, RLOCs,
and other = information learned through the registration process. and other information learned through the = registration process.
=
If none of the = ETRs have requested proxy reply service, then the Map- If none of the ETRs have requested proxy reply = service, then the Map-
Server = re-encapsulates and forwards the resulting Encapsulated Map- = Server re-encapsulates and forwards the = resulting Encapsulated Map-
Request to one = of the registered ETRs. It does not otherwise alter Request to one of the registered ETRs. It does not = otherwise alter
the = Map-Request, so any Map-Reply sent by the ETR is returned to = the the Map-Request, so any = Map-Reply sent by the ETR is returned to the
=
skipping = to change at page 37, line = 43 =C2=B6 = skipping to change at page 38, line = 43 =C2=B6
10. Changes = since RFC 6833 10. Changes since RFC = 6833
=
For = implementation considerations, the following changes have been = For implementation considerations, the = following changes have been
made to this = document since RFC 6833 was published: = made to this document since RFC 6833 was published:
=
o A = Map-Notify-Ack message is added in this document to provide = o A Map-Notify-Ack message is added in this = document to provide
reliability = for Map-Notify messages. Any receiver of a Map-Notify reliability for Map-Notify messages. Any receiver = of a Map-Notify
message = must respond with a Map-Notify-Ack message. Map-Servers = message must respond with a = Map-Notify-Ack message. Map-Servers
who are = senders of Map-Notify messages, must queue the Map-Notify = who are senders of Map-Notify messages, = must queue the Map-Notify
contents = until they receive a Map-Notify-Ack with the nonce used = contents until they receive a = Map-Notify-Ack with the nonce used
in the = Map-Notify message. in the = Map-Notify message. Note that implementations = for Map-
= Notify-Ack = support already exist and predate this document.
=
o This = document is incorporating the codepoint for the Map-Referral = o This document is incorporating the = codepoint for the Map-Referral
message = from the LISP-DDT specification [RFC8111] to indicate that = message from the LISP-DDT specification = [RFC8111] to indicate that
a = Map-Server must send the final Map-Referral message when it = a Map-Server must send the final = Map-Referral message when it
= participates in the LISP-DDT mapping system procedures. = participates in the LISP-DDT mapping = system procedures.
=
o The "m", = "I", "L", and "D" bits are added to the Map-Request o The "m", "I", "L", and "D" bits are added to the = Map-Request
message. = See Section 5.3 for details. = message. See Section 5.3 for details.
=
o The "S", = "I", "E", "T", "a", and "m" bits are added to the Map- o The "S", "I", "E", "T", "a", and "m" bits are = added to the Map-
=
skipping = to change at page 40, line = 35 =C2=B6 = skipping to change at page 41, line = 35 =C2=B6
12.1. Normative = References 12.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-16 = (work in progress), = (LISP)", draft-ietf-lisp-rfc6830bis-17 = (work in progress),
= August 2018. September = 2018.
=
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
[RFC4868] = Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- = [RFC4868] Kelly, S. and S. Frankel, "Using = HMAC-SHA-256, HMAC-SHA-
= 384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC = 4868,
DOI = 10.17487/RFC4868, May 2007, = DOI 10.17487/RFC4868, May 2007,
= <https://www.rfc-editor.org/info/rfc4868>. = <https://www.rfc-editor.org/info/rfc4868>.
=
= [RFC8085] Eggert, = L., Fairhurst, G., and G. Shepherd, "UDP Usage
= = Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
= March = 2017, <https://www.rfc-editor.org/info/rfc8085>.
= =
12.2. = Informative References 12.2. = Informative References
=
[AFI] = IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY = [AFI] IANA, "Address Family Identifier = (AFIs)", ADDRESS FAMILY
= NUMBERS http://www.iana.org/assignments/address-family- = NUMBERS = http://www.iana.org/assignments/address-family-
= numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, = Febuary 2007.
=
= [GTP-3GPP] [GTP-3GPP]
= 3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) = Tunnelling
= Protocol User Plane (GTPv1-U)", TS.29.281 Protocol User Plane (GTPv1-U)", = TS.29.281
= https://portal.3gpp.org/desktopmodules/Specifications/ = https://portal.3gpp.org/desktopmodules/Specifications/
=
skipping = to change at page 45, line = 19 =C2=B6 = skipping to change at page 46, line = 19 =C2=B6
Fabio Maino, = and members of the lisp@ietf.org mailing list for their = Fabio Maino, and members of the = lisp@ietf.org mailing list for their
feedback and = helpful suggestions. feedback and = helpful suggestions.
=
Special thanks = are due to Noel Chiappa for his extensive work and Special thanks are due to Noel Chiappa for his = extensive work and
thought about = caching in Map-Resolvers. thought = about caching in Map-Resolvers.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6833bis-14 B.1. = Changes to draft-ietf-lisp-rfc6833bis-15
=
= o Posted = mid-September 2018.
=
= o Changes to = reflect comments from Colin and Mirja.
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-14
=
o Posted = September 2018. o Posted September = 2018.
=
o Changes to = reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, = and Secdir
= reviews. reviews.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-13 B.3. Changes to = draft-ietf-lisp-rfc6833bis-13
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-12 B.4. Changes to = draft-ietf-lisp-rfc6833bis-12
=
o Posted late = July 2018. o Posted late July = 2018.
=
o Moved = RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative = References.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-11 B.5. Changes to = draft-ietf-lisp-rfc6833bis-11
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for = RFC status and
ran through = IDNITs again. ran through IDNITs = again.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-10 B.6. Changes to = draft-ietf-lisp-rfc6833bis-10
=
o Posted = after LISP WG at IETF week March. o = Posted after LISP WG at IETF week March.
=
o Move AD = field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM = packet format
description = section. description = section.
=
o Say more = about when the new Drop actions should be sent. o Say more about when the new Drop actions should be = sent.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-09 B.7. Changes to = draft-ietf-lisp-rfc6833bis-09
=
o Posted = March IETF week 2018. o Posted = March IETF week 2018.
=
o Fixed = editorial comments submitted by document shepherd Luigi = o Fixed editorial comments submitted by = document shepherd Luigi
= Iannone. Iannone.
=
B.7. Changes to = draft-ietf-lisp-rfc6833bis-08 B.8. Changes to = draft-ietf-lisp-rfc6833bis-08
=
o Posted = March 2018. o Posted March = 2018.
=
o Added = RLOC-probing algorithm. o Added = RLOC-probing algorithm.
=
o Added = Solicit-Map Request algorithm. o = Added Solicit-Map Request algorithm.
=
o Added = several mechanisms (from 6830bis) regarding Routing Locator = o Added several mechanisms (from 6830bis) = regarding Routing Locator
= Reachability. = Reachability.
=
o Added port = 4342 to IANA Considerations section. = o Added port 4342 to IANA Considerations section.
=
B.8. Changes to = draft-ietf-lisp-rfc6833bis-07 B.9. Changes to = draft-ietf-lisp-rfc6833bis-07
=
o Posted = December 2017. o Posted December = 2017.
=
o Make it = more clear in a couple of places that RLOCs are used to = o Make it more clear in a couple of places = that RLOCs are used to
locate ETRs = more so than for Map-Server Map-Request forwarding. locate ETRs more so than for Map-Server = Map-Request forwarding.
=
o Make it = clear that "encapsualted" for a control message is an ECM = o Make it clear that "encapsualted" for a = control message is an ECM
based = message. based message.
=
o Make it = more clear what messages use source-port 4342 and which = o Make it more clear what messages use = source-port 4342 and which
=
skipping = to change at page 47, line = 13 =C2=B6 = skipping to change at page 48, line = 16 =C2=B6
Can use = othe AFIs then IPv4 and IPv6. = Can use othe AFIs then IPv4 and IPv6.
=
o Many = editorial changes to clarify text. = o Many editorial changes to clarify text.
=
o Changed = some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to = capitalized.
=
o Added = definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply = messages.
=
o Ran = document through IDNITs. o Ran = document through IDNITs.
=
B.9. Changes to = draft-ietf-lisp-rfc6833bis-06 B.10. Changes to = draft-ietf-lisp-rfc6833bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Spec the = I-bit to include the xTR-ID in a Map-Request message to = o Spec the I-bit to include the xTR-ID in a = Map-Request message to
be = consistent with the Map-Register message and to anticipate the = be consistent with the Map-Register = message and to anticipate the
= introduction of pubsub functionality to allow Map-Requests to = introduction of pubsub functionality to = allow Map-Requests to
subscribe = to RLOC-set changes. subscribe = to RLOC-set changes.
=
o Updated = references for individual submissions that became working = o Updated references for individual = submissions that became working
group = documents. group = documents.
=
o Updated = references for working group documents that became RFCs. = o Updated references for working group = documents that became RFCs.
=
B.10. Changes to = draft-ietf-lisp-rfc6833bis-05 B.11. Changes to = draft-ietf-lisp-rfc6833bis-05
=
o Posted May = 2017. o Posted May 2017.
=
o Update IANA = Considerations section based on new requests from this o Update IANA Considerations section based on new = requests from this
document = and changes from what was requested in [RFC6830]. document and changes from what was requested in = [RFC6830].
=
B.11. Changes to = draft-ietf-lisp-rfc6833bis-04 B.12. Changes to = draft-ietf-lisp-rfc6833bis-04
=
o Posted May = 2017. o Posted May 2017.
=
o Clarify how = the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in = Map-Register and Map-
Notify = messages. Break the 16-bit field into a 8-bit Key-ID field = Notify messages. Break the 16-bit field = into a 8-bit Key-ID field
and a 8-bit = Algorithm-ID field. and a 8-bit = Algorithm-ID field.
=
o Move the = Control-Plane codepoints from the IANA Considerations o Move the Control-Plane codepoints from the IANA = Considerations
section of = RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations = section of this
= document. document.
=
o In the = "LISP Control Packet Type Allocations" section, indicate = o In the "LISP Control Packet Type = Allocations" section, indicate
how message = Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how = experimental RFC8113
sub-types = should be requested. sub-types = should be requested.
=
B.12. Changes to = draft-ietf-lisp-rfc6833bis-03 B.13. Changes to = draft-ietf-lisp-rfc6833bis-03
=
o Posted = April 2017. o Posted April = 2017.
=
o Add types = 9-14 and specify they are not assigned. = o Add types 9-14 and specify they are not assigned.
=
o Add the = "LISP Shared Extension Message" type and point to RFC8113. = o Add the "LISP Shared Extension Message" = type and point to RFC8113.
=
B.13. Changes to = draft-ietf-lisp-rfc6833bis-02 B.14. Changes to = draft-ietf-lisp-rfc6833bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Clarify = that the LISP Control-Plane document defines how the LISP = o Clarify that the LISP Control-Plane = document defines how the LISP
Data-Plane = uses Map-Requests with either the SMR-bit set or the Data-Plane uses Map-Requests with either the = SMR-bit set or the
P-bit set = supporting mapping updates and RLOC-probing. Indicating = P-bit set supporting mapping updates and = RLOC-probing. Indicating
that other = Data-Planes can use the same mechanisms or their own that other Data-Planes can use the same mechanisms = or their own
defined = mechanisms to achieve the same functionality. defined mechanisms to achieve the same = functionality.
=
B.14. Changes to = draft-ietf-lisp-rfc6833bis-01 B.15. Changes to = draft-ietf-lisp-rfc6833bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Remove = references to self. o Remove = references to self.
=
o Change = references from RFC6830 to RFC6830bis. = o Change references from RFC6830 to RFC6830bis.
=
o Add two new = action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has = posted to the LISP
WG mailing = list. WG mailing list.
=
o In intro = section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to = I-D.ietf-lisp-introduction.
=
o Removed = Open Issues section and references to "experimental". o Removed Open Issues section and references to = "experimental".
=
B.15. Changes to = draft-ietf-lisp-rfc6833bis-00 B.16. Changes to = draft-ietf-lisp-rfc6833bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6833-00 = individual submission. No other changes made. -rfc6833-00 individual submission. No other = changes made.
=
B.16. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.17. Changes to = draft-farinacci-lisp-rfc6833bis-00
=
o Posted = November 2016. o Posted November = 2016.
=
o This is the = initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into = RFC 6833bis.
=
o The = document name has changed from the "Locator/ID Separation = o The document name has changed from the = "Locator/ID Separation
Protocol = (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the = "Locator/ID
Separation = Protocol (LISP) Control-Plane". = Separation Protocol (LISP) Control-Plane".
=
o The = fundamental change was to move the Control-Plane messages from = o The fundamental change was to move the = Control-Plane messages from
 End of changes. 35 change blocks. 
77 lines changed or = deleted 112 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_EE553457-4FD2-4AF8-9260-03301B364B00 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_EE553457-4FD2-4AF8-9260-03301B364B00-- From nobody Fri Sep 14 07:47:26 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DC4130E3A; Fri, 14 Sep 2018 07:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cUl6Ko6ileYR; Fri, 14 Sep 2018 07:47:23 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3CFB124BE5; Fri, 14 Sep 2018 07:47:22 -0700 (PDT) X-AuditID: 1209190c-093ff70000002e47-3f-5b9bc9f981e3 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 39.13.11847.9F9CB9B5; Fri, 14 Sep 2018 10:47:21 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w8EElJV0032436; Fri, 14 Sep 2018 10:47:19 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8EElElK007196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Sep 2018 10:47:17 -0400 Date: Fri, 14 Sep 2018 09:47:14 -0500 From: Benjamin Kaduk To: Dino Farinacci Cc: Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6833bis@ietf.org, The IESG Message-ID: <20180914144714.GH48265@kduck.kaduk.org> References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <9086A458-31C0-4EB2-BC5B-D9CB7B22469E@kuehlewind.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9086A458-31C0-4EB2-BC5B-D9CB7B22469E@kuehlewind.net> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixCmqrfvz5Oxog8WflS1+PetmtGjffY3R YlXrPBaLGX8mMlu8aNvOZjHlrLoDm8fzWWtYPXbOusvusWTJT6YA5igum5TUnMyy1CJ9uwSu jI+dd9kLDnFW9B4/wNLAeIm9i5GTQ0LAROLVo20sXYxcHEICi5kkPu2/zwzhbGSU2DP3MCOE c5VJ4tWPMywgLSwCqhItW/4xgthsAioSDd2XmUFsEQENibvvd7ODNDALrGOUWP55IiuIIyyw gFHiy9MpYN28QAvXTHvJCjF2J6NE34cZ7BAJQYmTM5+AFTELqEv8mXcJaCwHkC0tsfwfB0RY XqJ562ywbZwCThLvdhxgA7FFBZQl9vYdYp/AKDgLyaRZSCbNQpg0C8mkBYwsqxhlU3KrdHMT M3OKU5N1i5MT8/JSi3QN9XIzS/RSU0o3MYKjQZJnB+OZN16HGAU4GJV4eDU2z44WYk0sK67M PcQoycGkJMq71QsoxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3feisaCHelMTKqtSifJiUNAeL kjjvWd3J0UIC6YklqdmpqQWpRTBZGQ4OJQnebyeAhgoWpaanVqRl5pQgpJk4OEGG8wAN1wEm DyHe4oLE3OLMdIj8KUZdjj/vp05iFmLJy89LlRLnLQcZJABSlFGaBzcHlMQksvfXvGIUB3pL mPcHSBUPMAHCTXoFtIQJaMnnPTNAlpQkIqSkGhh37njyVy66SrSx5OhDz/vVOxYn9rrL/3+Z OtHzrfdCl23fFV71JWSwvHsvPfvpXpHZc4+xP2EQDD12omSlaekH0/XtHIt03zhlp87cyHSU K/5yPwPHnRmWv5/3zv+/UFg5Vf/j0mmpt9I9gv6bHKhs0NOSZuM/I2eVX3FIpf0Dyy+Tyb4s D28rsRRnJBpqMRcVJwIAwQBoyD0DAAA= Archived-At: Subject: Re: [lisp] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-iet?= =?iso-8859-1?q?f-lisp-rfc6833bis-13=3A__=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 14 Sep 2018 14:47:25 -0000 On Wed, Sep 12, 2018 at 12:44:36PM +0200, Mirja Kuehlewind (IETF) wrote: > > > Am 11.09.2018 um 20:13 schrieb Dino Farinacci : > > > >> > >> Further comments: > >> > >> 1) The example given in 5.5 should probably used IPv6 addresses and use the IP > >> address space that is reserved for documentation purposes. > > > > I disagree. I think its simpler with IPv4 addresses and shouldn’t matter. We want this complex concept to come across as clear as possible. And I believe IPv6 doesn’t do that. This is not a v4 versus v6 response. It is a notation preference. > > I will let the INT AD to give further guidance, however, general guidance in the iETF is that IPV6 should also be provided in examples to avoid a bias towards IPv4. I disagree that an IPv6 example would be an more complicated than an IPv4 example. There is an IAB statement that is relevant here (https://www.iab.org/2016/11/07/iab-statement-on-ipv6/): [...] We recommend that all networking standards assume the use of IPv6, and be written so they do not require IPv4. We recommend that existing standards be reviewed to ensure they will work with IPv6, and use IPv6 examples. [...] -Benjamin From nobody Fri Sep 14 09:29:53 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D26130E27 for ; Fri, 14 Sep 2018 09:29:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 CeGC6N6ta_nT for ; Fri, 14 Sep 2018 09:29:43 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 6F96C130ED9 for ; Fri, 14 Sep 2018 09:29:40 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id f17-v6so5482353qkh.4 for ; Fri, 14 Sep 2018 09:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b5c7FPOJ6pJCRorfhF09I7Tks+dLbalRHND+IhlYpbg=; b=GohL8Nm0NPVR1kazJCDKRby0T3wFwQa8rqSu+hiDzm/EB+1osiMl6VbA1YHmqMSkIh EZCI1KTBLXUpxpKRJpOPwymyayX8gGdx+dFkNnHMAP5tKGOwCz25fPg1w2O1DDMot2zv MQh7YnhJWMXoPYsiJlyCggYXbzItTbtjLYAYg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b5c7FPOJ6pJCRorfhF09I7Tks+dLbalRHND+IhlYpbg=; b=Sz80C/+lWhzftED9Ob19mWuGkhEMMGRHO+sKydvc4eUcNjBsONqXOg13YMQTJc61jD D2fAJ33h9tU7+qIGT1im5PeA6wqOUbvA/ocJVFL1Bvzjh2JYxJ+DZ4TzboN2tvWAZla2 fxjT0ozJnJoPio530g13gYvAtqa+FnJq0eCZPrTllQrjV4YNZgm8m7DERlhxbmObF5xP fxKjXe3DOnWyj6lCMBwc4QtoYxS/7B1QiYUsu16J6GpPB9TyPWsmOvaT+7jXJ+MWmvw6 w0qIFCpYbQt70yoOqULPkxT+08K01YDWgkGpVS5SAYAosy6wvHTIUbJnMyFfRwchr0JU Vcuw== X-Gm-Message-State: APzg51CwOfnJQ6H4yd3Iq2/xwTiwGIZ9sZxMeJs/+bOHmWRNtXV+mzZs Utixc6wdj3TXptIXwxfMzrIHLrbq7Aj+CGTZc3Alyw== X-Google-Smtp-Source: ANB0VdbZUkrdrYgIX4cbJ2qOOxm0EgMFTr3hDa8XG87ig3lcvVK4eEk9VSP/NLHsybd8++ZK9R5QscSCvce03cqBo5A= X-Received: by 2002:a37:3492:: with SMTP id b140-v6mr8602943qka.355.1536942579133; Fri, 14 Sep 2018 09:29:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Fri, 14 Sep 2018 09:29:38 -0700 (PDT) X-Originating-IP: [2604:6000:8a42:6905:1d06:646e:3613:148c] In-Reply-To: References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> <5655CB57-721B-4F9C-8F7F-0E38FBA60E0C@gmail.com> From: Kyle Rose Date: Fri, 14 Sep 2018 12:29:38 -0400 Message-ID: To: "BRUNGARD, DEBORAH A" Cc: Dino Farinacci , IETF SecDir , "draft-ietf-lisp-rfc6830bis.all@ietf.org" , IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary="0000000000007841a40575d75408" Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 14 Sep 2018 16:29:51 -0000 --0000000000007841a40575d75408 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My response is that while I suspect based on the conversation between myself and Dino that LISP's security model probably adequately protects mapping system integrity, my confidence in that judgment is low because the information I need for a security review I can't find in the drafts without reading every LISP-related document in detail, a time commitment I simply can't justify. It's possible there's someone else in the security directorate who knows more about the details of LISP and so would be able to much more easily answer some of these questions with confidence; if so, I would recommend that you ask them to take a look. I'm unwilling to say "LGTM" simply because I can't find a problem in the time I've allocated. Kyle On Tue, Sep 11, 2018 at 5:55 PM, BRUNGARD, DEBORAH A wrote= : > Thanks much Kyle for your comments and Dino for resolving! > > Cutting to the end where Dino asked for help- > > -----Original Message----- > From: Dino Farinacci > Sent: Tuesday, September 11, 2018 2:40 PM > To: Kyle Rose > Cc: IETF SecDir ; draft-ietf-lisp-rfc6830bis.all@ietf.or= g; > IETF Discussion Mailing List ; lisp@ietf.org list < > lisp@ietf.org>; Benjamin Kaduk ; Mirja K=C3=BChlewind < > ietf@kuehlewind.net> > Subject: Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15 > > > > What I might recommend is either an augmentation of, or a new document > analogous to (and informationally referencing), > draft-ietf-lisp-introduction that covers the expected security properties > of the overall design and the requirements for each of the subcomponents = in > a way that someone can understand without referring to any document other > than the high-level architecture itself. draft-ietf-lisp-introduction is > actually quite good at getting the general point of LISP across to someon= e > new; I want to see something similar for LISP's security model. I think > that's going to be better than inserting clarifying text here or there. > I've actually read enough of this stuff at this point that I'm not sure I > can enumerate exactly what's missing where. The threat model document cou= ld > potentially be folded into that, but it has to start by painting a pictur= e > of the security that someone new to LISP can quickly understand. > > I=E2=80=99ll yield to the WG to respond to this. > > Dino > > [deborah] > > It's difficult to do *one* overview document on an evolving technology, > especially if the intention is to provide reference to other documents > which are also evolving. Lisp-intro is already having its problems and it > is not published yet. > > As Mark Nottingham noted in his "How to Read an RFC" blog, when reading > RFCs, for better or worse and the resulting frustration, it is "necessary > to read not only the relevant text but also anything that it references": > https://www.ietf.org/blog/how-read-rfc/ > > I'd suggest a wiki would be a better tool to capture this "overview" > informational material. Not only can the format be easier on the eye, it > can be a shared effort and timely updated. Similar to Benoit's work on hi= s > YANG tree dependencies, it would be helpful if a working group provided a > working group tree of documents and it could even reference other working > group documents. > > --0000000000007841a40575d75408 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My response is that while I suspect based on the conversat= ion between=20 myself and Dino that LISP's security model probably adequately protects= =20 mapping system integrity, my confidence in that judgment is low because=20 the information I need for a security review I can't find in the drafts= =20 without reading every LISP-related document in detail, a time commitment I = simply=20 can't justify. It's possible there's someone else in the securi= ty=20 directorate who knows more about the details of LISP and so would be=20 able to much more easily answer some of these questions with confidence; if so, I would recommend that you ask them to take a look. I'm=20 unwilling to say "LGTM" simply because I can't find a problem= in the=20 time I've allocated.

Kyle


On Tue, Sep 1= 1, 2018 at 5:55 PM, BRUNGARD, DEBORAH A <db3546@att.com> wrote:=
Thanks much Kyle for your comments and D= ino for resolving!

Cutting to the end where Dino asked for help-

-----Original Message-----
From: Dino Farinacci <farinacci@g= mail.com>
Sent: Tuesday, September 11, 2018 2:40 PM
To: Kyle Rose <krose@krose.org>= ;
Cc: IETF SecDir <secdir@ietf.org&= gt;; draft-ietf-= lisp-rfc6830bis.all@ietf.org; IETF Discussion Mailing List <ietf@ietf.org>; lisp@ietf.org list <lisp= @ietf.org>; Benjamin Kaduk <kadu= k@mit.edu>; Mirja K=C3=BChlewind <ietf@kuehlewind.net>
Subject: Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15


> What I might recommend is either an augmentation of, or a new document= analogous to (and informationally referencing), draft-ietf-lisp-introducti= on that covers the expected security properties of the overall design and t= he requirements for each of the subcomponents in a way that someone can und= erstand without referring to any document other than the high-level archite= cture itself. draft-ietf-lisp-introduction is actually quite good at gettin= g the general point of LISP across to someone new; I want to see something = similar for LISP's security model. I think that's going to be bette= r than inserting clarifying text here or there. I've actually read enou= gh of this stuff at this point that I'm not sure I can enumerate exactl= y what's missing where. The threat model document could potentially be = folded into that, but it has to start by painting a picture of the security= that someone new to LISP can quickly understand.

I=E2=80=99ll yield to the WG to respond to this.

Dino

[deborah]

It's difficult to do *one* overview document on an evolving technology,= especially if the intention is to provide reference to other documents whi= ch are also evolving. Lisp-intro is already having its problems and it is n= ot published yet.

As Mark Nottingham noted in his "How to Read an RFC" blog, when r= eading RFCs, for better or worse and the resulting frustration, it is "= ;necessary to read not only the relevant text but also anything that it ref= erences":
https://www.ietf.org/blog/how-read-rfc/

I'd suggest a wiki would be a better tool to capture this "overvie= w" informational material. Not only can the format be easier on the ey= e, it can be a shared effort and timely updated. Similar to Benoit's wo= rk on his YANG tree dependencies, it would be helpful if a working group pr= ovided a working group tree of documents and it could even reference other = working group documents.


--0000000000007841a40575d75408-- From nobody Fri Sep 14 09:50:57 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BDF12F1A5; Fri, 14 Sep 2018 09:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OnP5BR2CS7ip; Fri, 14 Sep 2018 09:50:45 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 48FB61292AD; Fri, 14 Sep 2018 09:50:45 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id 2-v6so4671208pgo.4; Fri, 14 Sep 2018 09:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=m/9b/CWEYrGSDNSV43NarrwGcV7XJLCs32WLetOp8tc=; b=UsM6cZLcD8ypVc297nESnMRdO0CFXMJyC5ixGXM5dp7UyeG2wdMIAgE0Lv/uVhud+s ghJBhs7UbXRUjwAad1Yys0G7u+AIjG7JJkzZRBUq83+i6M33VuJ5UNWA1t2fTiSVrBVg gAGFOTl2Dzy6KdY56tcyezCJcy51KnVsKB9SAVRW+NrnNWARWbkt4jL8FUd/uKajE2Yr I5UjacPeq6CGs0puEk9g8BD8EDD7Gj33n9/RzFwvoa6P3ucs4jN49cpjXYNHrmBBNXx6 qmVGyTJkzg8QYR2eCH1938Ry305cVZHFfbmIXLIkhpGuFT/3mk64PzD8PoHEu+s04XhV +RSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=m/9b/CWEYrGSDNSV43NarrwGcV7XJLCs32WLetOp8tc=; b=nIb3RO+cwr5EUJG47zXQug/BFGmsGazel+QENsubTaqil69ua2IptbNGux0j4Sd0sI nmQttmwKFA01rqBfN84WiWgiiNK+oC+ZrK6ltrzV58U3rrpAsdhJG5UtL3SNz04J+r63 5hHfSk+A34+HpNv6FRxKQylI7qNFbDdF5Q2U1drPerCc9dnsuclnk145FhjlTV/PqogK wK/nsXuDGAWwk18+ovL0NoacyjKmZHUx9EutVxMqXOMp9X5sshiGdAcmBgE4nduVtxri MpgkyoOjXJ8/7dLR1AWbn6a0Xomj26pQpqvaIlW8A7V1w/rk5BZMp91nEI67BXzcsAyw D0PA== X-Gm-Message-State: APzg51DfVmYSwrn49O8qToQOFwRBT51HZcVu9ggMdSxCk4eiz9OYJKD0 hubT5kSHsHzZhg01cOwwFpM= X-Google-Smtp-Source: ANB0VdaEVFbTq5bl+B78hFJPUouYoqulXheUd87w4Rlz5ZCVAWPdL++11ALZnM8rRRY3jw62O8Abrg== X-Received: by 2002:a62:1605:: with SMTP id 5-v6mr13468340pfw.11.1536943844762; Fri, 14 Sep 2018 09:50:44 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id x82-v6sm14836046pfe.129.2018.09.14.09.50.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Sep 2018 09:50:43 -0700 (PDT) From: Dino Farinacci Message-Id: <50DF2E0F-6BBC-47A5-996C-74445DF381FF@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_C7BCB5A8-EDC8-4A6E-BBFD-3081E939D131" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 14 Sep 2018 09:50:42 -0700 In-Reply-To: <20180914144714.GH48265@kduck.kaduk.org> Cc: Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6833bis@ietf.org, The IESG To: Benjamin Kaduk References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <9086A458-31C0-4EB2-BC5B-D9CB7B22469E@kuehlewind.net> <20180914144714.GH48265@kduck.kaduk.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 14 Sep 2018 16:50:49 -0000 --Apple-Mail=_C7BCB5A8-EDC8-4A6E-BBFD-3081E939D131 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Changed. See diff enclosed. Uses prefix 2001:db8::/16 for the example. Dino --Apple-Mail=_C7BCB5A8-EDC8-4A6E-BBFD-3081E939D131 Content-Disposition: attachment; filename=rfcdiff-6833bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6833bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-14.txt - = draft-ietf-lisp-rfc6833bis-15.txt=20 =20 =20 =20 =20 =20 =20 = = =
< draft-ietf-lisp-rfc6833bis-14.txt  =  draft-ietf-lisp-rfc6833bis-15.txt >
=
Network Working = Group V. Fuller = Network Working Group = V. Fuller
Internet-Draft = D. Farinacci Internet-Draft = D. Farinacci
Obsoletes: 6833 = (if approved) Cisco Systems = Obsoletes: 6833 (if approved) = Cisco Systems
Intended status: = Standards Track A. Cabellos (Ed.) = Intended status: Standards Track = A. Cabellos (Ed.)
Expires: March = 15, 2019 = UPC/BarcelonaTech Expires: March = 18, 2019 = UPC/BarcelonaTech
= September 11, 2018 = September 14, 2018
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-14 = = draft-ietf-lisp-rfc6833bis-15
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = Control-Plane service interface and communicating with By using this Control-Plane service interface and = communicating with
=
skipping to = change at = page 1, line 48 =C2=B6 = skipping to change at page 1, line 48 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on March 15, = 2019. This Internet-Draft will = expire on March 18, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 34 =C2=B6 = skipping to change at page 2, line 34 =C2=B6
3. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
4. Basic = Overview . . . . . . . . . . . . . . . . . . . . . . . 6 = 4. Basic Overview . . . . . . . . . . . . = . . . . . . . . . . . 6
5. LISP IPv4 = and IPv6 Control-Plane Packet Formats . . . . . . . 7 = 5. LISP IPv4 and IPv6 Control-Plane Packet = Formats . . . . . . . 7
5.1. LISP = Control Packet Type Allocations . . . . . . . . . . 9 = 5.1. LISP Control Packet Type Allocations = . . . . . . . . . . 9
5.2. = Map-Request Message Format . . . . . . . . . . . . . . . 10 = 5.2. Map-Request Message Format . . . . = . . . . . . . . . . . 10
5.3. = EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 = 5.3. EID-to-RLOC UDP Map-Request Message = . . . . . . . . . . . 13
5.4. = Map-Reply Message Format . . . . . . . . . . . . . . . . 15 = 5.4. Map-Reply Message Format . . . . . = . . . . . . . . . . . 15
5.5. = EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 = 5.5. EID-to-RLOC UDP Map-Reply Message . = . . . . . . . . . . . 19
5.6. = Map-Register Message Format . . . . . . . . . . . . . . . 22 = 5.6. Map-Register Message Format . . . . = . . . . . . . . . . . 22
5.7. = Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 = 5.7. Map-Notify/Map-Notify-Ack Message = Format . . . . . . . . 25
5.8. = Encapsulated Control Message Format . . . . . . . . . . . 26 5.8. = Encapsulated Control Message Format . . . . . . . . . . . 27
6. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 28 6. = Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 29
6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28 6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 29
7. Routing = Locator Reachability . . . . . . . . . . . . . . . . 29 7. = Routing Locator Reachability . . . . . . . . . . . . . . . . 30
7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31 7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 32
8. = Interactions with Other LISP Components . . . . . . . . . . . 32 8. = Interactions with Other LISP Components . . . . . . . . . . . 33
8.1. ITR = EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32 8.1. = ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 33
8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 33 8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 34
8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 35 8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 36
8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 36 8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 37
8.4.1. = Anycast Map-Resolver Operation . . . . . . . . . . . 36 = 8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 37
9. Security = Considerations . . . . . . . . . . . . . . . . . . . 36 9. = Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. Changes = since RFC 6833 . . . . . . . . . . . . . . . . . . . 37 10. = Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 38
11. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 38 11. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.1. = LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 38 11.1. = LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 39
11.2. = LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 11.2. = LISP Packet Type Codes . . . . . . . . . . . . . . . . . 39
11.3. = LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 39 11.3. = LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 40
11.4. = LISP Address Type Codes . . . . . . . . . . . . . . . . 39 11.4. = LISP Address Type Codes . . . . . . . . . . . . . . . . 40
11.5. = LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 40 11.5. = LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 41
=
12. = References . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. = References . . . . . . . . . . . . . . . . . . . . . . . . . 41
12.1. = Normative References . . . . . . . . . . . . . . . . . . 40 12.1. = Normative References . . . . . . . . . . . . . . . . . . 41
12.2. = Informative References . . . . . . . . . . . . . . . . . 41 12.2. = Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 45 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 46
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 45 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 46
B.1. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 45 B.1. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . = 46
B.2. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 45 B.2. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . = 46
B.3. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 45 B.3. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . = 46
B.4. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 45 B.4. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . = 46
B.5. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 46 B.5. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 46
B.6. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 46 B.6. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . = 47
B.7. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 46 B.7. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . = 47
B.8. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 46 B.8. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . = 47
B.9. = Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 47 B.9. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 47
B.10. = Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 47 B.10. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . = 48
B.11. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 47 B.11. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . = 48
B.12. = Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 48 B.12. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 48
B.13. = Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 48 B.13. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . = 49
B.14. = Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 48 B.14. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . = 49
B.15. = Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 48 B.15. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . = 49
B.16. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48 B.16. = Changes to draft-ietf-lisp-rfc6833bis-00 . . . . = . . . . 49
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 B.17. Changes to = draft-farinacci-lisp-rfc6833bis-00 . . . . . . 49
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 50
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol = [I-D.ietf-lisp-rfc6830bis] (see
also = [I-D.ietf-lisp-introduction]) specifies an architecture and = also [I-D.ietf-lisp-introduction]) specifies = an architecture and
mechanism = for dynamic tunnelling by logically = separating the mechanism for = dynamic tunneling by logically separating = the addresses
addresses = currently used by IP in two separate name spaces: Endpoint = currently used by IP in two separate name = spaces: Endpoint IDs
IDs (EIDs), = used within sites; and Routing Locators (RLOCs), used on = (EIDs), used within sites; and Routing = Locators (RLOCs), used on the
the transit = networks that make up the Internet infrastructure. To transit networks that make up the Internet = infrastructure. To
achieve this = separation, LISP defines protocol mechanisms for mapping = achieve this separation, LISP defines = protocol mechanisms for mapping
from EIDs to = RLOCs. In addition, LISP assumes the existence of a from EIDs to RLOCs. In addition, LISP assumes the = existence of a
database to = store and propagate those mappings globally. Several database to store and propagate those mappings = globally. Several
such databases = have been proposed; among them are the Content such databases have been proposed; among them are the = Content
distribution = Overlay Network Service for LISP-NERD (a Not-so-novel distribution Overlay Network Service for LISP-NERD (a = Not-so-novel
EID-to-RLOC = Database) [RFC6837], LISP Alternative Logical Topology EID-to-RLOC Database) [RFC6837], LISP Alternative = Logical Topology
(LISP-ALT) = [RFC6836], and LISP Delegated Database Tree (LISP-DDT) (LISP-ALT) [RFC6836], and LISP Delegated Database = Tree (LISP-DDT)
= [RFC8111]. [RFC8111].
=
The LISP = Mapping Service defines two new types of LISP-speaking The LISP Mapping Service defines two new types of = LISP-speaking
=
skipping to = change at = page 4, line 20 =C2=B6 = skipping to change at page 4, line 20 =C2=B6
[GTP-3GPP], = ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6) = [GTP-3GPP], ILA [I-D.herbert-intarea-ila], = and Segment Routing (SRv6)
= [RFC8402]. [RFC8402].
=
Conceptually, = LISP Map-Servers share some of the same basic Conceptually, LISP Map-Servers share some of the same = basic
configuration = and maintenance properties as Domain Name System (DNS) configuration and maintenance properties as Domain = Name System (DNS)
[RFC1035] = servers; likewise, Map-Resolvers are conceptually similar = [RFC1035] servers; likewise, Map-Resolvers = are conceptually similar
to DNS caching = resolvers. With this in mind, this specification to DNS caching resolvers. With this in mind, this = specification
borrows = familiar terminology (resolver and server) from the DNS = borrows familiar terminology (resolver and = server) from the DNS
= specifications. = specifications.
=
Note that while this document assumes a LISP-ALT = database mapping Note this document doesn't assume any particular = database mapping
infrastructure = to illustrate certain aspects of Map-Server and Map- infrastructure to illustrate certain aspects of = Map-Server and Map-
Resolver = operation, the Mapping Service interface can (and likely = Resolver operation, the Mapping Service = interface can (and likely
will) be used = by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other = mapping database
systems as the = LISP infrastructure evolves. = systems as the LISP infrastructure evolves.
=
The LISP = Mapping Service is an important component of the LISP The LISP Mapping Service is an important component of = the LISP
toolset. = Issues and concerns about the deployment of LISP for toolset. Issues and concerns about the deployment of = LISP for
Internet = traffic are discussed in [I-D.ietf-lisp-rfc6830bis], Internet traffic are discussed in = [I-D.ietf-lisp-rfc6830bis],
[RFC7215], and = [I-D.rodrigueznatal-lisp-oam]. = [RFC7215], and [I-D.rodrigueznatal-lisp-oam].
=
=
skipping to = change at = page 8, line 27 =C2=B6 = skipping to change at page 8, line 27 =C2=B6
sender and the = destination UDP port number is set to 4342. When a sender and the destination UDP port number is set to = 4342. When a
UDP Map-Reply, = Map-Notify (when used as an acknowledgement to a Map- UDP Map-Reply, Map-Notify (when used as an = acknowledgement to a Map-
Register), or = Map-Notify-Ack are sent, the source UDP port number is Register), or Map-Notify-Ack are sent, the source UDP = port number is
set to 4342 = and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is = copied from the
source port of = either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking = data packet.
= Implementations MUST be prepared to accept packets when either = the Implementations MUST be = prepared to accept packets when either the
source port or = destination UDP port is set to 4342 due to NATs source port or destination UDP port is set to 4342 = due to NATs
changing port = number values. changing port number = values.
=
The 'UDP = Length' field will reflect the length of the UDP header and = The 'UDP Length' field will reflect the = length of the UDP header and
the LISP = Message payload. the LISP Message = payload. Implementations should follow = the
= procedures from = [RFC8085] to determine the maximum size used for any
= LISP control = message.
=
The UDP = checksum is computed and set to non-zero for all messages = The UDP checksum is computed and set to = non-zero for all messages
sent to or = from port 4342. It MUST be checked on receipt, and if the = sent to or from port 4342. It MUST be = checked on receipt, and if the
checksum = fails, the control message MUST be dropped [RFC1071]. checksum fails, the control message MUST be dropped = [RFC1071].
=
The format of = control messages includes the UDP header so the The format of control messages includes the UDP = header so the
checksum and = length fields can be used to protect and delimit message = checksum and length fields can be used to = protect and delimit message
= boundaries. boundaries.
=
5.1. LISP = Control Packet Type Allocations 5.1. = LISP Control Packet Type Allocations
=
skipping to = change at = page 11, line 13 =C2=B6 = skipping to change at page 11, line = 13 =C2=B6
Request = (SMRs) Section 6.1 for details. = Request (SMRs) Section 6.1 for details.
=
p: This is the = PITR bit. This bit is set to 1 when a PITR sends a p: This is the PITR bit. This bit is set to 1 when a = PITR sends a
= Map-Request. = Map-Request.
=
s: This is the = SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 = when an xTR is
sending a = Map-Request in response to a received SMR-based Map- sending a Map-Request in response to a received = SMR-based Map-
= Request. Request.
=
m: This is the = LISP mobile-node m-bit. This bit is set by xTRs that m: This is the LISP mobile-node m-bit. This bit is = set by xTRs that
operate = as a mobile node as defined in [I-D.ietf-lisp-mn]. operate as a mobile node as defined in = [I-D.ietf-lisp-mn]. This
= bit can be = ignored if an implementation does not support
= = [I-D.ietf-lisp-mn].
=
I: This is the = xTR-ID bit. When this bit is set, what is appended to I: This is the xTR-ID bit. When this bit is set, = what is appended to
the = Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage = the Map-Request is a 128-bit xTR = router-ID. See LISP PubSub usage
= procedures in [I-D.ietf-lisp-pubsub] for details. procedures in [I-D.ietf-lisp-pubsub] for details. = This bit can be
= ignored if an = implementation does not support
= = [I-D.ietf-lisp-pubsub].
=
Rsvd: This = field MUST be set to 0 on transmit and MUST be ignored on = Rsvd: This field MUST be set to 0 on = transmit and MUST be ignored on
= receipt. receipt.
=
L: This is the = local-xtr bit. It is used by an xTR in a LISP site to L: This is the local-xtr bit. It is used by an xTR = in a LISP site to
tell other = xTRs in the same site that it is part of the RLOC-set tell other xTRs in the same site that it is part = of the RLOC-set
for the = LISP site. The L-bit is set to 1 when the RLOC is the for the LISP site. The L-bit is set to 1 when the = RLOC is the
sender's IP = address. sender's IP = address.
=
D: This is the = dont-map-reply bit. It is used in the SMR procedure D: This is the dont-map-reply bit. It is used in the = SMR procedure
=
skipping to = change at = page 11, line 48 =C2=B6 = skipping to change at page 12, line 4 =C2=B6
value of 0, = there is 1 ITR-RLOC address encoded; for a value of 1, value of 0, there is 1 ITR-RLOC address encoded; = for a value of 1,
there are 2 = ITR-RLOC addresses encoded, and so on up to 31, which there are 2 ITR-RLOC addresses encoded, and so on = up to 31, which
encodes a = total of 32 ITR-RLOC addresses. = encodes a total of 32 ITR-RLOC addresses.
=
Record Count: = This is the number of records in this Map-Request Record Count: This is the number of records in this = Map-Request
message. A = record is comprised of the portion of the packet that message. A record is comprised of the portion of = the packet that
is labeled = 'Rec' above and occurs the number of times equal to is labeled 'Rec' above and occurs the number of = times equal to
Record = Count. For this version of the protocol, a receiver MUST = Record Count. For this version of the = protocol, a receiver MUST
accept and = process Map-Requests that contain one or more records, accept and process Map-Requests that contain one = or more records,
but a = sender MUST only send Map-Requests containing one record. = but a sender MUST only send Map-Requests = containing one record.
Support = for requesting multiple EIDs in a single = Map-Request =
= Support for processing multiple EIDs in a single = Map-Request
message = will be specified in a future version of the protocol. message will be specified in a future version of = the protocol.
=
Nonce: This = is an 8-octet random value created by the sender of the = Nonce: This is an 8-octet random value = created by the sender of the
= Map-Request. This nonce will be returned in the Map-Reply. = The Map-Request. This nonce = will be returned in the Map-Reply. The
security of = the LISP mapping protocol critically depends on the security of the LISP mapping protocol critically = depends on the
strength of = the nonce in the Map-Request message. The nonce strength of the nonce in the Map-Request message. = The nonce
SHOULD be = generated by a properly seeded pseudo-random (or strong = SHOULD be generated by a properly seeded = pseudo-random (or strong
random) = source. See [RFC4086] for advice on generating security- = random) source. See [RFC4086] for advice = on generating security-
sensitive = random data. sensitive random = data.
=
=
skipping to = change at = page 13, line 41 =C2=B6 = skipping to change at page 13, line = 43 =C2=B6
=
Map-Requests = can also be LISP encapsulated using UDP destination Map-Requests can also be LISP encapsulated using UDP = destination
port 4342 with = a LISP Type value set to "Encapsulated Control port 4342 with a LISP Type value set to "Encapsulated = Control
Message", when = sent from an ITR to a Map-Resolver. Likewise, Map- Message", when sent from an ITR to a Map-Resolver. = Likewise, Map-
Requests are = LISP encapsulated the same way from a Map-Server to an Requests are LISP encapsulated the same way from a = Map-Server to an
ETR. Details = on Encapsulated Map-Requests and Map-Resolvers can be ETR. Details on Encapsulated Map-Requests and = Map-Resolvers can be
found in = Section 5.8. found in Section = 5.8.
=
Map-Requests = MUST be rate-limited. It is RECOMMENDED that a Map- Map-Requests MUST be rate-limited. It is RECOMMENDED = that a Map-
Request for = the same EID-Prefix be sent no more than once per second. = Request for the same EID-Prefix be sent no = more than once per second.
= However, = recommendations from [RFC8085] SHOULD be considered.
=
An ITR that is = configured with mapping database information (i.e., it An ITR that is configured with mapping database = information (i.e., it
is also an = ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings = in a Map-
Request. When = an ETR configured to accept and verify such Request. When an ETR configured to accept and verify = such
"piggybacked" = mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a = Map-Request and it does
not have this = mapping in the Map-Cache, it MAY originate a "verifying = not have this mapping in the Map-Cache, it = MAY originate a "verifying
Map-Request", = addressed to the map-requesting ITR and the ETR MAY add = Map-Request", addressed to the = map-requesting ITR and the ETR MAY add
a Map-Cache = entry. If the ETR has a Map-Cache entry that matches the = a Map-Cache entry. If the ETR has a = Map-Cache entry that matches the
"piggybacked" = EID and the RLOC is in the Locator-Set for the entry, "piggybacked" EID and the RLOC is in the Locator-Set = for the entry,
then it MAY = send the "verifying Map-Request" directly to the then it MAY send the "verifying Map-Request" directly = to the
=
skipping to = change at = page 19, line 49 =C2=B6 = skipping to change at page 19, line = 49 =C2=B6
=
When an EID = moves out of a LISP site [I-D.ietf-lisp-eid-mobility], When an EID moves out of a LISP site = [I-D.ietf-lisp-eid-mobility],
the database = mapping system may have overlapping EID-prefixes. Or the database mapping system may have overlapping = EID-prefixes. Or
when a LISP = site is configured with multiple sets of ETRs that when a LISP site is configured with multiple sets of = ETRs that
support = different EID-prefix lengths, the database mapping system may = support different EID-prefix lengths, the = database mapping system may
have = overlapping EID-prefixes. When overlapping EID-prefixes exist, = have overlapping EID-prefixes. When = overlapping EID-prefixes exist,
a Map-Request = with an EID that best matches any EID-Prefix MUST be a Map-Request with an EID that best matches any = EID-Prefix MUST be
returned in a = single Map-Reply message. For instance, if an ETR had returned in a single Map-Reply message. For = instance, if an ETR had
database = mapping entries for EID-Prefixes: = database mapping entries for EID-Prefixes:
=
10.0.0.0/8 = 2001:db8::/16
10.1.0.0/16 = 2001:db8:1::/24
10.1.1.0/24 = 2001:db8:1:1::/32
10.1.2.0/24 = 2001:db8:1:2::/32
=
A = Map-Request for EID 10.1.1.1 would cause a = Map-Reply with a record A = Map-Request for EID 2001:db8:1:1::1 would = cause a Map-Reply with a
count of 1 = to be returned with a mapping record EID-Prefix of record count of 1 to be returned with a mapping = record EID-Prefix of
10.1.1.0/24. = 2001:db8:1:1::/32.
=
A = Map-Request for EID 10.1.5.5 would cause a = Map-Reply with a record A = Map-Request for EID 2001:db8:1:5::5 would = cause a Map-Reply with a
count of 3 = to be returned with mapping records for EID-Prefixes = record count of 3 to be returned with mapping records for EID-
10.1.0.0/16, 10.1.1.0/24, and = 10.1.2.0/24. Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, = 2001:db8:1:2::/32. Note
= filling out the /16 = with more-specifics that exist in the mapping
= = system.
=
Note that not = all overlapping EID-Prefixes need to be returned but Note that not all overlapping EID-Prefixes need to be = returned but
only the = more-specific entries (note that in the second example above = only the more-specific entries (note that in = the second example above
10.0.0.0/8 was not returned for requesting EID = 10.1.5.5) for the 2001:db8::/16 was not = returned for requesting EID 2001:db8:1:5::5)
matching = EID-Prefix of the requesting EID. When more than one EID- for = the matching EID-Prefix of the requesting EID. When more than
Prefix is returned, all SHOULD use the same = Time to Live value so one EID-Prefix is returned, all SHOULD use the same = Time to Live
they can all = time out at the same time. When a more-specific = EID- value so they can all = time out at the same time. When a more-
Prefix is received later, its Time to Live = value in the Map-Reply specific EID-Prefix is received later, its = Time to Live value in the
record can = be stored even when other less-specific entries exist. Map-Reply record can be stored even when other = less-specific entries
When a = less-specific EID-Prefix is received later, its Map-Cache = exist. When a less-specific EID-Prefix is received later, its Map-
expiration = time SHOULD be set to the minimum expiration time of any = Cache = expiration time SHOULD be set to the minimum expiration time of
= more-specific EID-Prefix in the Map-Cache. This is done so the = any more-specific EID-Prefix in the = Map-Cache. This is done so the
integrity of = the EID-Prefix set is wholly maintained and so no more- = integrity of the EID-Prefix set is wholly = maintained and so no more-
specific = entries are removed from the Map-Cache while keeping less- = specific entries are removed from the = Map-Cache while keeping less-
specific = entries. specific entries.
=
Map-Replies = SHOULD be sent for an EID-Prefix no more often than once = Map-Replies SHOULD be sent for an EID-Prefix = no more often than once
per second to = the same requesting router. For scalability, it is per second to the same requesting router. For = scalability, it is
expected that = aggregation of EID addresses into EID-Prefixes will expected that aggregation of EID addresses into = EID-Prefixes will
allow one = Map-Reply to satisfy a mapping for the EID addresses in the = allow one Map-Reply to satisfy a mapping for = the EID addresses in the
prefix range, = thereby reducing the number of Map-Request messages. prefix range, thereby reducing the number of = Map-Request messages.
=
=
skipping = to change at page 23, line = 30 =C2=B6 = skipping to change at page 23, line = 30 =C2=B6
T: This is the = use-TTL for timeout bit. When set to 1, the xTR wants T: This is the use-TTL for timeout bit. When set to = 1, the xTR wants
the = Map-Server to time out registrations based on the value in the = the Map-Server to time out registrations = based on the value in the
"Record = TTL" field of this message. = "Record TTL" field of this message.
=
a: This is the = merge-request bit. When set to 1, the xTR requests to a: This is the merge-request bit. When set to 1, the = xTR requests to
merge = RLOC-records from different xTRs registering the same EID- = merge RLOC-records from different xTRs = registering the same EID-
record. = See signal-free multicast [RFC8378] for one use case record. See signal-free multicast [RFC8378] for = one use case
= example. example.
=
m: This is the = mobile-node bit. When set to 1, the registering xTR m: This is the mobile-node bit. When set to 1, the = registering xTR
supports = the procedures in [I-D.ietf-lisp-mn]. = supports the procedures in [I-D.ietf-lisp-mn]. This bit can be
= ignored if an = implementation does not support [I-D.ietf-lisp-mn]
=
M: This is the = want-map-notify bit. When set to 1, an ETR is M: This is the want-map-notify bit. When set to 1, = an ETR is
requesting = a Map-Notify message to be returned in response to requesting a Map-Notify message to be returned in = response to
sending a = Map-Register message. The Map-Notify message sent by a = sending a Map-Register message. The = Map-Notify message sent by a
Map-Server = is used to acknowledge receipt of a Map-Register Map-Server is used to acknowledge receipt of a = Map-Register
= message. message.
=
Record Count: = This is the number of records in this Map-Register Record Count: This is the number of records in this = Map-Register
message. A = record is comprised of that portion of the packet message. A record is comprised of that portion of = the packet
labeled = 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of = times equal to
=
skipping = to change at page 26, line = 5 =C2=B6 = skipping to change at page 26, line = 5 =C2=B6
Type: 4/5 = (Map-Notify/Map-Notify-Ack) Type: = 4/5 (Map-Notify/Map-Notify-Ack)
=
The Map-Notify = message has the same contents as a Map-Register The Map-Notify message has the same contents as a = Map-Register
message. See = the Map-Register section for field descriptions. message. See the Map-Register section for field = descriptions.
=
The = Map-Notify-Ack message has the same contents as a Map-Notify = The Map-Notify-Ack message has the same = contents as a Map-Notify
message. It = is used to acknowledge the receipt of a Map-Notify and message. It is used to acknowledge the receipt of a = Map-Notify and
for the sender = to stop retransmitting a Map-Notify with the same for the sender to stop retransmitting a Map-Notify = with the same
= nonce. nonce.
=
= A sender of an = unsolicited Map-Notify message (one that is not used
= as an acknowledgment = to a Map-Register message) will follow the
= Congestion Control = And Relability Guideline sections of [RFC8085]. A
= Map-Notify is = retransmitted until a Map-Notify-Ack with the same
= nonce from ther = Map-Notify message is received. If a Map-Notify-Ack
= is never received, a = log message is issued. An implementation SHOULD
= retransmit up to 3 = times at 3 second retransmission intervals, after
= which time the = retransmission interval is exponentially backed-off
= for anthoer 3 = retransmission attempts. After this time, the Map-
= Notify sender can = only get the RLOC-set change by later querying the
= mapping system or by = RLOC-probing one of the RLOCs of the existing
= cached RLOC-set to = get the new RLOC-set.
= =
5.8. = Encapsulated Control Message Format 5.8.= Encapsulated Control Message Format
=
An = Encapsulated Control Message (ECM) is used to encapsulate = control An Encapsulated Control = Message (ECM) is used to encapsulate control
packets sent = between xTRs and the mapping database system. packets sent between xTRs and the mapping database = system.
=
0 = 1 2 3 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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = IPv4 or IPv6 Header | / | IPv4 or IPv6 Header = |
OH | = (uses RLOC addresses) | OH | (uses RLOC addresses) = |
=
skipping = to change at page 29, line = 16 =C2=B6 = skipping to change at page 30, line = 16 =C2=B6
accept the = Map-Request. accept the = Map-Request.
=
3. The remote = ITR MUST rate-limit the Map-Request until it gets a 3. The remote ITR MUST rate-limit the Map-Request = until it gets a
Map-Reply = while continuing to use the cached mapping. When Map-Reply while continuing to use the cached = mapping. When
= Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, = Map-Versioning as described in = [I-D.ietf-lisp-6834bis] is used,
an SMR = sender can detect if an ITR is using the most up-to-date = an SMR sender can detect if an ITR is = using the most up-to-date
database = mapping. database = mapping.
=
4. The ETRs = at the site with the changed mapping will reply to the 4. The ETRs at the site with the changed mapping = will reply to the
= Map-Request with a Map-Reply message that has a nonce from the = Map-Request with a Map-Reply message = that has a nonce from the
= SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- SMR-invoked Map-Request. The Map-Reply messages = MUST be rate-
limited. This is important to avoid Map-Reply = implosion. limited according to procedures in [RFC8085]. = This is important
= to avoid Map-Reply implosion.
=
5. The ETRs = at the site with the changed mapping record the fact 5. The ETRs at the site with the changed mapping = record the fact
that the = site that sent the Map-Request has received the new that the site that sent the Map-Request has = received the new
mapping = data in the Map-Cache entry for the remote site so the mapping data in the Map-Cache entry for the = remote site so the
= Locator-Status-Bits are reflective of the new mapping for = packets Locator-Status-Bits are = reflective of the new mapping for packets
going to = the remote site. The ETR then stops sending SMR going to the remote site. The ETR then stops = sending SMR
= messages. messages.
=
For security = reasons, an ITR MUST NOT process unsolicited Map- For security reasons, an ITR MUST NOT process = unsolicited Map-
Replies. To = avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a = third party, a
=
skipping = to change at page 35, line = 35 =C2=B6 = skipping to change at page 36, line = 35 =C2=B6
1-minute = TTL. 1-minute TTL.
=
If the = EID-prefix is either registered or not registered to the = If the EID-prefix is either registered or = not registered to the
mapping system = and there is a policy in the Map-Server to have the mapping system and there is a policy in the = Map-Server to have the
requestor drop = packets for the matching EID-prefix, then a Drop/ requestor drop packets for the matching EID-prefix, = then a Drop/
Policy-Denied = action is returned. If the EID-prefix is registered or = Policy-Denied action is returned. If the = EID-prefix is registered or
not registered = and there is a authentication failure, then a Drop/ not registered and there is a authentication failure, = then a Drop/
= Authentication- failure action is returned. If either of these = Authentication- failure action is returned. = If either of these
actions result = as a temporary state in policy or authentication then actions result as a temporary state in policy or = authentication then
a = Send-Map-Request action with 1-minute TTL MAY be returned to = allow a Send-Map-Request action = with 1-minute TTL MAY be returned to allow
the reqeustor to retry the Map-Request. = the requestor = to retry the Map-Request.
=
If any of the = registered ETRs for the EID-Prefix have requested proxy = If any of the registered ETRs for the = EID-Prefix have requested proxy
reply service, = then the Map-Server answers the request instead of reply service, then the Map-Server answers the = request instead of
forwarding it. = It returns a Map-Reply with the EID-Prefix, RLOCs, forwarding it. It returns a Map-Reply with the = EID-Prefix, RLOCs,
and other = information learned through the registration process. and other information learned through the = registration process.
=
If none of the = ETRs have requested proxy reply service, then the Map- If none of the ETRs have requested proxy reply = service, then the Map-
Server = re-encapsulates and forwards the resulting Encapsulated Map- = Server re-encapsulates and forwards the = resulting Encapsulated Map-
Request to one = of the registered ETRs. It does not otherwise alter Request to one of the registered ETRs. It does not = otherwise alter
the = Map-Request, so any Map-Reply sent by the ETR is returned to = the the Map-Request, so any = Map-Reply sent by the ETR is returned to the
=
skipping = to change at page 37, line = 43 =C2=B6 = skipping to change at page 38, line = 43 =C2=B6
10. Changes = since RFC 6833 10. Changes since RFC = 6833
=
For = implementation considerations, the following changes have been = For implementation considerations, the = following changes have been
made to this = document since RFC 6833 was published: = made to this document since RFC 6833 was published:
=
o A = Map-Notify-Ack message is added in this document to provide = o A Map-Notify-Ack message is added in this = document to provide
reliability = for Map-Notify messages. Any receiver of a Map-Notify reliability for Map-Notify messages. Any receiver = of a Map-Notify
message = must respond with a Map-Notify-Ack message. Map-Servers = message must respond with a = Map-Notify-Ack message. Map-Servers
who are = senders of Map-Notify messages, must queue the Map-Notify = who are senders of Map-Notify messages, = must queue the Map-Notify
contents = until they receive a Map-Notify-Ack with the nonce used = contents until they receive a = Map-Notify-Ack with the nonce used
in the = Map-Notify message. in the = Map-Notify message. Note that implementations = for Map-
= Notify-Ack = support already exist and predate this document.
=
o This = document is incorporating the codepoint for the Map-Referral = o This document is incorporating the = codepoint for the Map-Referral
message = from the LISP-DDT specification [RFC8111] to indicate that = message from the LISP-DDT specification = [RFC8111] to indicate that
a = Map-Server must send the final Map-Referral message when it = a Map-Server must send the final = Map-Referral message when it
= participates in the LISP-DDT mapping system procedures. = participates in the LISP-DDT mapping = system procedures.
=
o The "m", = "I", "L", and "D" bits are added to the Map-Request o The "m", "I", "L", and "D" bits are added to the = Map-Request
message. = See Section 5.3 for details. = message. See Section 5.3 for details.
=
o The "S", = "I", "E", "T", "a", and "m" bits are added to the Map- o The "S", "I", "E", "T", "a", and "m" bits are = added to the Map-
=
skipping = to change at page 40, line = 35 =C2=B6 = skipping to change at page 41, line = 35 =C2=B6
12.1. Normative = References 12.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-16 = (work in progress), = (LISP)", draft-ietf-lisp-rfc6830bis-17 = (work in progress),
= August 2018. September = 2018.
=
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
[RFC4868] = Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- = [RFC4868] Kelly, S. and S. Frankel, "Using = HMAC-SHA-256, HMAC-SHA-
= 384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC = 4868,
DOI = 10.17487/RFC4868, May 2007, = DOI 10.17487/RFC4868, May 2007,
= <https://www.rfc-editor.org/info/rfc4868>. = <https://www.rfc-editor.org/info/rfc4868>.
=
= [RFC8085] Eggert, = L., Fairhurst, G., and G. Shepherd, "UDP Usage
= = Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
= March = 2017, <https://www.rfc-editor.org/info/rfc8085>.
= =
12.2. = Informative References 12.2. = Informative References
=
[AFI] = IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY = [AFI] IANA, "Address Family Identifier = (AFIs)", ADDRESS FAMILY
= NUMBERS http://www.iana.org/assignments/address-family- = NUMBERS = http://www.iana.org/assignments/address-family-
= numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, = Febuary 2007.
=
= [GTP-3GPP] [GTP-3GPP]
= 3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) = Tunnelling
= Protocol User Plane (GTPv1-U)", TS.29.281 Protocol User Plane (GTPv1-U)", = TS.29.281
= https://portal.3gpp.org/desktopmodules/Specifications/ = https://portal.3gpp.org/desktopmodules/Specifications/
=
skipping = to change at page 45, line = 19 =C2=B6 = skipping to change at page 46, line = 19 =C2=B6
Fabio Maino, = and members of the lisp@ietf.org mailing list for their = Fabio Maino, and members of the = lisp@ietf.org mailing list for their
feedback and = helpful suggestions. feedback and = helpful suggestions.
=
Special thanks = are due to Noel Chiappa for his extensive work and Special thanks are due to Noel Chiappa for his = extensive work and
thought about = caching in Map-Resolvers. thought = about caching in Map-Resolvers.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6833bis-14 B.1. = Changes to draft-ietf-lisp-rfc6833bis-15
=
= o Posted = mid-September 2018.
=
= o Changes to = reflect comments from Colin and Mirja.
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-14
=
o Posted = September 2018. o Posted September = 2018.
=
o Changes to = reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, = and Secdir
= reviews. reviews.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-13 B.3. Changes to = draft-ietf-lisp-rfc6833bis-13
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-12 B.4. Changes to = draft-ietf-lisp-rfc6833bis-12
=
o Posted late = July 2018. o Posted late July = 2018.
=
o Moved = RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative = References.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-11 B.5. Changes to = draft-ietf-lisp-rfc6833bis-11
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for = RFC status and
ran through = IDNITs again. ran through IDNITs = again.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-10 B.6. Changes to = draft-ietf-lisp-rfc6833bis-10
=
o Posted = after LISP WG at IETF week March. o = Posted after LISP WG at IETF week March.
=
o Move AD = field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM = packet format
description = section. description = section.
=
o Say more = about when the new Drop actions should be sent. o Say more about when the new Drop actions should be = sent.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-09 B.7. Changes to = draft-ietf-lisp-rfc6833bis-09
=
o Posted = March IETF week 2018. o Posted = March IETF week 2018.
=
o Fixed = editorial comments submitted by document shepherd Luigi = o Fixed editorial comments submitted by = document shepherd Luigi
= Iannone. Iannone.
=
B.7. Changes to = draft-ietf-lisp-rfc6833bis-08 B.8. Changes to = draft-ietf-lisp-rfc6833bis-08
=
o Posted = March 2018. o Posted March = 2018.
=
o Added = RLOC-probing algorithm. o Added = RLOC-probing algorithm.
=
o Added = Solicit-Map Request algorithm. o = Added Solicit-Map Request algorithm.
=
o Added = several mechanisms (from 6830bis) regarding Routing Locator = o Added several mechanisms (from 6830bis) = regarding Routing Locator
= Reachability. = Reachability.
=
o Added port = 4342 to IANA Considerations section. = o Added port 4342 to IANA Considerations section.
=
B.8. Changes to = draft-ietf-lisp-rfc6833bis-07 B.9. Changes to = draft-ietf-lisp-rfc6833bis-07
=
o Posted = December 2017. o Posted December = 2017.
=
o Make it = more clear in a couple of places that RLOCs are used to = o Make it more clear in a couple of places = that RLOCs are used to
locate ETRs = more so than for Map-Server Map-Request forwarding. locate ETRs more so than for Map-Server = Map-Request forwarding.
=
o Make it = clear that "encapsualted" for a control message is an ECM = o Make it clear that "encapsualted" for a = control message is an ECM
based = message. based message.
=
o Make it = more clear what messages use source-port 4342 and which = o Make it more clear what messages use = source-port 4342 and which
=
skipping = to change at page 47, line = 13 =C2=B6 = skipping to change at page 48, line = 16 =C2=B6
Can use = othe AFIs then IPv4 and IPv6. = Can use othe AFIs then IPv4 and IPv6.
=
o Many = editorial changes to clarify text. = o Many editorial changes to clarify text.
=
o Changed = some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to = capitalized.
=
o Added = definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply = messages.
=
o Ran = document through IDNITs. o Ran = document through IDNITs.
=
B.9. Changes to = draft-ietf-lisp-rfc6833bis-06 B.10. Changes to = draft-ietf-lisp-rfc6833bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Spec the = I-bit to include the xTR-ID in a Map-Request message to = o Spec the I-bit to include the xTR-ID in a = Map-Request message to
be = consistent with the Map-Register message and to anticipate the = be consistent with the Map-Register = message and to anticipate the
= introduction of pubsub functionality to allow Map-Requests to = introduction of pubsub functionality to = allow Map-Requests to
subscribe = to RLOC-set changes. subscribe = to RLOC-set changes.
=
o Updated = references for individual submissions that became working = o Updated references for individual = submissions that became working
group = documents. group = documents.
=
o Updated = references for working group documents that became RFCs. = o Updated references for working group = documents that became RFCs.
=
B.10. Changes to = draft-ietf-lisp-rfc6833bis-05 B.11. Changes to = draft-ietf-lisp-rfc6833bis-05
=
o Posted May = 2017. o Posted May 2017.
=
o Update IANA = Considerations section based on new requests from this o Update IANA Considerations section based on new = requests from this
document = and changes from what was requested in [RFC6830]. document and changes from what was requested in = [RFC6830].
=
B.11. Changes to = draft-ietf-lisp-rfc6833bis-04 B.12. Changes to = draft-ietf-lisp-rfc6833bis-04
=
o Posted May = 2017. o Posted May 2017.
=
o Clarify how = the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in = Map-Register and Map-
Notify = messages. Break the 16-bit field into a 8-bit Key-ID field = Notify messages. Break the 16-bit field = into a 8-bit Key-ID field
and a 8-bit = Algorithm-ID field. and a 8-bit = Algorithm-ID field.
=
o Move the = Control-Plane codepoints from the IANA Considerations o Move the Control-Plane codepoints from the IANA = Considerations
section of = RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations = section of this
= document. document.
=
o In the = "LISP Control Packet Type Allocations" section, indicate = o In the "LISP Control Packet Type = Allocations" section, indicate
how message = Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how = experimental RFC8113
sub-types = should be requested. sub-types = should be requested.
=
B.12. Changes to = draft-ietf-lisp-rfc6833bis-03 B.13. Changes to = draft-ietf-lisp-rfc6833bis-03
=
o Posted = April 2017. o Posted April = 2017.
=
o Add types = 9-14 and specify they are not assigned. = o Add types 9-14 and specify they are not assigned.
=
o Add the = "LISP Shared Extension Message" type and point to RFC8113. = o Add the "LISP Shared Extension Message" = type and point to RFC8113.
=
B.13. Changes to = draft-ietf-lisp-rfc6833bis-02 B.14. Changes to = draft-ietf-lisp-rfc6833bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Clarify = that the LISP Control-Plane document defines how the LISP = o Clarify that the LISP Control-Plane = document defines how the LISP
Data-Plane = uses Map-Requests with either the SMR-bit set or the Data-Plane uses Map-Requests with either the = SMR-bit set or the
P-bit set = supporting mapping updates and RLOC-probing. Indicating = P-bit set supporting mapping updates and = RLOC-probing. Indicating
that other = Data-Planes can use the same mechanisms or their own that other Data-Planes can use the same mechanisms = or their own
defined = mechanisms to achieve the same functionality. defined mechanisms to achieve the same = functionality.
=
B.14. Changes to = draft-ietf-lisp-rfc6833bis-01 B.15. Changes to = draft-ietf-lisp-rfc6833bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Remove = references to self. o Remove = references to self.
=
o Change = references from RFC6830 to RFC6830bis. = o Change references from RFC6830 to RFC6830bis.
=
o Add two new = action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has = posted to the LISP
WG mailing = list. WG mailing list.
=
o In intro = section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to = I-D.ietf-lisp-introduction.
=
o Removed = Open Issues section and references to "experimental". o Removed Open Issues section and references to = "experimental".
=
B.15. Changes to = draft-ietf-lisp-rfc6833bis-00 B.16. Changes to = draft-ietf-lisp-rfc6833bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6833-00 = individual submission. No other changes made. -rfc6833-00 individual submission. No other = changes made.
=
B.16. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.17. Changes to = draft-farinacci-lisp-rfc6833bis-00
=
o Posted = November 2016. o Posted November = 2016.
=
o This is the = initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into = RFC 6833bis.
=
o The = document name has changed from the "Locator/ID Separation = o The document name has changed from the = "Locator/ID Separation
Protocol = (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the = "Locator/ID
Separation = Protocol (LISP) Control-Plane". = Separation Protocol (LISP) Control-Plane".
=
o The = fundamental change was to move the Control-Plane messages from = o The fundamental change was to move the = Control-Plane messages from
 End of changes. 39 change blocks. 
96 lines changed or = deleted 133 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_C7BCB5A8-EDC8-4A6E-BBFD-3081E939D131 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 14, 2018, at 7:47 AM, Benjamin Kaduk wrote: >=20 > On Wed, Sep 12, 2018 at 12:44:36PM +0200, Mirja Kuehlewind (IETF) = wrote: >>=20 >>> Am 11.09.2018 um 20:13 schrieb Dino Farinacci : >>>=20 >>>>=20 >>>> Further comments: >>>>=20 >>>> 1) The example given in 5.5 should probably used IPv6 addresses and = use the IP >>>> address space that is reserved for documentation purposes. >>>=20 >>> I disagree. I think its simpler with IPv4 addresses and shouldn=E2=80=99= t matter. We want this complex concept to come across as clear as = possible. And I believe IPv6 doesn=E2=80=99t do that. This is not a v4 = versus v6 response. It is a notation preference. >>=20 >> I will let the INT AD to give further guidance, however, general = guidance in the iETF is that IPV6 should also be provided in examples to = avoid a bias towards IPv4. I disagree that an IPv6 example would be an = more complicated than an IPv4 example. >=20 > There is an IAB statement that is relevant here > (https://www.iab.org/2016/11/07/iab-statement-on-ipv6/): >=20 > [...] > We recommend that all networking standards assume the use of IPv6, and = be > written so they do not require IPv4. We recommend that existing = standards > be reviewed to ensure they will work with IPv6, and use IPv6 examples. > [...] >=20 > -Benjamin --Apple-Mail=_C7BCB5A8-EDC8-4A6E-BBFD-3081E939D131-- From nobody Fri Sep 14 09:59:57 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3C412F1A5; Fri, 14 Sep 2018 09:59:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uwhzw4Aj2nWv; Fri, 14 Sep 2018 09:59:53 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 101C412F1A2; Fri, 14 Sep 2018 09:59:53 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id ba4-v6so4469006plb.11; Fri, 14 Sep 2018 09:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mo54qbWH0tRtE4JAYcaR98ceC89lF8vUl+TanjlalTs=; b=A8k6A832onnetWSS3kBKVwFnsWOo6mPVNwYedkz9o/wBn6SVSeoime3CwQUDSiOnss XmDoUkH28ZfKIHsWaNL9+urZXEf1GEj1iB/VsA5tcjpwE79XRDAsx3wuE/d//9zEM3A/ f2l3VBOluiiA3TtNV4DyLYMEvJz8qsYkTepeavcl56RLL/XE6ZSNeLbFjW9i2/HPio4P AhQAB4350AAPi/JQlbGG0dqxoGbkchZIQwpbNzOOAeDHBVZ7yU77VUgm7rK57BUZrkMF +HAHgbo7B3GRtRGXJKstjh0Wew6uiaH+uP5KWkxAr8cZ3UU2FTcEGX107FnUrbnK9A/Q Azjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mo54qbWH0tRtE4JAYcaR98ceC89lF8vUl+TanjlalTs=; b=OKnQl51BF+Lc1xAB6SdOUn66tHmVSbYCYDFxYzKzfH/UcXBUv07HO4XZHmO0SGR/TF Jyur3IcwqYcFs14ZuE5CVmTf9/W/zM0cdnaDRPOZiY3vZVDA2hnoKMybsr7pgn4/9A1n qbjqcAKaEGEv+ze+vTTf4u/RxPaKQHxu7zWxLsUqyFCNJN9wiegIH09oJpNV6E9M6lNp FgTqA1sVC8GIRLvQSOmrfQOA+Ivk7U3X3UIQfYdZRg7/aaIqnc6ZP/44TNFrPJbhAvFU XQG9hdFyRBNpuP4a/z97irnqMq6UiD5CAm4PpPB0nG6is/8XcqqiTOjVvlwGGKWTgKUF g/YA== X-Gm-Message-State: APzg51CiLNg4ru2JBJtlWCsUuePkJg+f3eJgZCx9SecnrMruWMFCKVPT 8V/p3d5FViPm2vp7yWBZ79E= X-Google-Smtp-Source: ANB0VdajRObVIN//dyk8GgKn2rqzjZ2ApTf+Zw52gxy3P8IWvrOyHtA6W8hWtn5nh7oabGGyYJ9rXQ== X-Received: by 2002:a17:902:543:: with SMTP id 61-v6mr13335471plf.126.1536944392529; Fri, 14 Sep 2018 09:59:52 -0700 (PDT) Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id y124-v6sm10886408pfg.63.2018.09.14.09.59.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Sep 2018 09:59:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Fri, 14 Sep 2018 09:59:49 -0700 Cc: "BRUNGARD, DEBORAH A" , IETF SecDir , "draft-ietf-lisp-rfc6830bis.all@ietf.org" , IETF Discussion Mailing List , "lisp@ietf.org list" , Benjamin Kaduk , =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Transfer-Encoding: quoted-printable Message-Id: <022C3FE7-B146-44BE-9625-EC9FF3637C49@gmail.com> References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com> <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com> <5655CB57-721B-4F9C-8F7F-0E38FBA60E0C@gmail.com> To: Kyle Rose X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 14 Sep 2018 16:59:56 -0000 The SAAG has helped the LISP WG with RFC8061 (data-plane). And Brian = Weiss and Dan Harkins were authors/reviewers. As for the control-plane, draft-ietf-lisp-sec has been around and = implmented by cisco (in 3 implementations). RFC8111 (LISP-DDT) has been = around as well for a while, a pilot network deployed using it, and cisco = has an implementation of LISP-DDT-SEC. Draft draft-farinacci-lisp-ecdsa = is relatively new, necessary for IoT deployments. I have done an = implementation of it. I don=E2=80=99t know if that helps but focusing on = those 3 documents can clearly explain (in detail) the security = mechanisms in place. Your comment is noted about not seeing TLS or DTLS in = draft-ietf-lisp-sec but we had always intended it to be in there. I=E2=80=99= m not sure (I thought it was in) if it was removed for some reason. The = authors can comment about that. Dino > On Sep 14, 2018, at 9:29 AM, Kyle Rose wrote: >=20 > My response is that while I suspect based on the conversation between = myself and Dino that LISP's security model probably adequately protects = mapping system integrity, my confidence in that judgment is low because = the information I need for a security review I can't find in the drafts = without reading every LISP-related document in detail, a time commitment = I simply can't justify. It's possible there's someone else in the = security directorate who knows more about the details of LISP and so = would be able to much more easily answer some of these questions with = confidence; if so, I would recommend that you ask them to take a look. = I'm unwilling to say "LGTM" simply because I can't find a problem in the = time I've allocated. >=20 > Kyle >=20 >=20 > On Tue, Sep 11, 2018 at 5:55 PM, BRUNGARD, DEBORAH A = wrote: > Thanks much Kyle for your comments and Dino for resolving! >=20 > Cutting to the end where Dino asked for help- >=20 > -----Original Message----- > From: Dino Farinacci =20 > Sent: Tuesday, September 11, 2018 2:40 PM > To: Kyle Rose > Cc: IETF SecDir ; = draft-ietf-lisp-rfc6830bis.all@ietf.org; IETF Discussion Mailing List = ; lisp@ietf.org list ; Benjamin Kaduk = ; Mirja K=C3=BChlewind > Subject: Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15 >=20 >=20 > > What I might recommend is either an augmentation of, or a new = document analogous to (and informationally referencing), = draft-ietf-lisp-introduction that covers the expected security = properties of the overall design and the requirements for each of the = subcomponents in a way that someone can understand without referring to = any document other than the high-level architecture itself. = draft-ietf-lisp-introduction is actually quite good at getting the = general point of LISP across to someone new; I want to see something = similar for LISP's security model. I think that's going to be better = than inserting clarifying text here or there. I've actually read enough = of this stuff at this point that I'm not sure I can enumerate exactly = what's missing where. The threat model document could potentially be = folded into that, but it has to start by painting a picture of the = security that someone new to LISP can quickly understand. >=20 > I=E2=80=99ll yield to the WG to respond to this. >=20 > Dino >=20 > [deborah]=20 >=20 > It's difficult to do *one* overview document on an evolving = technology, especially if the intention is to provide reference to other = documents which are also evolving. Lisp-intro is already having its = problems and it is not published yet. >=20 > As Mark Nottingham noted in his "How to Read an RFC" blog, when = reading RFCs, for better or worse and the resulting frustration, it is = "necessary to read not only the relevant text but also anything that it = references": > https://www.ietf.org/blog/how-read-rfc/ >=20 > I'd suggest a wiki would be a better tool to capture this "overview" = informational material. Not only can the format be easier on the eye, it = can be a shared effort and timely updated. Similar to Benoit's work on = his YANG tree dependencies, it would be helpful if a working group = provided a working group tree of documents and it could even reference = other working group documents. >=20 >=20 From nobody Sun Sep 16 03:17:20 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2665A130E18 for ; Sun, 16 Sep 2018 03:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bartschnet.de 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 2m29SqliWs-S for ; Sun, 16 Sep 2018 03:17:18 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAE0130E10 for ; Sun, 16 Sep 2018 03:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bartschnet.de; s=2018030201; h=Content-Transfer-Encoding:MIME-Version:Date: Message-ID:To:Subject:From:content-disposition; bh=4zl+i3M+fLqBSRwrDvayZzU60Of/eovVNj9BKUWALyU=; b=jmLb+fU7NokGApG1BSJAu0RK15 KxnDC+GPeE9Kksjn852eKW8+M+ggbQRS5/OTBwJS9ROXjKJB5lbuK01O6+PMtPCFmxFNrM5tqlT7f lu7lXcWm1gbBnosDWY1Wk2bhToCqGyrMabTOf7Kul1XsRSOAnSV1yJgLaTaT/XWxQJTn7jx0OYsLi kZFVdZfZTODo5yDbpc/TQtOm3nDc4zM/zhFKHAjwWTnxfqsT6Vutg+LILbXyqznDRBRqUPVk/lhgg A7zdxxPSYn9OGCxiTNr++Li6Vaz0Ke0pe8T8xUPGNZfVQRfcS7PI5kiEfPlOJLFQBQFswrkBzfGHR aUTJCBQ0m+z/PLSirJjoinJOHls6xXi6IMgYCMFMeA/L0nxXmeaaNR4eA9OrXuZNiogw9oNTYJYn6 j4tAGzpfOpNu0/trCnRq6EIxxrvrFDY3iH+uvX94wJdPW/eHcc50SlHRM3ETW2CdFBwIG+OVBokZr rq0dWvBnTvmt8iGDSRIln+zuDouQXemhaSwIpNaxVEF852kKga82etKr+XhPMjBmS8IjGrjbpXEWJ JY/yCSnGOeVZxPgY8ku80cVBM2fkNr2WLp0ULISTj2XxZm/K4Geg+C6xYDKLUKJ7mn+kLpsm0zuxQ 2nVz/UdkRIYFegeZKQxA42a+ey+h5zRQMJCd73MxE=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1g1U79-0000Dh-7z with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for lisp@ietf.org; Sun, 16 Sep 2018 12:17:16 +0200 From: "Rene 'Renne' Bartsch, B.Sc. Informatics" To: lisp@ietf.org Message-ID: Date: Sun, 16 Sep 2018 12:17:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] draft-ietf-lisp-rfc6833bis-14 8.4.1 Anycast Map-Resolver Operation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2018 10:17:19 -0000 Hi, "draft-ietf-lisp-rfc6833bis-14" section "8.4.1 Anycast Map-Resolver Operation" says "Note that Map-Server associations with ETRs SHOULD NOT use anycast addresses, as registrations need to be established between an ETR and a specific set of Map-Servers, each identified by a specific registration association." In my opinion it is sensible to use anycast addresses for map servers of a distributed database for fail-over/load balancing cases and the "SHOULD NOT" is to limiting. Instead I suggest to encourage operators to specifially consider possible pitfalls of anycast operation. Regards, Renne From nobody Sun Sep 16 15:05:11 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB92B130DC4 for ; Sun, 16 Sep 2018 15:05:09 -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_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 9nW67F449_Ff for ; Sun, 16 Sep 2018 15:05:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685D5128B14 for ; Sun, 16 Sep 2018 15:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1201; q=dns/txt; s=iport; t=1537135507; x=1538345107; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9f2Hj5y7Vced637+8xQefobOn436UdqDRQBOFRhwgCs=; b=KW+YokntwWlAUHqfo485U4Ue3Qc4xyEAxF88fAxZ9ydt2js3j7kYdH0a X0KdIcKO/cB9zQyLbN3q0Dc9RpXgPExuoip+vpMeZr+5biKw83MnJP42f cX2cBj0d2bqEeXi6W6dGQyABHm9F2ZelXpQXNxiZAIf5B55z1pbieweY8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AABH0p5b/4oNJK1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYFQgghlfygKi32MKIFoJZZLgXoLGAuESQKDXiE0GAEDAQE?= =?us-ascii?q?CAQECbRwMhTgBAQEBAgEBATg0BAcFCwIBCBgeECcLJQIEDgWDIQGBeQgPpRS?= =?us-ascii?q?Ec4UNim0XgUE/gTkME4JMgxsBAQKBSRaDMoImApxECQKQExePDZQoAhEUgSU?= =?us-ascii?q?dOCcagRRwFTsqAYJBCYsMgR+EH28BjRKBHgEB?= X-IronPort-AV: E=Sophos;i="5.53,382,1531785600"; d="scan'208";a="452915166" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Sep 2018 22:05:06 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id w8GM56op008776 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Sep 2018 22:05:06 GMT Received: from xch-rcd-018.cisco.com (173.37.102.28) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 16 Sep 2018 17:05:05 -0500 Received: from xch-rcd-018.cisco.com ([173.37.102.28]) by XCH-RCD-018.cisco.com ([173.37.102.28]) with mapi id 15.00.1395.000; Sun, 16 Sep 2018 17:05:05 -0500 From: "Darrel Lewis (darlewis)" To: "Rene 'Renne' Bartsch, B.Sc. Informatics" CC: "Darrel Lewis (darlewis)" , "lisp@ietf.org" Thread-Topic: [lisp] draft-ietf-lisp-rfc6833bis-14 8.4.1 Anycast Map-Resolver Operation Thread-Index: AQHUTglSwyMwslNltEKsj8FgSn3zSA== Date: Sun, 16 Sep 2018 22:05:05 +0000 Message-ID: <3DDE70BC-D951-4110-B7F8-1C45BFC7CA0C@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.253.181] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-14 8.4.1 Anycast Map-Resolver Operation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2018 22:05:10 -0000 Hi, This turns out to be not the case Renne. The idea of map-server resiliency= is attractive. But any-cast works best for non-stateful cases, and the re= lationship between an ETR and a MS is by definition, stateful. -Darrel > On Sep 16, 2018, at 3:17 AM, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: >=20 > Hi, >=20 > "draft-ietf-lisp-rfc6833bis-14" section "8.4.1 Anycast Map-Resolver Opera= tion" says >=20 > "Note that Map-Server associations with ETRs SHOULD NOT use anycast > addresses, as registrations need to be established between an ETR and > a specific set of Map-Servers, each identified by a specific > registration association." >=20 > In my opinion it is sensible to use anycast addresses for map servers of = a distributed database for fail-over/load balancing cases and the "SHOULD N= OT" is to limiting. >=20 > Instead I suggest to encourage operators to specifially consider possible= pitfalls of anycast operation. >=20 >=20 > Regards, >=20 >=20 > Renne >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Sun Sep 16 16:30:43 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF01F126BED for ; Sun, 16 Sep 2018 16:30:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eN8i-GqwIaWx for ; Sun, 16 Sep 2018 16:30:39 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 9563C130DFD for ; Sun, 16 Sep 2018 16:30:39 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id s13-v6so6664241pfi.7 for ; Sun, 16 Sep 2018 16:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2ILFAiQETtUHIfpRExxilAkx3x/XODDZ5BkdPr2JG9I=; b=toANHr3bKjHutcE390sDMBcHlOHZhBW+ka/d4kWPSzIqkFZn0R7Z0s7VXNTVzgB0gz SpxLJ6P7Cksan2+UPfQ8SMqKEUBWyD0HFvzsA92bIWODyCsE3gWCidcTmkY8Wjy1dXdz /ppg8aGUlz+qwQ5TRxKSW7Xqmk7DWTyBJIVAdKNKyRTdG1JfaOzxlagTv3BQegxOkbuF d6LXHgIefAI8PUx+C1QH92WqfBf0uivVySdR76Dd780tEk/QYDuYgpr112Ke7duiUNPZ EnyNYlp0vhXdNxUAsIAko6jjEb1iqlNBg1kngKSQ/lEzcMu7gYhKK8A39LN5V/AI6np7 DupA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2ILFAiQETtUHIfpRExxilAkx3x/XODDZ5BkdPr2JG9I=; b=Gn+QoKTQxmI6EiUY2Cou72JASLmmWpb3S8RGAjeHgD9qdRhhZXckRzHFnyaQs6go7L TlhiPJsqSPZRnP3mBAiioEfUy1juQZRojJfntGtuEZywsxASlrGXPX/OliIj76GVBbnP 5ul//f4OfLZHpDbuvskVkqAppjHYp64pX5PIPgr9rSvD0pSRqq6nx6V6BIoq5X8qtOiv aA6HQhcjIdgmcpMfL3x5uffV+n81/OqyYPIYZ4C1R7W/urULNWbKiQ6MdUXGyXZz1UqT fUSHBJnl2IqSS4u3q38BgngNfDwQELhKadG/pVfbZTqRZWrcqby+Qr+scF6GZarlGYYp 2IqQ== X-Gm-Message-State: APzg51AXiz6fiYwDDkMxvT2NgxLRejhtKDPH00P69NG47U50woqXC+iw rRhrVGEBkAOJO8tIRz/2QsSitC6H X-Google-Smtp-Source: ANB0Vdb6TO615n46MKG+vsa1G2byOnDeYXqO2EiBpL2aPhzKvoP145jo5kt9Jow0dKnjOq5bhM/cYw== X-Received: by 2002:a63:9619:: with SMTP id c25-v6mr21416752pge.23.1537140638940; Sun, 16 Sep 2018 16:30:38 -0700 (PDT) Received: from ?IPv6:2603:3024:151c:55f0:2c93:666e:6b5d:9ef5? ([2603:3024:151c:55f0:2c93:666e:6b5d:9ef5]) by smtp.gmail.com with ESMTPSA id k64-v6sm19293772pfg.141.2018.09.16.16.30.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Sep 2018 16:30:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (15G77) In-Reply-To: <3DDE70BC-D951-4110-B7F8-1C45BFC7CA0C@cisco.com> Date: Sun, 16 Sep 2018 16:30:37 -0700 Cc: "Rene 'Renne' Bartsch, B.Sc. Informatics" , "lisp@ietf.org" , Dino Farinacci Content-Transfer-Encoding: quoted-printable Message-Id: <3E22595A-D702-4826-9E6F-A005A65A45DD@gmail.com> References: <3DDE70BC-D951-4110-B7F8-1C45BFC7CA0C@cisco.com> To: "Darrel Lewis (darlewis)" Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-14 8.4.1 Anycast Map-Resolver Operation X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2018 23:30:42 -0000 Well I would say so much has changed since that paragraph was written where w= e have xTR-IDs used for the association and registration between an ETR and= a map-server and with newer ways of authentication (like using different ke= ys per ETR with same anycast address as well as signature-IDs) we should lig= hten from SHOULD NOT to MAY.=20 I=E2=80=99m willing to change it if there are no objections.=20 Dino > On Sep 16, 2018, at 3:05 PM, Darrel Lewis (darlewis) wrote: >=20 > Hi, >=20 > This turns out to be not the case Renne. The idea of map-server resilienc= y is attractive. But any-cast works best for non-stateful cases, and the re= lationship between an ETR and a MS is by definition, stateful. >=20 > -Darrel >=20 >> On Sep 16, 2018, at 3:17 AM, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: >>=20 >> Hi, >>=20 >> "draft-ietf-lisp-rfc6833bis-14" section "8.4.1 Anycast Map-Resolver Opera= tion" says >>=20 >> "Note that Map-Server associations with ETRs SHOULD NOT use anycast >> addresses, as registrations need to be established between an ETR and >> a specific set of Map-Servers, each identified by a specific >> registration association." >>=20 >> In my opinion it is sensible to use anycast addresses for map servers of a= distributed database for fail-over/load balancing cases and the "SHOULD NOT= " is to limiting. >>=20 >> Instead I suggest to encourage operators to specifially consider possible= pitfalls of anycast operation. >>=20 >>=20 >> Regards, >>=20 >>=20 >> Renne >>=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 Mon Sep 17 09:04:39 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9F4130DE9; Mon, 17 Sep 2018 09:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XVYE5egomVv8; Mon, 17 Sep 2018 09:04:32 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 E63FE126DBF; Mon, 17 Sep 2018 09:04:31 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id s17-v6so7635401plp.7; Mon, 17 Sep 2018 09:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=Wwb7UbCM0ALcldwYUJMhR6WVdT5bjj/LXzcbN2jOPsI=; b=k4PWIi3oPp+QHmph/yTUhaJO2bGLSR1nmlFJPO910Ku6LR0vQvOtrLtxDt5dqUfbtg JyFhxgYATMH1E+HGAbM5PebRZEmVHtoPSPCVt7KEzqCmfOtG/kENGA4B5tFQjwYbZOC3 bw/BqgvHTzeiy4AMPCtetaLHzYJvuIFjYuXKyR8sypx1Wqt7QIwg1Pnvuv2VD94pg23V HEgi2VSx4DWi3QtIYSwUXpOOWDmtJ2MfgQ1y+FtAxMa4AoaECV8coSNcfGw0pLBPYPPF 1sELpVRW8KCP4QVQ70nig1O5aHk7EM6TmtVJ4QEr3yWFRX2/iTRnRd5C0I6w0yMQxsK1 ezVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=Wwb7UbCM0ALcldwYUJMhR6WVdT5bjj/LXzcbN2jOPsI=; b=gjemWKchTvrCh4tU0f9Nk2eFuotDnsopdyIU+bh6RuEr7moMFLdH1skYERej9Sikr3 VZBVvfJNS3KcYNIMc4IqcjqknBPY1nPkOcyPCT9wZWAL8nnzqMbsZd+rO3pFS7mtM1JF e1h09mByG6OZhLsZv3cx2Vl54a0pGpsV0AvsocZhSP8jjb/YaM775xwY6ju72Z/2IlPe sWX+nmjc1XAkaMqvyy49hYczwzz3yxpFvlnFYEtNdepFuDvk9mGPEVkRpXxeoGjROa4N 66gSI6cDbG++4w4nr+pq6ZVxJW+aU4SM5+NAyQtdtdlZmE66fa8p23lS7n9lRIkAIbdB d6Zw== X-Gm-Message-State: APzg51CAgm1XCZUHBQ+ESKpqBbBd3naMgbb3nI9P6xKbRT3bglHV2bmA UKWJCyUUW4zpQg3ybGLsOHU6LV93 X-Google-Smtp-Source: ANB0VdaU13g3JkpUetSi0G77zw24WR/Mxh5r6utaWJv2djUMZrsVM8qijkaeW5634l8MpFM00skM5g== X-Received: by 2002:a17:902:9893:: with SMTP id s19-v6mr25645568plp.130.1537200271111; Mon, 17 Sep 2018 09:04:31 -0700 (PDT) Received: from [10.10.10.70] ([4.28.87.67]) by smtp.gmail.com with ESMTPSA id r19-v6sm31716141pgg.39.2018.09.17.09.04.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Sep 2018 09:04:30 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/mixed; boundary="Apple-Mail=_BA4D8C21-DC21-434D-87F6-5658E8EB32FE" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Mon, 17 Sep 2018 09:04:28 -0700 To: The IESG , Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6833bis@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [lisp] Read this latest diff file for 6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 17 Sep 2018 16:04:37 -0000 --Apple-Mail=_BA4D8C21-DC21-434D-87F6-5658E8EB32FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Albert had comments about clarity of the paragraph added describing = Map-Notify retransmissions. I have word-smithed it a bit. Also from = Renne/Darrel comments about anycast addressing for ETRs. Reworded some = of that paragraph. Please review the latest diff enclosed. Thanks, Dino --Apple-Mail=_BA4D8C21-DC21-434D-87F6-5658E8EB32FE Content-Disposition: attachment; filename=rfcdiff-6833bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6833bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-14.txt - = draft-ietf-lisp-rfc6833bis-15.txt=20 =20 =20 =20 =20 =20 =20 = = =
< draft-ietf-lisp-rfc6833bis-14.txt  =  draft-ietf-lisp-rfc6833bis-15.txt >
=
Network Working = Group V. Fuller = Network Working Group = V. Fuller
Internet-Draft = D. Farinacci Internet-Draft = D. Farinacci
Obsoletes: 6833 = (if approved) Cisco Systems = Obsoletes: 6833 (if approved) = Cisco Systems
Intended status: = Standards Track A. Cabellos (Ed.) = Intended status: Standards Track = A. Cabellos (Ed.)
Expires: March = 15, 2019 = UPC/BarcelonaTech Expires: March = 21, 2019 = UPC/BarcelonaTech
= September 11, 2018 = September 17, 2018
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-14 = = draft-ietf-lisp-rfc6833bis-15
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = Control-Plane service interface and communicating with By using this Control-Plane service interface and = communicating with
=
skipping to = change at = page 1, line 48 =C2=B6 = skipping to change at page 1, line 48 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on March 15, = 2019. This Internet-Draft will = expire on March 21, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 34 =C2=B6 = skipping to change at page 2, line 34 =C2=B6
3. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
4. Basic = Overview . . . . . . . . . . . . . . . . . . . . . . . 6 = 4. Basic Overview . . . . . . . . . . . . = . . . . . . . . . . . 6
5. LISP IPv4 = and IPv6 Control-Plane Packet Formats . . . . . . . 7 = 5. LISP IPv4 and IPv6 Control-Plane Packet = Formats . . . . . . . 7
5.1. LISP = Control Packet Type Allocations . . . . . . . . . . 9 = 5.1. LISP Control Packet Type Allocations = . . . . . . . . . . 9
5.2. = Map-Request Message Format . . . . . . . . . . . . . . . 10 = 5.2. Map-Request Message Format . . . . = . . . . . . . . . . . 10
5.3. = EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 = 5.3. EID-to-RLOC UDP Map-Request Message = . . . . . . . . . . . 13
5.4. = Map-Reply Message Format . . . . . . . . . . . . . . . . 15 = 5.4. Map-Reply Message Format . . . . . = . . . . . . . . . . . 15
5.5. = EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 = 5.5. EID-to-RLOC UDP Map-Reply Message . = . . . . . . . . . . . 19
5.6. = Map-Register Message Format . . . . . . . . . . . . . . . 22 = 5.6. Map-Register Message Format . . . . = . . . . . . . . . . . 22
5.7. = Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 = 5.7. Map-Notify/Map-Notify-Ack Message = Format . . . . . . . . 25
5.8. = Encapsulated Control Message Format . . . . . . . . . . . 26 5.8. = Encapsulated Control Message Format . . . . . . . . . . . 27
6. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 28 6. = Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 29
6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28 6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 29
7. Routing = Locator Reachability . . . . . . . . . . . . . . . . 29 7. = Routing Locator Reachability . . . . . . . . . . . . . . . . 30
7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31 7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 32
8. = Interactions with Other LISP Components . . . . . . . . . . . 32 8. = Interactions with Other LISP Components . . . . . . . . . . . 33
8.1. ITR = EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32 8.1. = ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 33
8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 33 8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 34
8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 35 8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 36
8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 36 8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 37
8.4.1. = Anycast Map-Resolver Operation . . . . . . . . . . . 36 = 8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 37
9. Security = Considerations . . . . . . . . . . . . . . . . . . . 36 9. = Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. Changes = since RFC 6833 . . . . . . . . . . . . . . . . . . . 37 10. = Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 38
11. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 38 11. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.1. = LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 38 11.1. = LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 39
11.2. = LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 11.2. = LISP Packet Type Codes . . . . . . . . . . . . . . . . . 39
11.3. = LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 39 11.3. = LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 40
11.4. = LISP Address Type Codes . . . . . . . . . . . . . . . . 39 11.4. = LISP Address Type Codes . . . . . . . . . . . . . . . . 40
11.5. = LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 40 11.5. = LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 41
=
12. = References . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. = References . . . . . . . . . . . . . . . . . . . . . . . . . 41
12.1. = Normative References . . . . . . . . . . . . . . . . . . 40 12.1. = Normative References . . . . . . . . . . . . . . . . . . 41
12.2. = Informative References . . . . . . . . . . . . . . . . . 41 12.2. = Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 45 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 46
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 45 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 46
B.1. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 45 B.1. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . = 46
B.2. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 45 B.2. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . = 46
B.3. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 45 B.3. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . = 46
B.4. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 45 B.4. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . = 46
B.5. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 46 B.5. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 46
B.6. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 46 B.6. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . = 47
B.7. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 46 B.7. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . = 47
B.8. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 46 B.8. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . = 47
B.9. = Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 47 B.9. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 47
B.10. = Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 47 B.10. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . = 48
B.11. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 47 B.11. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . = 48
B.12. = Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 48 B.12. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 48
B.13. = Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 48 B.13. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . = 49
B.14. = Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 48 B.14. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . = 49
B.15. = Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 48 B.15. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . = 49
B.16. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48 B.16. = Changes to draft-ietf-lisp-rfc6833bis-00 . . . . = . . . . 49
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 B.17. Changes to = draft-farinacci-lisp-rfc6833bis-00 . . . . . . 49
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 50
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol = [I-D.ietf-lisp-rfc6830bis] (see
also = [I-D.ietf-lisp-introduction]) specifies an architecture and = also [I-D.ietf-lisp-introduction]) specifies = an architecture and
mechanism = for dynamic tunnelling by logically = separating the mechanism for = dynamic tunneling by logically separating = the addresses
addresses = currently used by IP in two separate name spaces: Endpoint = currently used by IP in two separate name = spaces: Endpoint IDs
IDs (EIDs), = used within sites; and Routing Locators (RLOCs), used on = (EIDs), used within sites; and Routing = Locators (RLOCs), used on the
the transit = networks that make up the Internet infrastructure. To transit networks that make up the Internet = infrastructure. To
achieve this = separation, LISP defines protocol mechanisms for mapping = achieve this separation, LISP defines = protocol mechanisms for mapping
from EIDs to = RLOCs. In addition, LISP assumes the existence of a from EIDs to RLOCs. In addition, LISP assumes the = existence of a
database to = store and propagate those mappings globally. Several database to store and propagate those mappings = globally. Several
such databases = have been proposed; among them are the Content such databases have been proposed; among them are the = Content
distribution = Overlay Network Service for LISP-NERD (a Not-so-novel distribution Overlay Network Service for LISP-NERD (a = Not-so-novel
EID-to-RLOC = Database) [RFC6837], LISP Alternative Logical Topology EID-to-RLOC Database) [RFC6837], LISP Alternative = Logical Topology
(LISP-ALT) = [RFC6836], and LISP Delegated Database Tree (LISP-DDT) (LISP-ALT) [RFC6836], and LISP Delegated Database = Tree (LISP-DDT)
= [RFC8111]. [RFC8111].
=
The LISP = Mapping Service defines two new types of LISP-speaking The LISP Mapping Service defines two new types of = LISP-speaking
=
skipping to = change at = page 4, line 20 =C2=B6 = skipping to change at page 4, line 20 =C2=B6
[GTP-3GPP], = ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6) = [GTP-3GPP], ILA [I-D.herbert-intarea-ila], = and Segment Routing (SRv6)
= [RFC8402]. [RFC8402].
=
Conceptually, = LISP Map-Servers share some of the same basic Conceptually, LISP Map-Servers share some of the same = basic
configuration = and maintenance properties as Domain Name System (DNS) configuration and maintenance properties as Domain = Name System (DNS)
[RFC1035] = servers; likewise, Map-Resolvers are conceptually similar = [RFC1035] servers; likewise, Map-Resolvers = are conceptually similar
to DNS caching = resolvers. With this in mind, this specification to DNS caching resolvers. With this in mind, this = specification
borrows = familiar terminology (resolver and server) from the DNS = borrows familiar terminology (resolver and = server) from the DNS
= specifications. = specifications.
=
Note that while this document assumes a LISP-ALT = database mapping Note this document doesn't assume any particular = database mapping
infrastructure = to illustrate certain aspects of Map-Server and Map- infrastructure to illustrate certain aspects of = Map-Server and Map-
Resolver = operation, the Mapping Service interface can (and likely = Resolver operation, the Mapping Service = interface can (and likely
will) be used = by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other = mapping database
systems as the = LISP infrastructure evolves. = systems as the LISP infrastructure evolves.
=
The LISP = Mapping Service is an important component of the LISP The LISP Mapping Service is an important component of = the LISP
toolset. = Issues and concerns about the deployment of LISP for toolset. Issues and concerns about the deployment of = LISP for
Internet = traffic are discussed in [I-D.ietf-lisp-rfc6830bis], Internet traffic are discussed in = [I-D.ietf-lisp-rfc6830bis],
[RFC7215], and = [I-D.rodrigueznatal-lisp-oam]. = [RFC7215], and [I-D.rodrigueznatal-lisp-oam].
=
=
skipping to = change at = page 8, line 27 =C2=B6 = skipping to change at page 8, line 27 =C2=B6
sender and the = destination UDP port number is set to 4342. When a sender and the destination UDP port number is set to = 4342. When a
UDP Map-Reply, = Map-Notify (when used as an acknowledgement to a Map- UDP Map-Reply, Map-Notify (when used as an = acknowledgement to a Map-
Register), or = Map-Notify-Ack are sent, the source UDP port number is Register), or Map-Notify-Ack are sent, the source UDP = port number is
set to 4342 = and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is = copied from the
source port of = either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking = data packet.
= Implementations MUST be prepared to accept packets when either = the Implementations MUST be = prepared to accept packets when either the
source port or = destination UDP port is set to 4342 due to NATs source port or destination UDP port is set to 4342 = due to NATs
changing port = number values. changing port number = values.
=
The 'UDP = Length' field will reflect the length of the UDP header and = The 'UDP Length' field will reflect the = length of the UDP header and
the LISP = Message payload. the LISP Message = payload. Implementations should follow = the
= procedures from = [RFC8085] to determine the maximum size used for any
= LISP control = message.
=
The UDP = checksum is computed and set to non-zero for all messages = The UDP checksum is computed and set to = non-zero for all messages
sent to or = from port 4342. It MUST be checked on receipt, and if the = sent to or from port 4342. It MUST be = checked on receipt, and if the
checksum = fails, the control message MUST be dropped [RFC1071]. checksum fails, the control message MUST be dropped = [RFC1071].
=
The format of = control messages includes the UDP header so the The format of control messages includes the UDP = header so the
checksum and = length fields can be used to protect and delimit message = checksum and length fields can be used to = protect and delimit message
= boundaries. boundaries.
=
5.1. LISP = Control Packet Type Allocations 5.1. = LISP Control Packet Type Allocations
=
skipping to = change at = page 11, line 13 =C2=B6 = skipping to change at page 11, line = 13 =C2=B6
Request = (SMRs) Section 6.1 for details. = Request (SMRs) Section 6.1 for details.
=
p: This is the = PITR bit. This bit is set to 1 when a PITR sends a p: This is the PITR bit. This bit is set to 1 when a = PITR sends a
= Map-Request. = Map-Request.
=
s: This is the = SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 = when an xTR is
sending a = Map-Request in response to a received SMR-based Map- sending a Map-Request in response to a received = SMR-based Map-
= Request. Request.
=
m: This is the = LISP mobile-node m-bit. This bit is set by xTRs that m: This is the LISP mobile-node m-bit. This bit is = set by xTRs that
operate = as a mobile node as defined in [I-D.ietf-lisp-mn]. operate as a mobile node as defined in = [I-D.ietf-lisp-mn]. This
= bit can be = ignored if an implementation does not support
= = [I-D.ietf-lisp-mn].
=
I: This is the = xTR-ID bit. When this bit is set, what is appended to I: This is the xTR-ID bit. When this bit is set, = what is appended to
the = Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage = the Map-Request is a 128-bit xTR = router-ID. See LISP PubSub usage
= procedures in [I-D.ietf-lisp-pubsub] for details. procedures in [I-D.ietf-lisp-pubsub] for details. = This bit can be
= ignored if an = implementation does not support
= = [I-D.ietf-lisp-pubsub].
=
Rsvd: This = field MUST be set to 0 on transmit and MUST be ignored on = Rsvd: This field MUST be set to 0 on = transmit and MUST be ignored on
= receipt. receipt.
=
L: This is the = local-xtr bit. It is used by an xTR in a LISP site to L: This is the local-xtr bit. It is used by an xTR = in a LISP site to
tell other = xTRs in the same site that it is part of the RLOC-set tell other xTRs in the same site that it is part = of the RLOC-set
for the = LISP site. The L-bit is set to 1 when the RLOC is the for the LISP site. The L-bit is set to 1 when the = RLOC is the
sender's IP = address. sender's IP = address.
=
D: This is the = dont-map-reply bit. It is used in the SMR procedure D: This is the dont-map-reply bit. It is used in the = SMR procedure
=
skipping to = change at = page 11, line 48 =C2=B6 = skipping to change at page 12, line 4 =C2=B6
value of 0, = there is 1 ITR-RLOC address encoded; for a value of 1, value of 0, there is 1 ITR-RLOC address encoded; = for a value of 1,
there are 2 = ITR-RLOC addresses encoded, and so on up to 31, which there are 2 ITR-RLOC addresses encoded, and so on = up to 31, which
encodes a = total of 32 ITR-RLOC addresses. = encodes a total of 32 ITR-RLOC addresses.
=
Record Count: = This is the number of records in this Map-Request Record Count: This is the number of records in this = Map-Request
message. A = record is comprised of the portion of the packet that message. A record is comprised of the portion of = the packet that
is labeled = 'Rec' above and occurs the number of times equal to is labeled 'Rec' above and occurs the number of = times equal to
Record = Count. For this version of the protocol, a receiver MUST = Record Count. For this version of the = protocol, a receiver MUST
accept and = process Map-Requests that contain one or more records, accept and process Map-Requests that contain one = or more records,
but a = sender MUST only send Map-Requests containing one record. = but a sender MUST only send Map-Requests = containing one record.
Support = for requesting multiple EIDs in a single = Map-Request =
= Support for processing multiple EIDs in a single = Map-Request
message = will be specified in a future version of the protocol. message will be specified in a future version of = the protocol.
=
Nonce: This = is an 8-octet random value created by the sender of the = Nonce: This is an 8-octet random value = created by the sender of the
= Map-Request. This nonce will be returned in the Map-Reply. = The Map-Request. This nonce = will be returned in the Map-Reply. The
security of = the LISP mapping protocol critically depends on the security of the LISP mapping protocol critically = depends on the
strength of = the nonce in the Map-Request message. The nonce strength of the nonce in the Map-Request message. = The nonce
SHOULD be = generated by a properly seeded pseudo-random (or strong = SHOULD be generated by a properly seeded = pseudo-random (or strong
random) = source. See [RFC4086] for advice on generating security- = random) source. See [RFC4086] for advice = on generating security-
sensitive = random data. sensitive random = data.
=
=
skipping to = change at = page 13, line 41 =C2=B6 = skipping to change at page 13, line = 43 =C2=B6
=
Map-Requests = can also be LISP encapsulated using UDP destination Map-Requests can also be LISP encapsulated using UDP = destination
port 4342 with = a LISP Type value set to "Encapsulated Control port 4342 with a LISP Type value set to "Encapsulated = Control
Message", when = sent from an ITR to a Map-Resolver. Likewise, Map- Message", when sent from an ITR to a Map-Resolver. = Likewise, Map-
Requests are = LISP encapsulated the same way from a Map-Server to an Requests are LISP encapsulated the same way from a = Map-Server to an
ETR. Details = on Encapsulated Map-Requests and Map-Resolvers can be ETR. Details on Encapsulated Map-Requests and = Map-Resolvers can be
found in = Section 5.8. found in Section = 5.8.
=
Map-Requests = MUST be rate-limited. It is RECOMMENDED that a Map- Map-Requests MUST be rate-limited. It is RECOMMENDED = that a Map-
Request for = the same EID-Prefix be sent no more than once per second. = Request for the same EID-Prefix be sent no = more than once per second.
= However, = recommendations from [RFC8085] SHOULD be considered.
=
An ITR that is = configured with mapping database information (i.e., it An ITR that is configured with mapping database = information (i.e., it
is also an = ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings = in a Map-
Request. When = an ETR configured to accept and verify such Request. When an ETR configured to accept and verify = such
"piggybacked" = mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a = Map-Request and it does
not have this = mapping in the Map-Cache, it MAY originate a "verifying = not have this mapping in the Map-Cache, it = MAY originate a "verifying
Map-Request", = addressed to the map-requesting ITR and the ETR MAY add = Map-Request", addressed to the = map-requesting ITR and the ETR MAY add
a Map-Cache = entry. If the ETR has a Map-Cache entry that matches the = a Map-Cache entry. If the ETR has a = Map-Cache entry that matches the
"piggybacked" = EID and the RLOC is in the Locator-Set for the entry, "piggybacked" EID and the RLOC is in the Locator-Set = for the entry,
then it MAY = send the "verifying Map-Request" directly to the then it MAY send the "verifying Map-Request" directly = to the
=
skipping to = change at = page 19, line 49 =C2=B6 = skipping to change at page 19, line = 49 =C2=B6
=
When an EID = moves out of a LISP site [I-D.ietf-lisp-eid-mobility], When an EID moves out of a LISP site = [I-D.ietf-lisp-eid-mobility],
the database = mapping system may have overlapping EID-prefixes. Or the database mapping system may have overlapping = EID-prefixes. Or
when a LISP = site is configured with multiple sets of ETRs that when a LISP site is configured with multiple sets of = ETRs that
support = different EID-prefix lengths, the database mapping system may = support different EID-prefix lengths, the = database mapping system may
have = overlapping EID-prefixes. When overlapping EID-prefixes exist, = have overlapping EID-prefixes. When = overlapping EID-prefixes exist,
a Map-Request = with an EID that best matches any EID-Prefix MUST be a Map-Request with an EID that best matches any = EID-Prefix MUST be
returned in a = single Map-Reply message. For instance, if an ETR had returned in a single Map-Reply message. For = instance, if an ETR had
database = mapping entries for EID-Prefixes: = database mapping entries for EID-Prefixes:
=
10.0.0.0/8 = 2001:db8::/16
10.1.0.0/16 = 2001:db8:1::/24
10.1.1.0/24 = 2001:db8:1:1::/32
10.1.2.0/24 = 2001:db8:1:2::/32
=
A = Map-Request for EID 10.1.1.1 would cause a = Map-Reply with a record A = Map-Request for EID 2001:db8:1:1::1 would = cause a Map-Reply with a
count of 1 = to be returned with a mapping record EID-Prefix of record count of 1 to be returned with a mapping = record EID-Prefix of
10.1.1.0/24. = 2001:db8:1:1::/32.
=
A = Map-Request for EID 10.1.5.5 would cause a = Map-Reply with a record A = Map-Request for EID 2001:db8:1:5::5 would = cause a Map-Reply with a
count of 3 = to be returned with mapping records for EID-Prefixes = record count of 3 to be returned with mapping records for EID-
10.1.0.0/16, 10.1.1.0/24, and = 10.1.2.0/24. Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, = 2001:db8:1:2::/32. Note
= filling out the /24 = with more-specifics that exist in the mapping
= = system.
=
Note that not = all overlapping EID-Prefixes need to be returned but Note that not all overlapping EID-Prefixes need to be = returned but
only the = more-specific entries (note that in the second example above = only the more-specific entries (note that in = the second example above
10.0.0.0/8 was not returned for requesting EID = 10.1.5.5) for the 2001:db8::/16 was not = returned for requesting EID 2001:db8:1:5::5)
matching = EID-Prefix of the requesting EID. When more than one EID- for = the matching EID-Prefix of the requesting EID. When more than
Prefix is returned, all SHOULD use the same = Time to Live value so one EID-Prefix is returned, all SHOULD use the same = Time to Live
they can all = time out at the same time. When a more-specific = EID- value so they can all = time out at the same time. When a more-
Prefix is received later, its Time to Live = value in the Map-Reply specific EID-Prefix is received later, its = Time to Live value in the
record can = be stored even when other less-specific entries exist. Map-Reply record can be stored even when other = less-specific entries
When a = less-specific EID-Prefix is received later, its Map-Cache = exist. When a less-specific EID-Prefix is received later, its Map-
expiration = time SHOULD be set to the minimum expiration time of any = Cache = expiration time SHOULD be set to the minimum expiration time of
= more-specific EID-Prefix in the Map-Cache. This is done so the = any more-specific EID-Prefix in the = Map-Cache. This is done so the
integrity of = the EID-Prefix set is wholly maintained and so no more- = integrity of the EID-Prefix set is wholly = maintained and so no more-
specific = entries are removed from the Map-Cache while keeping less- = specific entries are removed from the = Map-Cache while keeping less-
specific = entries. specific entries.
=
Map-Replies = SHOULD be sent for an EID-Prefix no more often than once = Map-Replies SHOULD be sent for an EID-Prefix = no more often than once
per second to = the same requesting router. For scalability, it is per second to the same requesting router. For = scalability, it is
expected that = aggregation of EID addresses into EID-Prefixes will expected that aggregation of EID addresses into = EID-Prefixes will
allow one = Map-Reply to satisfy a mapping for the EID addresses in the = allow one Map-Reply to satisfy a mapping for = the EID addresses in the
prefix range, = thereby reducing the number of Map-Request messages. prefix range, thereby reducing the number of = Map-Request messages.
=
=
skipping = to change at page 23, line = 30 =C2=B6 = skipping to change at page 23, line = 30 =C2=B6
T: This is the = use-TTL for timeout bit. When set to 1, the xTR wants T: This is the use-TTL for timeout bit. When set to = 1, the xTR wants
the = Map-Server to time out registrations based on the value in the = the Map-Server to time out registrations = based on the value in the
"Record = TTL" field of this message. = "Record TTL" field of this message.
=
a: This is the = merge-request bit. When set to 1, the xTR requests to a: This is the merge-request bit. When set to 1, the = xTR requests to
merge = RLOC-records from different xTRs registering the same EID- = merge RLOC-records from different xTRs = registering the same EID-
record. = See signal-free multicast [RFC8378] for one use case record. See signal-free multicast [RFC8378] for = one use case
= example. example.
=
m: This is the = mobile-node bit. When set to 1, the registering xTR m: This is the mobile-node bit. When set to 1, the = registering xTR
supports = the procedures in [I-D.ietf-lisp-mn]. = supports the procedures in [I-D.ietf-lisp-mn]. This bit can be
= ignored if an = implementation does not support [I-D.ietf-lisp-mn]
=
M: This is the = want-map-notify bit. When set to 1, an ETR is M: This is the want-map-notify bit. When set to 1, = an ETR is
requesting = a Map-Notify message to be returned in response to requesting a Map-Notify message to be returned in = response to
sending a = Map-Register message. The Map-Notify message sent by a = sending a Map-Register message. The = Map-Notify message sent by a
Map-Server = is used to acknowledge receipt of a Map-Register Map-Server is used to acknowledge receipt of a = Map-Register
= message. message.
=
Record Count: = This is the number of records in this Map-Register Record Count: This is the number of records in this = Map-Register
message. A = record is comprised of that portion of the packet message. A record is comprised of that portion of = the packet
labeled = 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of = times equal to
=
skipping = to change at page 26, line = 5 =C2=B6 = skipping to change at page 26, line = 5 =C2=B6
Type: 4/5 = (Map-Notify/Map-Notify-Ack) Type: = 4/5 (Map-Notify/Map-Notify-Ack)
=
The Map-Notify = message has the same contents as a Map-Register The Map-Notify message has the same contents as a = Map-Register
message. See = the Map-Register section for field descriptions. message. See the Map-Register section for field = descriptions.
=
The = Map-Notify-Ack message has the same contents as a Map-Notify = The Map-Notify-Ack message has the same = contents as a Map-Notify
message. It = is used to acknowledge the receipt of a Map-Notify and message. It is used to acknowledge the receipt of a = Map-Notify and
for the sender = to stop retransmitting a Map-Notify with the same for the sender to stop retransmitting a Map-Notify = with the same
= nonce. nonce.
=
= A Map-Server sends = an unsolicited Map-Notify message (one that is not
= used as an = acknowledgment to a Map-Register message) that follows = the
= Congestion Control = And Relability Guideline sections of [RFC8085]. A
= Map-Notify is = retransmitted until a Map-Notify-Ack is received by the
= Map-Server with the = same nonce used in the Map-Notify message. If a
= Map-Notify-Ack is = never received by the Map-Server, it issues a log
= message. An = implementation SHOULD retransmit up to 3 times at 3
= second = retransmission intervals, after which time the = retransmission
= interval is = exponentially backed-off for another 3 retransmission
= attempts. After = this time, an xTR can only get the RLOC-set change
= by later querying = the mapping system or by RLOC-probing one of the
= RLOCs of the = existing cached RLOC-set to get the new RLOC-set.
= =
5.8. = Encapsulated Control Message Format 5.8.= Encapsulated Control Message Format
=
An = Encapsulated Control Message (ECM) is used to encapsulate = control An Encapsulated Control = Message (ECM) is used to encapsulate control
packets sent = between xTRs and the mapping database system. packets sent between xTRs and the mapping database = system.
=
0 = 1 2 3 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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = IPv4 or IPv6 Header | / | IPv4 or IPv6 Header = |
OH | = (uses RLOC addresses) | OH | (uses RLOC addresses) = |
=
skipping = to change at page 29, line = 16 =C2=B6 = skipping to change at page 30, line = 16 =C2=B6
accept the = Map-Request. accept the = Map-Request.
=
3. The remote = ITR MUST rate-limit the Map-Request until it gets a 3. The remote ITR MUST rate-limit the Map-Request = until it gets a
Map-Reply = while continuing to use the cached mapping. When Map-Reply while continuing to use the cached = mapping. When
= Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, = Map-Versioning as described in = [I-D.ietf-lisp-6834bis] is used,
an SMR = sender can detect if an ITR is using the most up-to-date = an SMR sender can detect if an ITR is = using the most up-to-date
database = mapping. database = mapping.
=
4. The ETRs = at the site with the changed mapping will reply to the 4. The ETRs at the site with the changed mapping = will reply to the
= Map-Request with a Map-Reply message that has a nonce from the = Map-Request with a Map-Reply message = that has a nonce from the
= SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- SMR-invoked Map-Request. The Map-Reply messages = MUST be rate-
limited. This is important to avoid Map-Reply = implosion. limited according to procedures in [RFC8085]. = This is important
= to avoid Map-Reply implosion.
=
5. The ETRs = at the site with the changed mapping record the fact 5. The ETRs at the site with the changed mapping = record the fact
that the = site that sent the Map-Request has received the new that the site that sent the Map-Request has = received the new
mapping = data in the Map-Cache entry for the remote site so the mapping data in the Map-Cache entry for the = remote site so the
= Locator-Status-Bits are reflective of the new mapping for = packets Locator-Status-Bits are = reflective of the new mapping for packets
going to = the remote site. The ETR then stops sending SMR going to the remote site. The ETR then stops = sending SMR
= messages. messages.
=
For security = reasons, an ITR MUST NOT process unsolicited Map- For security reasons, an ITR MUST NOT process = unsolicited Map-
Replies. To = avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a = third party, a
=
skipping = to change at page 35, line = 35 =C2=B6 = skipping to change at page 36, line = 35 =C2=B6
1-minute = TTL. 1-minute TTL.
=
If the = EID-prefix is either registered or not registered to the = If the EID-prefix is either registered or = not registered to the
mapping system = and there is a policy in the Map-Server to have the mapping system and there is a policy in the = Map-Server to have the
requestor drop = packets for the matching EID-prefix, then a Drop/ requestor drop packets for the matching EID-prefix, = then a Drop/
Policy-Denied = action is returned. If the EID-prefix is registered or = Policy-Denied action is returned. If the = EID-prefix is registered or
not registered = and there is a authentication failure, then a Drop/ not registered and there is a authentication failure, = then a Drop/
= Authentication- failure action is returned. If either of these = Authentication- failure action is returned. = If either of these
actions result = as a temporary state in policy or authentication then actions result as a temporary state in policy or = authentication then
a = Send-Map-Request action with 1-minute TTL MAY be returned to = allow a Send-Map-Request action = with 1-minute TTL MAY be returned to allow
the reqeustor to retry the Map-Request. = the requestor = to retry the Map-Request.
=
If any of the = registered ETRs for the EID-Prefix have requested proxy = If any of the registered ETRs for the = EID-Prefix have requested proxy
reply service, = then the Map-Server answers the request instead of reply service, then the Map-Server answers the = request instead of
forwarding it. = It returns a Map-Reply with the EID-Prefix, RLOCs, forwarding it. It returns a Map-Reply with the = EID-Prefix, RLOCs,
and other = information learned through the registration process. and other information learned through the = registration process.
=
If none of the = ETRs have requested proxy reply service, then the Map- If none of the ETRs have requested proxy reply = service, then the Map-
Server = re-encapsulates and forwards the resulting Encapsulated Map- = Server re-encapsulates and forwards the = resulting Encapsulated Map-
Request to one = of the registered ETRs. It does not otherwise alter Request to one of the registered ETRs. It does not = otherwise alter
the = Map-Request, so any Map-Reply sent by the ETR is returned to = the the Map-Request, so any = Map-Reply sent by the ETR is returned to the
=
skipping = to change at page 36, line = 43 =C2=B6 = skipping to change at page 37, line = 43 =C2=B6
Server that = receives the Map-Request over the ALT and responds will = Server that receives the Map-Request over = the ALT and responds will
do so directly = to the ITR. do so directly to the = ITR.
=
8.4.1. Anycast = Map-Resolver Operation 8.4.1. Anycast = Map-Resolver Operation
=
A Map-Resolver = can be set up to use "anycast", where the same address A Map-Resolver can be set up to use "anycast", where = the same address
is assigned to = multiple Map-Resolvers and is propagated through IGP is assigned to multiple Map-Resolvers and is = propagated through IGP
routing, to = facilitate the use of a topologically close Map-Resolver = routing, to facilitate the use of a = topologically close Map-Resolver
by each = ITR. by each ITR.
=
Note that Map-Server associations with ETRs = SHOULD NOT use anycast ETRs MAY have anycast = RLOC addresses which are registered as = part of
addresses, as registrations need to be established = between an ETR and their RLOC-set to the mapping system. = However, registrations MUST
a specific set of Map-Servers, each identified by a = specific = use their unique RLOC addresses, xTR-IDs, or distinct = authentication
registration association. keys to identify security associations with the = Map-Servers.
=
9. Security = Considerations 9. Security = Considerations
=
The 2-way LISP = header nonce exchange documented in = The 2-way LISP header nonce exchange documented in
= [I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing = attacks. [I-D.ietf-lisp-rfc6830bis] = can be used to avoid ITR spoofing attacks.
=
To publish an = authoritative EID-to-RLOC mapping with a Map-Server, an = To publish an authoritative EID-to-RLOC = mapping with a Map-Server, an
ETR includes = authentication data that is a hash of the message using = ETR includes authentication data that is a = hash of the message using
a pair-wise = shared key. An implementation MUST support use of HMAC- = a pair-wise shared key. An implementation = MUST support use of HMAC-
SHA-1-96 = [RFC2104] and SHOULD support use of HMAC-SHA-256-128 SHA-1-96 [RFC2104] and SHOULD support use of = HMAC-SHA-256-128
=
skipping = to change at page 37, line = 43 =C2=B6 = skipping to change at page 38, line = 43 =C2=B6
10. Changes = since RFC 6833 10. Changes since RFC = 6833
=
For = implementation considerations, the following changes have been = For implementation considerations, the = following changes have been
made to this = document since RFC 6833 was published: = made to this document since RFC 6833 was published:
=
o A = Map-Notify-Ack message is added in this document to provide = o A Map-Notify-Ack message is added in this = document to provide
reliability = for Map-Notify messages. Any receiver of a Map-Notify reliability for Map-Notify messages. Any receiver = of a Map-Notify
message = must respond with a Map-Notify-Ack message. Map-Servers = message must respond with a = Map-Notify-Ack message. Map-Servers
who are = senders of Map-Notify messages, must queue the Map-Notify = who are senders of Map-Notify messages, = must queue the Map-Notify
contents = until they receive a Map-Notify-Ack with the nonce used = contents until they receive a = Map-Notify-Ack with the nonce used
in the = Map-Notify message. in the = Map-Notify message. Note that implementations = for Map-
= Notify-Ack = support already exist and predate this document.
=
o This = document is incorporating the codepoint for the Map-Referral = o This document is incorporating the = codepoint for the Map-Referral
message = from the LISP-DDT specification [RFC8111] to indicate that = message from the LISP-DDT specification = [RFC8111] to indicate that
a = Map-Server must send the final Map-Referral message when it = a Map-Server must send the final = Map-Referral message when it
= participates in the LISP-DDT mapping system procedures. = participates in the LISP-DDT mapping = system procedures.
=
o The "m", = "I", "L", and "D" bits are added to the Map-Request o The "m", "I", "L", and "D" bits are added to the = Map-Request
message. = See Section 5.3 for details. = message. See Section 5.3 for details.
=
o The "S", = "I", "E", "T", "a", and "m" bits are added to the Map- o The "S", "I", "E", "T", "a", and "m" bits are = added to the Map-
=
skipping = to change at page 40, line = 35 =C2=B6 = skipping to change at page 41, line = 35 =C2=B6
12.1. Normative = References 12.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-16 = (work in progress), = (LISP)", draft-ietf-lisp-rfc6830bis-17 = (work in progress),
= August 2018. September = 2018.
=
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
[RFC4868] = Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- = [RFC4868] Kelly, S. and S. Frankel, "Using = HMAC-SHA-256, HMAC-SHA-
= 384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC = 4868,
DOI = 10.17487/RFC4868, May 2007, = DOI 10.17487/RFC4868, May 2007,
= <https://www.rfc-editor.org/info/rfc4868>. = <https://www.rfc-editor.org/info/rfc4868>.
=
= [RFC8085] Eggert, = L., Fairhurst, G., and G. Shepherd, "UDP Usage
= = Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
= March = 2017, <https://www.rfc-editor.org/info/rfc8085>.
= =
12.2. = Informative References 12.2. = Informative References
=
[AFI] = IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY = [AFI] IANA, "Address Family Identifier = (AFIs)", ADDRESS FAMILY
= NUMBERS http://www.iana.org/assignments/address-family- = NUMBERS = http://www.iana.org/assignments/address-family-
= numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, = Febuary 2007.
=
= [GTP-3GPP] [GTP-3GPP]
= 3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) = Tunnelling
= Protocol User Plane (GTPv1-U)", TS.29.281 Protocol User Plane (GTPv1-U)", = TS.29.281
= https://portal.3gpp.org/desktopmodules/Specifications/ = https://portal.3gpp.org/desktopmodules/Specifications/
=
skipping = to change at page 45, line = 19 =C2=B6 = skipping to change at page 46, line = 19 =C2=B6
Fabio Maino, = and members of the lisp@ietf.org mailing list for their = Fabio Maino, and members of the = lisp@ietf.org mailing list for their
feedback and = helpful suggestions. feedback and = helpful suggestions.
=
Special thanks = are due to Noel Chiappa for his extensive work and Special thanks are due to Noel Chiappa for his = extensive work and
thought about = caching in Map-Resolvers. thought = about caching in Map-Resolvers.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6833bis-14 B.1. = Changes to draft-ietf-lisp-rfc6833bis-15
=
= o Posted = mid-September 2018.
=
= o Changes to = reflect comments from Colin and Mirja.
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-14
=
o Posted = September 2018. o Posted September = 2018.
=
o Changes to = reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, = and Secdir
= reviews. reviews.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-13 B.3. Changes to = draft-ietf-lisp-rfc6833bis-13
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-12 B.4. Changes to = draft-ietf-lisp-rfc6833bis-12
=
o Posted late = July 2018. o Posted late July = 2018.
=
o Moved = RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative = References.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-11 B.5. Changes to = draft-ietf-lisp-rfc6833bis-11
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for = RFC status and
ran through = IDNITs again. ran through IDNITs = again.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-10 B.6. Changes to = draft-ietf-lisp-rfc6833bis-10
=
o Posted = after LISP WG at IETF week March. o = Posted after LISP WG at IETF week March.
=
o Move AD = field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM = packet format
description = section. description = section.
=
o Say more = about when the new Drop actions should be sent. o Say more about when the new Drop actions should be = sent.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-09 B.7. Changes to = draft-ietf-lisp-rfc6833bis-09
=
o Posted = March IETF week 2018. o Posted = March IETF week 2018.
=
o Fixed = editorial comments submitted by document shepherd Luigi = o Fixed editorial comments submitted by = document shepherd Luigi
= Iannone. Iannone.
=
B.7. Changes to = draft-ietf-lisp-rfc6833bis-08 B.8. Changes to = draft-ietf-lisp-rfc6833bis-08
=
o Posted = March 2018. o Posted March = 2018.
=
o Added = RLOC-probing algorithm. o Added = RLOC-probing algorithm.
=
o Added = Solicit-Map Request algorithm. o = Added Solicit-Map Request algorithm.
=
o Added = several mechanisms (from 6830bis) regarding Routing Locator = o Added several mechanisms (from 6830bis) = regarding Routing Locator
= Reachability. = Reachability.
=
o Added port = 4342 to IANA Considerations section. = o Added port 4342 to IANA Considerations section.
=
B.8. Changes to = draft-ietf-lisp-rfc6833bis-07 B.9. Changes to = draft-ietf-lisp-rfc6833bis-07
=
o Posted = December 2017. o Posted December = 2017.
=
o Make it = more clear in a couple of places that RLOCs are used to = o Make it more clear in a couple of places = that RLOCs are used to
locate ETRs = more so than for Map-Server Map-Request forwarding. locate ETRs more so than for Map-Server = Map-Request forwarding.
=
o Make it = clear that "encapsualted" for a control message is an ECM = o Make it clear that "encapsualted" for a = control message is an ECM
based = message. based message.
=
o Make it = more clear what messages use source-port 4342 and which = o Make it more clear what messages use = source-port 4342 and which
=
skipping = to change at page 47, line = 13 =C2=B6 = skipping to change at page 48, line = 16 =C2=B6
Can use = othe AFIs then IPv4 and IPv6. = Can use othe AFIs then IPv4 and IPv6.
=
o Many = editorial changes to clarify text. = o Many editorial changes to clarify text.
=
o Changed = some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to = capitalized.
=
o Added = definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply = messages.
=
o Ran = document through IDNITs. o Ran = document through IDNITs.
=
B.9. Changes to = draft-ietf-lisp-rfc6833bis-06 B.10. Changes to = draft-ietf-lisp-rfc6833bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Spec the = I-bit to include the xTR-ID in a Map-Request message to = o Spec the I-bit to include the xTR-ID in a = Map-Request message to
be = consistent with the Map-Register message and to anticipate the = be consistent with the Map-Register = message and to anticipate the
= introduction of pubsub functionality to allow Map-Requests to = introduction of pubsub functionality to = allow Map-Requests to
subscribe = to RLOC-set changes. subscribe = to RLOC-set changes.
=
o Updated = references for individual submissions that became working = o Updated references for individual = submissions that became working
group = documents. group = documents.
=
o Updated = references for working group documents that became RFCs. = o Updated references for working group = documents that became RFCs.
=
B.10. Changes to = draft-ietf-lisp-rfc6833bis-05 B.11. Changes to = draft-ietf-lisp-rfc6833bis-05
=
o Posted May = 2017. o Posted May 2017.
=
o Update IANA = Considerations section based on new requests from this o Update IANA Considerations section based on new = requests from this
document = and changes from what was requested in [RFC6830]. document and changes from what was requested in = [RFC6830].
=
B.11. Changes to = draft-ietf-lisp-rfc6833bis-04 B.12. Changes to = draft-ietf-lisp-rfc6833bis-04
=
o Posted May = 2017. o Posted May 2017.
=
o Clarify how = the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in = Map-Register and Map-
Notify = messages. Break the 16-bit field into a 8-bit Key-ID field = Notify messages. Break the 16-bit field = into a 8-bit Key-ID field
and a 8-bit = Algorithm-ID field. and a 8-bit = Algorithm-ID field.
=
o Move the = Control-Plane codepoints from the IANA Considerations o Move the Control-Plane codepoints from the IANA = Considerations
section of = RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations = section of this
= document. document.
=
o In the = "LISP Control Packet Type Allocations" section, indicate = o In the "LISP Control Packet Type = Allocations" section, indicate
how message = Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how = experimental RFC8113
sub-types = should be requested. sub-types = should be requested.
=
B.12. Changes to = draft-ietf-lisp-rfc6833bis-03 B.13. Changes to = draft-ietf-lisp-rfc6833bis-03
=
o Posted = April 2017. o Posted April = 2017.
=
o Add types = 9-14 and specify they are not assigned. = o Add types 9-14 and specify they are not assigned.
=
o Add the = "LISP Shared Extension Message" type and point to RFC8113. = o Add the "LISP Shared Extension Message" = type and point to RFC8113.
=
B.13. Changes to = draft-ietf-lisp-rfc6833bis-02 B.14. Changes to = draft-ietf-lisp-rfc6833bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Clarify = that the LISP Control-Plane document defines how the LISP = o Clarify that the LISP Control-Plane = document defines how the LISP
Data-Plane = uses Map-Requests with either the SMR-bit set or the Data-Plane uses Map-Requests with either the = SMR-bit set or the
P-bit set = supporting mapping updates and RLOC-probing. Indicating = P-bit set supporting mapping updates and = RLOC-probing. Indicating
that other = Data-Planes can use the same mechanisms or their own that other Data-Planes can use the same mechanisms = or their own
defined = mechanisms to achieve the same functionality. defined mechanisms to achieve the same = functionality.
=
B.14. Changes to = draft-ietf-lisp-rfc6833bis-01 B.15. Changes to = draft-ietf-lisp-rfc6833bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Remove = references to self. o Remove = references to self.
=
o Change = references from RFC6830 to RFC6830bis. = o Change references from RFC6830 to RFC6830bis.
=
o Add two new = action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has = posted to the LISP
WG mailing = list. WG mailing list.
=
o In intro = section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to = I-D.ietf-lisp-introduction.
=
o Removed = Open Issues section and references to "experimental". o Removed Open Issues section and references to = "experimental".
=
B.15. Changes to = draft-ietf-lisp-rfc6833bis-00 B.16. Changes to = draft-ietf-lisp-rfc6833bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6833-00 = individual submission. No other changes made. -rfc6833-00 individual submission. No other = changes made.
=
B.16. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.17. Changes to = draft-farinacci-lisp-rfc6833bis-00
=
o Posted = November 2016. o Posted November = 2016.
=
o This is the = initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into = RFC 6833bis.
=
o The = document name has changed from the "Locator/ID Separation = o The document name has changed from the = "Locator/ID Separation
Protocol = (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the = "Locator/ID
Separation = Protocol (LISP) Control-Plane". = Separation Protocol (LISP) Control-Plane".
=
o The = fundamental change was to move the Control-Plane messages from = o The fundamental change was to move the = Control-Plane messages from
 End of changes. 40 change blocks. 
100 lines changed or = deleted 137 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_BA4D8C21-DC21-434D-87F6-5658E8EB32FE-- From nobody Mon Sep 17 09:16:58 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70871130E95 for ; Mon, 17 Sep 2018 09:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 UgrdEj-YE_en for ; Mon, 17 Sep 2018 09:16:53 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED46130E84 for ; Mon, 17 Sep 2018 09:16:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=uQ/jxB/yRbeIUG/rFPx9qroXXab9Ierbr367HSDbZMf9zkXKY5123Di7mss6USwLQ5iZiv0jGwcmJ30XZ+RR8eJl4trs6YeKuhWbnLW6WkQ0DFKpaqYJ8InZP8VmFspqBIHZjXbwzihNiCKRKfLyjTcZQ30pRgQaZCCNO7CuFJI=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 6945 invoked from network); 17 Sep 2018 18:15:50 +0200 Received: from mue-88-130-61-174.dsl.tropolys.de (HELO ?192.168.178.24?) (88.130.61.174) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Sep 2018 18:15:50 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> Date: Mon, 17 Sep 2018 18:15:42 +0200 Cc: lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, The IESG , Luigi Iannone , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) X-PPP-Message-ID: <20180917161550.6936.81331@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 17 Sep 2018 16:16:57 -0000 Hi Dino, unfortunately, I don=E2=80=99t think this is quite there yet. First of = all, I have to say that I misread the original text which already says = that only the CE should be copied which is at least mostly inline with = RFC6040 already. However, I really would like the existing text to be = clearer here (instead of just adding additional text). Also you still need at least one reference to rfc3168 because that=E2=80=99= s the spec that defines the mechanism and IP bits. Let me propose something: For encapsulation: OLD "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header.=E2=80=9C PROPOSED "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) [RFC3168] requires special = treatment in order to preserve the use of ECN on the path. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header, inline with the =E2=80=99Normal = Mode=E2=80=99 in section 4.1=20 of [RFC6040]. Re-encapsulation SHOULD follow the decapsulation as = described=20 below and then 2-bit 'ECN' field from the stripped inner header to = the=20 new outer header.=E2=80=9C For decapsulation: OLD "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168]. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints.=E2=80=9C PROPOSED "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment on=20= decapsulation in order to avoid discarding indications of congestion,=20 inline with section 4.2 of [RFC6040]. If the 'ECN=E2=80=98 field of the outer header contains a congestion = indication =09 codepoint (the value is '11', the Congestion Experienced (CE) codepoint) and the = inner=20 header indicates ECN support (either ECT(0) or ECT(1) codepoint is = set),=20 then ETR decapsulation MUST also set CE field in the inner header = that is=20 used to forward the packet beyond the ETR. If the inner packet is = marked as non- ECT but the outer header has the CE mark set, the packet MUST be = dropped=20 instead. Any discrepancy between the inner and outer header for = non-ECT,=20 ECT(0) and ECT(1) MUST NOT be copied from the outer header. These=20= requirements preserve CE indications when a packet that is ECN-capable traverses a LISP = tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints or transforms an CE into loss if that packet = is not=20 ECN-capable conserving the congestion indication towards a non-ECN = enables=20 endpoint." Please also remove the duplicated text after these bullet lists in the = draft! Further I believe my discuss points 2) and 4) are not fully resolved = yet. Also I would like to at least see more explanation about the = approach for extensibility that was taken in this doc (point 6). Mirja =20 > Am 12.09.2018 um 23:30 schrieb Dino Farinacci : >=20 >> Hi again, >>=20 >> please see below. >=20 > Thanks for the ongoing discussion Mirja. See a new diff file enclosed = as a proposed -18 update. Let me know if the text I added to address = your comments are sufficient. >=20 > I believe (but could be wrong) that this should be the last set of = comments to 6830bis. But I have not seen any acks from Alvaro if we = addressed all his comments (specifically for 6830bis). >=20 >>=20 >>> Am 11.09.2018 um 18:45 schrieb Dino Farinacci : >>>=20 >>>=20 >>>>> Well it doesn=E2=80=99t have to be. I am a bit hesitant to just = point to another long complicated RFC. This text has gone through review = for quite a long time and many ECN experts decided we should write it = this way. And this text did go through IESG review when RFC6830 was made = experimental RFC. >>>>=20 >>>> Procedere explained in RFC6040 are actually not that complicated. = It=E2=80=99s mainly the table provided in section 3.2. Please have a = look at the draft. However, I disagree that it =E2=80=9Enegative=E2=80=9C = to point for this part to another RFC. This is not a unique problem, = that=E2=80=99s why we have RFC6040 and all approaches that face this = problem should point to RFC6040 and implement the same strategy. >>>=20 >>> I am just worried it will be ignored because there are = implementations out there that do what they already do. If we want to = suggest to consider the procedures in RFC6040, I am okay with that, but = you need to provide the wording because I certainly don=E2=80=99t want = it too strong. >>=20 >> Actually the behavior as currently described in the lisp draft is not = even complainant with rfc3138, however, rfc3168 is updated by rfc6040. = The encapsulation in the lisp draft behavior is already what RFC6040 = described; so that=E2=80=99s good. However, the decapsulation is neither = what RFC3168 nor rfc6040 says. Therefore this must be fixed and I guess = a bis doc is also the best chance we get to fix these incorrect = implementation then. If you are worried that this will be ignored, you = should mention it explicitly in section 18 (Changes since RFC 6830). >=20 > The working group made this decsision back in 2009 when the LISP WG = was formed. Actually earlier when we did the initial work in the IRTF = RRG. RFC3168 was published in Sep 2001. But note one of the authors, = David Black, offered the text you see in the document rewgarding ECN = handling. >=20 > So by doing this update, we ARE going to create a implementation = incompatibility. >=20 >> There is no matter about the wording being too strong or whatever, = RFC6040 is very clear about the correct behavior and that is exactly = what needs to be implemented. Please go ahead and read RFC6040. If you = need further help, please ask an ECN expert for help, e.g. Bob Briscoe = who is the author of RFC6040. >=20 > Check the diff file to see if you are okay with the new text added. It = WAS NOT simple because there are a number of cases that need to be = described that doesn=E2=80=99t contradict RFC6040 that I do not want to = repeat. >=20 >> Please note that I actually pointer to a wrong section in RFC6040 = above. It should of course be 4.2 (and not 3.2). >=20 > Okay, that makes more sense now. I was confused. >=20 >>>>>=20 >>>>>=20 >>>>>> 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets = while >>>>>> "IPv4-encapsulated packet with the DF bit set to 1" should be = addressed as well. >>>>>=20 >>>>> This is discussed in length. I don=E2=80=99t know how you could = have missed this. >>>>=20 >>>> I didn't miss that discussion but the text got fixed incorrectly = because it doesn=E2=80=99t not address IPv4 through the whole text. = Please have a look and fix that as well. I think this is mainly an = editorial issue but and important one to fix. >>>=20 >>> I am sorry. I don=E2=80=99t know what you think is wrong. Please = point to the text specifically. >>=20 >> Sec 7.2: >> " 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated = packet >> with the DF bit set to 1, exceeds what the core network can >> deliver, one of the intermediate routers on the path will send = an >> ICMPv6 "Packet Too Big" message to the ITR. The ITR will parse >> ^^^^^^^^^^^^^^^^^^^^^^ >> there will be no ICMPv6 message is the packet was IPv4 >>=20 >> the ICMPv6 message to determine which Locator is affected by the >> effective MTU change and then record the new effective MTU value >> in the Map-Cache entry. >>=20 >> 3. When a packet is received by the ITR from a source inside of the >> site and the size of the packet is greater than the effective = MTU >> stored with the Map-Cache entry associated with the destination >> EID the packet is for, the ITR will send an ICMPv6 "Packet Too >> ^^^^^^^^^^^^^^^^^^^ >>=20 >> Big" message back to the source. The packet size advertised by >> the ITR in the ICMPv6 message is the effective MTU minus the = LISP >> encapsulation length.=E2=80=9D >=20 > This is now fixed. I now understand your comment. Please check the = diff file enclosed. >=20 >>>=20 >>>>>=20 >>>>>> 6) And now the more-discussion-needed point: >>>>>> So my underlying concern is the same as brought up by the TSV-ART = review that >>>>>> lisp information are not end-to-end integrity protected or = authenticated. >>>>>=20 >>>>> I would like you to be more specific. Beacuse there is a lot of = security in the protocol and we believe the current drafts, in their = entirety, inicdate so. >>>>=20 >>>> I was thinking about the option to add an authenticated hash, = anyway=E2=80=A6 >>>=20 >>> LISP uses lisp-crypto (RFC8061) which uses AEAD. >>=20 >> I think the pity here is that RFC8061 is still a separate optional = RFC. I would have expected to have this integrated into rfc6830bis and = make it mandatory to implement if not mandatory to use. >=20 > Agree. I don=E2=80=99t know what to tell you. But as you might now, = there is a tradeoff between privacy and monitoring/lawful intercept that = is being made and we know there are strong camps on each side. >=20 > You might have heard me say it at a recent IETF plenary =E2=80=9Ceveryth= ing should be encrypted, period=E2=80=9D. So you know what camp I=E2=80=99= m in. ;-) >=20 >>=20 >>>=20 >>>>>=20 >>>>>> However, while briefly thinking about how this could be = eventually realized, I >>>>>> noticed that there is actually no mechanism to extend the LISP = header in any >>>>>=20 >>>>> Right, by design so it is efficient for hardware AND software = forwarding. But we do have the LISP-GPE header that can be used for = extensions. But that has limited deployment. >>>>>=20 >>>>>> way. There is no version, no option and the LISP header seems to = have a fixed, >>>>>=20 >>>>> We decdied as a working group that the UDP port number would = indicate what header follows and therefore what LISP version is used. >>>>=20 >>>> Okay, that needs to be explained in the doc! >>>>=20 >>>> Mirja >>>=20 >>> The document says that UDP port 4341 is assigned and when so, the = LISP header as docmented is used. We shouldn=E2=80=99t just encourage = versioning if the philosophy it not to churn often. >>=20 >> Okay, that is actually not possible based on the recommendation in = RFC6335: >>=20 >> " o IANA strives to assign only one assigned port number for all >> variants of a service (e.g., for updated versions of a = service).=E2=80=9C >>=20 >> That means it is not possible to get another port number for a new = version of lisp. You need a different version approach. >>=20 >> Mirja >=20 > The working group made this decsision back in 2009 when the LISP WG = was formed. Actually earlier when we did the initial work in the IRTF = RRG. RFC3168 was published in Aug 2011. >=20 > LISP-GPE is a variant of the the LISP data-plane, and it is using the = same UDP port 4341. So we actually accomplished the reuse. >=20 > Dino >=20 > >=20 >=20 From nobody Mon Sep 17 09:31:18 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62FF127B92 for ; Mon, 17 Sep 2018 09:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bartschnet.de 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 mmGOISJZJg27 for ; Mon, 17 Sep 2018 09:31:14 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1931130F16 for ; Mon, 17 Sep 2018 09:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bartschnet.de; s=2018030201; h=Content-Transfer-Encoding:MIME-Version:Date: Message-ID:From:To:Subject:content-disposition; bh=UoVquc+781d6MZkYEolcfx0mk2qKFDWm1QibIg2Ld8A=; b=isULbOUmS/EZy3bm+dfs5ZmOc5 mRDiH4P5/4GNYS/SNXJZI+IWKLRycN3AovB34RjhpqrzVTWlQ2W8Fw02cMRW8nVEvI66LuHvvIldv BNRB0AeNIjIcS5hCVa4G1xQEyowo0UdQCOBv2KVZuY5TRMjeaZ2nOBg724WLnHxiZEzRyTAngjYDH AR8LDSUR+0hc3lSIpNAuwxHFVpNWq9JBdNaeHhkUqUPnpBMLIJbNKTQkUB6iBgUgwtm3FqhuDTIZS 7Yp3O1oD6Lnz5lBQSxCowlUoVenPb/e67rKtQT47LpIdIhHwNWgFsAjLR7hiXWWbz/qhTr/gc2uaC 2IoR66BYOiGoqQ4Jxalv3aaksecOatV7jFSfPyzfN24ram+YhIZbCHuha0WZbWQM5H9l0OY/GU4m1 EiBZaRcle9RwHYqbJelQzyDsP/KmrDL83tSMKkgBDiTcguFEI0kDAovKtqSWVHacUItouHaL5B0zq NAMXqsksYUaxS7VaH8oxPU9xsEsH0gftrdnRh4emkoAw7+KPEfNw4tnwFcXsXOmeb+sGHxXjY4IJU 4SdrmwGRTiDwv/rfRFbv3rwE3kyH3KCvzcpcHy4qvBWzbP6lYnfQzGEhPq3JADOHqFtnaSz6juahu P83LrhpNKws3pjUAmxtB8/fxegfu1ApIdsLSGW5XA=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1g1wQ5-00009e-OX with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for lisp@ietf.org; Mon, 17 Sep 2018 18:30:43 +0200 To: lisp@ietf.org References: From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: Date: Mon, 17 Sep 2018 18:30:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] Read this latest diff file for 6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 17 Sep 2018 16:31:17 -0000 Am 17.09.18 um 18:04 schrieb Dino Farinacci: > Also from Renne/Darrel comments about anycast addressing for ETRs. Reworded some of that paragraph. Great! Did I miss implicit statements about anycast addresses of map-servers and ITRs or is there no rule? Regards, Renne From nobody Mon Sep 17 10:12:26 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDECC130EDA for ; Mon, 17 Sep 2018 10:12:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7ad-fus2Ef15 for ; Mon, 17 Sep 2018 10:12:13 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 A47EE130EEF for ; Mon, 17 Sep 2018 10:12:13 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id f1-v6so7724579plt.4 for ; Mon, 17 Sep 2018 10:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q3NBQ3anqk940ITXPRwA8A6EYPNPOSlgmhhfJXzHLmA=; b=Zekyy/bCjBBfj53SdMbCga8wd8m05vMI0N/qA+0fLMLDXi0iEsE/X4soURAzEC57vs crxbbl8GU6VF7LOQvDhf6aSItfo7F0C/qV2VAw31ksi4Up7vwt4gl9nFHrVeV0J7bTSC I1/yY7FJhuU+68u+NMswC2ROfNJaSOtH5P4pSC+nolXhjRweWhoRMKQpEvXPUdPydJWa T6n6OaY8tAgnzB/04TsluUhLK6CCsy2NgkK3K2E3PGstnIXwnd6c1xLg2es/fx/EqHEf K1iH7qmxiXpAyi5leV+o1lRJBk8G6dV8NbachnzuU75k36XGqyJCbzLzWXJUrP6x4cvt mvvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q3NBQ3anqk940ITXPRwA8A6EYPNPOSlgmhhfJXzHLmA=; b=jiGwc3gQnPG0ee/C7B5smDgdy8c6cgkkR3+JxHz3Z5/m8quHa9dYf0vd5YuzhD3gds kt+AgIcmqPTU8AvbBXMLiRGScY+CqZYpLpk7Amhg7p5OWqsvPF0PmJuWrwxoMUYvYLGO vANQAGBh9uheUZZReAAb3/uTyK7tk02U82Kw+Z2WkwqMnTFjXOLr6GN251NBeG3rjNUm cSjk/YsqIpZ4TbcyB3BwKWU784tcBRyI7mV+JHykSdn9SaQh25IntYlnSJTyb0R/SOcR QIZgVbHssIvgLTiMRpl8mVMTYlkRh6xlh+FSrWH72b3FDWVU9wrtq7gWhtbytimU5BHY 9Qgw== X-Gm-Message-State: APzg51DKhRTfs2QeqxSeHzSq02xiIQC1X4KpXomi5nkWmwgOqApWS+W1 NjrOJShcfLfVIXD5/DewrTY= X-Google-Smtp-Source: ANB0Vdba1zwhH01N1I7h/Ul3hS2EtI5Kh9G/c81NL69o5RSZeldzfqGNzmUlBrylDwtTZBzivDqu3A== X-Received: by 2002:a17:902:25ab:: with SMTP id y40-v6mr25161848pla.120.1537204333083; Mon, 17 Sep 2018 10:12:13 -0700 (PDT) Received: from [10.10.10.70] ([4.28.87.67]) by smtp.gmail.com with ESMTPSA id 3-v6sm26867536pfq.10.2018.09.17.10.12.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Sep 2018 10:12:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Mon, 17 Sep 2018 10:12:11 -0700 Cc: lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Rene 'Renne' Bartsch, B.Sc. Informatics" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Read this latest diff file for 6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 17 Sep 2018 17:12:25 -0000 It doesn=E2=80=99t make semantic sense to have anycast addresses for = ITRs since they are sender/encapsulators and nothing gets sent to them = as a service discovery entity. However, obviously, an xTR, is both a = co-located ITR and ETR, in which case, an anycast RLOC be assigned to it = (the ETR part of it). Dino > On Sep 17, 2018, at 9:30 AM, Rene 'Renne' Bartsch, B.Sc. Informatics = wrote: >=20 >=20 >=20 > Am 17.09.18 um 18:04 schrieb Dino Farinacci: >> Also from Renne/Darrel comments about anycast addressing for ETRs. = Reworded some of that paragraph. >=20 > Great! >=20 > Did I miss implicit statements about anycast addresses of map-servers = and ITRs or is there no rule? >=20 > Regards, >=20 > Renne >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Sep 17 10:48:23 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B36124BE5; Mon, 17 Sep 2018 10:48:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TOAR0CFjTa7K; Mon, 17 Sep 2018 10:48:13 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 92D931200D7; Mon, 17 Sep 2018 10:48:13 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id x17-v6so7912705pfh.5; Mon, 17 Sep 2018 10:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pz7sMS2g+Z+37m7O9NNgo8Q3UJobycRBCSxZRKX7kZw=; b=a8zZw96JpbIsWsP6xd3X56N1upM4CuIa6+SzecNTaHoYX0RmXkYgoMyx4N4OmskCv3 zUKQIBkBfj5B9uoy2+i7igyjVzrffqIVDDgrmUUuW47omsINptmWtiTA6eUQoFUhMsQo 4wg3LKCTkyA7arLuGG4faqI/B0XbuF9WKjUvUCr5WW58nJcCm9AhxlmOBjrDHFmz3w2u jCfbFjneNagVyiB34rJP6RyAnVmISviWxjgEUpD7WzlW05yuuk7Qk07bYxRpU85fcO5S Oipp1pY86LjfV6jYR1zZMWS3Z4Ql5EWlT+KFwQEWcsVu6ShATAkEviEXjm6+crdnKJaF UvGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pz7sMS2g+Z+37m7O9NNgo8Q3UJobycRBCSxZRKX7kZw=; b=UqCiG/SeX5RG0AQTVm3UAT7bXzD7v6ajQtE3ewo8UyFP4ft8kLo1V4xV5GQ0yWZjnF dE7I6b2WF63/45AzqOHeEXmIzmX4WzfSQ4hQCMTtMGYeYY/loONi1vLH9joDYCGl744f 42f+rub+jrNQkclebwcTsU1mvJDa/FtOmt2X4B8en7U9v2oVJj2CluettxJHSSah1F7k nF5kTwaOLB6FTV6CNZXK2ohN8ElTSBmoD8k/3bv/McQ7SORFWqga5yX+AaRVsuSJdX4B IB8GRMpKRgTlJJ5Oc3K9TmMuWEjm2QTcgv/aAkBcrsPL74j4J+6vFPZ6NJlx+OrAcUrN Kskg== X-Gm-Message-State: APzg51CicW8po8OrD0JEdfMUpicSfTo0AzLo5aCsuhW0wKogDbt47i+e 93uKmU94tBrccvFWzyQ10urUA5Vp X-Google-Smtp-Source: ANB0VdbQ84EItjJy8bgMxVhzOS/vDv2PGV9IwS9fMM9Tt8jcRPZR+VL8AAVogHoD/hFKCtr8SdIsow== X-Received: by 2002:a63:c114:: with SMTP id w20-v6mr23544215pgf.234.1537206493043; Mon, 17 Sep 2018 10:48:13 -0700 (PDT) Received: from [10.10.10.70] ([4.28.87.67]) by smtp.gmail.com with ESMTPSA id i26-v6sm18841413pfo.107.2018.09.17.10.48.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Sep 2018 10:48:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> Date: Mon, 17 Sep 2018 10:48:11 -0700 Cc: lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, The IESG , Luigi Iannone , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com> References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 17 Sep 2018 17:48:16 -0000 > PROPOSED > "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) [RFC3168] requires special = treatment in > order to preserve the use of ECN on the path. > ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner > header to the outer header, inline with the =E2=80=99Normal = Mode=E2=80=99 in section 4.1=20 > of [RFC6040]. Re-encapsulation SHOULD follow the decapsulation = as described=20 > below and then 2-bit 'ECN' field from the stripped inner header = to the=20 > new outer header.=E2=80=9C I did not include this text because the last sentence is not formed = well. Please restate. A verb is missing. > "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment on=20= > decapsulation in > order to avoid discarding indications of congestion,=20 > inline with section 4.2 of [RFC6040]. If > the 'ECN=E2=80=98 field of the outer header contains a congestion = indication =09 > codepoint (the > value is '11', the Congestion Experienced (CE) codepoint) and the = inner=20 > header indicates ECN support (either ECT(0) or ECT(1) codepoint = is set),=20 > then ETR decapsulation MUST also set CE field in the inner header = that is=20 > used > to forward the packet beyond the ETR. If the inner packet is = marked as non- > ECT but the outer header has the CE mark set, the packet MUST be = dropped=20 > instead. Any discrepancy between the inner and outer header for = non-ECT,=20 > ECT(0) and ECT(1) MUST NOT be copied from the outer header. These=20= > requirements preserve > CE indications when a packet that is ECN-capable traverses a LISP = tunnel > and becomes marked with a CE indication due to congestion between > the tunnel endpoints or transforms an CE into loss if that packet = is not=20 > ECN-capable conserving the congestion indication towards a = non-ECN enables=20 > endpoint.=E2=80=9D I didn=E2=80=99t include this text because (1) it under states what to = do with IPv4, (2) it has too much detail that is already in RFC6040, and = (3) it undoes text that other reviewers have offered. > Please also remove the duplicated text after these bullet lists in the = draft! You have to tell me what text. I am too confused at this point on what = you want. > Further I believe my discuss points 2) and 4) are not fully resolved = yet. Also I would like to at least see more explanation about the = approach for extensibility that was taken in this doc (point 6). You are going to have to repeat what they are because too many emails = have flown by since your initial post. And for extensibility, we discuss = it in RFC8060 and don=E2=80=99t think anything more should be said here = otherwise, we will duplicate unnecessary text. Another new diff file enclosed. Dino From nobody Mon Sep 17 10:59:34 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D900C1274D0; Mon, 17 Sep 2018 10:59:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153720716686.24868.1167129610578400593@ietfa.amsl.com> Date: Mon, 17 Sep 2018 10:59:26 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-18.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 17 Sep 2018 17:59:27 -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 WG of the IETF. Title : The Locator/ID Separation Protocol (LISP) Authors : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Albert Cabellos Filename : draft-ietf-lisp-rfc6830bis-18.txt Pages : 44 Date : 2018-09-17 Abstract: This document describes the Data-Plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. This document obsoletes RFC 6830. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-18 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-18 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 Tue Sep 18 01:14:55 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66C2128D0C for ; Tue, 18 Sep 2018 01:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 3p4jr4o_FTcM for ; Tue, 18 Sep 2018 01:14:50 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 43DE3127AC2 for ; Tue, 18 Sep 2018 01:14:50 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id e1-v6so1035746wrt.3 for ; Tue, 18 Sep 2018 01:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OWp4gjnGkoN1ViHm1rF9jmBG14eISnX+wSHD726xAD4=; b=QT29CSjg+5gAsupAsfyAmbiNzEpy4FXCcyrg/EKPU95GsTLi2S/Pjh+8L4svkPL4XW yezhCKvj7k255Gwa9WCe7KXKKZKwjiUEC1/IUlC7ijsWEdi6SjHZn8LWeYYOSJxA+22o Z7XaVAway47Pg5qsGT4G6/hMt0pxsfzjvQH/78JSjKm+ySeIDj/oDnrTuINzYMAWGR6o ZtPbxnn6zGpva776RtIkCIqc/cvH75PhelwwezznIudnRpM8BCs5L/A2PEXCMvhedowJ 31ShKcTJvg6htFacT6Qeijn4CmFZ5CKmVRnPzYtWW/i06miWfQI+/8SHpiPL5x9iXfxY X6jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OWp4gjnGkoN1ViHm1rF9jmBG14eISnX+wSHD726xAD4=; b=AP/dEX7eWS+aWsocse7xifQytmClCPiVkIOqDHd2p9ZqBweLUhHzaExkPlwra/7dYV lB8Zc5GJhYxzGJfIhrvzGDVoa2q7YJl3z0nqGk3m7SDYAJpihSpt40wp1SuYbx3MpX7Z BQIL1IKiZtAMNW1hJi890MnGUhva981t4yiPH0sSsI/t5HTj+Yc86Vu58uBp89mI+4zK p1NAOKz6xcpHUjNvuLGz35SSC8oHS/mri930K/8Itefukz1Zl8WW2GtxYhWTF4ZqdFBv LZfVTbtE+U6iZnS4Ni0zGS/B1bAj7sOzeERPRagqNNmdH3prVnWUGFGY+lZMWvP7ERtt 84iA== X-Gm-Message-State: APzg51CwJXmNUCgTejEoFT3QhStLapgixapyb9jQfOEk/mdstLDfuCDp YKka8d4+PTgP1X9oJ8YSmUrFAg== X-Google-Smtp-Source: ANB0VdaRVzl0tnR0x/Xdn4sIat0sCe8DygV0JPT6XOEwkCYHnJXHwkJIEUha0DGDfxIRQqOcULiDeA== X-Received: by 2002:a5d:4e0a:: with SMTP id p10-v6mr21361778wrt.48.1537258488526; Tue, 18 Sep 2018 01:14:48 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:25f4:45e1:39b9:1fee? ([2001:660:330f:a4:25f4:45e1:39b9:1fee]) by smtp.gmail.com with ESMTPSA id k5-v6sm13725865wrm.96.2018.09.18.01.14.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Sep 2018 01:14:47 -0700 (PDT) From: Luigi Iannone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_656AF8F2-D1D1-473D-ACDF-2A4D695242AF" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 18 Sep 2018 10:14:52 +0200 In-Reply-To: <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> Cc: Dino Farinacci , lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, The IESG , "lisp@ietf.org list" To: "Mirja Kuehlewind (IETF)" References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 18 Sep 2018 08:14:54 -0000 --Apple-Mail=_656AF8F2-D1D1-473D-ACDF-2A4D695242AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dino, Mirja, a couple of comments inline. Thanks=20 > On 17 Sep 2018, at 18:15, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Dino, >=20 > unfortunately, I don=E2=80=99t think this is quite there yet. First of = all, I have to say that I misread the original text which already says = that only the CE should be copied which is at least mostly inline with = RFC6040 already. However, I really would like the existing text to be = clearer here (instead of just adding additional text). >=20 > Also you still need at least one reference to rfc3168 because that=E2=80= =99s the spec that defines the mechanism and IP bits. >=20 > Let me propose something: >=20 > For encapsulation: > OLD > "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion [RFC3168]. > ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner > header to the outer header. Re-encapsulation MUST copy the 2-bit > 'ECN' field from the stripped outer header to the new outer > header.=E2=80=9C > PROPOSED > "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) [RFC3168] requires special = treatment in > order to preserve the use of ECN on the path. > ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner > header to the outer header, inline with the =E2=80=99Normal = Mode=E2=80=99 in section 4.1=20 > of [RFC6040]. Re-encapsulation SHOULD follow the decapsulation = as described=20 > below and then 2-bit 'ECN' field from the stripped inner header = to the=20 > new outer header.=E2=80=9C >=20 > For decapsulation: > OLD > "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion [RFC3168]. = If > the 'ECN' field contains a congestion indication codepoint (the > value is '11', the Congestion Experienced (CE) codepoint), then > ETR decapsulation MUST copy the 2-bit 'ECN' field from the > stripped outer header to the surviving inner header that is used > to forward the packet beyond the ETR. These requirements = preserve > CE indications when a packet that uses ECN traverses a LISP = tunnel > and becomes marked with a CE indication due to congestion between > the tunnel endpoints.=E2=80=9C @Mirja: As Dino pointed out the last sentence is unclear. > PROPOSED > "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment on=20= > decapsulation in > order to avoid discarding indications of congestion,=20 > inline with section 4.2 of [RFC6040]. If > the 'ECN=E2=80=98 field of the outer header contains a congestion = indication =09 > codepoint (the > value is '11', the Congestion Experienced (CE) codepoint) and the = inner=20 > header indicates ECN support (either ECT(0) or ECT(1) codepoint = is set),=20 > then ETR decapsulation MUST also set CE field in the inner header = that is=20 > used > to forward the packet beyond the ETR. @Mirja: So far so good. Is the equivalent of what is already there. > If the inner packet is marked as non- > ECT but the outer header has the CE mark set, the packet MUST be = dropped=20 > instead. @ Mirja: How can this happen? As for your text we MUST copy inner CE to = outer CE when encapsulating, so if the original packet does not support = ECN the outer header will state so and there will not be any CE mark = set. > Any discrepancy between the inner and outer header for non-ECT,=20 > ECT(0) and ECT(1) MUST NOT be copied from the outer header. These=20= > requirements preserve > CE indications when a packet that is ECN-capable traverses a LISP = tunnel > and becomes marked with a CE indication due to congestion between > the tunnel endpoints or transforms an CE into loss if that packet = is not=20 > ECN-capable conserving the congestion indication towards a = non-ECN enables=20 > endpoint." >=20 > Please also remove the duplicated text after these bullet lists in the = draft! >=20 > Further I believe my discuss points 2) @ Dino: this point is about the following bullet in section 5.3: The outer-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header DSCP field ('Traffic Class' field, in the case of IPv6) considering the exception listed below. You need to delete the trailing =E2=80=9Cconsidering the exception = listed below=E2=80=9D because there is no exception listed. > and 4) @ Mirja: This point is about all packets of the same flow having the = same source port number. Version -17 includes the following sentence in = section 12: The source port SHOULD be the same for all packets belonging to the same flow. As you have requested. > are not fully resolved yet. Also I would like to at least see more = explanation about the approach for extensibility that was taken in this = doc (point 6). @Mirja: Would you mind being more explicit? I fail to see the exact = point you are trying to make. Dino already explained the rationale of why LISP is as it is. We can = discuss endlessly whether was a good or bad choice, but it is what it is = and we cannot change it now. IMHO, it is not worth to add any discussion on this matter in this = document.=20 Unless we just keep it to a simple sentence like:=20 =E2=80=9CExtension to the LISP header described in this document can be = achieved using the LISP General Protocol Encapsulation mechanism = [draft-ietf-lisp-gpe]."=20 Ciao L. > Mirja >=20 >=20 >> Am 12.09.2018 um 23:30 schrieb Dino Farinacci : >>=20 >>> Hi again, >>>=20 >>> please see below. >>=20 >> Thanks for the ongoing discussion Mirja. See a new diff file enclosed = as a proposed -18 update. Let me know if the text I added to address = your comments are sufficient. >>=20 >> I believe (but could be wrong) that this should be the last set of = comments to 6830bis. But I have not seen any acks from Alvaro if we = addressed all his comments (specifically for 6830bis). >>=20 >>>=20 >>>> Am 11.09.2018 um 18:45 schrieb Dino Farinacci = : >>>>=20 >>>>=20 >>>>>> Well it doesn=E2=80=99t have to be. I am a bit hesitant to just = point to another long complicated RFC. This text has gone through review = for quite a long time and many ECN experts decided we should write it = this way. And this text did go through IESG review when RFC6830 was made = experimental RFC. >>>>>=20 >>>>> Procedere explained in RFC6040 are actually not that complicated. = It=E2=80=99s mainly the table provided in section 3.2. Please have a = look at the draft. However, I disagree that it =E2=80=9Enegative=E2=80=9C = to point for this part to another RFC. This is not a unique problem, = that=E2=80=99s why we have RFC6040 and all approaches that face this = problem should point to RFC6040 and implement the same strategy. >>>>=20 >>>> I am just worried it will be ignored because there are = implementations out there that do what they already do. If we want to = suggest to consider the procedures in RFC6040, I am okay with that, but = you need to provide the wording because I certainly don=E2=80=99t want = it too strong. >>>=20 >>> Actually the behavior as currently described in the lisp draft is = not even complainant with rfc3138, however, rfc3168 is updated by = rfc6040. The encapsulation in the lisp draft behavior is already what = RFC6040 described; so that=E2=80=99s good. However, the decapsulation is = neither what RFC3168 nor rfc6040 says. Therefore this must be fixed and = I guess a bis doc is also the best chance we get to fix these incorrect = implementation then. If you are worried that this will be ignored, you = should mention it explicitly in section 18 (Changes since RFC 6830). >>=20 >> The working group made this decsision back in 2009 when the LISP WG = was formed. Actually earlier when we did the initial work in the IRTF = RRG. RFC3168 was published in Sep 2001. But note one of the authors, = David Black, offered the text you see in the document rewgarding ECN = handling. >>=20 >> So by doing this update, we ARE going to create a implementation = incompatibility. >>=20 >>> There is no matter about the wording being too strong or whatever, = RFC6040 is very clear about the correct behavior and that is exactly = what needs to be implemented. Please go ahead and read RFC6040. If you = need further help, please ask an ECN expert for help, e.g. Bob Briscoe = who is the author of RFC6040. >>=20 >> Check the diff file to see if you are okay with the new text added. = It WAS NOT simple because there are a number of cases that need to be = described that doesn=E2=80=99t contradict RFC6040 that I do not want to = repeat. >>=20 >>> Please note that I actually pointer to a wrong section in RFC6040 = above. It should of course be 4.2 (and not 3.2). >>=20 >> Okay, that makes more sense now. I was confused. >>=20 >>>>>>=20 >>>>>>=20 >>>>>>> 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets = while >>>>>>> "IPv4-encapsulated packet with the DF bit set to 1" should be = addressed as well. >>>>>>=20 >>>>>> This is discussed in length. I don=E2=80=99t know how you could = have missed this. >>>>>=20 >>>>> I didn't miss that discussion but the text got fixed incorrectly = because it doesn=E2=80=99t not address IPv4 through the whole text. = Please have a look and fix that as well. I think this is mainly an = editorial issue but and important one to fix. >>>>=20 >>>> I am sorry. I don=E2=80=99t know what you think is wrong. Please = point to the text specifically. >>>=20 >>> Sec 7.2: >>> " 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated = packet >>> with the DF bit set to 1, exceeds what the core network can >>> deliver, one of the intermediate routers on the path will send = an >>> ICMPv6 "Packet Too Big" message to the ITR. The ITR will parse >>> ^^^^^^^^^^^^^^^^^^^^^^ >>> there will be no ICMPv6 message is the packet was IPv4 >>>=20 >>> the ICMPv6 message to determine which Locator is affected by the >>> effective MTU change and then record the new effective MTU value >>> in the Map-Cache entry. >>>=20 >>> 3. When a packet is received by the ITR from a source inside of the >>> site and the size of the packet is greater than the effective = MTU >>> stored with the Map-Cache entry associated with the destination >>> EID the packet is for, the ITR will send an ICMPv6 "Packet Too >>> ^^^^^^^^^^^^^^^^^^^ >>>=20 >>> Big" message back to the source. The packet size advertised by >>> the ITR in the ICMPv6 message is the effective MTU minus the = LISP >>> encapsulation length.=E2=80=9D >>=20 >> This is now fixed. I now understand your comment. Please check the = diff file enclosed. >>=20 >>>>=20 >>>>>>=20 >>>>>>> 6) And now the more-discussion-needed point: >>>>>>> So my underlying concern is the same as brought up by the = TSV-ART review that >>>>>>> lisp information are not end-to-end integrity protected or = authenticated. >>>>>>=20 >>>>>> I would like you to be more specific. Beacuse there is a lot of = security in the protocol and we believe the current drafts, in their = entirety, inicdate so. >>>>>=20 >>>>> I was thinking about the option to add an authenticated hash, = anyway=E2=80=A6 >>>>=20 >>>> LISP uses lisp-crypto (RFC8061) which uses AEAD. >>>=20 >>> I think the pity here is that RFC8061 is still a separate optional = RFC. I would have expected to have this integrated into rfc6830bis and = make it mandatory to implement if not mandatory to use. >>=20 >> Agree. I don=E2=80=99t know what to tell you. But as you might now, = there is a tradeoff between privacy and monitoring/lawful intercept that = is being made and we know there are strong camps on each side. >>=20 >> You might have heard me say it at a recent IETF plenary =E2=80=9Ceveryt= hing should be encrypted, period=E2=80=9D. So you know what camp I=E2=80=99= m in. ;-) >>=20 >>>=20 >>>>=20 >>>>>>=20 >>>>>>> However, while briefly thinking about how this could be = eventually realized, I >>>>>>> noticed that there is actually no mechanism to extend the LISP = header in any >>>>>>=20 >>>>>> Right, by design so it is efficient for hardware AND software = forwarding. But we do have the LISP-GPE header that can be used for = extensions. But that has limited deployment. >>>>>>=20 >>>>>>> way. There is no version, no option and the LISP header seems to = have a fixed, >>>>>>=20 >>>>>> We decdied as a working group that the UDP port number would = indicate what header follows and therefore what LISP version is used. >>>>>=20 >>>>> Okay, that needs to be explained in the doc! >>>>>=20 >>>>> Mirja >>>>=20 >>>> The document says that UDP port 4341 is assigned and when so, the = LISP header as docmented is used. We shouldn=E2=80=99t just encourage = versioning if the philosophy it not to churn often. >>>=20 >>> Okay, that is actually not possible based on the recommendation in = RFC6335: >>>=20 >>> " o IANA strives to assign only one assigned port number for all >>> variants of a service (e.g., for updated versions of a = service).=E2=80=9C >>>=20 >>> That means it is not possible to get another port number for a new = version of lisp. You need a different version approach. >>>=20 >>> Mirja >>=20 >> The working group made this decsision back in 2009 when the LISP WG = was formed. Actually earlier when we did the initial work in the IRTF = RRG. RFC3168 was published in Aug 2011. >>=20 >> LISP-GPE is a variant of the the LISP data-plane, and it is using the = same UDP port 4341. So we actually accomplished the reuse. >>=20 >> Dino >>=20 >> >>=20 >>=20 >=20 --Apple-Mail=_656AF8F2-D1D1-473D-ACDF-2A4D695242AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dino,= Mirja,

a couple of = comments inline.

Thanks 

On 17 Sep 2018, at 18:15, Mirja = Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:

Hi = Dino,

unfortunately, I don=E2=80=99t think = this is quite there yet. First of all, I have to say that I misread the = original text which already says that only the CE should be copied which = is at least mostly inline with RFC6040 already. However, I really would = like the existing text to be clearer here (instead of just adding = additional text).

Also you still need at = least one reference to rfc3168 because that=E2=80=99s the spec that = defines the mechanism and IP bits.

Let me = propose something:

For encapsulation:
OLD
"The 'Explicit Congestion Notification' = (ECN) field (bits 6 and 7
=      of the IPv6 'Traffic Class' field) = requires special treatment in
=      order to avoid discarding indications of = congestion [RFC3168].
     ITR = encapsulation MUST copy the 2-bit 'ECN' field from the inner
     header to the outer header. =  Re-encapsulation MUST copy the 2-bit
=      'ECN' field from the stripped outer header = to the new outer
=      header.=E2=80=9C
PROPOSED
"The 'Explicit Congestion Notification' (ECN) field (bits 6 = and 7
     of the IPv6 'Traffic = Class' field) [RFC3168] requires special treatment in
=      order to preserve the use of ECN on the = path.
     ITR encapsulation = MUST copy the 2-bit 'ECN' field from the inner
=      header to the outer header, inline with = the =E2=80=99Normal Mode=E2=80=99 in section 4.1
=      of [RFC6040].  Re-encapsulation = SHOULD follow the decapsulation as described
=      below and then 2-bit 'ECN' field from the = stripped inner header to the
=      new outer header.=E2=80=9C
For decapsulation:
OLD
"The = 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
     of the IPv6 'Traffic Class' = field) requires special treatment in
=      order to avoid discarding indications of = congestion [RFC3168].  If
=      the 'ECN' field contains a congestion = indication codepoint (the
=      value is '11', the Congestion Experienced = (CE) codepoint), then
     ETR = decapsulation MUST copy the 2-bit 'ECN' field from the
=      stripped outer header to the surviving = inner header that is used
=      to forward the packet beyond the ETR. =  These requirements preserve
=      CE indications when a packet that uses ECN = traverses a LISP tunnel
     and = becomes marked with a CE indication due to congestion between
     the tunnel endpoints.=E2=80=9C

@Mirja: As Dino pointed out the last sentence is = unclear.


PROPOSED
"The 'Explicit Congestion Notification' (ECN) field (bits 6 = and 7
     of the IPv6 'Traffic = Class' field) requires special treatment on
=      decapsulation in
=      order to avoid discarding indications of = congestion,
     inline with = section 4.2 of [RFC6040]. If
=      the 'ECN=E2=80=98 field of the outer = header contains a congestion indication
=      codepoint (the
=      value is '11', the Congestion Experienced = (CE) codepoint) and the inner
=      header indicates ECN support (either = ECT(0) or ECT(1) codepoint is set),
=      then ETR decapsulation MUST also set CE = field in the inner header that is
=      used
=      to forward the packet beyond the ETR. =

@Mirja: So far = so good. Is the equivalent of what is already there.

If the inner packet is marked as non-
=      ECT but the outer header has the CE mark = set, the packet MUST be dropped
=      instead.

@ Mirja: How can this happen? As for your text we MUST = copy inner CE to outer CE when encapsulating, so if the original packet = does not support ECN the outer header will state so and there will not = be any CE mark set.


Any discrepancy between the inner and outer header for = non-ECT,
     ECT(0) and ECT(1) = MUST NOT be copied from the outer header. These
=      requirements preserve
=      CE indications when a packet that is = ECN-capable traverses a LISP tunnel
=      and becomes marked with a CE indication = due to congestion between
=      the tunnel endpoints or transforms an CE = into loss if that packet is not
=      ECN-capable conserving the congestion = indication towards a non-ECN enables
=      endpoint."

Please also remove the duplicated text after these bullet = lists in the draft!

Further I believe my = discuss points 2)

@= Dino: this point is about the following bullet in section = 5.3:

 The outer-header =
'Differentiated Services Code Point' (DSCP) field
      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
      copied from the inner-header DSCP field ('Traffic Class' field, in
      the case of IPv6) considering the exception listed below.


You need to delete the trailing = =E2=80=9Cconsidering the exception listed below=E2=80=9D because there = is no exception listed.


and 4) =

@ Mirja: This = point is about all packets of the same flow having the same source port = number. Version -17 includes the following sentence in section = 12:

The source port
   SHOULD be the same for all packets belonging to the same =
flow.


As you have requested.


are not fully resolved yet. Also I would like = to at least see more explanation about the approach for extensibility = that was taken in this doc (point 6).

@Mirja:= Would you mind being more explicit? I fail to see the exact point you = are trying to make.

Dino already = explained the rationale of why LISP is as it is. We can discuss = endlessly whether was a good or bad choice, but it is what it is and we = cannot change it now.

IMHO, it is = not worth to add any discussion on this matter in this = document. 
Unless we just keep it to a simple sentence = like: 

=E2=80=9CExtension to = the LISP header described in this document can be achieved using the = LISP General Protocol Encapsulation mechanism = [draft-ietf-lisp-gpe]." 


Ciao

L.




Mirja


Am 12.09.2018 um 23:30 schrieb Dino Farinacci <farinacci@gmail.com>:

Hi again,

please see below.
Thanks for the ongoing discussion Mirja. See a new diff file = enclosed as a proposed -18 update. Let me know if the text I added to = address your comments are sufficient.

I = believe (but could be wrong) that this should be the last set of = comments to 6830bis. But I have not seen any acks from Alvaro if we = addressed all his comments (specifically for 6830bis).


Am 11.09.2018 um 18:45 schrieb Dino Farinacci = <farinacci@gmail.com>:


Well it doesn=E2=80=99t have to be. I am a bit hesitant to = just point to another long complicated RFC. This text has gone through = review for quite a long time and many ECN experts decided we should = write it this way. And this text did go through IESG review when RFC6830 = was made experimental RFC.

Procedere explained in RFC6040 are actually not that = complicated. It=E2=80=99s mainly the table provided in section 3.2. = Please have a look at the draft. However, I disagree that it = =E2=80=9Enegative=E2=80=9C to point for this part to another RFC. This = is not a unique problem, that=E2=80=99s why we have RFC6040 and all = approaches that face this problem should point to RFC6040 and implement = the same strategy.

I am just = worried it will be ignored because there are implementations out there = that do what they already do. If we want to suggest to consider the = procedures in RFC6040, I am okay with that, but you need to provide the = wording because I certainly don=E2=80=99t want it too strong.

Actually the behavior as = currently described in the lisp draft is not even complainant with = rfc3138, however, rfc3168 is updated by rfc6040. The encapsulation in = the lisp draft behavior is already what RFC6040 described; so that=E2=80=99= s good. However, the decapsulation is neither what RFC3168 nor rfc6040 = says. Therefore this must be fixed and I guess a bis doc is also the = best chance we get to fix these incorrect implementation then. If you = are worried that this will be ignored, you should mention it explicitly = in section 18 (Changes since RFC 6830).

The working group made this decsision back in 2009 when the = LISP WG was formed. Actually earlier when we did the initial work in the = IRTF RRG. RFC3168 was published in Sep 2001. But note one of the = authors, David Black, offered the text you see in the document = rewgarding ECN handling.

So by doing this = update, we ARE going to create a implementation incompatibility.

There is = no matter about the wording being too strong or whatever, RFC6040 is = very clear about the correct behavior and that is exactly what needs to = be implemented. Please go ahead and read RFC6040. If you need further = help, please ask an ECN expert for help, e.g. Bob Briscoe who is the = author of RFC6040.

Check the = diff file to see if you are okay with the new text added. It WAS NOT = simple because there are a number of cases that need to be described = that doesn=E2=80=99t contradict RFC6040 that I do not want to repeat.

Please = note that I actually pointer to a wrong section in RFC6040 above. It = should of course be 4.2 (and not 3.2).

Okay, that makes more sense now. I was confused.



3) Sec 7.1. only takes about ICMPv6 "Packet Too = Big" packets while
"IPv4-encapsulated packet with the DF = bit set to 1" should be addressed as well.

This is discussed in length. I don=E2=80=99t know how you = could have missed this.

I = didn't miss that discussion but the text got fixed incorrectly because = it doesn=E2=80=99t not address IPv4 through the whole text. Please have = a look and fix that as well. I think this is mainly an editorial issue = but and important one to fix.

I = am sorry. I don=E2=80=99t know what you think is wrong. Please point to = the text specifically.

Sec = 7.2:
"   2.  When an IPv6-encapsulated = packet, or an IPv4-encapsulated packet
=     with the DF bit set to 1, exceeds what the core = network can
    deliver, one of the = intermediate routers on the path will send an
=     ICMPv6 "Packet Too Big" message to the ITR. =  The ITR will parse
=     ^^^^^^^^^^^^^^^^^^^^^^
=    there will be no ICMPv6 message is the packet was = IPv4

    the ICMPv6 = message to determine which Locator is affected by the
=     effective MTU change and then record the new = effective MTU value
    in the = Map-Cache entry.

3.  When a packet is = received by the ITR from a source inside of the
=     site and the size of the packet is greater than = the effective MTU
    stored with the = Map-Cache entry associated with the destination
=     EID the packet is for, the ITR will send an = ICMPv6 "Packet Too
=             &n= bsp;           &nbs= p;            =            ^^^^^^^^= ^^^^^^^^^^^

    Big" = message back to the source.  The packet size advertised by
    the ITR in the ICMPv6 message is the = effective MTU minus the LISP
=     encapsulation length.=E2=80=9D

This is now fixed. I now = understand your comment. Please check the diff file enclosed.



6) And now the more-discussion-needed = point:
So my underlying concern is the same as brought up = by the TSV-ART review that
lisp information are not = end-to-end integrity protected or authenticated.

I would like you to be more = specific. Beacuse there is a lot of security in the protocol and we = believe the current drafts, in their entirety, inicdate so.

I was thinking about the option = to add an authenticated hash, anyway=E2=80=A6

LISP uses lisp-crypto (RFC8061) = which uses AEAD.

I think the = pity here is that RFC8061 is still a separate optional RFC. I would have = expected to have this integrated into rfc6830bis and make it mandatory = to implement if not mandatory to use.

Agree. I don=E2=80=99t know what to tell you. But as you = might now, there is a tradeoff between privacy and monitoring/lawful = intercept that is being made and we know there are strong camps on each = side.

You might have heard me say it at a = recent IETF plenary =E2=80=9Ceverything should be encrypted, period=E2=80=9D= . So you know what camp I=E2=80=99m in.  ;-)




However, while briefly thinking about how this = could be eventually realized, I
noticed that there is = actually no mechanism to extend the LISP header in any

Right, by design so it is = efficient for hardware AND software forwarding. But we do have the = LISP-GPE header that can be used for extensions. But that has limited = deployment.

way. There is no version, no option and the LISP header seems = to have a fixed,

We decdied as = a working group that the UDP port number would indicate what header = follows and therefore what LISP version is used.

Okay, that needs to be explained = in the doc!

Mirja

The document says that UDP port = 4341 is assigned and when so, the LISP header as docmented is used. We = shouldn=E2=80=99t just encourage versioning if the philosophy it not to = churn often.

Okay, that is = actually not possible based on the recommendation in RFC6335:

"   o  IANA strives to assign = only one assigned port number for all
=    variants of a service (e.g., for updated versions of a = service).=E2=80=9C

That means it is not = possible to get another port number for a new version of lisp. You need = a different version approach.

Mirja

The working group made this = decsision back in 2009 when the LISP WG was formed. Actually earlier = when we did the initial work in the IRTF RRG. RFC3168 was published in = Aug 2011.

LISP-GPE is a variant of the the = LISP data-plane, and it is using the same UDP port 4341. So we actually = accomplished the reuse.

Dino

<rfcdiff-6830bis.html>




= --Apple-Mail=_656AF8F2-D1D1-473D-ACDF-2A4D695242AF-- From nobody Tue Sep 18 03:23:52 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C59D130DE2 for ; Tue, 18 Sep 2018 03:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 obymEe5SS73x for ; Tue, 18 Sep 2018 03:23:47 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57721292AD for ; Tue, 18 Sep 2018 03:23:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=bT5AQqMuqZq0Z86Y+3B6c1D9Q6fsQhGR7ouuyIwMJmcZ/d5JyUEUdjWJt0H65gSSpRiQQU36xbT+XAnXD0+57Tr/KqtmDbqabUfraH6wxHlXIfEM669hqCgVs4AwDmvc9rX2GXcT/FfKRrxx6bYiybYlh0Ha8MnT2WkMCXXRDf8=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 27642 invoked from network); 18 Sep 2018 12:23:44 +0200 Received: from i577bce80.versanet.de (HELO ?192.168.178.24?) (87.123.206.128) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Sep 2018 12:23:44 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Tue, 18 Sep 2018 12:23:41 +0200 Cc: lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <523C5B6B-12C8-4B67-B67D-A445D9C57E28@kuehlewind.net> References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> To: Luigi Iannone , Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) X-PPP-Message-ID: <20180918102344.27633.53975@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 18 Sep 2018 10:23:50 -0000 Hi Luigi, hi Dino, please see below. > Am 18.09.2018 um 10:14 schrieb Luigi Iannone : >=20 > Dino, Mirja, >=20 > a couple of comments inline. >=20 > Thanks=20 >=20 >> On 17 Sep 2018, at 18:15, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Hi Dino, >>=20 >> unfortunately, I don=E2=80=99t think this is quite there yet. First = of all, I have to say that I misread the original text which already = says that only the CE should be copied which is at least mostly inline = with RFC6040 already. However, I really would like the existing text to = be clearer here (instead of just adding additional text). >>=20 >> Also you still need at least one reference to rfc3168 because = that=E2=80=99s the spec that defines the mechanism and IP bits. >>=20 >> Let me propose something: >>=20 >> For encapsulation: >> OLD >> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) requires special treatment in >> order to avoid discarding indications of congestion [RFC3168]. >> ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner >> header to the outer header. Re-encapsulation MUST copy the = 2-bit >> 'ECN' field from the stripped outer header to the new outer >> header.=E2=80=9C >> PROPOSED >> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) [RFC3168] requires special = treatment in >> order to preserve the use of ECN on the path. >> ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner >> header to the outer header, inline with the =E2=80=99Normal = Mode=E2=80=99 in section 4.1=20 >> of [RFC6040]. Re-encapsulation SHOULD follow the decapsulation = as described=20 >> below and then 2-bit 'ECN' field from the stripped inner header = to the=20 >> new outer header.=E2=80=9C The word =E2=80=9Ecopy=E2=80=9C got lost...=20 >>=20 >> For decapsulation: >> OLD >> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) requires special treatment in >> order to avoid discarding indications of congestion [RFC3168]. = If >> the 'ECN' field contains a congestion indication codepoint (the >> value is '11', the Congestion Experienced (CE) codepoint), then >> ETR decapsulation MUST copy the 2-bit 'ECN' field from the >> stripped outer header to the surviving inner header that is used >> to forward the packet beyond the ETR. These requirements = preserve >> CE indications when a packet that uses ECN traverses a LISP = tunnel >> and becomes marked with a CE indication due to congestion = between >> the tunnel endpoints.=E2=80=9C >=20 > @Mirja: As Dino pointed out the last sentence is unclear. That was the text that is in the doc. >=20 >=20 >> PROPOSED >> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) requires special treatment on=20= >> decapsulation in >> order to avoid discarding indications of congestion,=20 >> inline with section 4.2 of [RFC6040]. If >> the 'ECN=E2=80=98 field of the outer header contains a = congestion indication =09 >> codepoint (the >> value is '11', the Congestion Experienced (CE) codepoint) and = the inner=20 >> header indicates ECN support (either ECT(0) or ECT(1) codepoint = is set),=20 >> then ETR decapsulation MUST also set CE field in the inner = header that is=20 >> used >> to forward the packet beyond the ETR. >=20 > @Mirja: So far so good. Is the equivalent of what is already there. Expect that it is clarified that the CE should only be coped if the = inner codepoint is ECT(0) or ETC(1) and not if the codepoint is not-ECT. >=20 >> If the inner packet is marked as non- >> ECT but the outer header has the CE mark set, the packet MUST be = dropped=20 >> instead. >=20 > @ Mirja: How can this happen? As for your text we MUST copy inner CE = to outer CE when encapsulating, so if the original packet does not = support ECN the outer header will state so and there will not be any CE = mark set. Yes, this is an error case but that doesn=E2=80=99t mean that it cannot = happen. In RFC6040 this would cover a case where some encapsulation = boxes would set the ECT flags anyway to benefit from ECN for the tunnel. = This might be less a problem for lisp but it still should be cover in = the spec to not end up with some unexpected behavior if this case = happens anyway. And that also what RFC6040 say which should simply be = followed here. I also okay with just pointing at RFC6040 and not use own = normative language in this doc. >=20 >=20 >> Any discrepancy between the inner and outer header for non-ECT,=20 >> ECT(0) and ECT(1) MUST NOT be copied from the outer header. = These=20 >> requirements preserve >> CE indications when a packet that is ECN-capable traverses a = LISP tunnel >> and becomes marked with a CE indication due to congestion = between >> the tunnel endpoints or transforms an CE into loss if that = packet is not=20 >> ECN-capable conserving the congestion indication towards a = non-ECN enables=20 >> endpoint." >>=20 >> Please also remove the duplicated text after these bullet lists in = the draft! >>=20 >> Further I believe my discuss points 2) >=20 > @ Dino: this point is about the following bullet in section 5.3: >=20 > The outer-header 'Differentiated Services Code Point' (DSCP) field > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be > copied from the inner-header DSCP field ('Traffic Class' field, = in > the case of IPv6) considering the exception listed below. >=20 >=20 >=20 > You need to delete the trailing =E2=80=9Cconsidering the exception = listed below=E2=80=9D because there is no exception listed. It=E2=80=99s more then that. Copying DCSP just over might not always be = the right behavior. Depending on how DCSP is used in the lisp network = otherwise there maybe local policies that either copy the field or e.g = bleach it or set it to something else. This should be noted, e.g. = =E2=80=9ESHOULD be copied [=E2=80=A6] expect local policies define a = different use of DSCP." >=20 >=20 >> and 4) >=20 > @ Mirja: This point is about all packets of the same flow having the = same source port number. Version -17 includes the following sentence in = section 12: >=20 > The source port > SHOULD be the same for all packets belonging to the same flow. As missed that. Okay that=E2=80=99s fine. Thanks! >=20 >=20 >=20 > As you have requested. >=20 >=20 >> are not fully resolved yet. Also I would like to at least see more = explanation about the approach for extensibility that was taken in this = doc (point 6). >=20 > @Mirja: Would you mind being more explicit? I fail to see the exact = point you are trying to make. >=20 > Dino already explained the rationale of why LISP is as it is. We can = discuss endlessly whether was a good or bad choice, but it is what it is = and we cannot change it now. >=20 > IMHO, it is not worth to add any discussion on this matter in this = document.=20 > Unless we just keep it to a simple sentence like:=20 >=20 > =E2=80=9CExtension to the LISP header described in this document can = be achieved using the LISP General Protocol Encapsulation mechanism = [draft-ietf-lisp-gpe].=E2=80=9C=20 Yes, that would be sufficient. I=E2=80=99m actually wondering with this = draft was not directly included in 6830bis. Mirja >=20 >=20 > Ciao >=20 > L. >=20 >=20 >=20 >=20 >> Mirja >>=20 >>=20 >>> Am 12.09.2018 um 23:30 schrieb Dino Farinacci : >>>=20 >>>> Hi again, >>>>=20 >>>> please see below. >>>=20 >>> Thanks for the ongoing discussion Mirja. See a new diff file = enclosed as a proposed -18 update. Let me know if the text I added to = address your comments are sufficient. >>>=20 >>> I believe (but could be wrong) that this should be the last set of = comments to 6830bis. But I have not seen any acks from Alvaro if we = addressed all his comments (specifically for 6830bis). >>>=20 >>>>=20 >>>>> Am 11.09.2018 um 18:45 schrieb Dino Farinacci = : >>>>>=20 >>>>>=20 >>>>>>> Well it doesn=E2=80=99t have to be. I am a bit hesitant to just = point to another long complicated RFC. This text has gone through review = for quite a long time and many ECN experts decided we should write it = this way. And this text did go through IESG review when RFC6830 was made = experimental RFC. >>>>>>=20 >>>>>> Procedere explained in RFC6040 are actually not that complicated. = It=E2=80=99s mainly the table provided in section 3.2. Please have a = look at the draft. However, I disagree that it =E2=80=9Enegative=E2=80=9C = to point for this part to another RFC. This is not a unique problem, = that=E2=80=99s why we have RFC6040 and all approaches that face this = problem should point to RFC6040 and implement the same strategy. >>>>>=20 >>>>> I am just worried it will be ignored because there are = implementations out there that do what they already do. If we want to = suggest to consider the procedures in RFC6040, I am okay with that, but = you need to provide the wording because I certainly don=E2=80=99t want = it too strong. >>>>=20 >>>> Actually the behavior as currently described in the lisp draft is = not even complainant with rfc3138, however, rfc3168 is updated by = rfc6040. The encapsulation in the lisp draft behavior is already what = RFC6040 described; so that=E2=80=99s good. However, the decapsulation is = neither what RFC3168 nor rfc6040 says. Therefore this must be fixed and = I guess a bis doc is also the best chance we get to fix these incorrect = implementation then. If you are worried that this will be ignored, you = should mention it explicitly in section 18 (Changes since RFC 6830). >>>=20 >>> The working group made this decsision back in 2009 when the LISP WG = was formed. Actually earlier when we did the initial work in the IRTF = RRG. RFC3168 was published in Sep 2001. But note one of the authors, = David Black, offered the text you see in the document rewgarding ECN = handling. >>>=20 >>> So by doing this update, we ARE going to create a implementation = incompatibility. >>>=20 >>>> There is no matter about the wording being too strong or whatever, = RFC6040 is very clear about the correct behavior and that is exactly = what needs to be implemented. Please go ahead and read RFC6040. If you = need further help, please ask an ECN expert for help, e.g. Bob Briscoe = who is the author of RFC6040. >>>=20 >>> Check the diff file to see if you are okay with the new text added. = It WAS NOT simple because there are a number of cases that need to be = described that doesn=E2=80=99t contradict RFC6040 that I do not want to = repeat. >>>=20 >>>> Please note that I actually pointer to a wrong section in RFC6040 = above. It should of course be 4.2 (and not 3.2). >>>=20 >>> Okay, that makes more sense now. I was confused. >>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets = while >>>>>>>> "IPv4-encapsulated packet with the DF bit set to 1" should be = addressed as well. >>>>>>>=20 >>>>>>> This is discussed in length. I don=E2=80=99t know how you could = have missed this. >>>>>>=20 >>>>>> I didn't miss that discussion but the text got fixed incorrectly = because it doesn=E2=80=99t not address IPv4 through the whole text. = Please have a look and fix that as well. I think this is mainly an = editorial issue but and important one to fix. >>>>>=20 >>>>> I am sorry. I don=E2=80=99t know what you think is wrong. Please = point to the text specifically. >>>>=20 >>>> Sec 7.2: >>>> " 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated = packet >>>> with the DF bit set to 1, exceeds what the core network can >>>> deliver, one of the intermediate routers on the path will send = an >>>> ICMPv6 "Packet Too Big" message to the ITR. The ITR will parse >>>> ^^^^^^^^^^^^^^^^^^^^^^ >>>> there will be no ICMPv6 message is the packet was IPv4 >>>>=20 >>>> the ICMPv6 message to determine which Locator is affected by = the >>>> effective MTU change and then record the new effective MTU = value >>>> in the Map-Cache entry. >>>>=20 >>>> 3. When a packet is received by the ITR from a source inside of = the >>>> site and the size of the packet is greater than the effective = MTU >>>> stored with the Map-Cache entry associated with the destination >>>> EID the packet is for, the ITR will send an ICMPv6 "Packet Too >>>> ^^^^^^^^^^^^^^^^^^^ >>>>=20 >>>> Big" message back to the source. The packet size advertised by >>>> the ITR in the ICMPv6 message is the effective MTU minus the = LISP >>>> encapsulation length.=E2=80=9D >>>=20 >>> This is now fixed. I now understand your comment. Please check the = diff file enclosed. >>>=20 >>>>>=20 >>>>>>>=20 >>>>>>>> 6) And now the more-discussion-needed point: >>>>>>>> So my underlying concern is the same as brought up by the = TSV-ART review that >>>>>>>> lisp information are not end-to-end integrity protected or = authenticated. >>>>>>>=20 >>>>>>> I would like you to be more specific. Beacuse there is a lot of = security in the protocol and we believe the current drafts, in their = entirety, inicdate so. >>>>>>=20 >>>>>> I was thinking about the option to add an authenticated hash, = anyway=E2=80=A6 >>>>>=20 >>>>> LISP uses lisp-crypto (RFC8061) which uses AEAD. >>>>=20 >>>> I think the pity here is that RFC8061 is still a separate optional = RFC. I would have expected to have this integrated into rfc6830bis and = make it mandatory to implement if not mandatory to use. >>>=20 >>> Agree. I don=E2=80=99t know what to tell you. But as you might now, = there is a tradeoff between privacy and monitoring/lawful intercept that = is being made and we know there are strong camps on each side. >>>=20 >>> You might have heard me say it at a recent IETF plenary = =E2=80=9Ceverything should be encrypted, period=E2=80=9D.. So you know = what camp I=E2=80=99m in. ;-) >>>=20 >>>>=20 >>>>>=20 >>>>>>>=20 >>>>>>>> However, while briefly thinking about how this could be = eventually realized, I >>>>>>>> noticed that there is actually no mechanism to extend the LISP = header in any >>>>>>>=20 >>>>>>> Right, by design so it is efficient for hardware AND software = forwarding. But we do have the LISP-GPE header that can be used for = extensions. But that has limited deployment. >>>>>>>=20 >>>>>>>> way. There is no version, no option and the LISP header seems = to have a fixed, >>>>>>>=20 >>>>>>> We decdied as a working group that the UDP port number would = indicate what header follows and therefore what LISP version is used. >>>>>>=20 >>>>>> Okay, that needs to be explained in the doc! >>>>>>=20 >>>>>> Mirja >>>>>=20 >>>>> The document says that UDP port 4341 is assigned and when so, the = LISP header as docmented is used. We shouldn=E2=80=99t just encourage = versioning if the philosophy it not to churn often. >>>>=20 >>>> Okay, that is actually not possible based on the recommendation in = RFC6335: >>>>=20 >>>> " o IANA strives to assign only one assigned port number for all >>>> variants of a service (e.g., for updated versions of a = service).=E2=80=9C >>>>=20 >>>> That means it is not possible to get another port number for a new = version of lisp. You need a different version approach. >>>>=20 >>>> Mirja >>>=20 >>> The working group made this decsision back in 2009 when the LISP WG = was formed. Actually earlier when we did the initial work in the IRTF = RRG. RFC3168 was published in Aug 2011. >>>=20 >>> LISP-GPE is a variant of the the LISP data-plane, and it is using = the same UDP port 4341. So we actually accomplished the reuse. >>>=20 >>> Dino >>>=20 >>> >>>=20 >>>=20 >>=20 >=20 From nobody Tue Sep 18 03:39:10 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E85A130DCC for ; Tue, 18 Sep 2018 03:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 nHYbe6Gs19KL for ; Tue, 18 Sep 2018 03:39:07 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE65C1292AD for ; Tue, 18 Sep 2018 03:39:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=LXoHB+EZ22EfELGaYihAnE+MX+Tgf7VXQ1kMLD5L4Psv/2/byYQ3J+JrdKcN3tAOIZ3ofGhq+uSoLNSZJNDjHa2Sh+UpfjzM/wRFBblkYFqKOFUSlf3D3FnW7AkVXXWjxyEWPaA2DhNTOu64P3V9MsACo6mQ5+n91ZCCB6mhXz4=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 27916 invoked from network); 18 Sep 2018 12:32:24 +0200 Received: from i577bce80.versanet.de (HELO ?192.168.178.24?) (87.123.206.128) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Sep 2018 12:32:24 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com> Date: Tue, 18 Sep 2018 12:32:23 +0200 Cc: Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) X-PPP-Message-ID: <20180918103224.27907.51870@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 18 Sep 2018 10:39:08 -0000 Hi Dino, please see below. > Am 17.09.2018 um 19:48 schrieb Dino Farinacci : >=20 >> PROPOSED >> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) [RFC3168] requires special = treatment in >> order to preserve the use of ECN on the path. >> ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner >> header to the outer header, inline with the =E2=80=99Normal = Mode=E2=80=99 in section 4.1=20 >> of [RFC6040]. Re-encapsulation SHOULD follow the decapsulation = as described=20 >> below and then 2-bit 'ECN' field from the stripped inner header = to the=20 >> new outer header.=E2=80=9C >=20 > I did not include this text because the last sentence is not formed = well. Please restate. A verb is missing. copy >=20 >> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >> of the IPv6 'Traffic Class' field) requires special treatment on=20= >> decapsulation in >> order to avoid discarding indications of congestion,=20 >> inline with section 4.2 of [RFC6040]. If >> the 'ECN=E2=80=98 field of the outer header contains a congestion = indication =09 >> codepoint (the >> value is '11', the Congestion Experienced (CE) codepoint) and the = inner=20 >> header indicates ECN support (either ECT(0) or ECT(1) codepoint = is set),=20 >> then ETR decapsulation MUST also set CE field in the inner header = that is=20 >> used >> to forward the packet beyond the ETR. If the inner packet is = marked as non- >> ECT but the outer header has the CE mark set, the packet MUST be = dropped=20 >> instead. Any discrepancy between the inner and outer header for = non-ECT,=20 >> ECT(0) and ECT(1) MUST NOT be copied from the outer header. These=20= >> requirements preserve >> CE indications when a packet that is ECN-capable traverses a LISP = tunnel >> and becomes marked with a CE indication due to congestion between >> the tunnel endpoints or transforms an CE into loss if that packet = is not=20 >> ECN-capable conserving the congestion indication towards a = non-ECN enables=20 >> endpoint.=E2=80=9D >=20 > I didn=E2=80=99t include this text because (1) it under states what to = do with IPv4, (2) it has too much detail that is already in RFC6040, and = (3) it undoes text that other reviewers have offered. I didn=E2=80=99t change the mentioning of IPv6 here. Yes please at IPv4. You can remove all this text and only point to rfc6040. That would = actually my preferred solution. I don=E2=80=99t think it =E2=80=9Eundoes=E2= =80=9C text; it just adds what was missing in compliance with RFC6040. = Anyway it doesn=E2=80=99t matter point being that it should specify the = same things as RFC6040 does not matter what other have ofter because = RFC6040 is the IETF-consensus doc how describing how to handle this. >=20 >=20 >> Please also remove the duplicated text after these bullet lists in = the draft! >=20 > You have to tell me what text. I am too confused at this point on what = you want. This is the text in the en-/ and decapsulation lists: "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header." "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC6040]. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints." And this text comes up right after the list in the same section: "The Explicit Congestion Notification ('ECN') field occupies bits 6 and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic Class' field [RFC6040]. The 'ECN' field requires special treatment in order to avoid discarding indications of congestion [RFC6040]. An ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR/ PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints." The last text bit does not add any information; it just states all = normative requirement twice, even using basically exactly the some = words. This can lead to discrepancies and it really not necessary. I=E2=80= =99d recommend to just remove the last text block here (and fix the = IPv6/IPv4 issue in the other blocks). Mirja >=20 >> Further I believe my discuss points 2) and 4) are not fully resolved = yet. Also I would like to at least see more explanation about the = approach for extensibility that was taken in this doc (point 6). >=20 > You are going to have to repeat what they are because too many emails = have flown by since your initial post. And for extensibility, we discuss = it in RFC8060 and don=E2=80=99t think anything more should be said here = otherwise, we will duplicate unnecessary text. >=20 > Another new diff file enclosed. >=20 > Dino >=20 >=20 >=20 >=20 >=20 >=20 From nobody Tue Sep 18 04:05:59 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9BD130DCC for ; Tue, 18 Sep 2018 04:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 7gWCzXKB1RnW for ; Tue, 18 Sep 2018 04:05:54 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A902A130DC1 for ; Tue, 18 Sep 2018 04:05:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=XSS+56fYUKw74DI7jqyaie3a4mVwA1XoNQG2P6VZOk0slCtD6Z+hMDd59paPvifglkLu6gLa/mAoNbBPc0wZfY+8ztcPIaiXOoWTOm+pSMHHcDbUTk5UvoeWgvkL8WtdjIixst4Jm12ZlRUM+C9v/b8mOljqKSVShMqOQZO3fW0=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 28818 invoked from network); 18 Sep 2018 13:05:51 +0200 Received: from i577bce80.versanet.de (HELO ?192.168.178.24?) (87.123.206.128) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Sep 2018 13:05:50 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Tue, 18 Sep 2018 13:05:49 +0200 Cc: lisp-chairs@ietf.org, "lisp@ietf.org list" , The IESG , Luigi Iannone , Colin Perkins , draft-ietf-lisp-rfc6833bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0D9A60A2-FE18-4AF1-8A8E-0C6C742CF4F6@kuehlewind.net> References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <9086A458-31C0-4EB2-BC5B-D9CB7B22469E@kuehlewind.net> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) X-PPP-Message-ID: <20180918110551.28808.78665@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 18 Sep 2018 11:05:57 -0000 Hi Dino, please see below. > Am 13.09.2018 um 23:46 schrieb Dino Farinacci : >=20 > I have a new diff file for -15 of 6833bis. I have included changes = from your emails and from Colin=E2=80=99s. See my responses inline. I = have trimmed a bit of text to hopefully make it more readable for = others. >=20 > I will only submit the new revision if you agree with the changes and = there are no objections from the LISP working group. Thanks in = advance. >=20 >>>>=20 >>> The multiple EID-record encoding is already spec=E2=80=99ed and is = in the protocol. And since Map-Requests are triggered by packet arrival = or network management tools, they tend to be sent for a single EID. What = is for further study is if a ITR would want the entire map-cache, so = would it request a set of aggregates and would a replier return all more = specifics for the aggregates requested. >>=20 >> I guess this sentence should be revised then. >=20 > Fixed. The sentence still talked about =E2=80=9Efuture version of the = protocol=E2=80=9C. Is that still necessary?=20 >=20 >>=20 >>>=20 >>>> Further given there is no new version, I wonder if the changes as = outlined in >>>> section 10 are all backward-compatible? Especially for the = introduction of the >>>> Message-Notify-Ack message, I guess there is no problem if a server = sends it, >>>> however, as the sender of the Message-Notify message might not know = if the >>>> other end supports sending of the Message-Notify-Ack it can't rely = on it. This >>>> should be further discussed in the doc! Or is there another = strategy to achieve >>>> backward compatibility? >>>=20 >>> The Map-Notify-Ack has been there since day-1 in implementations. = This is just IETF catching up. And it took over 5 years. So we really = don=E2=80=99t have a compatibility situation. And didn=E2=80=99t want to = create one in the specifications. So consider it a day 1, version 1 = message. It really wasn=E2=80=99t added later. >>=20 >> This should be stated in section 18. >=20 > Done. I would specifically state here that for that reason no interop problems = are expected. >=20 >>=20 >>>=20 >>> And big part of this push for standardization is to have the specs = =E2=80=9Ccatch up=E2=80=9D with the implementations. The implementations = are way further ahead than the specs. >>>=20 >>>> 2) Size and MTU >>>>=20 >>>> As outlined in the TSV-ART review (Thanks Colin!) this document = does not >>>> discuss fragmentation or Path MTU discovery. RFC8085 recommends to = either >>>=20 >>>> perform Path MTU discovery or limit the message to 576 bytes for = IPv4 or 1280 >>>> bytes for IPv6 (minus any static header). As this seems to be an = appropriate >>>> size for LISP messages, I would recommend this approach. Relying on = IP >>>> fragmentation (as indicated in the reply to the TSV-ART review) is = not >>>> recommended by RFC8085 as this would lead to IP packet without a = UDP header, in >>>> the case of LISP, which can cause problem and loss when NATs are = involved. In >>>> any case the chosen approach needs to be further discussed in the = doc. >>>>=20 >>>=20 >>> This is a data-plane feature so it is discussed in 6830bis and = RFC6830. >>=20 >> This is a different issue. The control plane protocol as specified in = this doc also needs to consider fragmentation and MTU. Please read = RFC8085 accordingly. >=20 > I have added text per Colin=E2=80=99s comments. Just pointing to RFC8085 is not enough. This spec must specify that = messages MUST not exceed the MTU and fragmentation should not be used. = And further either recommend to use MTU discovery or just restrict the = message size according to the recommendations in RFC8085. I would = recommend to just do the later for simplicity. >=20 >>>=20 >>>> 3) Rate-limiting and congestion control >>>>=20 >>>> Sec 5.3: "Map-Requests MUST be rate-limited. It is RECOMMENDED = that a Map- >>>> Request for the same EID-Prefix be sent no more than once per = second." >>>> As already noted by the TSV-ART review (Thanks Colin!), RFC8085 = actually >>>> recommends to not send more the one packet per 3 seconds, and that = is a >>>> restriction for all traffic not on a per-receiver base, or = implement congestion >>>> control. This limit is meant to not only protect the receiver but = also the >>>> network from overloading. Why do you use a smaller interval here? = Also if >>>> (appropriate) rate limiting is used, this should either be a MUST = or more >>>> explanation when it is okay to use a smaller rate limit should be = provided. >>>> However, after all, I don't think you those the right approach here = for rate >>>> limiting. A Map-Request is always expected to be followed by some = reply. For >>>> these kind of communication pattern, RFC8085 recommends to limit = the number of >>>> outstanding requests to 1 (see sec 3.1.1 of RFC8085 recommending = one packet per >>>> RTT), also for all traffic and not only per receiver. However, this = would also >>>> require to implement some simple mechanism to detect a message as = lost (see >>>> also further below in point 4). >>>=20 >>> We have referenced RFC8085 in the too be published -14 version of = 6833bis. >>=20 >> I didn=E2=80=99t find a reference in -14. However a reference is not = enough, the specified behavior is not appropriate and needs to change. = If you need further help, please consult the respective transport = experts, e.g. Gorry Fairhurst who is an author of RFC8085. >=20 > I have added text. We have a smaller interval because 3 seconds is way = too long (arguably 1 seond is too) to populate a map-cache. Note during = that time, packets that arrive to the ITR are discarded. So this occurs = if just one Map-Request is lost. As I said, just providing a pointer to RFC8085 is not sufficient.=20 >=20 >>=20 >>>=20 >>>> Similarly I'm not sure about the intent of this requirement in = section 5.5: >>>> "Map-Replies SHOULD be sent for an EID-Prefix no more often than = once >>>> per second to the same requesting router. " >>>> My understanding is that Replies are only sent when a request is = received. Why >>>> is this additional rate limit needed? Again if used it should be 3 = seconds for >>>> all traffic to be inline with RFC8085. Also again, why is that not = a MUST? >>>> Further recommendation are needed here. >>>=20 >>> Because the source is a bad-actor and sending new Map-Requests (with = a new nonce). >>=20 >> Not sure if that is the right choice because it may interact badly = with loss detection. However, as I said the specified behavior need to = be refined at various places in the doc. >=20 > Well there is not many choices. You can choose to not have this rate limiting but limit the total number = of request per requesting router per time interval. That would trigger a = reply immediately but still limit the total load in case of = =E2=80=9Ebad-actors=E2=80=9C. >=20 >>=20 >>>=20 >>>> Further section 6.1 say "Both the SMR sender and the Map-Request = responder MUST >>>> rate-limit >>>> these messages. Rate-limiting can be implemented as a global rate- >>>> limiter or one rate-limiter per SMR destination." >>>> This seems to be the same rate limit as mention above, or not...? = It would >>>> probably make sense to rate limit the SMR even further. Please = clarify and >>>> provide more guidance, e.g. what should the value of a potential = additional >>>> rate limit for SMR be? >>>=20 >>> Some of this machinery is left to the implementor. But we have = published some map-cache management guidelines in the lisp-threat RFC. >>=20 >> I think clear default guidance must be given in this document. My = main problem is that the guidance here is not clear (in relation to = other rate limits). >=20 > I have tightened it up. I don=E2=80=99t think I saw any change in the diff you=E2=80=99ve = attached. Please explain what you did. >=20 >>>=20 >>>> Respectively the following sentence in section 6.1 is also unclear: >>>> "The remote ITR MUST rate-limit the Map-Request until it gets a = Map-Reply" >>>> Why is the rate-limit as currently proposed depend on the fact if a = Map-Reply >>>> is received? Is the ITR supposed to retransmit the Map-Request=E2=80=A6= ? >>>=20 >>> If you are not getting answers to your Map-Requests because of = packet loss or MITM, sending them faster is not going to get you a = Map-Reply. >>=20 >> If you detect loss, you should send slower not faster for congestion = collapse avoidance. >=20 > That was my point. Should should instead specify a similar loss detection and = retransmission mechanism for Map-Request as now done for Map-Notify. The = rate-limit alone is not helpful. >=20 >>=20 >>>=20 >>>> And finally the Map-Register, Map-Notify and Map-Notify-Ack = messages does not >>>> seem to have any rate-limits. Recommendations inline with RFC8085 = should be >>>> provided for the total traffic and not only for a few message = types. Again, >>>> Map-Notify and Map-Notify-Ack messages should be send only once per = RTT as >>>> there is a feedback mechanism. >>>=20 >>> We have added that in -14. >>>=20 >>>> For Map-Register sec 8.2 say: "Map-Register messages are sent = periodically from >>>> an ETR to a Map- >>>> Server with a suggested interval between messages of one minute." >>>> However, this a rather a low bound than an upper bound. A required = (MUST) rate >>>> limit is still needed. >>>=20 >>> That is not rate-limiting to avoid message reduction. It is a = soft-state way of keeping registration state alive in the map-server(s). >>=20 >> That fine but you also need to specify normatively an upper bound. >=20 > The recommended upper bound is 1 minute. If you are not getting your = point across, please be more specific. Then you have to say =E2=80=9EMUST NOT send more than one message per = minutes=E2=80=9C. The current text just gives a recommendation what a go = value might be but does not specify an actually limit. >=20 >>=20 >>>=20 >>>> 4) Loss detection and retransmission >>>>=20 >>>> As also mention by the TSV-ART review (Once more thanks to Colin!), = this spec >>>> has an ACK mechanism for Map-Requests and now also for Map-Notify, = however, it >>>=20 >>> And Map-Notify are acks to Map-Registers when requested. >>>=20 >>>> does not specify what to do if the ACK is not received (loss = detection and >>>> retransmission scheduling). This makes the spec incomplete and = needs to be >>>> further specified in the doc (and also has a relation to the point = 3 above of >>>> course). >>>=20 >>> We focus on why a Map-Request is being generated (to populate the = map-cache) and a Map-Reply not only provides information to be put in = the map-cache, but acts as an ackl now. If the Map-Request nonce is = being replied with a Map-Reply with the same nonce, Map-Requests no = longer need to be sent and the requestor is happy with the result (and = hence it was reliable). >>=20 >> That all fine. However, you don=E2=80=99t specify the behavior if the = ack is not received. How/when is the message assumed to be lost? When = should it be retransmitted? How often? When to give up? Should = exponential backoff be used? This whole part s completely missing in the = spec. >=20 > Have added text. Thanks! Not sure I understand the first sentence: =E2=80=9EA sender of an unsolicited Map-Notify message (one that is not = used=09 as an acknowledgment to a Map-Register message) will follow = the=09 Congestion Control And Relability Guideline sections of = [RFC8085].=E2=80=9C The rest of the text is fine and gives a good spec. I think it is okay = to mention that that spec is inline with RFC8085 but other than that = I=E2=80=99m not sure what this first sentence is telling me=E2=80=A6? And also the last sentence is not fully clear: "After this time, the Map-=09 Notify sender can only get the RLOC-set change by later = querying the=09 mapping system or by RLOC-probing one of the RLOCs of the = existing=09 cached RLOC-set to get the new RLOC-set.=E2=80=9C I don=E2=80=99t think there should be an attempt to later try again. = Probably the system should log or notify an error instead. However, if = it makes sense to try later again you have to specify what later means = (hours, days?) and how often it should try again before it finally gives = up and logs an error. >=20 >>=20 >>>> 2) I find the security requirements in this doc very unsatisfying. = Most >>>> important the doc requires the support of authentication mechanism = but not the >>>> use of it. I would like to see more clear MUST requirements here. = Further, >>>> today and at this stage of the protocol (moving from exp to PS) I = find it not >>>> acceptable anymore to have certain security feature as optional and = outsourced >>>> into a different work-in-process draft. However, I leave further = discussion to >>>> the SEC ADs. >>>=20 >>> Can you cite where this is a problem. Are you saying we are not = supplying enough MUST text? >>=20 >> In section 8.2 a few SHOULDs are used but no discussion about when it = would be appropriate to not follow these SHOULDs. Further these SHOULDs = mainly just say what should be implemented and provided, however there = is no normative language that these endpoint SHOULD/MUST actually be = authenticated or that the configured EID-Prefixes list MUST be enforced. >>=20 >>>=20 >>>> Clarification questions: >>>> 1) Sec 5.3.: >>>> "For the initial case, the destination IP >>>> address used for the Map-Request is the data packet's destination >>>> address (i.e., the destination EID) that had a mapping cache lookup >>>> failure." >>>> Does that mean that the Map-Request needs to use the IPv4 or IPv6 = depending on >>>> the IP version used by the initial message from the EID. Is that = always the >>>> case or just for this initial message? I would assume that for all = other cases >>>> this is actually independent...? Because otherwise there would be a = constraint >>>> on what needs to be requested. I would like t see further = clarification about >>>> this in the doc. >>>=20 >>> No it doesn=E2=80=99t. It depends on the address-family of the = map-resolver. And that is configured. >>=20 >> Okay, if the map-resolver is IPv6 and I receive an IPv4 packet, how = can I copy the "the data packet's destination address=E2=80=9C which is = IPv4 in to the "destination IP address used for the Map-Request=E2=80=9C = which is IPv6? Or even worse, the other way around. >=20 > Because a Map-Request going to the mapping system is =E2=80=9CECM=E2=80=99= ed=E2=80=9D =E2=80=9CEncapsulated Control Message=E2=80=9D with the = header address-family as the EID being requested. You say that if the EID send e.g. an IPv4 message it also has to be = encapsulated in IPv4? That is stated nowhere. If that is the intention = that has to be specified. However, I don=E2=80=99t really see why this = restriction needs to exists=E2=80=A6? >=20 >>=20 >>>=20 >>>> 2) In section 5.3: "The ITR MAY include all locally >>>> configured Locators in this list or just provide one locator = address >>>> from each address family it supports." >>>> Would it make sense to include a SHOULD requirement to at least the = address >>>> family that is used to send the Request is included (to increase = chance to >>>> enable a communication/get a reply)=E2=80=A6? >>>=20 >>> But all address-families are used all the time. And in some ITRs, = usually there is no IPv6 at the edge.=20 >>=20 >> What? You say all address families are used all the time but not in = some ITRs=E2=80=A6? I don=E2=80=99t understand what you want to say. = However, if e.g. an IPv4 packet is received and processed, it probably = doesn=E2=80=99t make sense to only include the IPv6 locator address (and = not the IPv4 locator address), especially as it is unknown if the ITR = support IPV6 (while it has been proven to support IPv4). Currently the = spec however would allow that. I=E2=80=99m saying it should to make sure = there is no unnecessary failure case her. >=20 > RLOCs for an xTR can be a collection of IPv4 and IPv6 addresses. They = are tested by remote ITRs to see if they are reachable. When they are, = they may be used. When they are not, no packets get encapsulated to = those RLOCs. >=20 > The Routing Locator Reachability section explains this. This is all understood. I=E2=80=99m still wondering if there should be = more normative recommendations which locator addresses should be = included.=20 >=20 >>=20 >>>=20 >>>> 3) Sec 5.4: "If all Weights for a Locator-Set are equal, >>>> the receiver of the Map-Reply will decide how to load-split the >>>> traffic. " >>>> Shouldn't the receiver in this case split the traffic equally? = Otherwise how >>>> would you signal that the traffic should be split equally? Maybe = use all zero >>>> instead to let the receiver decide=E2=80=A6? >>>=20 >>> It means the ITR will load-split according to hashing. Versus if the = priorities are not equal, it is the ETR deciding how packets ingress the = LISP site. >>=20 >> This is not what the text says. Please clarify in the doc. >=20 > It says it in RFC6830bis since this decision is done by the = data-plane. I still think the text in this doc is not correct. >=20 >>=20 >>>=20 >>>> 4) sec 6.1: "When an ITR receives an SMR-based Map-Request for = which it does not >>>> have a cached mapping for the EID in the SMR message, it may not = send >>>> an SMR-invoked Map-Request." >>>> I guess this should be normative and probably also a MUST NOT or at = least >>>> SHOULD NOT. >>>=20 >>> Yes, I changed to SHOULD NOT. Good catch. Don=E2=80=99t want to make = it a MUST NOT because both sides could be mobile and the remote side may = need to populate its map-cache. That would allow less packet loss if we = keep it SHOULD NOT versus MUST NOT. >=20 > While trying to change it, I noticed its already there: >=20 > When an ITR receives an SMR-based Map-Request for = =20 > which it does not have a cached mapping for the EID in = =20 >>>>> the SMR message, it SHOULD NOT send an SMR-invoked = =20 > Map-Request. This scenario can occur when an ETR sends = =20 > SMR messages to all Locators in the Locator-Set it has = =20 > stored in its Map-Cache but the remote ITRs that receive the = =20 > SMR may not be sending packets to the site. There is no = =20 > point in updating the ITRs until they need to send, in = =20 > which case they will send Map-Requests to obtain a = =20 > Map-Cache entry. Good. Thanks! I guess that was changed based on someone else comment = already. >=20 >>>=20 >>>> 6) Section 8.2 says: "Note that the Map-Notify message >>>> is sent to UDP destination port 4342, not to the source port >>>> specified in the original Map-Register message." >>>> Actually why is that? >>>=20 >>> cisco interperability. >>=20 >> I would expect to still see more reasoning in the doc. >=20 > Sorry, I was wrong in my reply. I read Map-Reply. For Map-Registers = this is normal behavior that a request is sent to a well-known port and = a reply is sent *from* the well known port. Okay, then I still don=E2=80=99t understand WHY this is done? Mirja >=20 > Thanks again for all the effort, > Dino >=20 > >=20 From nobody Tue Sep 18 06:46:46 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3B3130E4A for ; Tue, 18 Sep 2018 06:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 x49Ci7SyjAvt for ; Tue, 18 Sep 2018 06:46:41 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 1BD01130E10 for ; Tue, 18 Sep 2018 06:46:41 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id 20-v6so2158865wrb.12 for ; Tue, 18 Sep 2018 06:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UO4i15++Hq5OOOkV3At/XmNMTOb0M/CIvGHu9+Bz0ns=; b=KSkSOwww7U7RB1mdlNwlReIewVZFwblFJT/imFHE5oNwWB/FrUASqatIVbbdvE7TbV 5WBjX0cM9vB1A+qJIpRTaAoBP/FiAGCSUUPiH7rsZ/pJV+0gHBxeFyFhgqVwXbU5IwZy YnaruBIT6wQxJSxynK/cVKbQXf5vzYyZrwvd2eWaxn6arqiaXYO/dN7qdEf6HDhmHtkt exMCNXknNk5XmPlycCrm3MywwFeJZc6fiJ+feyA8fA3WR74rJkP4T+WyD0F5gOy503hl RUyNRUYHs9O7uivYd1Xaxrv1vcIZ5cR4jjqkhhes8rSKuvmhhSiWBl0PAdl8D9VXPmbX T9og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UO4i15++Hq5OOOkV3At/XmNMTOb0M/CIvGHu9+Bz0ns=; b=QGsMLSgxz2WRbu84tegytaXnd204NARSeqyqmfdbAEgzdFkUCxJ7xCKivXoApsojPc ib+B0iWBQhc9Vn42w0KkoAo9j3M25cp8Szk6FKcv+K23CQ56uFBVxuAUHiMm3qh1ZMfn eej0fgSQ22kfl3vCBxsCEp8Es+CrLRNWgBCtEEQG/2t35/e5l+5unX2xZrS/Qn/987m2 AJwFMQMDQfCZlfFnuEiFrZzqjwuyuIy86n8LofCBvjuP2TpW+kRdtYdVcifavEdAihHx vRtkzqSGfg2rODoURAF8mo5w9QbvhccyzVgstDB+25q+Tmwbqj9Kn5poWrfq9n6/io+c iiZA== X-Gm-Message-State: APzg51DfDFZHGGMsvx5g4Hrmm0N5zb/LD4Kc6p0vNIIUl2vVTlhN9LzN kxTJE3WdC4e0gdCiLc6At8GJmA== X-Google-Smtp-Source: ANB0VdampPfXsXIYcBurwCrAHMLqBpROaAVOx3/S+1ESSP1sI9KnFpjHhbsgfAkcLWX33WSSMgncDw== X-Received: by 2002:adf:fb0e:: with SMTP id c14-v6mr23911500wrr.117.1537278399394; Tue, 18 Sep 2018 06:46:39 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:25f4:45e1:39b9:1fee? ([2001:660:330f:a4:25f4:45e1:39b9:1fee]) by smtp.gmail.com with ESMTPSA id 124-v6sm3892638wmk.20.2018.09.18.06.46.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Sep 2018 06:46:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Luigi Iannone In-Reply-To: Date: Tue, 18 Sep 2018 15:46:43 +0200 Cc: Dino Farinacci , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <1A5C783B-05EE-4A58-8905-C5F95B2729D6@gigix.net> References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 18 Sep 2018 13:46:44 -0000 > On 18 Sep 2018, at 12:32, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Dino, >=20 > please see below. >=20 >> Am 17.09.2018 um 19:48 schrieb Dino Farinacci : >>=20 >>> PROPOSED >>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >>> of the IPv6 'Traffic Class' field) [RFC3168] requires special = treatment in >>> order to preserve the use of ECN on the path. >>> ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner >>> header to the outer header, inline with the =E2=80=99Normal = Mode=E2=80=99 in section 4.1=20 >>> of [RFC6040]. Re-encapsulation SHOULD follow the decapsulation = as described=20 >>> below and then 2-bit 'ECN' field from the stripped inner header = to the=20 >>> new outer header.=E2=80=9C >>=20 >> I did not include this text because the last sentence is not formed = well. Please restate. A verb is missing. >=20 > copy >=20 >>=20 >>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >>> of the IPv6 'Traffic Class' field) requires special treatment on=20= >>> decapsulation in >>> order to avoid discarding indications of congestion,=20 >>> inline with section 4.2 of [RFC6040]. If >>> the 'ECN=E2=80=98 field of the outer header contains a congestion = indication =09 >>> codepoint (the >>> value is '11', the Congestion Experienced (CE) codepoint) and the = inner=20 >>> header indicates ECN support (either ECT(0) or ECT(1) codepoint = is set),=20 >>> then ETR decapsulation MUST also set CE field in the inner header = that is=20 >>> used >>> to forward the packet beyond the ETR. If the inner packet is = marked as non- >>> ECT but the outer header has the CE mark set, the packet MUST be = dropped=20 >>> instead. Any discrepancy between the inner and outer header for = non-ECT,=20 >>> ECT(0) and ECT(1) MUST NOT be copied from the outer header. These=20= >>> requirements preserve >>> CE indications when a packet that is ECN-capable traverses a LISP = tunnel >>> and becomes marked with a CE indication due to congestion between >>> the tunnel endpoints or transforms an CE into loss if that packet = is not=20 >>> ECN-capable conserving the congestion indication towards a = non-ECN enables=20 >>> endpoint.=E2=80=9D >>=20 >> I didn=E2=80=99t include this text because (1) it under states what = to do with IPv4, (2) it has too much detail that is already in RFC6040, = and (3) it undoes text that other reviewers have offered. >=20 > I didn=E2=80=99t change the mentioning of IPv6 here. Yes please at = IPv4. >=20 > You can remove all this text and only point to rfc6040. Mirja, So why not keeping the text as it is (actually with some of the = improvement you suggested), but for all the rest we refer to 6040. See below. For the encapsulation we keep what you proposed: "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) [RFC3168] requires special = treatment in order to preserve the use of ECN on the path. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header, inline with the =E2=80=99Normal Mode=E2=80= =99 in section 4.1=20 of [RFC6040]. Re-encapsulation SHOULD follow the decapsulation as = described=20 below and then copy the 2-bit 'ECN' field from the stripped inner = header to the=20 new outer header.=E2=80=9C For the decapsulation we simply keep the following: "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment on=20 decapsulation in order to avoid discarding indications of congestion,=20 inline with section 4.2 of [RFC6040]. If the 'ECN=E2=80=98 field of the outer header contains a congestion = indication =09 codepoint (the value is '11', the Congestion Experienced (CE) codepoint) and the = inner=20 header indicates ECN support (either ECT(0) or ECT(1) codepoint is = set),=20 then ETR decapsulation MUST also set CE field in the inner header = that is=20 used to forward the packet beyond the ETR.=20 Further information on how to preserve CE information can be found = in RFC6040.=E2=80=9D L. From nobody Tue Sep 18 09:24:23 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79E0130E53; Tue, 18 Sep 2018 09:24:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8sfGRQ0xsIOa; Tue, 18 Sep 2018 09:24:12 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 39AA61277C8; Tue, 18 Sep 2018 09:24:12 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id h79-v6so1258537pfk.8; Tue, 18 Sep 2018 09:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mt4hNHhJ+TdSu8XtuBr6uQGCvUSNyiCvzvk5//SmdMI=; b=lZ8eBot94LxGym1dvN7syzv8KXO4fsc1o/VDDvQHFiCeTF7jBim+PezWGJzcvNAaR6 /ZQaUEZvJg+9g2gCSuRLNjzU2EuosfTbN/2y1lCaJzHLwH0Rl2Z/pA5iB3CgVCsIZ8A6 NKvZ8KREFaulDe8QaOq4MBRPP9pZ3+nvthLAtKJEGDohyN+O5k27rhc34/EkDQ5gJIKp gKjKTbnZElNcwL+CExsBWuv1L3WfkJkPnusaEbrBraUeNyv+kUwRksiSD6eDH+Q9d+W/ d1oBzAuX0lFMrZXVvLCn5I2rhQZNT219zztvOj8MoPKLjWHedlbsegJdLHDiwsn5bcie 0k2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mt4hNHhJ+TdSu8XtuBr6uQGCvUSNyiCvzvk5//SmdMI=; b=rovfu2Hwbinw2FYYcaDQYjW3YcUpQFzo4QzEq6rOvUWqSSl66LdXO7fFsHOLMqGXRh RRD9VAqCrhwwb6rQ3V/M2AlrmDDexHvzJmMGMHJBSOpQv45uRhfbzAZ9vKp1zu0ZxQYA Yqr1jUvyWC+u5syRzsEhg9Tjzii6Vumpod6dOd23i59AU2xotHKfnpafvTrSAmSJRm8d eYKAoRMjQbDXWN+x08658soMAE7ItkZCwbRfchlxYrEqMRERoHHMnQg6kX4ce/dzhvmK OPSxZhAkpwgDyetrGwocXj6BTMI17ZAQHYvmd4sRYDtInEWuMbBIciz6oUmOdFLRubTe sKDQ== X-Gm-Message-State: APzg51Bi9TrvTaKtBMLqq7o9XLrDtqBFU0zHU1r1kMPpfxDJdKAS96FK tFEswjsbFl3w0KcsANSWdsc= X-Google-Smtp-Source: ANB0VdZnMkyzPlkGAuVUH31EhLa9zWIoWmBUHHULFWkjWOhu/mxt/063M17c1S9Ff7V7AhTfmpNlCg== X-Received: by 2002:a63:798c:: with SMTP id u134-v6mr25201706pgc.111.1537287851657; Tue, 18 Sep 2018 09:24:11 -0700 (PDT) Received: from [10.10.32.182] ([65.154.156.52]) by smtp.gmail.com with ESMTPSA id n79-v6sm37701366pfh.2.2018.09.18.09.24.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Sep 2018 09:24:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <0D9A60A2-FE18-4AF1-8A8E-0C6C742CF4F6@kuehlewind.net> Date: Tue, 18 Sep 2018 09:24:06 -0700 Cc: lisp-chairs@ietf.org, "lisp@ietf.org list" , The IESG , Luigi Iannone , Colin Perkins , draft-ietf-lisp-rfc6833bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <9086A458-31C0-4EB2-BC5B-D9CB7B22469E@kuehlewind.net> <0D9A60A2-FE18-4AF1-8A8E-0C6C742CF4F6@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6833bis-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 18 Sep 2018 16:24:15 -0000 Snipping a bit of text to keep the email more readable. >>=20 >> Fixed. >=20 > The sentence still talked about =E2=80=9Efuture version of the = protocol=E2=80=9C. Is that still necessary?=20 Beacuse it is still true. >=20 >>>> The Map-Notify-Ack has been there since day-1 in implementations. = This is just IETF catching up. And it took over 5 years. So we really = don=E2=80=99t have a compatibility situation. And didn=E2=80=99t want to = create one in the specifications. So consider it a day 1, version 1 = message. It really wasn=E2=80=99t added later. >>>=20 >>> This should be stated in section 18. >>=20 >> Done. >=20 > I would specifically state here that for that reason no interop = problems are expected. I think it is clear enough and we shouldn=E2=80=99t over think this. >=20 >>=20 >>>>> any case the chosen approach needs to be further discussed in the = doc. >>>>>=20 >>>>=20 >>>> This is a data-plane feature so it is discussed in 6830bis and = RFC6830. >>>=20 >>> This is a different issue. The control plane protocol as specified = in this doc also needs to consider fragmentation and MTU. Please read = RFC8085 accordingly. >>=20 >> I have added text per Colin=E2=80=99s comments. >=20 > Just pointing to RFC8085 is not enough. This spec must specify that = messages MUST not exceed the MTU and fragmentation should not be used. = And further either recommend to use MTU discovery or just restrict the = message size according to the recommendations in RFC8085. I would = recommend to just do the later for simplicity. I cannot say that or else we invalidate curernt implementations. We do = this and people see the implementations are different than the spec, = then the spec lacks credability. >>>>=20 >>>> We have referenced RFC8085 in the too be published -14 version of = 6833bis. >>>=20 >>> I didn=E2=80=99t find a reference in -14. However a reference is not = enough, the specified behavior is not appropriate and needs to change. = If you need further help, please consult the respective transport = experts, e.g. Gorry Fairhurst who is an author of RFC8085. >>=20 >> I have added text. We have a smaller interval because 3 seconds is = way too long (arguably 1 seond is too) to populate a map-cache. Note = during that time, packets that arrive to the ITR are discarded. So this = occurs if just one Map-Request is lost. >=20 > As I said, just providing a pointer to RFC8085 is not sufficient.=20 Well I think it is. >>>>> Similarly I'm not sure about the intent of this requirement in = section 5.5: >>>>> "Map-Replies SHOULD be sent for an EID-Prefix no more often than = once >>>>> per second to the same requesting router. " >>>>> My understanding is that Replies are only sent when a request is = received. Why >>>>> is this additional rate limit needed? Again if used it should be 3 = seconds for >>>>> all traffic to be inline with RFC8085. Also again, why is that not = a MUST? >>>>> Further recommendation are needed here. >>>>=20 >>>> Because the source is a bad-actor and sending new Map-Requests = (with a new nonce). >>>=20 >>> Not sure if that is the right choice because it may interact badly = with loss detection. However, as I said the specified behavior need to = be refined at various places in the doc. >>=20 >> Well there is not many choices. >=20 > You can choose to not have this rate limiting but limit the total = number of request per requesting router per time interval. That would = trigger a reply immediately but still limit the total load in case of = =E2=80=9Ebad-actors=E2=80=9C. You have to be careful what is added or else it will not reflect = implementations. We have made it a goal to keep the implementations and = IETF specs in sync and didn=E2=80=99t want to repeat issues BGP had in = the 90s (and to this day actually). >>=20 >>>>=20 >>>>> Respectively the following sentence in section 6.1 is also = unclear: >>>>> "The remote ITR MUST rate-limit the Map-Request until it gets a = Map-Reply" >>>>> Why is the rate-limit as currently proposed depend on the fact if = a Map-Reply >>>>> is received? Is the ITR supposed to retransmit the Map-Request=E2=80= =A6? >>>>=20 >>>> If you are not getting answers to your Map-Requests because of = packet loss or MITM, sending them faster is not going to get you a = Map-Reply. >>>=20 >>> If you detect loss, you should send slower not faster for congestion = collapse avoidance. >>=20 >> That was my point. >=20 > Should should instead specify a similar loss detection and = retransmission mechanism for Map-Request as now done for Map-Notify. The = rate-limit alone is not helpful. No. Because Map-Notify is just moving a single message for a particular = reason. The Map-Request is used for a variety of reasons and the = rate-limiting is built into the cache management algorithms. >>>>=20 >>>> That is not rate-limiting to avoid message reduction. It is a = soft-state way of keeping registration state alive in the map-server(s). >>>=20 >>> That fine but you also need to specify normatively an upper bound. >>=20 >> The recommended upper bound is 1 minute. If you are not getting your = point across, please be more specific. >=20 > Then you have to say =E2=80=9EMUST NOT send more than one message per = minutes=E2=80=9C. The current text just gives a recommendation what a go = value might be but does not specify an actually limit. You can=E2=80=99t say that because deregisters are Map-Registers with a = TTL of 0 and can be triggered. I really think the text is fine. >=20 >>>=20 >>> That all fine. However, you don=E2=80=99t specify the behavior if = the ack is not received. How/when is the message assumed to be lost? = When should it be retransmitted? How often? When to give up? Should = exponential backoff be used? This whole part s completely missing in the = spec. >>=20 >> Have added text. >=20 > Thanks! >=20 > Not sure I understand the first sentence: >=20 > =E2=80=9EA sender of an unsolicited Map-Notify message (one that is = not used=09 > as an acknowledgment to a Map-Register message) will follow = the=09 > Congestion Control And Relability Guideline sections of = [RFC8085].=E2=80=9C >=20 > The rest of the text is fine and gives a good spec. I think it is okay = to mention that that spec is inline with RFC8085 but other than that = I=E2=80=99m not sure what this first sentence is telling me=E2=80=A6? >=20 >=20 > And also the last sentence is not fully clear: >=20 > "After this time, the Map-=09 > Notify sender can only get the RLOC-set change by later = querying the=09 > mapping system or by RLOC-probing one of the RLOCs of the = existing=09 > cached RLOC-set to get the new RLOC-set.=E2=80=9C >=20 > I don=E2=80=99t think there should be an attempt to later try again. = Probably the system should log or notify an error instead. However, if = it makes sense to try later again you have to specify what later means = (hours, days?) and how often it should try again before it finally gives = up and logs an error. Did you read the latest version of this paragraph that Albert commented = on. It reads much better. >>>>=20 >>>>> Clarification questions: >>>>> 1) Sec 5.3.: >>>>> "For the initial case, the destination IP >>>>> address used for the Map-Request is the data packet's destination >>>>> address (i.e., the destination EID) that had a mapping cache = lookup >>>>> failure." >>>>> Does that mean that the Map-Request needs to use the IPv4 or IPv6 = depending on >>>>> the IP version used by the initial message from the EID. Is that = always the >>>>> case or just for this initial message? I would assume that for all = other cases >>>>> this is actually independent...? Because otherwise there would be = a constraint >>>>> on what needs to be requested. I would like t see further = clarification about >>>>> this in the doc. >>>>=20 >>>> No it doesn=E2=80=99t. It depends on the address-family of the = map-resolver. And that is configured. >>>=20 >>> Okay, if the map-resolver is IPv6 and I receive an IPv4 packet, how = can I copy the "the data packet's destination address=E2=80=9C which is = IPv4 in to the "destination IP address used for the Map-Request=E2=80=9C = which is IPv6? Or even worse, the other way around. >>=20 >> Because a Map-Request going to the mapping system is =E2=80=9CECM=E2=80= =99ed=E2=80=9D =E2=80=9CEncapsulated Control Message=E2=80=9D with the = header address-family as the EID being requested. >=20 > You say that if the EID send e.g. an IPv4 message it also has to be = encapsulated in IPv4? That is stated nowhere. If that is the intention = that has to be specified. However, I don=E2=80=99t really see why this = restriction needs to exists=E2=80=A6? Let me explain. If you are sending a Map-Request for an IPv4 EID, you = build an IPv4 Map-Request. Before sending it it is wrapped with an ECM = header and then sent to the Map-Resolver. The IP header wrapped around = the ECM header is the address family of the configured Map-Resolver. All = 4 combinations work and is deployed. >>>>=20 >>>>> 6) Section 8.2 says: "Note that the Map-Notify message >>>>> is sent to UDP destination port 4342, not to the source port >>>>> specified in the original Map-Register message." >>>>> Actually why is that? >>>>=20 >>>> cisco interperability. >>>=20 >>> I would expect to still see more reasoning in the doc. >>=20 >> Sorry, I was wrong in my reply. I read Map-Reply. For Map-Registers = this is normal behavior that a request is sent to a well-known port and = a reply is sent *from* the well known port. >=20 > Okay, then I still don=E2=80=99t understand WHY this is done? The interoperability reference is a cisco implementation issue. And I = won=E2=80=99t comment why it was done this way, lots of historical = details. Dino >=20 > Mirja From nobody Tue Sep 18 09:32:05 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D071277C8; Tue, 18 Sep 2018 09:31:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153728831776.7811.10271947752669799423@ietfa.amsl.com> Date: Tue, 18 Sep 2018 09:31:57 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-15.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 18 Sep 2018 16:31: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 WG of the IETF. Title : Locator/ID Separation Protocol (LISP) Control-Plane Authors : Vince Fuller Dino Farinacci Albert Cabellos Filename : draft-ietf-lisp-rfc6833bis-15.txt Pages : 50 Date : 2018-09-18 Abstract: This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases. By using this Control-Plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems, which facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP Control-Plane infrastructure, connect directly to LISP-capable Internet end sites, and comprising the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. This document obsoletes RFC 6830 and 6833. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-15 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-15 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 Tue Sep 18 09:50:18 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D16127333; Tue, 18 Sep 2018 09:50:10 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3FCc2tCPtlOM; Tue, 18 Sep 2018 09:50:07 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 EFFEB130E22; Tue, 18 Sep 2018 09:50:06 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id b97-v6so1293355plb.0; Tue, 18 Sep 2018 09:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IuUKayw/9qpk7LE3VOrkBtS8uW/TL2qE80fY+nYribM=; b=ROEKCShwO4KF6+xj1UZfc0GQtBsdU4Ar/ZRFIqq4eHCuoI/HHQMcUOIAi9fkCbFpQs mQDWM7wBQcauB4T3LDMfwyR9a76iPnQwAKXCH7n10y+GV6FnzUOdGAiNnQmuGSHm3+Sd NyY2q1exbpJ4c4JOzYzwNUD3JCYR6ffXXeEUB3xE4xjNefsCio3n9TEgwdgQqgfEhS+S GBDYpfUA8xmRK9l/HGVR3p0dltCndmk2lyoSlWrYvcH0pFUHvRVQo683t+LHJUVwpUOd syzcljgGyzMDB0/lx/CwPIAi5PfyCa0JrOtIhQiLWNTBPRT6YJnTHnDMw9kymmmLtPDg Z6CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IuUKayw/9qpk7LE3VOrkBtS8uW/TL2qE80fY+nYribM=; b=NIVyn3HEU7id79kHI4PWcTtqJGjrdod37eAEmxjcgFCT8bp9p3Ks2XY6i9bMFpeoUC C0/Ef7IlqUH4fAJbFtnoNNB6sdOC2GXNK4fiL4oX1xPgvyZzxIR9MrbOW559/eXzrJdp l3KYesbhL+pupN8UyIO3XzKVyaoi+OeQM6bRR7QDN/ui832yEMx5dSKtKMseN1tFZa0C OD8odqnXVD6k0+YxyrFc7USuwPRqATA3PWPGEJrK+4APWGAhZEowXMezj6Pq+eSl0/Gn J1NlS8iuhWEcPCFt4UveRkN3aPfxKDmu352WTLjfxy57lQgCFgT+ZN5lmmo6eepCTIKs D/lg== X-Gm-Message-State: APzg51CAk4lDEHa+ewFZxi0H5890K3QPeWLzNfYCQ0pVtB1fU3pYj76w dFOCO6w45sQTeofo6AYyZP4VbxTc X-Google-Smtp-Source: ANB0VdZTReP5+PBG+9VFe9CviDPsQLMHnvBygxxG5o+DSAFwML3K1zHEHFeMnD9Y9ASWGq7uQbb4oA== X-Received: by 2002:a17:902:2e83:: with SMTP id r3-v6mr30411477plb.80.1537289406516; Tue, 18 Sep 2018 09:50:06 -0700 (PDT) Received: from [10.10.32.182] ([65.154.156.52]) by smtp.gmail.com with ESMTPSA id t12-v6sm23154739pgg.72.2018.09.18.09.50.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Sep 2018 09:50:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 18 Sep 2018 09:50:04 -0700 Cc: "Mirja Kuehlewind (IETF)" , lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, The IESG , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 18 Sep 2018 16:50:11 -0000 > @ Dino: this point is about the following bullet in section 5.3: >=20 > The outer-header 'Differentiated Services Code Point' (DSCP) field > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be > copied from the inner-header DSCP field ('Traffic Class' field, = in > the case of IPv6) considering the exception listed below. >=20 >=20 >=20 > You need to delete the trailing =E2=80=9Cconsidering the exception = listed below=E2=80=9D because there is no exception listed. Done. And add =E2=80=9Cto the outer-header.=E2=80=9D Will go in -19. The outer-header 'Differentiated Services Code Point' = =20 (DSCP) field (or the 'Traffic Class' field, in the case of = =20 IPv6) SHOULD be copied from the inner-header DSCP field = =20 ('Traffic Class' field, in the case of IPv6) to the = =20 outer-header. Dino From nobody Tue Sep 18 09:54:56 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E21130E22; Tue, 18 Sep 2018 09:54:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Fr8WDBfVIj5w; Tue, 18 Sep 2018 09:54:52 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 C6CF1130E0A; Tue, 18 Sep 2018 09:54:52 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id s15-v6so1321848pgv.8; Tue, 18 Sep 2018 09:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gn05nwKF6kRjRKeWuKdudBvM44x++VzwootuERThc0w=; b=sAWiEYofdmmXJ4WiodPSEghjgb0sshR5OoRJ3EQYq53FqGMV4WgvAz4HfBQLGaIjCX GVxYtJ/3iLteGUHO4isrrcY0y7TiB8WvTa9pFNY4vRieleZOI3p0meWXRxHZgo7z3ZZH Qz7+QKItunPZuyKhnsQFY2xtEVNUcL14wFPPTg/aByGjKHE7lC/B4jVPt3zsII38zyl2 rzSAU52k1XBSayPjbk20V+fV/uQsVsxVSbBq+alKVB16/BlKnwMw71KBdxngqHDmDbTy P2kVwqHCbzIHyTUY75DgiYd0vADAvJU/jn450PDlIQfi0yvYNeibv4RRE0S3tkTT2lxN vkww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gn05nwKF6kRjRKeWuKdudBvM44x++VzwootuERThc0w=; b=WA3lFsiyJaZhHciae7UbooYjZRGBEy7t3wAhTdAZkMqsxLNasXPYVccoCZYTr254jA XUMnTdU1Xc2o90JDTGrg24PI4tj8wop8kskY9a4ZPyxbRX08hn9zO6uT5MUJhlcI2RLU +n+HXcnP9WqPNoBuF9AHRd/fjuPgK21ZvWwX3hrtn9wVMBL2mUfCWFRQEqUrkyNme32v 1oTOxVQPW5bFIZ2BEAnmhUygzZ2TJkom+xqCPcHmT3udOtOfqTNn7k01SpS4At3LpwEv i0p9ADg7xoLLty47zE0tgXYEogpoY4rlo8d3y7hPGxF9xXKqAh19xAC2zb5L5lqVwTdn J3vA== X-Gm-Message-State: APzg51ApbDDLQXO16SQM2Yf++DG7rOOVcUphL9F9Zz+YAsHVqnNehb0P lCrgSDBsiSvmusluxuP/VGI= X-Google-Smtp-Source: ANB0VdbeiXKzE5CCvfyj1ZbobzVhU1ktUNdeWCHuZQhb/osBKN5AZogAguCqJ5EhCCojFiLFLZB35w== X-Received: by 2002:a63:df4e:: with SMTP id h14-v6mr28541909pgj.300.1537289692262; Tue, 18 Sep 2018 09:54:52 -0700 (PDT) Received: from [10.10.32.182] ([65.154.156.52]) by smtp.gmail.com with ESMTPSA id l79-v6sm33862695pfi.172.2018.09.18.09.54.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Sep 2018 09:54:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <523C5B6B-12C8-4B67-B67D-A445D9C57E28@kuehlewind.net> Date: Tue, 18 Sep 2018 09:54:50 -0700 Cc: Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <523C5B6B-12C8-4B67-B67D-A445D9C57E28@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 18 Sep 2018 16:54:55 -0000 >>=20 >> =E2=80=9CExtension to the LISP header described in this document can = be achieved using the LISP General Protocol Encapsulation mechanism = [draft-ietf-lisp-gpe].=E2=80=9C=20 >=20 > Yes, that would be sufficient. I=E2=80=99m actually wondering with = this draft was not directly included in 6830bis. I thought we (the WG) made a decision to not reference lisp-gpe in = 6830bis. It is not referenced now. Dino From nobody Tue Sep 18 09:56:33 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392F9130E0A; Tue, 18 Sep 2018 09:56: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Z7CT4GSaNQpb; Tue, 18 Sep 2018 09:56:29 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 9F8BA127333; Tue, 18 Sep 2018 09:56:29 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id h79-v6so1299860pfk.8; Tue, 18 Sep 2018 09:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MSftNArNbdrJRIiPLIwQDTdD7GWEqd2ZJVZHRjxxsbM=; b=O10qMwGaZ4JdRm/Dwno1xr4sqw7V0n0/Zpiu4xKxyzJpqOCyXTE4ruq0bAf3XU7dLd Fs0nF8iLecvMONrtbqaseuCR9CPdQPu0+nwLhboJJuZntVp16MCm3u3zJmBYtahwg7SN RjETJM3p7Yra8wdoJK2PDRWEAfNFVobPjsrAaNJCKwUJA46fiI+a1xFvmigF+zTmyk/S +PCaNTkyvWYZkbxdGg420ElwS0RSPFwSouikGWXXFSoajuCe66jSjOqpTeC4Vwhbpu06 ZGo54qWxFHlJLTaDztKyD6YPnpc8RXv8mYFQZidcqmT/PkHOXbjwtHwmoFviN3NuPdo+ IBSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MSftNArNbdrJRIiPLIwQDTdD7GWEqd2ZJVZHRjxxsbM=; b=ln7A2hbMJb2i5zBbS3z3OHvhqxN4FG9G80HlpZ1gARAizM7MeU1gaip9bA3Znwea3d w2RGZe8lC72XCXO+FGHYocOvlpL8j1jxivjdNaOYm/O7NOlBqDst8aN8DiBtrkFEn67s kR+/2iLDCLVVUxsDFTQniLd1M34OlcdiTOU0PYjUTxHDTtnvuqtFtD3X/MPfirw1Y1h8 VfbguvaRbV+RmnSb3oB406GBMQdkNhs9hDOScKa4NqVhSRmyD/K2kcvQRKLjPHT9u+cu JoJWWdBL1p1WTkp1MwAcClCE7LZWIY37jdSr4ZP24Y4awesQtPX4qBzDIUEV2ujLmjmz AH/A== X-Gm-Message-State: APzg51CMmicV+OQFpkEidai0YDiyT11fAC8tQNOEfZ6Ux2RgV8t4l7Ob 6Zl77CC4ogl+rDLQQlM3YGiF78En X-Google-Smtp-Source: ANB0VdYFxGLNcGb8fFVZv7he22U2ns0QTCsmYMe2ep4UAN98FhXWoR7cxsGyCypp9Yc2fnBoHsYVkQ== X-Received: by 2002:a62:fc5:: with SMTP id 66-v6mr31555579pfp.237.1537289789188; Tue, 18 Sep 2018 09:56:29 -0700 (PDT) Received: from [10.10.32.182] ([65.154.156.52]) by smtp.gmail.com with ESMTPSA id e73-v6sm35873418pfb.153.2018.09.18.09.56.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Sep 2018 09:56:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 18 Sep 2018 09:56:27 -0700 Cc: Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 18 Sep 2018 16:56:33 -0000 As I already said, this text is too detailed and repeats what is in = other RFCs. And since implementations do what they already do, adding = more details that are not implemented, IMO, is not good form. Dino > On Sep 18, 2018, at 3:32 AM, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Dino, >=20 > please see below. >=20 >> Am 17.09.2018 um 19:48 schrieb Dino Farinacci : >>=20 >>> PROPOSED >>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >>> of the IPv6 'Traffic Class' field) [RFC3168] requires special = treatment in >>> order to preserve the use of ECN on the path. >>> ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner >>> header to the outer header, inline with the =E2=80=99Normal = Mode=E2=80=99 in section 4.1=20 >>> of [RFC6040]. Re-encapsulation SHOULD follow the decapsulation = as described=20 >>> below and then 2-bit 'ECN' field from the stripped inner header = to the=20 >>> new outer header.=E2=80=9C >>=20 >> I did not include this text because the last sentence is not formed = well. Please restate. A verb is missing. >=20 > copy >=20 >>=20 >>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >>> of the IPv6 'Traffic Class' field) requires special treatment on=20= >>> decapsulation in >>> order to avoid discarding indications of congestion,=20 >>> inline with section 4.2 of [RFC6040]. If >>> the 'ECN=E2=80=98 field of the outer header contains a congestion = indication =09 >>> codepoint (the >>> value is '11', the Congestion Experienced (CE) codepoint) and the = inner=20 >>> header indicates ECN support (either ECT(0) or ECT(1) codepoint = is set),=20 >>> then ETR decapsulation MUST also set CE field in the inner header = that is=20 >>> used >>> to forward the packet beyond the ETR. If the inner packet is = marked as non- >>> ECT but the outer header has the CE mark set, the packet MUST be = dropped=20 >>> instead. Any discrepancy between the inner and outer header for = non-ECT,=20 >>> ECT(0) and ECT(1) MUST NOT be copied from the outer header. These=20= >>> requirements preserve >>> CE indications when a packet that is ECN-capable traverses a LISP = tunnel >>> and becomes marked with a CE indication due to congestion between >>> the tunnel endpoints or transforms an CE into loss if that packet = is not=20 >>> ECN-capable conserving the congestion indication towards a = non-ECN enables=20 >>> endpoint.=E2=80=9D >>=20 >> I didn=E2=80=99t include this text because (1) it under states what = to do with IPv4, (2) it has too much detail that is already in RFC6040, = and (3) it undoes text that other reviewers have offered. >=20 > I didn=E2=80=99t change the mentioning of IPv6 here. Yes please at = IPv4. >=20 > You can remove all this text and only point to rfc6040. That would = actually my preferred solution. I don=E2=80=99t think it =E2=80=9Eundoes=E2= =80=9C text; it just adds what was missing in compliance with RFC6040. = Anyway it doesn=E2=80=99t matter point being that it should specify the = same things as RFC6040 does not matter what other have ofter because = RFC6040 is the IETF-consensus doc how describing how to handle this. >=20 >>=20 >>=20 >>> Please also remove the duplicated text after these bullet lists in = the draft! >>=20 >> You have to tell me what text. I am too confused at this point on = what you want. >=20 > This is the text in the en-/ and decapsulation lists: >=20 > "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion [RFC3168]. > ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner > header to the outer header. Re-encapsulation MUST copy the 2-bit > 'ECN' field from the stripped outer header to the new outer > header." >=20 > "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion [RFC6040]. = If > the 'ECN' field contains a congestion indication codepoint (the > value is '11', the Congestion Experienced (CE) codepoint), then > ETR decapsulation MUST copy the 2-bit 'ECN' field from the > stripped outer header to the surviving inner header that is used > to forward the packet beyond the ETR. These requirements = preserve > CE indications when a packet that uses ECN traverses a LISP = tunnel > and becomes marked with a CE indication due to congestion between > the tunnel endpoints." >=20 > And this text comes up right after the list in the same section: >=20 > "The Explicit Congestion Notification ('ECN') field occupies bits 6 > and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic > Class' field [RFC6040]. The 'ECN' field requires special treatment > in order to avoid discarding indications of congestion [RFC6040]. = An > ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the = inner > header to the outer header. Re-encapsulation MUST copy the 2-bit > 'ECN' field from the stripped outer header to the new outer header. > If the 'ECN' field contains a congestion indication codepoint (the > value is '11', the Congestion Experienced (CE) codepoint), then ETR/ > PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped > outer header to the surviving inner header that is used to forward > the packet beyond the ETR. These requirements preserve CE > indications when a packet that uses ECN traverses a LISP tunnel and > becomes marked with a CE indication due to congestion between the > tunnel endpoints." >=20 > The last text bit does not add any information; it just states all = normative requirement twice, even using basically exactly the some = words. This can lead to discrepancies and it really not necessary. I=E2=80= =99d recommend to just remove the last text block here (and fix the = IPv6/IPv4 issue in the other blocks). >=20 > Mirja >=20 >=20 >>=20 >>> Further I believe my discuss points 2) and 4) are not fully resolved = yet. Also I would like to at least see more explanation about the = approach for extensibility that was taken in this doc (point 6). >>=20 >> You are going to have to repeat what they are because too many emails = have flown by since your initial post. And for extensibility, we discuss = it in RFC8060 and don=E2=80=99t think anything more should be said here = otherwise, we will duplicate unnecessary text. >>=20 >> Another new diff file enclosed. >>=20 >> Dino >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 From nobody Tue Sep 18 12:53:03 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA01130E35; Tue, 18 Sep 2018 12:53:01 -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_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 8RHSmZ9mFAIy; Tue, 18 Sep 2018 12:52:58 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967FE120072; Tue, 18 Sep 2018 12:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20483; q=dns/txt; s=iport; t=1537300378; x=1538509978; h=from:subject:to:cc:references:message-id:date: mime-version:in-reply-to; bh=r3xZNIiKEtGQfklKBUI9j1lhEzD3rDradKu94SJ5uaw=; b=K/A0HOL1cc5M3xV2y4AEHlxJipgcg0P9Ue9nGeR+RqEygeF0i6b5MYvY u+120Xn/wSTrt/cpnM0R38NVRYwVlNLqgtOfJx6MrFpFN4Ag4Qtw2ocTu KE4JpnuVQdencgxKO8Cgd4dWblnWaAZ1obTQnHbFkLESJPlNh+ANIYW8L w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAAB4VqFb/4ENJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYFRgVgFKmV/KINylESBYC2REYU7gXoLI4RJAoMmITUXAQM?= =?us-ascii?q?BAQIBAQJtHAyFOQEFIyQyEAsYKgICVwYBDAYCAQGDHQGCAQ+lH4EuH4MKgQY?= =?us-ascii?q?GQoUSBYptF4FBP4ESJ4JrgxsCAwGBNoMoglcCiBkghiGNdwmGQoMEhlUGF4F?= =?us-ascii?q?DhEyCXYYoi2uIf4FDATaBVTMaCBsVgyeCJRd6AQeHV4VeHzCKe4JMAQE?= X-IronPort-AV: E=Sophos;i="5.53,391,1531785600"; d="scan'208,217";a="454114877" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2018 19:52:56 +0000 Received: from [10.32.172.181] ([10.32.172.181]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTP id w8IJquQc007825; Tue, 18 Sep 2018 19:52:56 GMT From: Fabio Maino To: Magnus Westerlund , tsv-art@ietf.org Cc: lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org References: <153553422964.14784.628403975182959075@ietfa.amsl.com> Message-ID: Date: Tue, 18 Sep 2018 12:52:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153553422964.14784.628403975182959075@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------36B296874702ADB3BC3A9A5E" Content-Language: en-US X-Outbound-SMTP-Client: 10.32.172.181, [10.32.172.181] X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 18 Sep 2018 19:53:02 -0000 This is a multi-part message in MIME format. --------------36B296874702ADB3BC3A9A5E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Magnus, thanks for your comments. I think I see the points you are making. I'll add the section 3.1 below to specify the general transport requirements for the registration of new LISP-GPE payloads, and I will introduce two subsections to instantiate those requirements for Ethernet and NSH (section 4.2 and 4.3 will be moved here). In the "IANA Considerations" section I'll refer to this new section 3.1 as a requirement for registration of new encapsulated payload. "3.1 Payload Specific Transport Interactions To ensure that protocols that are encapsulated in LISP-GPE will work well from a transport interaction perspective, the specification of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion Notification (ECN) bits whenever they apply to the new encapsulated payload. For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] specifies how to handle UDP Checksums encouraging implementors to consider UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP and LISP headers against corruption. Each new encapsulated payloads, when registered with LISP-GPE, MUST be accompanied by a similar analysis. Encapsulated payloads may have a priority field that may or may not be mapped to the DSCP field of the outer IP header (part of Type of Service in IPv4 or Traffic Class in IPv6). Such new encapsulated payloads, when registered with LISP-GPE, MUST be accompanied by an analysis similar to the one performed in Section 3.1.1 of this document for Ethernet payloads. Encapsulated payloads may have Explicit Congestion Notification mechanisms that may or may not be mapped to the outer IP header ECN field. Such new encapsulated payolads, when registered with LISP-GPE, MUST  be accompanied by a set of guidelines derived from [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. The rest of this section specifies payload specific transport interactions considerations for the two new LISP-GPE encapsulated payloads specified in this document: Ethernet and NSH. 3.1.1 Payload Specific Transport Interactions for Ethernet Encapsulated Payloads The UDP Checksum considerations specified in section 5.3 of [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. Implementors are encouraged to consider the UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP, LISP and Ethernet headers against corruption. When a LISP-GPE router performs Ethernet encapsulation, the inner 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be mapped from the encapsulated frame to the Type of Service field in the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' field as per guidelines provided by [RFC8325]. When a LISP-GPE router performs Ethernet encapsulation, the inner header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or used to determine the LISP Instance ID field. 3.1.2 Payload Specific Transport Interactions for NSH Encapsulated Payloads The UDP Checksum considerations specified in section 5.3 of [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. Implementors are encouraged to consider the UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP, LISP, and NSH headers against corruption. When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN values MAY be mapped as specified for the Next Protocol encapsulated by NSH (namely IPv4, IPv6 and Ethernet)." I will also add a paragraph to "Iana Considerations" that says: "To ensure that protocols that are encapsulated in LISP-GPE will work well from a transport interaction perspective, the registration of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion Notification (ECN) bits whenever they apply to the new encapsulated payload. The analysis for the new encapsulated payload registered in this document is in section 3.1." Please, let me know if this address your comments. Thanks, Fabio On 8/29/18 2:17 AM, Magnus Westerlund wrote: > Reviewer: Magnus Westerlund > Review result: Not Ready > > This document has been reviewed as part of the transport area directorate's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG for their information and to allow them to address any issues > raised. > > When done at the time of IETF Last Call, the authors should consider this > review together with any other last-call comments they receive. > Please always CCtsv-art@ietf.org if you reply to or forward this review. > > Issue A. > > The reason I state Not Ready has to do with this documents failure to consider > the use of zero checksum for IPv6 when tunneling other things than IP. The none > GPE version is limited to tunnel IP for which the analysis for use of zero > checksum has been done. Each of the new tunneled protocols that are specified > in this document, i.e. ethernet and NHS, will need to perform the analysis if > they are safe to use zero checksum or not, and if not disallow zero checksum > for IPv6/UDP. The documetn also need a requirement in the registration > requirements to perform this analysis and defined if zero checksum is > acceptable or not. > > Citing Section 5.3 of draft-ietf-lisp-rfc6830bis > > UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero > by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation > [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is > received by an ETR, the ETR MUST accept the packet for > decapsulation. When an ITR transmits a non-zero value for the UDP > checksum, it MUST send a correctly computed value in this field. > When an ETR receives a packet with a non-zero UDP checksum, it MAY > choose to verify the checksum value. If it chooses to perform > such verification, and the verification fails, the packet MUST be > silently dropped. If the ETR chooses not to perform the > verification, or performs the verification successfully, the > packet MUST be accepted for decapsulation. The handling of UDP > zero checksums over IPv6 for all tunneling protocols, including > LISP, is subject to the applicability statement in [RFC6936]. > > The issue is that when LISP encapsulate other protocols the impact of a > missdelivered tunnel packet to the wrong ETR can have different impacts. As > well as errors in the headers of the encapsulated packet that may be assumed to > be protected by the encapsulating layer. Thus, individual analysis of each > protocol that are tunneled are needed. > > B.) 4.2. Type of Service > > When a LISP-GPE router performs Ethernet encapsulation, the inner > 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be > mapped from the encapsulated frame to the Type of Service field in > the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' > field. > > Any recommendation about how to perform that mapping? Maybe parts of > https://datatracker.ietf.org/doc/rfc8325/ are relevant in this context. > > C. General case of 4.2: > > I expect other protocols than Ethernet may have a priority field that may or > may not be mapped to the DSCP field of the tunnel packet. > > I would expect that for new protocol registration in the LISP-GPE Next Protocol > Registry should consider this. Thus, it would be good to note that such > considerations are needed and part of what should be evaluated for new > registrations. > > D. ECN handling > > Section 5.3 of draft-ietf-lisp-rfc6830bis states: > > o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion [RFC3168]. > ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner > header to the outer header. Re-encapsulation MUST copy the 2-bit > 'ECN' field from the stripped outer header to the new outer > header. > > The above rules may not be applicable for all transport protocols. Thus I think > it is required that one do protocol specific considerations of ECN. TSVWG are > working on recommendations for tunnels handling of ECN here, see: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ Thus, > my expectation would be to ensure that the registered protocols have defined > ECN handling, explicitly or by reference. Secondly that registration > requirement states the need for this consideration. > > Summary: To ensure that future added protocols that are encapsulated will work > well from a transport interaction perspective there need to be a requirement on > new registration to consider and define how they use zero checksum, any DSCP > mapping and ECN bits. In addition the current document needs to ensure these > things are clearly specified for the encapsulated protocols in this document. > > --------------36B296874702ADB3BC3A9A5E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Magnus,
thanks for your comments.

I think I see the points you are making.

I'll add the section 3.1 below to specify the general transport requirements for the registration of new LISP-GPE payloads, and I will introduce two subsections to instantiate those requirements for Ethernet and NSH (section 4.2 and 4.3 will be moved here). In the "IANA Considerations" section I'll refer to this new section 3.1 as a requirement for registration of new encapsulated payload.

"3.1 Payload Specific Transport Interactions

To ensure that protocols that are encapsulated in LISP-GPE will work well from a transport interaction perspective, the specification of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion Notification (ECN) bits whenever they apply to the new encapsulated payload.

For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] specifies how to handle UDP Checksums encouraging implementors to consider UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP and LISP headers against corruption. Each new encapsulated payloads, when registered with LISP-GPE, MUST be accompanied by a similar analysis.

Encapsulated payloads may have a priority field that may or may not be mapped to the DSCP field of the outer IP header (part of Type of Service in IPv4 or Traffic Class in IPv6). Such new encapsulated payloads, when registered with LISP-GPE, MUST be accompanied by an analysis similar to the one performed in Section 3.1.1 of this document for Ethernet payloads.

Encapsulated payloads may have Explicit Congestion Notification mechanisms that may or may not be mapped to the outer IP header ECN field. Such new encapsulated payolads, when registered with LISP-GPE, MUST  be accompanied by a set of guidelines derived from [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].

The rest of this section specifies payload specific transport interactions considerations for the two new LISP-GPE encapsulated payloads specified in this document: Ethernet and NSH.

3.1.1 Payload Specific Transport Interactions for Ethernet Encapsulated Payloads

The UDP Checksum considerations specified in section 5.3 of [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. Implementors are encouraged to consider the UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP, LISP and Ethernet headers against corruption.

When a LISP-GPE router performs Ethernet encapsulation, the inner 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be mapped from the encapsulated frame to the Type of Service field in the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' field as per guidelines provided by [RFC8325].

When a LISP-GPE router performs Ethernet encapsulation, the inner header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or used to determine the LISP Instance ID field.

3.1.2 Payload Specific Transport Interactions for NSH Encapsulated Payloads

The UDP Checksum considerations specified in section 5.3 of [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. Implementors are encouraged to consider the UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP, LISP, and NSH headers against corruption.

When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN values MAY be mapped as specified for the Next Protocol encapsulated by NSH (namely IPv4, IPv6 and Ethernet)." 


I will also add a paragraph to "Iana Considerations" that says:


"To ensure that protocols that are encapsulated in LISP-GPE will work well from a transport interaction perspective, the registration of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion Notification (ECN) bits whenever they apply to the new encapsulated payload. The analysis for the new encapsulated payload registered in this document is in section 3.1."

Please, let me know if this address your comments.

Thanks,
Fabio



On 8/29/18 2:17 AM, Magnus Westerlund wrote:
Reviewer: Magnus Westerlund
Review result: Not Ready

This document has been reviewed as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG for their information and to allow them to address any issues
raised.

When done at the time of IETF Last Call, the authors should consider this
review together with any other last-call comments they receive.
Please always CC tsv-art@ietf.org if you reply to or forward this review.

Issue A.

The reason I state Not Ready has to do with this documents failure to consider
the use of zero checksum for IPv6 when tunneling other things than IP. The none
GPE version is limited to tunnel IP for which the analysis for use of zero
checksum has been done. Each of the new tunneled protocols that are specified
in this document, i.e. ethernet and NHS, will need to perform the analysis if
they are safe to use zero checksum or not, and if not disallow zero checksum
for IPv6/UDP. The documetn also need a requirement in the registration
requirements to perform this analysis and defined if zero checksum is
acceptable or not.

Citing Section 5.3 of draft-ietf-lisp-rfc6830bis

   UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as zero
      by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
      [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is
      received by an ETR, the ETR MUST accept the packet for
      decapsulation.  When an ITR transmits a non-zero value for the UDP
      checksum, it MUST send a correctly computed value in this field.
      When an ETR receives a packet with a non-zero UDP checksum, it MAY
      choose to verify the checksum value.  If it chooses to perform
      such verification, and the verification fails, the packet MUST be
      silently dropped.  If the ETR chooses not to perform the
      verification, or performs the verification successfully, the
      packet MUST be accepted for decapsulation.  The handling of UDP
      zero checksums over IPv6 for all tunneling protocols, including
      LISP, is subject to the applicability statement in [RFC6936].

The issue is that when LISP encapsulate other protocols the impact of a
missdelivered tunnel packet to the wrong ETR can have different impacts. As
well as errors in the headers of the encapsulated packet that may be assumed to
be protected by the encapsulating layer. Thus, individual analysis of each
protocol that are tunneled are needed.

B.) 4.2.  Type of Service

   When a LISP-GPE router performs Ethernet encapsulation, the inner
   802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be
   mapped from the encapsulated frame to the Type of Service field in
   the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'
   field.

Any recommendation about how to perform that mapping? Maybe parts of
https://datatracker.ietf.org/doc/rfc8325/ are relevant in this context.

C. General case of 4.2:

I expect other protocols than Ethernet may have a priority field that may or
may not be mapped to the DSCP field of the tunnel packet.

I would expect that for new protocol registration in the LISP-GPE Next Protocol
Registry should consider this. Thus, it would be good to note that such
considerations are needed and part of what should be evaluated for new
registrations.

D. ECN handling

Section 5.3 of draft-ietf-lisp-rfc6830bis states:

   o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion [RFC3168].
      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
      header to the outer header.  Re-encapsulation MUST copy the 2-bit
      'ECN' field from the stripped outer header to the new outer
      header.

The above rules may not be applicable for all transport protocols. Thus I think
it is required that one do protocol specific considerations of ECN. TSVWG are
working on recommendations for tunnels handling of  ECN here, see: 
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ Thus,
my expectation would be to ensure that the registered protocols have defined
ECN handling, explicitly or by reference. Secondly that registration
requirement states the need for this consideration.

Summary: To ensure that future added protocols that are encapsulated will work
well from a transport interaction perspective there need to be a requirement on
new registration to consider and define how they use zero checksum, any DSCP
mapping and ECN bits. In addition the current document needs to ensure these
things are clearly specified for the encapsulated protocols in this document.


--------------36B296874702ADB3BC3A9A5E-- From nobody Wed Sep 19 05:41:54 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4A7130FCE; Wed, 19 Sep 2018 05:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 hug_yA7SlGmg; Wed, 19 Sep 2018 05:41:48 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49531130FCD; Wed, 19 Sep 2018 05:41:48 -0700 (PDT) Received: from [130.209.157.50] (port=16459 helo=glaroam2-141-222.wireless.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1g2bna-0004iE-IT; Wed, 19 Sep 2018 13:41:46 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: Date: Wed, 19 Sep 2018 13:41:29 +0100 Cc: tsv-art@ietf.org, draft-ietf-lisp-rfc6833bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <95DE3AE3-225C-487C-A690-DEF2C3870561@csperkins.org> References: <153597929696.13392.8265627120055145654@ietfa.amsl.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 12:41:51 -0000 Some follow-up comments inline. Colin > On 12 Sep 2018, at 19:58, Dino Farinacci wrote: >=20 > Thanks for the response, no worries on the slow follow-up. I have cut = out some email text. >=20 >>>>=20 >>>=20 >>> The control-plane does=E2=80=99t try to send MTU size packets. It = depends on IP fragmentation/reassembly. But an implementation should = know it cannot build a LISP message larger than 65535 bytes. >>=20 >> I=E2=80=99m not convinced relying on IP fragmentation is a good idea. = In the best case, loss of a fragment results in loss of the entire = packet, multiplying the effective loss rate. There can also be = middleboxes that drop fragments. It would be better if the control place = could fragment to MTU size packets (either the actual MTU, or a typical = MTU =E2=80=93 1280 octets perhaps). >=20 > Well an implementation can certainly build messages of effective MTU = length which in most cases is 1280/1500 as well. I=E2=80=99d suggest that the document provide guidance on doing this, = since relying on IP fragmentation is going to be problematic. >>>> The draft does not mention congestion control, but many of the = messages are >>>> rate limited. If the intent of the rate limits is that no further = congestion >>>> control is needed, then it needs to be made explicit that this is = the case, and >>>=20 >>> Yes, that is the intent. >>>=20 >>>> some justification needs to be added to explain why it is safe. = This could, >>>> perhaps, take the form of an appendix that analyses the expected = control plane >>>> traffic that will flow over a particular path when the protocol is = in use, and >>>> demonstrates that this will be low enough rate not to be = problematic. In any >>>> case, the draft needs some discussion of how congestion control is = addressed. >>>=20 >>> The flow-control is coupled with protecting caches as well as = request and register load on map-resolvers and map-servers. >>=20 >> Sure, but as I mentioned, the draft needs some justification for why = this is safe from a congestion control viewpoint. >=20 > Can you suggest some simple text that would be sufficient. We have = done the analysis in other drafts. Would simply pointing a reference to = them be sufficient you think? If the analysis exists elsewhere, then referencing it is likely = sufficient. If not, this needs analysis by someone who understands LISP = to explain why it won=E2=80=99t cause congestion. I=E2=80=99m not a LISP = expert, so cannot do that analysis. >>>> It=E2=80=99s unclear what messages need to be retransmitted if = they=E2=80=99re lost, and how to >>>> determine if a message is lost (e.g., what is the timeout) and what = is the >>>> retransmission schedule. This may be clear to a reader with an = in-depth >>>> understanding of LISP, but it would be helpful to provide more = explicit >>>> statements about loss detection and retransmission. >>>=20 >>> Map-Registers are sent periodically but the text says that if = Map-Notify messages are desired for acknowledgement, the Map-Registers = can be transmitted more quickly in the case of loss. >>>=20 >>> Map-Notify messages are obviously acknowledgement by Map-Notify-Ack. = That was an added message to RFC6833bis. >>>=20 >>> Map-Requests and Map-Replies are reliability sent for cache = population. And the nonce is used for both security purproses and to = associated a Map-Reply to a previous sent Map-Request, which is = rate-limited. >>>=20 >>> That is pretty much it and I think is explained in pretty much = detail. So if you have any specific comments, please provide them. = Thanks. >>=20 >> I perhaps missed it, but didn=E2=80=99t see any discussion of = timeouts to detect loss, retransmission frequency, how often = retransmissions should be retried before giving up, and what might = happen if the retransmissions fail. It=E2=80=99s not sufficient to just = say a response is retransmitted, without saying how loss is detected and = how retransmissions work. >>=20 >>>> Many of these issues could perhaps be addressed by running the = control plane >>>> over TCP rather than UDP, as is beginning to happen with the DNS. I = understand >>>> that this would be a significant late change to the protocol. >>>=20 >>> We have a draft that is considering running the LISP control-plane = over TCP/QUIC with the addition of encryped security TLS/QUIC. But not = as a replacement to UDP but so an LISP control-plane implementation cam = be simplfied. >>=20 >> I=E2=80=99d encourage this work, with the goal of eventually = replacing the UDP-based transport. >=20 > Fabio and Marc have been working on it. A draft expired, so I don=E2=80=99= t know their status. I agree with you. >=20 >>=20 >>>> The control plane messages contain embedded IP addresses. Does this = cause any >>>> issues in the presence of NAT boxes, either by leaking information = about >>>> private addressing or by distributing addresses that are = unreachable outside >>>> their realm? I noticed there is a mention of an individual draft on = LISP NAT >>>> Traversal in Section 5.6, but the embedded addresses are included = in more >>>> places. >>>=20 >>> We want private addresses to be inside of LISP control-plane packet = payload because there are cases where two xTRs want to determine if they = are behind the same NAT, so they can encapsulate directly to each other = with those private addresses. For xTRs that are not behind this common = NAT, RLOC-probing will tell them they cannot reach the private address. >>=20 >> That=E2=80=99s fine, there should be some discussion of the privacy = implications of exposing those addresses. The WebRTC community has run = into considerable issues due to leaking IP addressing information =E2=80=93= perhaps this is not a concern for LISP, but the issue should be = considered, if only to add a note explaining why it=E2=80=99s not a = concern. >=20 > This only happens in the NAT-traversal cases. I think it should go in = the Security Consideration section of that draft. Not this draft. The = standardization effort at this point in time is not including = NAT-traversal mechanisms because that draft has not been accepted as a = working group draft yet. Putting the details into the NAT traversal draft likely makes sense, but = I do think a brief addition to highlight that there may be an issue, and = to point to the discussion elsewhere, would be worthwhile. >> Is there a need to protect the addresses? STUN uses XOR-mapping of = embedded IP addresses, because NATs were found that tried to translate = embedded IP addresses, outside of the IP header, and broke the protocol. = Does LISP need something similar? >=20 > No it doesn=E2=80=99t but as we evolved the NAT-traversal draft, we = will consider this. Thanks for the heads-up. >=20 > Thanks again, > Dino >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art --=20 Colin Perkins https://csperkins.org/ From nobody Wed Sep 19 08:04:59 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4111271FF for ; Wed, 19 Sep 2018 08:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 eXfO6WWh6Iz4 for ; Wed, 19 Sep 2018 08:04:54 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 95291130E27 for ; Wed, 19 Sep 2018 08:04:52 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id 20-v6so6156516wrb.12 for ; Wed, 19 Sep 2018 08:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:cc:to:message-id; bh=ym9y9biX6ZufCsRXdhWAgBCXVsZQ14ojlhXPbILbmfU=; b=rrcEhRLpAk2p4ZbMiXqgxQKFOVNOhR9d71reqrpiJ6Zx4rMS2rIwIUXNMWbDWChO2T 7mSOz7P2TNqr88awQX8d/LiItRiHEG8QTVc4IuHsrfohFBrfpbmxOoVzDfdq1SOasm3d lrKUbOLmGX0ATLMYmWDfTutiEh42J89z25N5CxhmbsKXIv72shkK+30UWwfW7VOYAvyh j44TM4azaYbf9jKxQDa0f9AfxdiUeb0M7CpSjKfzi8DI+QThGKvEpsFhJQeLAaaAlUIW ftRn/Jiiy++ZhBws6GRF9lmPdxe9C6zZvcdXeJwJGv5OQ+wckJ1qJjU/hZRuTzbz3pt/ iwNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=ym9y9biX6ZufCsRXdhWAgBCXVsZQ14ojlhXPbILbmfU=; b=uLchdK5qAw92Ib1G+QoeeMNf615B+qnynpzkodQj3Dw5blLZsV1vq0dLvQKAHnLxLt iewtAtKn9+E7X904WOkkPma0dmRNdD7qOdRqkdgpvL6Sa9ViAglpbx7bquaoK817bwQr kt6x4h1zHaosSipgC1OaY3QAlRLTi4A/egn7vm+KkXvlNQYi41ldEDYyPf2l3ykP2pyt 4N+waDX13DUhaU+MDLvNV9/aqLl+n2vhfEmganPsR7r2vfhwC8GwjVwvQaAaQtrh3KU5 FmCmr5pCoQL2ttjiqRoswHhudXDbgNfNjY343LCJmAOT4q5Ri5O4URsYtCKzU/ldItM2 b8XQ== X-Gm-Message-State: APzg51B3QfbP2FD4DSuB5QUn0fwhpXnDjzrwUDIaHuL0EZD9dsXXfrvC spBFhVzk2udX10Bck4qKjtzLR9SCKrI= X-Google-Smtp-Source: ANB0VdYEBKzrc+bLk8w6dTAFceblQO3klgEJBuotht3NKa68fhMwaAtvOg9R5zjBcB389s9TREtcEA== X-Received: by 2002:a5d:5248:: with SMTP id p8-v6mr29342780wrv.198.1537369490636; Wed, 19 Sep 2018 08:04:50 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:6df9:b297:ca07:d060? ([2001:660:330f:a4:6df9:b297:ca07:d060]) by smtp.gmail.com with ESMTPSA id h17-v6sm17613663wrq.73.2018.09.19.08.04.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Sep 2018 08:04:48 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_6733FE51-BCF9-4D80-8AAB-5A512985C118" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 19 Sep 2018 17:04:41 +0200 References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> Cc: lisp-chairs@ietf.org, "BRUNGARD, DEBORAH A" To: "lisp@ietf.org list" Message-Id: <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113bis-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 15:04:59 -0000 --Apple-Mail=_6733FE51-BCF9-4D80-8AAB-5A512985C118 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, here is another piece of the work done in our WG that needs to be moved = to PS. It is the updated version of RFC 8113, nothing changed just updated = coherently with the current status of the other documents. Because this documents is really really short we will have just one week = adoption call followed be one week WG Last Call. This email officially starts the one week call for adoption. Please spend 10 minutes having a look at the document and send an email = on whether you agree or not to adopt it. Thanks Ciao Luigi > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt > Date: 19 September 2018 at 16:49:31 CEST > To: > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Locator/ID Separation Protocol (LISP): Shared = Extension Message & IANA Registry for Packet Type Allocations > Authors : Mohamed Boucadair > Christian Jacquenet > Filename : draft-boucadair-lisp-rfc8113bis-01.txt > Pages : 5 > Date : 2018-09-19 >=20 > Abstract: > This document specifies a Locator/ID Separation Protocol (LISP) > shared message type for defining future extensions and conducting > experiments without consuming a LISP packet type codepoint for each > extension. >=20 > This document obsoletes RFC 8113. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01 > = https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc8113bis-01 >=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 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_6733FE51-BCF9-4D80-8AAB-5A512985C118 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Folks,

here= is another piece of the work done in our WG that needs to be moved to = PS.

It is the = updated version of RFC 8113, nothing changed just updated coherently = with the current status of the other documents.

Because this documents is really really = short we will have just one week adoption call followed be one week WG = Last Call.

This = email officially starts the one week call for adoption.

Please spend 10 minutes = having a look at the document and send an email on whether you agree or = not to adopt it.

Thanks

Ciao

Luigi


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = I-D Action: = draft-boucadair-lisp-rfc8113bis-01.txt
Date: = 19 September 2018 at 16:49:31 = CEST
To: = <i-d-announce@ietf.org>
Reply-To: = internet-drafts@ietf.org


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


=        Title =           : Locator/ID = Separation Protocol (LISP): Shared Extension Message & IANA Registry = for Packet Type Allocations
=        Authors =         : Mohamed Boucadair
=             &n= bsp;           &nbs= p;Christian Jacquenet
Filename =        : = draft-boucadair-lisp-rfc8113bis-01.txt
Pages =           : 5
= Date =            : = 2018-09-19

Abstract:
=   This document specifies a Locator/ID Separation Protocol = (LISP)
  shared message type for defining = future extensions and conducting
  experiments = without consuming a LISP packet type codepoint for each
=   extension.

  This = document obsoletes RFC 8113.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bi= s/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01<= br = class=3D"">https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8= 113bis-01

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc811= 3bis-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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

= --Apple-Mail=_6733FE51-BCF9-4D80-8AAB-5A512985C118-- From nobody Wed Sep 19 08:15:57 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D887130E03; Wed, 19 Sep 2018 08:15:55 -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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 qEisGk7GYZVX; Wed, 19 Sep 2018 08:15:53 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5993D130DD2; Wed, 19 Sep 2018 08:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3089; q=dns/txt; s=iport; t=1537370152; x=1538579752; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=jNiYpeWpVoxh+dHHrYAbcXUAxMM3vZtXy9hoOGJElYQ=; b=ahc3xF2UZfr1+eZhhFkyUoQy1bsVAJMyhxMVGgPBXRrLgiKLOtr+0t5u WbHphXEzF0mhRqUBKmifffpPEf6H4zy7CK1AnEORo7fdQveSH+1Ppuq2t fUuZti0Atv6MT4HyE0lnapNUDCBpH9XmI349V9A9SGncHBXOE9vfiKYIk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AAAmZ6Jb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYFTgmptEiiDc4h0jV+WYIFmCxgNhEcCg1w3FQEDAQECAQE?= =?us-ascii?q?CbRwMhTgBAQEBAwEBGwYPAQU2CxAJAg4DAwECAQICIwMCAicfCQgGAQwGAgE?= =?us-ascii?q?BBYMYAYIBD4lqm0yBLoQsAwEFQoUYgQuJeYFBP4ESJ4JrgxALAQEBAQEBFoE?= =?us-ascii?q?UARIBgyCCVwKcWQmGQolaBheBQ0qEBYJeJoYEi2+Bb4ZqAhEUgVgiJz1xMxo?= =?us-ascii?q?IGxUaIYJsCYsMhUA9MAGLIYI9AQE?= X-IronPort-AV: E=Sophos;i="5.53,394,1531785600"; d="scan'208";a="6605309" 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/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2018 15:15:49 +0000 Received: from [10.61.226.66] ([10.61.226.66]) (authenticated bits=0) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPSA id w8JFFmCO031833 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2018 15:15:49 GMT To: Luigi Iannone , "lisp@ietf.org list" Cc: lisp-chairs@ietf.org References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> From: Lori Jakab Organization: cisco Systems, Inc. Message-ID: <0e0828bb-4b20-46f6-aa50-e9c2cddb513b@cisco.com> Date: Wed, 19 Sep 2018 17:15:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Authenticated-User: lojakab X-Outbound-SMTP-Client: 10.61.226.66, [10.61.226.66] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113bis-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 15:15:56 -0000 Hi, I read the draft, and support its adoption as a WG document. -Lori On 19/09/2018 17:04, Luigi Iannone wrote: > Folks, > > here is another piece of the work done in our WG that needs to be > moved to PS. > > It is the updated version of RFC 8113, nothing changed just updated > coherently with the current status of the other documents. > > Because this documents is really really short we will have just one > week adoption call followed be one week WG Last Call. > > This email officially starts the one week call for adoption. > > Please spend 10 minutes having a look at the document and send an > email on whether you agree or not to adopt it. > > Thanks > > Ciao > > Luigi > > >> Begin forwarded message: >> >> *From: *internet-drafts@ietf.org >> *Subject: **I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt* >> *Date: *19 September 2018 at 16:49:31 CEST >> *To: *> >> *Reply-To: *internet-drafts@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >>        Title           : Locator/ID Separation Protocol (LISP): >> Shared Extension Message & IANA Registry for Packet Type Allocations >>        Authors         : Mohamed Boucadair >>                          Christian Jacquenet >> Filename        : draft-boucadair-lisp-rfc8113bis-01.txt >> Pages           : 5 >> Date            : 2018-09-19 >> >> Abstract: >>   This document specifies a Locator/ID Separation Protocol (LISP) >>   shared message type for defining future extensions and conducting >>   experiments without consuming a LISP packet type codepoint for each >>   extension. >> >>   This document obsoletes RFC 8113. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01 >> https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-boucadair-lisp-rfc8113bis-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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Sep 19 08:16:21 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADF8130F2F; Wed, 19 Sep 2018 08:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ZmsEkqMr6uCC; Wed, 19 Sep 2018 08:16:17 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C74D130E45; Wed, 19 Sep 2018 08:16:17 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 42Fk330nL9z1yHs; Wed, 19 Sep 2018 17:16:15 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 42Fk33008fz1xp9; Wed, 19 Sep 2018 17:16:15 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0415.000; Wed, 19 Sep 2018 17:16:14 +0200 From: To: Luigi Iannone , "lisp@ietf.org list" CC: "lisp-chairs@ietf.org" Thread-Topic: [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113bis-01.txt Thread-Index: AQHUUConEYhMU4MDQE2d4zB1KK6yLqT3ttSA Date: Wed, 19 Sep 2018 15:16:13 +0000 Message-ID: <11632_1537370175_5BA2683F_11632_417_1_88132E969123D14D9BD844E1CD516EDE38A0EFD0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> In-Reply-To: <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_88132E969123D14D9BD844E1CD516EDE38A0EFD0OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113bis-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 15:16:19 -0000 --_000_88132E969123D14D9BD844E1CD516EDE38A0EFD0OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello WG, Support (as one of the authors). Cheers, Christian. De : lisp [mailto:lisp-bounces@ietf.org] De la part de Luigi Iannone Envoy=E9 : mercredi 19 septembre 2018 17:05 =C0 : lisp@ietf.org list Cc : lisp-chairs@ietf.org Objet : [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113bis-01.txt Folks, here is another piece of the work done in our WG that needs to be moved to = PS. It is the updated version of RFC 8113, nothing changed just updated coheren= tly with the current status of the other documents. Because this documents is really really short we will have just one week ad= option call followed be one week WG Last Call. This email officially starts the one week call for adoption. Please spend 10 minutes having a look at the document and send an email on = whether you agree or not to adopt it. Thanks Ciao Luigi Begin forwarded message: From: internet-drafts@ietf.org Subject: I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt Date: 19 September 2018 at 16:49:31 CEST To: > Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Locator/ID Separation Protocol (LISP): Shared Exte= nsion Message & IANA Registry for Packet Type Allocations Authors : Mohamed Boucadair Christian Jacquenet Filename : draft-boucadair-lisp-rfc8113bis-01.txt Pages : 5 Date : 2018-09-19 Abstract: This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. This document obsoletes RFC 8113. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01 https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc8113bis-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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_88132E969123D14D9BD844E1CD516EDE38A0EFD0OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello WG,

 

Support (as one of the authors).<= /span>

 

Cheers,

 

Christian.

 

De : lisp [mailto:lisp-bounces@ietf.org] De la part de Luigi Iannone
Envoy=E9 : mercredi 19 septembre 2018 17:05
=C0 : lisp@ietf.org list
Cc : lisp-chairs@ietf.org
Objet : [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113= bis-01.txt

 

Folks,

 

here is another piece of the work done in our WG tha= t needs to be moved to PS.

 

It is the updated version of RFC 8113, nothing chang= ed just updated coherently with the current status of the other documents.<= o:p>

 

Because this documents is really really short we wil= l have just one week adoption call followed be one week WG Last Call.<= /o:p>

 

This email officially starts the one week call for a= doption.

 

Please spend 10 minutes having a look at the documen= t and send an email on whether you agree or not to adopt it.

 

Thanks

 

Ciao

 

Luigi

 

 

Begin forwarded message:

 

Subject: I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt

Date: 19 September 2018 at 16:49:31 CEST

Reply-To: internet-drafts@ietf.org<= /p>

 


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


       Title     &nb= sp;     : Locator/ID Separation Protocol (LISP): S= hared Extension Message & IANA Registry for Packet Type Allocations
       Authors     &= nbsp;   : Mohamed Boucadair
            &nb= sp;            = Christian Jacquenet
       &n= bsp;    Filename       =  : draft-boucadair-lisp-rfc8113bis-01.txt
       &n= bsp;    Pages       &nb= sp;   : 5
       &n= bsp;    Date       &nbs= p;    : 2018-09-19

Abstract:
  This document specifies a Locator/ID Separation Protocol (LISP)=
  shared message type for defining future extensions and conducti= ng
  experiments without consuming a LISP packet type codepoint for = each
  extension.

  This document obsoletes RFC 8113.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01
https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc8113bis-01


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_88132E969123D14D9BD844E1CD516EDE38A0EFD0OPEXCLILMA3corp_-- From nobody Wed Sep 19 08:46:05 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84288130DC9; Wed, 19 Sep 2018 08:46:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QA8bNgzJtvpB; Wed, 19 Sep 2018 08:46:00 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 635BC128CF3; Wed, 19 Sep 2018 08:46:00 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id k19-v6so2909304pfi.1; Wed, 19 Sep 2018 08:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=av2IuY9WqeRuX9whAS2hYG6b/XF08yypxzdyhWsSfEg=; b=NBZuiUthuJsCnRm5bVsVK6R/jVO8k/LJHi12UkDHp4MudjNLTCi+99tOc6Rn5bANtS 9ADaGvS7tGd14d2LlxX83k5iQfvV3PYpxVBhAhsQeNHJ6RT2r7G8pY2NhIaCtN7NCeSC DglqFjkTs05MiUvIYJcPBdg3BRoe54mNyVlBNpGcILy1QrzCia4rWNVKOwp4C0X+F2hy aLc1kca5ZYKJq7Xj/JGYeH1mK/uk8w0jI95KjCNYSlw2OA/PO73ll1A27akkLxw7s8mm GKmgwCPyDv7FQNx+qaCcQNHgrLJDVOnnrqGScVfYLxl9v8lI3H2PxEdkaPfPpgYsVsIE A2/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=av2IuY9WqeRuX9whAS2hYG6b/XF08yypxzdyhWsSfEg=; b=V/31Td9/Sj/VbuM7zgL6nS6wd++1lRdYqdFfx0QpIby+wKjnJJiQJBl2qsOSFh1S+m BCHn1Xf7spRT9uky8AK831DYn+z4PK9glatghWAGL51w8DvZD3pZv67uc4bMk0CGtwgb urgyv/j0Fgqx6dSxRrTHoThDlaoaclDIEcS0K83HPaeREghpagidcTJxRVlS/i5PRX/C 7qIKP2UtE/Wrtg8gMvS5CmfedHqsdyzCuN5hkNpi7WtPXnYQLn7om3d78kkVtPxwyM7V 13bZykWJtKXmVE8K8E0zT2cwv29QyEnh7EMGNQZ1hZ2fW/GCZdGVoWvekGB9BEt1Rm1g RxFg== X-Gm-Message-State: APzg51CmgkfHk9EcDCEgXsWNoYavWuNUn22H5ZYnBnrJTj4BdBKq8kbm fZHYwYflYOg4ucOEr6j7tRs= X-Google-Smtp-Source: ANB0VdaJgPbi3hmvIenhuTWlfBJFjGTJz3/h/Jzr9KN4jLb3ZfazPNRLP85zPEiHXr9LL5rgeRmAAA== X-Received: by 2002:a63:ee15:: with SMTP id e21-v6mr33041621pgi.421.1537371959802; Wed, 19 Sep 2018 08:45:59 -0700 (PDT) Received: from [10.10.32.182] ([65.154.156.50]) by smtp.gmail.com with ESMTPSA id k69-v6sm25016675pgd.9.2018.09.19.08.45.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Sep 2018 08:45:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <0e0828bb-4b20-46f6-aa50-e9c2cddb513b@cisco.com> Date: Wed, 19 Sep 2018 08:45:58 -0700 Cc: Luigi Iannone , "lisp@ietf.org list" , lisp-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <22EE95B3-9D29-4639-9A74-6F5FB0192F09@gmail.com> References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> <0e0828bb-4b20-46f6-aa50-e9c2cddb513b@cisco.com> To: Lori Jakab X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113bis-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 15:46:04 -0000 +1 Dino > On Sep 19, 2018, at 8:15 AM, Lori Jakab = wrote: >=20 > Hi, >=20 > I read the draft, and support its adoption as a WG document. >=20 > -Lori >=20 > On 19/09/2018 17:04, Luigi Iannone wrote: >> Folks, >>=20 >> here is another piece of the work done in our WG that needs to be = moved to PS. >>=20 >> It is the updated version of RFC 8113, nothing changed just updated = coherently with the current status of the other documents. >>=20 >> Because this documents is really really short we will have just one = week adoption call followed be one week WG Last Call. >>=20 >> This email officially starts the one week call for adoption. >>=20 >> Please spend 10 minutes having a look at the document and send an = email on whether you agree or not to adopt it. >>=20 >> Thanks >>=20 >> Ciao >>=20 >> Luigi >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> *From: *internet-drafts@ietf.org >>> *Subject: **I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt* >>> *Date: *19 September 2018 at 16:49:31 CEST >>> *To: *> >>> *Reply-To: *internet-drafts@ietf.org = >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>=20 >>>=20 >>> Title : Locator/ID Separation Protocol (LISP): = Shared Extension Message & IANA Registry for Packet Type Allocations >>> Authors : Mohamed Boucadair >>> Christian Jacquenet >>> Filename : draft-boucadair-lisp-rfc8113bis-01.txt >>> Pages : 5 >>> Date : 2018-09-19 >>>=20 >>> Abstract: >>> This document specifies a Locator/ID Separation Protocol (LISP) >>> shared message type for defining future extensions and conducting >>> experiments without consuming a LISP packet type codepoint for = each >>> extension. >>>=20 >>> This document obsoletes RFC 8113. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01 >>> = https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc8113bis-01= >>>=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 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >>=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 Wed Sep 19 08:50:54 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB7C130DF0; Wed, 19 Sep 2018 08:50:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 aHw_XGG5AprA; Wed, 19 Sep 2018 08:50:44 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 D3B3C129385; Wed, 19 Sep 2018 08:50:44 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id x186-v6so1574190pgd.12; Wed, 19 Sep 2018 08:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sGboLqaJ6wLfrBBUVPIJSJwEOZyDAXfqreNKtf2gfUw=; b=fMwCBIy7o4Ig1wQp0RKjr0gpbdRl6PrWsZntgSkPdWQwTPhmoyMIfnEHc3OHdawYhT q52kIUiyvo/2fHr0EAIvXuzmOKAbK/hjORzRDKA/AvMoujfpQHhJg8Svkyhcf18Rahle Kryq/OxrzD57M3E0+9F8cWOj94qAW17LucMy4jIQsZkpfcxqKc3sZiCDVh9pvmrQKUse TPQSbMuAf0bNzNU6Ix47a8QCRgezliTXbhbPsbIONtya9oBvzF/uMt1/1ksE8GeD+k8j 4fZ0hMXygEte1CAH4FIYDKaScrB/hxSbadvC2KHmNJrV7bx1/sTqlyWD0A7YdeEjMvEV TvEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sGboLqaJ6wLfrBBUVPIJSJwEOZyDAXfqreNKtf2gfUw=; b=doT6fZZCKPf96tuzaZso/9pG+NojJMxubzizZfsUEDvkvsZIaUDBqTHuaoK80GZ4po biUg7ybZIut85tYSNiQrgSCcSlCHs+nC2aE9vYP8QhgUHjSuLNvN0yAYtDrH/B3izPqh ahtVZBuCJre6HEeT+q0s5davismkXEGgm5tPeolIJXfe5fEQggsuQXJ9VsBylIOWgebY Lo5A5ovEf0fP6BzSIG1LDFVJ3mUyx87ZD/5cdNlh6w+/bbtXGTHqr/vnr3vzmyojC+4M iyCv3orfKF8rFQ6YKV01wDy4lz8sal/A2DHtPbTwEXHTY+rthYgw23uWKZnJuZCem2CR EpfA== X-Gm-Message-State: APzg51AiCg8AJjV7rfq0vR2Po7LZBKmIcHyXcDK2X9zY1gjQayyLNubW zKboeEuzR+L6enbbB/9CU+r2OPot X-Google-Smtp-Source: ANB0VdacNYJWCOK5grvJEFcI3wVdJj9Svzv7rNfW5lHDeF+Ido0y0ZEqdyoKRU9VPgt0ORj7Rh4kJg== X-Received: by 2002:a62:3703:: with SMTP id e3-v6mr36580092pfa.117.1537372244158; Wed, 19 Sep 2018 08:50:44 -0700 (PDT) Received: from [10.10.32.182] ([65.154.156.50]) by smtp.gmail.com with ESMTPSA id z19-v6sm28656731pgi.33.2018.09.19.08.50.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Sep 2018 08:50:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <95DE3AE3-225C-487C-A690-DEF2C3870561@csperkins.org> Date: Wed, 19 Sep 2018 08:50:42 -0700 Cc: tsv-art@ietf.org, draft-ietf-lisp-rfc6833bis.all@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: References: <153597929696.13392.8265627120055145654@ietfa.amsl.com> <95DE3AE3-225C-487C-A690-DEF2C3870561@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6833bis-13 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 15:50:47 -0000 >>> I=E2=80=99m not convinced relying on IP fragmentation is a good = idea. In the best case, loss of a fragment results in loss of the entire = packet, multiplying the effective loss rate. There can also be = middleboxes that drop fragments. It would be better if the control place = could fragment to MTU size packets (either the actual MTU, or a typical = MTU =E2=80=93 1280 octets perhaps). >>=20 >> Well an implementation can certainly build messages of effective MTU = length which in most cases is 1280/1500 as well. >=20 > I=E2=80=99d suggest that the document provide guidance on doing this, = since relying on IP fragmentation is going to be problematic. Did you see the text we added to the posted = draft-ietf-lisp-rfc6833bis-15? >=20 >>> Sure, but as I mentioned, the draft needs some justification for why = this is safe from a congestion control viewpoint. >>=20 >> Can you suggest some simple text that would be sufficient. We have = done the analysis in other drafts. Would simply pointing a reference to = them be sufficient you think? >=20 > If the analysis exists elsewhere, then referencing it is likely = sufficient. If not, this needs analysis by someone who understands LISP = to explain why it won=E2=80=99t cause congestion. I=E2=80=99m not a LISP = expert, so cannot do that analysis. Okay. >>> That=E2=80=99s fine, there should be some discussion of the privacy = implications of exposing those addresses. The WebRTC community has run = into considerable issues due to leaking IP addressing information =E2=80=93= perhaps this is not a concern for LISP, but the issue should be = considered, if only to add a note explaining why it=E2=80=99s not a = concern. >>=20 >> This only happens in the NAT-traversal cases. I think it should go in = the Security Consideration section of that draft. Not this draft. The = standardization effort at this point in time is not including = NAT-traversal mechanisms because that draft has not been accepted as a = working group draft yet. >=20 > Putting the details into the NAT traversal draft likely makes sense, = but I do think a brief addition to highlight that there may be an issue, = and to point to the discussion elsewhere, would be worthwhile. There is no issue. The private address RLOCs are probed by ITRs and = found unreachable. So they are not used to encapsulate packets to. Dino From nobody Wed Sep 19 08:52:48 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4DB130DF7; Wed, 19 Sep 2018 08:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IncRybM1upVu; Wed, 19 Sep 2018 08:52:43 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 6B94D129385; Wed, 19 Sep 2018 08:52:42 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id x20-v6so5593432lfg.2; Wed, 19 Sep 2018 08:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EzlHfqL4VVNP31wUv/YQ/6kM6miybNineOwzEo+BdNQ=; b=EtpAVT78+iwi84hq41hjYU4BUUBsesLUDOmslcnAY+RgxkZsMh2SsN1Sb0ZVs3A+5D 3qWSd87cbx7RO/HZw7TIJ5DJmZtgNsCq2eeESr8N49l3qx3NXGaWLo7WiWlr3i7EZysE SxNGyJ83uuucn3J46U8evEkHeqRCtod+bXHcBPTpsW41EBangIEsNKzOzejoG1Av6JQR 91EBQYjr4Af7CUdQ17sbTEhUYos/k4voP0CFwF0rM+G6rE4lTNjTKaV421fPNRZoJVvt MAgpspBYm3IoHwymrL3cSnm/gKSU6b8+PyHZ+Ejn3AT+0BT8sxyhNdGzXNWdF5/OOSgF iy5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EzlHfqL4VVNP31wUv/YQ/6kM6miybNineOwzEo+BdNQ=; b=tNL08tOt3nCEkreV+ADvRdXKEDdANZ1MpA+Fdz7i0EeJg+RHGmp2yRPC/o5OoO78GO n6wEs20MBrtdjYhNbEcNFS5atEBJkK4iWnQmmjT+yhGoICPEN74D/cXUJj+U8U5PYGI6 wrpmyUG8NDEXC8xS8WR0/sLigEBMk7sIaqRuOY+2qeooYNYWP5KJ3lca763UNJW/hzNG ZahpsDvkbZfaMA+eHxmSwIpKjjV8ouRwavf1/X+v+RVW8xBU6DIfUaPtH62sXpMNIB4j KFCaXSaf+OqefZbvjR219EjWGi0B/OGogBXeYPW581hQ28/gvEK7gxzwIbMBu9KsRz9U 9D3g== X-Gm-Message-State: APzg51A5g0Os3wk7pI5hi2pLzMdJj0JgkWr8iKDKiqxJDoO6YvKwBO44 n4D2jnV3VyC4wwcYLvDH+7xjNTgl9fAZK8vxMIND4Q== X-Google-Smtp-Source: ANB0VdaV52cioQFIO1lMpP8PhRDQKODzPxL+csmzxvDrHS8jGwJeLUDjvwDDCkfmAtLn5sWrm5rQYYt1pUQ8F48yFBc= X-Received: by 2002:a19:cc97:: with SMTP id c145-v6mr14421940lfg.145.1537372360450; Wed, 19 Sep 2018 08:52:40 -0700 (PDT) MIME-Version: 1.0 References: <153608761426.14137.783984991533026116@ietfa.amsl.com> In-Reply-To: From: Alberto Rodriguez-Natal Date: Wed, 19 Sep 2018 08:52:28 -0700 Message-ID: To: Luigi Iannone Cc: "lisp@ietf.org list" , lisp-chairs@ietf.org, erik@zededa.com Content-Type: multipart/alternative; boundary="0000000000006eaa9405763b6579" Archived-At: Subject: Re: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 15:52:45 -0000 --0000000000006eaa9405763b6579 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Support. Alberto On Wed, Sep 5, 2018 at 12:46 AM Luigi Iannone wrote: > Folks, > > As you can see from Dino=E2=80=99s email (below) the authors are requesti= ng that > the document > > https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ > > be adopted as WG item. > > This email starts the usual 14 days call for adoption, this call will end > on > Thursday the 19th September, 2018. > > Please email the WG list stating whether or not you support acceptance. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, > or review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriatel= y. > > The Chairs > Joel & Luigi > > > On 4 Sep 2018, at 21:05, Dino Farinacci wrote: > > Folks, here is an update that reflects comments we received at the > Montreal presentation: > > > > A diff file is included for your convenience. > > At this time, I would like to request this document for working group > adoption. > > Thanks, > Dino/Erik > > > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt* > *Date: *September 4, 2018 at 12:00:14 PM PDT > *To: * > *Reply-To: *internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : LISP Control-Plane ECDSA Authentication and > Authorization > Authors : Dino Farinacci > Erik Nordmark > Filename : draft-farinacci-lisp-ecdsa-auth-03.txt > Pages : 17 > Date : 2018-09-04 > > Abstract: > This draft describes how LISP control-plane messages can be > individually authenticated and authorized without a a priori shared- > key configuration. Public-key cryptography is used with no new PKI > infrastructure required. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03 > https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecdsa-auth-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-ecdsa-auth-03 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --0000000000006eaa9405763b6579 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Support.

Alberto

On Wed, Sep 5, 2018 at = 12:46 AM Luigi Iannone <ggx@gigix.net> wrote:
Folks,

As yo= u can see from Dino=E2=80=99s email (below) the authors are requesting that= the document


=
be adopted as WG item.

This email starts the = usual 14 days call for adoption, this call will end on
Thursday t= he 19th September, 2018.

Please email the WG list stating whether or= not you support acceptance.

If you email to support the acceptance = of this document as a WG item, please
also indicate if you are able and = willing to either contribute to, or=C2=A0review, (or both) the draft.
Sitting in silence does not indicate support, please respond appropriatel= y.

The Chairs
Joel & Luigi


On 4 Sep 2018, at 21:05, Dino Farinac= ci <farinacci@g= mail.com> wrote:

Folks, here is an update that reflects comments we received= at the Montreal presentation:

<Paste= dGraphic-1.png>

A diff file is included for your co= nvenience.=C2=A0

At this time, I would like to req= uest this document for working group adoption.

Tha= nks,
Dino/Erik

<rfcdiff-ecdsa.html>


Begin forwarded message:

Subject: I-D Action: draft-farinacci-lisp-ecds= a-auth-03.txt
Date: <= /span>September 4, 2018 at 12:00:14 PM PDT
<= span style=3D"font-family:-webkit-system-font,"Helvetica Neue",He= lvetica,sans-serif">To: <i-d-announce@ietf.org>
=


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


=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0: LISP Control-Plane ECDSA Authentication and Authorizati= on
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Dino Farinacci
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Erik Nordmark
Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: draft-farina= cci-lisp-ecdsa-auth-03.txt
Pages =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 17
Date =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2018-09-04
Abstract:
=C2=A0=C2=A0This draft describes how LISP control-plane = messages can be
=C2=A0=C2=A0individually authenticated and authorized w= ithout a a priori shared-
=C2=A0=C2=A0key configuration.=C2=A0 Public-k= ey cryptography is used with no new PKI
=C2=A0=C2=A0infrastructure requ= ired.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecd= sa-auth/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03=
https://datatracker.ietf.org/doc/html/d= raft-farinacci-lisp-ecdsa-auth-03

A diff from the previous versi= on is available at:
https://www.ietf.org/rfcdi= ff?url2=3Ddraft-farinacci-lisp-ecdsa-auth-03


Please note tha= t 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 ava= ilable by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

______= _________________________________________
I-D-Announce mailing list
<= a href=3D"mailto:I-D-Announce@ietf.org" target=3D"_blank">I-D-Announce@ietf= .org
https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/i= etf/1shadow-sites.txt

_______________________________________________
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
--0000000000006eaa9405763b6579-- From nobody Wed Sep 19 08:53:16 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9033D1292AD; Wed, 19 Sep 2018 08:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7fc3MW1MKME9; Wed, 19 Sep 2018 08:53:13 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 D6FFD130E3D; Wed, 19 Sep 2018 08:53:09 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id m26-v6so5609245lfb.0; Wed, 19 Sep 2018 08:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CH7jVLxm9HZQFGTXdyimO3WpdBRxS/ghvMMtOj1Rpf4=; b=Vbacl+YmgpCKe43jv3jPL3fHr9FIUhA3PTmkBkM8ZFu/3vqUmuNd3+WSY02QUv5IHV Pkd6FNsw3SvmIUO7u8IcFC64BIRACEhkQC2QCXcs3XY4dXJ64KIv4ONnMHBAAtraTdHM dP8uAuoLA1ckHYki/IGGHmRs1pmcJCK2XxtS04xD5FtXOX7dCVzg77wA3DAn0rbW1M4O bRlE3WpXtW2MJG73Nb3KAZD0Hye7p7jZ3PTyu7JaEf6JukFvRED3Et7PRN3wuFylorj+ wG0gsqMK6irBkdPIj1OsoskYa4Dv7jXoA/vBM0sI6Fg7SuRqUpPzaMwLU8JHuYbzuQ+w Pjcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CH7jVLxm9HZQFGTXdyimO3WpdBRxS/ghvMMtOj1Rpf4=; b=C+qLmBacwYFFTZJtHKDGbz0In8J6uZvjKWJI2tr0eaqj6918NP7IuNWGik9Pvp5sjt 1pupy886h9rynjiP087u8gSU6uL02vS++djfrLP+qR68rBx6fjA2eyo9yftJq8fIn4qb LTQ1ULMAti5u7kuw/OgM7lhNgOQ6rbomzUq8+kNc5LZv3kIBp4yRObA6xKLzYd+6YqrB MDxGIHtklDMDDbVPbjRBNa3jdKERHzTFOLWMpkj1Hx5ZzF74h3YomlKjxIgA5JmtUMPZ V4pTL8IYwEoszZy66tGbY9kNASNxImniKhzbGTQ0ViqgK+aeqgv3aSXHGgX0knSAtUJo XbKA== X-Gm-Message-State: APzg51ANsngakGoJsADhHwxOwpoxlbM+e6aDUhN91eLcByDz6zjz6Zwy vvEF5RcNXlAA/UdeKnCfT8x6sI+I0mbZO+N9qAo= X-Google-Smtp-Source: ANB0VdaXQZ6mj5Uorg+NDJY/C+de9fh1xw2t8ODZ+AvtnbUJaGi9GMFr4xaakdd/UDIdSz1DfnjAm0p+sUpxkuJchYo= X-Received: by 2002:a19:1709:: with SMTP id n9-v6mr14861427lfi.74.1537372387901; Wed, 19 Sep 2018 08:53:07 -0700 (PDT) MIME-Version: 1.0 References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> In-Reply-To: <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> From: Alberto Rodriguez-Natal Date: Wed, 19 Sep 2018 08:52:56 -0700 Message-ID: To: Luigi Iannone Cc: "lisp@ietf.org list" , lisp-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000011878005763b67ed" Archived-At: Subject: Re: [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113bis-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 15:53:16 -0000 --00000000000011878005763b67ed Content-Type: text/plain; charset="UTF-8" Support. Alberto On Wed, Sep 19, 2018 at 8:05 AM Luigi Iannone wrote: > Folks, > > here is another piece of the work done in our WG that needs to be moved to > PS. > > It is the updated version of RFC 8113, nothing changed just updated > coherently with the current status of the other documents. > > Because this documents is really really short we will have just one week > adoption call followed be one week WG Last Call. > > This email officially starts the one week call for adoption. > > Please spend 10 minutes having a look at the document and send an email on > whether you agree or not to adopt it. > > Thanks > > Ciao > > Luigi > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt* > *Date: *19 September 2018 at 16:49:31 CEST > *To: * > *Reply-To: *internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Locator/ID Separation Protocol (LISP): Shared > Extension Message & IANA Registry for Packet Type Allocations > Authors : Mohamed Boucadair > Christian Jacquenet > Filename : draft-boucadair-lisp-rfc8113bis-01.txt > Pages : 5 > Date : 2018-09-19 > > Abstract: > This document specifies a Locator/ID Separation Protocol (LISP) > shared message type for defining future extensions and conducting > experiments without consuming a LISP packet type codepoint for each > extension. > > This document obsoletes RFC 8113. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01 > https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-boucadair-lisp-rfc8113bis-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --00000000000011878005763b67ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Support.

Alberto

On Wed, Sep 19, 2018 at= 8:05 AM Luigi Iannone <ggx@gigix.net> wrote:
Folks,

here = is another piece of the work done in our WG that needs to be moved to PS.

It is the updated version of RFC 8113, nothing chan= ged just updated coherently with the current status of the other documents.=

Because this documents is really really short we = will have just one week adoption call followed be one week WG Last Call.

This email officially starts the one week call for a= doption.

Please spend 10 minutes having a look at = the document and send an email on whether you agree or not to adopt it.

Thanks

Ciao

Luigi


=
Begin forwarded message:

Date: 19 September 2018 at 16:49:31 CEST


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


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Locator/ID Separation Pro= tocol (LISP): Shared Extension Message & IANA Registry for Packet Type = Allocations
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Mohamed Boucadair
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Christian Ja= cquenet
Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0: draft-boucadair-lisp-rfc8113bis-01.txt
Pages =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 5
Date =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2= 018-09-19

Abstract:
=C2=A0=C2=A0This document specifies a Locato= r/ID Separation Protocol (LISP)
=C2=A0=C2=A0shared message type for def= ining future extensions and conducting
=C2=A0=C2=A0experiments without = consuming a LISP packet type codepoint for each
=C2=A0=C2=A0extension.<= br>
=C2=A0=C2=A0This document obsoletes RFC 8113.


The IETF d= atatracker status page for this draft is:
https://d= atatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/

There a= re also htmlized versions available at:
https://tools.= ietf.org/html/draft-boucadair-lisp-rfc8113bis-01
https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113= bis-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-l= isp-rfc8113bis-01


Please note that it may take a couple of m= inutes from the time of submission
until the htmlized version and diff a= re available at tools.i= etf.org.

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

_________________________________= ______________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://w= ww.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories= : http://www.= ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

__________________________= _____________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
--00000000000011878005763b67ed-- From nobody Wed Sep 19 12:42:10 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B993F1252B7; Wed, 19 Sep 2018 12:42:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-lisp-gpe@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153738612868.21424.5753365080841918983.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2018 12:42:08 -0700 Archived-At: Subject: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-gpe-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 19 Sep 2018 19:42:09 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-lisp-gpe-05: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for addressing the TSV-ART review (and Magnus for doing the review)! I assume that the proposed text will be incorporated in the next version. (Would have been even better if those (larger) changes would have been added before the doc was put on the telechat; please update as soon as possible so other AD can review that text as well). However, I think the text still needs to say more about HOW the PCP should be mapped to DSCPs. RFC8325 doesn't provide guidelines but a mapping for 802.11. Is the same mapping applicable here? Also, I'm not an expert for that part, but I guess there also is further guidance needed on HOW to map the VID...? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given this doc uses the last reserved bit in the lisp header, I would really like to see more discussion how the data plane lisp can still be extended. I think the solution is straight-forward (define a shim layer for the extension and announce this capability in the Map-Reply), however, spelling this out seems to be appropriate for this doc. From nobody Wed Sep 19 14:08:03 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DB9130E8B; Wed, 19 Sep 2018 14:07:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Pete Resnick To: Cc: draft-ietf-lisp-rfc6833bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153739126898.21452.4751492511227758945@ietfa.amsl.com> Date: Wed, 19 Sep 2018 14:07:49 -0700 Archived-At: Subject: [lisp] Genart telechat review of draft-ietf-lisp-rfc6833bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 19 Sep 2018 21:07:49 -0000 Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lisp-rfc6833bis-15 Reviewer: Pete Resnick Review Date: 2018-09-19 IETF LC End Date: 2018-08-31 IESG Telechat date: 2018-09-27 Summary: Ready Major issues: None. Minor issues: None. Nits/editorial comments: None. Thanks for all of the cleanup based on my previous review. From nobody Wed Sep 19 14:17:10 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C560130EC6; Wed, 19 Sep 2018 14:17:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 x9JPAdq4DjHI; Wed, 19 Sep 2018 14:17:00 -0700 (PDT) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 BCA9C130E8B; Wed, 19 Sep 2018 14:17:00 -0700 (PDT) Received: by mail-pg1-x543.google.com with SMTP id w9-v6so130840pgc.12; Wed, 19 Sep 2018 14:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zswUyUoAEdN/uUGqW6YiRgxxP1w6+YqJxlhm26mAZAY=; b=jbw2BFeJux00oR7yJUDGCE64gdFiLXT4GzfWJwmUrxnkvWOIdH4G+Hjd+9Qo8IavqB GqPILpkmD1FQWUUD1V//3cmaID5wgDr7w8I+6XppwvIah3eJN3GdCwJTACQrXjSU6CAU vvn8FSxrVQl0IyigJdWQ8yk6hcSbQFOsMKtzmrOdDNUuig9lHu5JjiFT91/DcWkedvWb 0izPQgoSA1FTwoYTX5gHE2F3aDBZRYpYeEX0nNa08BRZh3t4vN9uUEFnKxw/uWtHdpK5 AsPpQhGWtmGRp3x+eXUcaue9cFoOKcR0Ywncpf2jmKXN4bXXB7qNpphnbbEwZr2xvso3 8L0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zswUyUoAEdN/uUGqW6YiRgxxP1w6+YqJxlhm26mAZAY=; b=IUy/o3VN7Ozd/Eq9o1ejY61qChDyhoFHoQ71cOix/ZbHl18ywOU5sfFJNrYMjAzPCg 5z3U++eLa0oVjGE8vvY0OpvfyFEw13W8B8SBb1HnP7AglkvYPsvIdkp3Nq0cxmG+P3A3 Izf5gAgLeO/L4hBC17k9hFw1xn+4bLGKsnwu7+1l2HICwUkeqXbNSm8sBqP5miLV2O3V 4mnXJAleObUiPZQ6Rk4Ydlsz8ZtkMeFOJjP1CFtA1nVLowaSnsjlUwHJthDnYcSo2sY5 D8Uq8Z2An3pos+lLnpi+Eg0mv46Mn5jEKOYdP+spfNvfj2XgHSntRo32BrUDWusVoNmE HVWw== X-Gm-Message-State: APzg51CNqCOwC7Ej0Q4ui0iNwA3n8cWnLRhRGLBrC2dmZa+gnSM/lLVW jIQBchgVGSUdExujcz4zZGBU7Xn3 X-Google-Smtp-Source: ANB0VdYJtcr2VC3ZuwPQ0GOKlCgxRp9YRiMb1VQkDVcfkbjVOEGEgGgNshcD8QRvCluYWeUVZ1dFoQ== X-Received: by 2002:a62:4e56:: with SMTP id c83-v6mr38255374pfb.240.1537391820256; Wed, 19 Sep 2018 14:17:00 -0700 (PDT) Received: from [10.10.22.180] ([65.154.156.52]) by smtp.gmail.com with ESMTPSA id e14-v6sm27638308pff.128.2018.09.19.14.16.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Sep 2018 14:16:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (16A366) In-Reply-To: <153739126898.21452.4751492511227758945@ietfa.amsl.com> Date: Wed, 19 Sep 2018 14:16:58 -0700 Cc: gen-art@ietf.org, draft-ietf-lisp-rfc6833bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153739126898.21452.4751492511227758945@ietfa.amsl.com> To: Pete Resnick Archived-At: Subject: Re: [lisp] Genart telechat review of draft-ietf-lisp-rfc6833bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 21:17:04 -0000 Thanks again Pete for all your effort.=20 Dino > On Sep 19, 2018, at 2:07 PM, Pete Resnick wrote: >=20 > Reviewer: Pete Resnick > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lisp-rfc6833bis-15 > Reviewer: Pete Resnick > Review Date: 2018-09-19 > IETF LC End Date: 2018-08-31 > IESG Telechat date: 2018-09-27 >=20 > Summary: Ready >=20 > Major issues: None. >=20 > Minor issues: None. >=20 > Nits/editorial comments: None. Thanks for all of the cleanup based on my p= revious review. >=20 From nobody Wed Sep 19 16:29:10 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC14F124C04; Wed, 19 Sep 2018 16:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Iry8XTYf42wt; Wed, 19 Sep 2018 16:28:57 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908911274D0; Wed, 19 Sep 2018 16:28:57 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w8JLFwfV015650; Wed, 19 Sep 2018 17:17:57 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2mkx5ng4fv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Sep 2018 17:17:56 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8JLHtRO012099; Wed, 19 Sep 2018 17:17:55 -0400 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [135.66.87.31]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8JLHs2U012085; Wed, 19 Sep 2018 17:17:54 -0400 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [127.0.0.1]) by zlp27127.vci.att.com (Service) with ESMTP id 397044048B54; Wed, 19 Sep 2018 21:17:54 +0000 (GMT) Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (unknown [130.9.129.149]) by zlp27127.vci.att.com (Service) with ESMTPS id 1983D4048B47; Wed, 19 Sep 2018 21:17:54 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.5]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0415.000; Wed, 19 Sep 2018 17:17:53 -0400 From: "BRUNGARD, DEBORAH A" To: Fabio Maino , Magnus Westerlund , "tsv-art@ietf.org" CC: "lisp@ietf.org" , "ietf@ietf.org" , "draft-ietf-lisp-gpe.all@ietf.org" Thread-Topic: Tsvart last call review of draft-ietf-lisp-gpe-05 Thread-Index: AQHUP3kdKafKjKdpRUWhrwqxilH4EaT21n4AgAFiGGA= Date: Wed, 19 Sep 2018 21:17:52 +0000 Message-ID: References: <153553422964.14784.628403975182959075@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.234.88] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C88841A9D9MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-19_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809190205 Archived-At: Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 19 Sep 2018 23:29:01 -0000 --_000_F64C10EAA68C8044B33656FA214632C88841A9D9MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIE1hZ251cyBmb3IgeW91ciBjYXJlZnVsIHJldmlldyENCg0KRmFiaW8sIG9uIHlvdXIg c3VnZ2VzdGVkIHRleHQgYmVsb3csIGl0IGlzIG5vdCBuZWVkZWQgdG8gZHVwbGljYXRlIHRoaXMg aW4gdGhlIElBTkEgc2VjdGlvbi4gVGhlIElBTkEgc2VjdGlvbiBwcm92aWRlcyBndWlkZWxpbmVz IG9uIGFzc2lnbm1lbnQgZm9yIElBTkEsIG5vdCB0byBmdXR1cmUgYXV0aG9ycyAtIGl0IHdvdWxk IG5vdCBiZSBmb3IgSUFOQSB0byBlbnN1cmUgcmVxdWVzdHMgZm9yIHJlZ2lzdHJhdGlvbiBwcm92 aWRlIHRoZSBwcm9wZXIgYW5hbHlzaXMuDQoNClRoYW5rcywNCkRlYm9yYWgNCg0KDQpGcm9tOiBG YWJpbyBNYWlubyA8Zm1haW5vQGNpc2NvLmNvbT4NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAx OCwgMjAxOCAzOjUzIFBNDQpUbzogTWFnbnVzIFdlc3Rlcmx1bmQgPG1hZ251cy53ZXN0ZXJsdW5k QGVyaWNzc29uLmNvbT47IHRzdi1hcnRAaWV0Zi5vcmcNCkNjOiBsaXNwQGlldGYub3JnOyBpZXRm QGlldGYub3JnOyBkcmFmdC1pZXRmLWxpc3AtZ3BlLmFsbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFRzdmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1ncGUtMDUNCg0KSGkg TWFnbnVzLA0KdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQpJIHRoaW5rIEkgc2VlIHRoZSBw b2ludHMgeW91IGFyZSBtYWtpbmcuDQoNCkknbGwgYWRkIHRoZSBzZWN0aW9uIDMuMSBiZWxvdyB0 byBzcGVjaWZ5IHRoZSBnZW5lcmFsIHRyYW5zcG9ydCByZXF1aXJlbWVudHMgZm9yIHRoZSByZWdp c3RyYXRpb24gb2YgbmV3IExJU1AtR1BFIHBheWxvYWRzLCBhbmQgSSB3aWxsIGludHJvZHVjZSB0 d28gc3Vic2VjdGlvbnMgdG8gaW5zdGFudGlhdGUgdGhvc2UgcmVxdWlyZW1lbnRzIGZvciBFdGhl cm5ldCBhbmQgTlNIIChzZWN0aW9uIDQuMiBhbmQgNC4zIHdpbGwgYmUgbW92ZWQgaGVyZSkuIElu IHRoZSAiSUFOQSBDb25zaWRlcmF0aW9ucyIgc2VjdGlvbiBJJ2xsIHJlZmVyIHRvIHRoaXMgbmV3 IHNlY3Rpb24gMy4xIGFzIGEgcmVxdWlyZW1lbnQgZm9yIHJlZ2lzdHJhdGlvbiBvZiBuZXcgZW5j YXBzdWxhdGVkIHBheWxvYWQuDQoNCiIzLjEgUGF5bG9hZCBTcGVjaWZpYyBUcmFuc3BvcnQgSW50 ZXJhY3Rpb25zDQoNClRvIGVuc3VyZSB0aGF0IHByb3RvY29scyB0aGF0IGFyZSBlbmNhcHN1bGF0 ZWQgaW4gTElTUC1HUEUgd2lsbCB3b3JrIHdlbGwgZnJvbSBhIHRyYW5zcG9ydCBpbnRlcmFjdGlv biBwZXJzcGVjdGl2ZSwgdGhlIHNwZWNpZmljYXRpb24gb2YgYSBuZXcgZW5jYXBzdWxhdGVkIHBh eWxvYWQgTVVTVCBjb250YWluIGFuIGFuYWx5c2lzIG9mIGhvdyBMSVNQLUdQRSBTSE9VTEQgZGVh bCB3aXRoIG91dGVyIFVEUCBDaGVja3N1bSwgRFNDUCBtYXBwaW5nLCBhbmQgRXhwbGljaXQgQ29u Z2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgYml0cyB3aGVuZXZlciB0aGV5IGFwcGx5IHRvIHRo ZSBuZXcgZW5jYXBzdWxhdGVkIHBheWxvYWQuDQoNCkZvciBJUCBwYXlsb2Fkcywgc2VjdGlvbiA1 LjMgb2YgW2RyYWZ0LWlldGYtbGlzcC1yZmM2ODMwYmlzXSBzcGVjaWZpZXMgaG93IHRvIGhhbmRs ZSBVRFAgQ2hlY2tzdW1zIGVuY291cmFnaW5nIGltcGxlbWVudG9ycyB0byBjb25zaWRlciBVRFAg Y2hlY2tzdW0gdXNhZ2UgZ3VpZGVsaW5lcyBpbiBzZWN0aW9uIDMuNCBvZiBbUkZDODA4NV0gd2hl biBpdCBpcyBkZXNpcmFibGUgdG8gcHJvdGVjdCBVRFAgYW5kIExJU1AgaGVhZGVycyBhZ2FpbnN0 IGNvcnJ1cHRpb24uIEVhY2ggbmV3IGVuY2Fwc3VsYXRlZCBwYXlsb2Fkcywgd2hlbiByZWdpc3Rl cmVkIHdpdGggTElTUC1HUEUsIE1VU1QgYmUgYWNjb21wYW5pZWQgYnkgYSBzaW1pbGFyIGFuYWx5 c2lzLg0KDQpFbmNhcHN1bGF0ZWQgcGF5bG9hZHMgbWF5IGhhdmUgYSBwcmlvcml0eSBmaWVsZCB0 aGF0IG1heSBvciBtYXkgbm90IGJlIG1hcHBlZCB0byB0aGUgRFNDUCBmaWVsZCBvZiB0aGUgb3V0 ZXIgSVAgaGVhZGVyIChwYXJ0IG9mIFR5cGUgb2YgU2VydmljZSBpbiBJUHY0IG9yIFRyYWZmaWMg Q2xhc3MgaW4gSVB2NikuIFN1Y2ggbmV3IGVuY2Fwc3VsYXRlZCBwYXlsb2Fkcywgd2hlbiByZWdp c3RlcmVkIHdpdGggTElTUC1HUEUsIE1VU1QgYmUgYWNjb21wYW5pZWQgYnkgYW4gYW5hbHlzaXMg c2ltaWxhciB0byB0aGUgb25lIHBlcmZvcm1lZCBpbiBTZWN0aW9uIDMuMS4xIG9mIHRoaXMgZG9j dW1lbnQgZm9yIEV0aGVybmV0IHBheWxvYWRzLg0KDQpFbmNhcHN1bGF0ZWQgcGF5bG9hZHMgbWF5 IGhhdmUgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gbWVjaGFuaXNtcyB0aGF0IG1h eSBvciBtYXkgbm90IGJlIG1hcHBlZCB0byB0aGUgb3V0ZXIgSVAgaGVhZGVyIEVDTiBmaWVsZC4g U3VjaCBuZXcgZW5jYXBzdWxhdGVkIHBheW9sYWRzLCB3aGVuIHJlZ2lzdGVyZWQgd2l0aCBMSVNQ LUdQRSwgTVVTVCAgYmUgYWNjb21wYW5pZWQgYnkgYSBzZXQgb2YgZ3VpZGVsaW5lcyBkZXJpdmVk IGZyb20gW2RyYWZ0LWlldGYtdHN2d2ctZWNuLWVuY2FwLWd1aWRlbGluZXNdIGFuZCBbUkZDNjA0 MF0uDQoNClRoZSByZXN0IG9mIHRoaXMgc2VjdGlvbiBzcGVjaWZpZXMgcGF5bG9hZCBzcGVjaWZp YyB0cmFuc3BvcnQgaW50ZXJhY3Rpb25zIGNvbnNpZGVyYXRpb25zIGZvciB0aGUgdHdvIG5ldyBM SVNQLUdQRSBlbmNhcHN1bGF0ZWQgcGF5bG9hZHMgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQ6 IEV0aGVybmV0IGFuZCBOU0guDQoNCjMuMS4xIFBheWxvYWQgU3BlY2lmaWMgVHJhbnNwb3J0IElu dGVyYWN0aW9ucyBmb3IgRXRoZXJuZXQgRW5jYXBzdWxhdGVkIFBheWxvYWRzDQoNClRoZSBVRFAg Q2hlY2tzdW0gY29uc2lkZXJhdGlvbnMgc3BlY2lmaWVkIGluIHNlY3Rpb24gNS4zIG9mIFtkcmFm dC1pZXRmLWxpc3AtcmZjNjgzMGJpc10gYXBwbHkgdG8gRXRoZXJuZXQgRW5jYXBzdWxhdGVkIFBh eWxvYWRzLiBJbXBsZW1lbnRvcnMgYXJlIGVuY291cmFnZWQgdG8gY29uc2lkZXIgdGhlIFVEUCBj aGVja3N1bSB1c2FnZSBndWlkZWxpbmVzIGluIHNlY3Rpb24gMy40IG9mIFtSRkM4MDg1XSB3aGVu IGl0IGlzIGRlc2lyYWJsZSB0byBwcm90ZWN0IFVEUCwgTElTUCBhbmQgRXRoZXJuZXQgaGVhZGVy cyBhZ2FpbnN0IGNvcnJ1cHRpb24uDQoNCldoZW4gYSBMSVNQLUdQRSByb3V0ZXIgcGVyZm9ybXMg RXRoZXJuZXQgZW5jYXBzdWxhdGlvbiwgdGhlIGlubmVyIDgwMi4xUSBbSUVFRS44MDIuMVFfMjAx NF0gcHJpb3JpdHkgY29kZSBwb2ludCAoUENQKSBmaWVsZCBNQVkgYmUgbWFwcGVkIGZyb20gdGhl IGVuY2Fwc3VsYXRlZCBmcmFtZSB0byB0aGUgVHlwZSBvZiBTZXJ2aWNlIGZpZWxkIGluIHRoZSBv dXRlciBJUHY0IGhlYWRlciwgb3IgaW4gdGhlIGNhc2Ugb2YgSVB2NiB0aGUgJ1RyYWZmaWMgQ2xh c3MnIGZpZWxkIGFzIHBlciBndWlkZWxpbmVzIHByb3ZpZGVkIGJ5IFtSRkM4MzI1XS4NCg0KV2hl biBhIExJU1AtR1BFIHJvdXRlciBwZXJmb3JtcyBFdGhlcm5ldCBlbmNhcHN1bGF0aW9uLCB0aGUg aW5uZXIgaGVhZGVyIDgwMi4xUSBbSUVFRTgwMjFRXSBWTEFOIElkZW50aWZpZXIgKFZJRCkgTUFZ IGJlIG1hcHBlZCB0bywgb3IgdXNlZCB0byBkZXRlcm1pbmUgdGhlIExJU1AgSW5zdGFuY2UgSUQg ZmllbGQuDQoNCjMuMS4yIFBheWxvYWQgU3BlY2lmaWMgVHJhbnNwb3J0IEludGVyYWN0aW9ucyBm b3IgTlNIIEVuY2Fwc3VsYXRlZCBQYXlsb2Fkcw0KDQpUaGUgVURQIENoZWNrc3VtIGNvbnNpZGVy YXRpb25zIHNwZWNpZmllZCBpbiBzZWN0aW9uIDUuMyBvZiBbZHJhZnQtaWV0Zi1saXNwLXJmYzY4 MzBiaXNdIGFwcGx5IHRvIE5TSCBFbmNhcHN1bGF0ZWQgUGF5bG9hZHMuIEltcGxlbWVudG9ycyBh cmUgZW5jb3VyYWdlZCB0byBjb25zaWRlciB0aGUgVURQIGNoZWNrc3VtIHVzYWdlIGd1aWRlbGlu ZXMgaW4gc2VjdGlvbiAzLjQgb2YgW1JGQzgwODVdIHdoZW4gaXQgaXMgZGVzaXJhYmxlIHRvIHBy b3RlY3QgVURQLCBMSVNQLCBhbmQgTlNIIGhlYWRlcnMgYWdhaW5zdCBjb3JydXB0aW9uLg0KDQpX aGVuIGEgTElTUC1HUEUgcm91dGVyIHBlcmZvcm1zIGFuIE5TSCBlbmNhcHN1bGF0aW9uLCBEU0NQ IGFuZCBFQ04gdmFsdWVzIE1BWSBiZSBtYXBwZWQgYXMgc3BlY2lmaWVkIGZvciB0aGUgTmV4dCBQ cm90b2NvbCBlbmNhcHN1bGF0ZWQgYnkgTlNIIChuYW1lbHkgSVB2NCwgSVB2NiBhbmQgRXRoZXJu ZXQpLiINCg0KDQpJIHdpbGwgYWxzbyBhZGQgYSBwYXJhZ3JhcGggdG8gIklhbmEgQ29uc2lkZXJh dGlvbnMiIHRoYXQgc2F5czoNCg0KDQoiVG8gZW5zdXJlIHRoYXQgcHJvdG9jb2xzIHRoYXQgYXJl IGVuY2Fwc3VsYXRlZCBpbiBMSVNQLUdQRSB3aWxsIHdvcmsgd2VsbCBmcm9tIGEgdHJhbnNwb3J0 IGludGVyYWN0aW9uIHBlcnNwZWN0aXZlLCB0aGUgcmVnaXN0cmF0aW9uIG9mIGEgbmV3IGVuY2Fw c3VsYXRlZCBwYXlsb2FkIE1VU1QgY29udGFpbiBhbiBhbmFseXNpcyBvZiBob3cgTElTUC1HUEUg U0hPVUxEIGRlYWwgd2l0aCBvdXRlciBVRFAgQ2hlY2tzdW0sIERTQ1AgbWFwcGluZywgYW5kIEV4 cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIGJpdHMgd2hlbmV2ZXIgdGhleSBh cHBseSB0byB0aGUgbmV3IGVuY2Fwc3VsYXRlZCBwYXlsb2FkLiBUaGUgYW5hbHlzaXMgZm9yIHRo ZSBuZXcgZW5jYXBzdWxhdGVkIHBheWxvYWQgcmVnaXN0ZXJlZCBpbiB0aGlzIGRvY3VtZW50IGlz IGluIHNlY3Rpb24gMy4xLiINCg0KUGxlYXNlLCBsZXQgbWUga25vdyBpZiB0aGlzIGFkZHJlc3Mg eW91ciBjb21tZW50cy4NCg0KVGhhbmtzLA0KRmFiaW8NCg0KDQoNCk9uIDgvMjkvMTggMjoxNyBB TSwgTWFnbnVzIFdlc3Rlcmx1bmQgd3JvdGU6DQoNClJldmlld2VyOiBNYWdudXMgV2VzdGVybHVu ZA0KDQpSZXZpZXcgcmVzdWx0OiBOb3QgUmVhZHkNCg0KDQoNClRoaXMgZG9jdW1lbnQgaGFzIGJl ZW4gcmV2aWV3ZWQgYXMgcGFydCBvZiB0aGUgdHJhbnNwb3J0IGFyZWEgZGlyZWN0b3JhdGUncw0K DQpvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcga2V5IElFVEYgZG9jdW1lbnRzLiBUaGVzZSBjb21t ZW50cyB3ZXJlIHdyaXR0ZW4NCg0KcHJpbWFyaWx5IGZvciB0aGUgdHJhbnNwb3J0IGFyZWEgZGly ZWN0b3JzLCBidXQgYXJlIGNvcGllZCB0byB0aGUgZG9jdW1lbnQncw0KDQphdXRob3JzIGFuZCBX RyBmb3IgdGhlaXIgaW5mb3JtYXRpb24gYW5kIHRvIGFsbG93IHRoZW0gdG8gYWRkcmVzcyBhbnkg aXNzdWVzDQoNCnJhaXNlZC4NCg0KDQoNCldoZW4gZG9uZSBhdCB0aGUgdGltZSBvZiBJRVRGIExh c3QgQ2FsbCwgdGhlIGF1dGhvcnMgc2hvdWxkIGNvbnNpZGVyIHRoaXMNCg0KcmV2aWV3IHRvZ2V0 aGVyIHdpdGggYW55IG90aGVyIGxhc3QtY2FsbCBjb21tZW50cyB0aGV5IHJlY2VpdmUuDQoNClBs ZWFzZSBhbHdheXMgQ0MgdHN2LWFydEBpZXRmLm9yZzxtYWlsdG86dHN2LWFydEBpZXRmLm9yZz4g aWYgeW91IHJlcGx5IHRvIG9yIGZvcndhcmQgdGhpcyByZXZpZXcuDQoNCg0KDQpJc3N1ZSBBLg0K DQoNCg0KVGhlIHJlYXNvbiBJIHN0YXRlIE5vdCBSZWFkeSBoYXMgdG8gZG8gd2l0aCB0aGlzIGRv Y3VtZW50cyBmYWlsdXJlIHRvIGNvbnNpZGVyDQoNCnRoZSB1c2Ugb2YgemVybyBjaGVja3N1bSBm b3IgSVB2NiB3aGVuIHR1bm5lbGluZyBvdGhlciB0aGluZ3MgdGhhbiBJUC4gVGhlIG5vbmUNCg0K R1BFIHZlcnNpb24gaXMgbGltaXRlZCB0byB0dW5uZWwgSVAgZm9yIHdoaWNoIHRoZSBhbmFseXNp cyBmb3IgdXNlIG9mIHplcm8NCg0KY2hlY2tzdW0gaGFzIGJlZW4gZG9uZS4gRWFjaCBvZiB0aGUg bmV3IHR1bm5lbGVkIHByb3RvY29scyB0aGF0IGFyZSBzcGVjaWZpZWQNCg0KaW4gdGhpcyBkb2N1 bWVudCwgaS5lLiBldGhlcm5ldCBhbmQgTkhTLCB3aWxsIG5lZWQgdG8gcGVyZm9ybSB0aGUgYW5h bHlzaXMgaWYNCg0KdGhleSBhcmUgc2FmZSB0byB1c2UgemVybyBjaGVja3N1bSBvciBub3QsIGFu ZCBpZiBub3QgZGlzYWxsb3cgemVybyBjaGVja3N1bQ0KDQpmb3IgSVB2Ni9VRFAuIFRoZSBkb2N1 bWV0biBhbHNvIG5lZWQgYSByZXF1aXJlbWVudCBpbiB0aGUgcmVnaXN0cmF0aW9uDQoNCnJlcXVp cmVtZW50cyB0byBwZXJmb3JtIHRoaXMgYW5hbHlzaXMgYW5kIGRlZmluZWQgaWYgemVybyBjaGVj a3N1bSBpcw0KDQphY2NlcHRhYmxlIG9yIG5vdC4NCg0KDQoNCkNpdGluZyBTZWN0aW9uIDUuMyBv ZiBkcmFmdC1pZXRmLWxpc3AtcmZjNjgzMGJpcw0KDQoNCg0KICAgVURQIENoZWNrc3VtOiAgVGhl ICdVRFAgQ2hlY2tzdW0nIGZpZWxkIFNIT1VMRCBiZSB0cmFuc21pdHRlZCBhcyB6ZXJvDQoNCiAg ICAgIGJ5IGFuIElUUiBmb3IgZWl0aGVyIElQdjQgW1JGQzA3NjhdIGFuZCBJUHY2IGVuY2Fwc3Vs YXRpb24NCg0KICAgICAgW1JGQzY5MzVdIFtSRkM2OTM2XS4gIFdoZW4gYSBwYWNrZXQgd2l0aCBh IHplcm8gVURQIGNoZWNrc3VtIGlzDQoNCiAgICAgIHJlY2VpdmVkIGJ5IGFuIEVUUiwgdGhlIEVU UiBNVVNUIGFjY2VwdCB0aGUgcGFja2V0IGZvcg0KDQogICAgICBkZWNhcHN1bGF0aW9uLiAgV2hl biBhbiBJVFIgdHJhbnNtaXRzIGEgbm9uLXplcm8gdmFsdWUgZm9yIHRoZSBVRFANCg0KICAgICAg Y2hlY2tzdW0sIGl0IE1VU1Qgc2VuZCBhIGNvcnJlY3RseSBjb21wdXRlZCB2YWx1ZSBpbiB0aGlz IGZpZWxkLg0KDQogICAgICBXaGVuIGFuIEVUUiByZWNlaXZlcyBhIHBhY2tldCB3aXRoIGEgbm9u LXplcm8gVURQIGNoZWNrc3VtLCBpdCBNQVkNCg0KICAgICAgY2hvb3NlIHRvIHZlcmlmeSB0aGUg Y2hlY2tzdW0gdmFsdWUuICBJZiBpdCBjaG9vc2VzIHRvIHBlcmZvcm0NCg0KICAgICAgc3VjaCB2 ZXJpZmljYXRpb24sIGFuZCB0aGUgdmVyaWZpY2F0aW9uIGZhaWxzLCB0aGUgcGFja2V0IE1VU1Qg YmUNCg0KICAgICAgc2lsZW50bHkgZHJvcHBlZC4gIElmIHRoZSBFVFIgY2hvb3NlcyBub3QgdG8g cGVyZm9ybSB0aGUNCg0KICAgICAgdmVyaWZpY2F0aW9uLCBvciBwZXJmb3JtcyB0aGUgdmVyaWZp Y2F0aW9uIHN1Y2Nlc3NmdWxseSwgdGhlDQoNCiAgICAgIHBhY2tldCBNVVNUIGJlIGFjY2VwdGVk IGZvciBkZWNhcHN1bGF0aW9uLiAgVGhlIGhhbmRsaW5nIG9mIFVEUA0KDQogICAgICB6ZXJvIGNo ZWNrc3VtcyBvdmVyIElQdjYgZm9yIGFsbCB0dW5uZWxpbmcgcHJvdG9jb2xzLCBpbmNsdWRpbmcN Cg0KICAgICAgTElTUCwgaXMgc3ViamVjdCB0byB0aGUgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQg aW4gW1JGQzY5MzZdLg0KDQoNCg0KVGhlIGlzc3VlIGlzIHRoYXQgd2hlbiBMSVNQIGVuY2Fwc3Vs YXRlIG90aGVyIHByb3RvY29scyB0aGUgaW1wYWN0IG9mIGENCg0KbWlzc2RlbGl2ZXJlZCB0dW5u ZWwgcGFja2V0IHRvIHRoZSB3cm9uZyBFVFIgY2FuIGhhdmUgZGlmZmVyZW50IGltcGFjdHMuIEFz DQoNCndlbGwgYXMgZXJyb3JzIGluIHRoZSBoZWFkZXJzIG9mIHRoZSBlbmNhcHN1bGF0ZWQgcGFj a2V0IHRoYXQgbWF5IGJlIGFzc3VtZWQgdG8NCg0KYmUgcHJvdGVjdGVkIGJ5IHRoZSBlbmNhcHN1 bGF0aW5nIGxheWVyLiBUaHVzLCBpbmRpdmlkdWFsIGFuYWx5c2lzIG9mIGVhY2gNCg0KcHJvdG9j b2wgdGhhdCBhcmUgdHVubmVsZWQgYXJlIG5lZWRlZC4NCg0KDQoNCkIuKSA0LjIuICBUeXBlIG9m IFNlcnZpY2UNCg0KDQoNCiAgIFdoZW4gYSBMSVNQLUdQRSByb3V0ZXIgcGVyZm9ybXMgRXRoZXJu ZXQgZW5jYXBzdWxhdGlvbiwgdGhlIGlubmVyDQoNCiAgIDgwMi4xUSBbSUVFRS44MDIuMVFfMjAx NF0gcHJpb3JpdHkgY29kZSBwb2ludCAoUENQKSBmaWVsZCBNQVkgYmUNCg0KICAgbWFwcGVkIGZy b20gdGhlIGVuY2Fwc3VsYXRlZCBmcmFtZSB0byB0aGUgVHlwZSBvZiBTZXJ2aWNlIGZpZWxkIGlu DQoNCiAgIHRoZSBvdXRlciBJUHY0IGhlYWRlciwgb3IgaW4gdGhlIGNhc2Ugb2YgSVB2NiB0aGUg J1RyYWZmaWMgQ2xhc3MnDQoNCiAgIGZpZWxkLg0KDQoNCg0KQW55IHJlY29tbWVuZGF0aW9uIGFi b3V0IGhvdyB0byBwZXJmb3JtIHRoYXQgbWFwcGluZz8gTWF5YmUgcGFydHMgb2YNCg0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmZjODMyNS88aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2Nf cmZjODMyNV8mZD1Ed01EYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlk TTdqWWx4WEQ4dyZtPXhodi12aXBUd3RXd2c1QWNRdE1yWkNyUUExSkFmWVhNQWdHV3Fiamo0QXcm cz04Z2lkcHJJVUNmaGFkRmRXaTd4bFdEMGJQc2IzZFBkZkN3OVFmOGtkd1RJJmU9PiBhcmUgcmVs ZXZhbnQgaW4gdGhpcyBjb250ZXh0Lg0KDQoNCg0KQy4gR2VuZXJhbCBjYXNlIG9mIDQuMjoNCg0K DQoNCkkgZXhwZWN0IG90aGVyIHByb3RvY29scyB0aGFuIEV0aGVybmV0IG1heSBoYXZlIGEgcHJp b3JpdHkgZmllbGQgdGhhdCBtYXkgb3INCg0KbWF5IG5vdCBiZSBtYXBwZWQgdG8gdGhlIERTQ1Ag ZmllbGQgb2YgdGhlIHR1bm5lbCBwYWNrZXQuDQoNCg0KDQpJIHdvdWxkIGV4cGVjdCB0aGF0IGZv ciBuZXcgcHJvdG9jb2wgcmVnaXN0cmF0aW9uIGluIHRoZSBMSVNQLUdQRSBOZXh0IFByb3RvY29s DQoNClJlZ2lzdHJ5IHNob3VsZCBjb25zaWRlciB0aGlzLiBUaHVzLCBpdCB3b3VsZCBiZSBnb29k IHRvIG5vdGUgdGhhdCBzdWNoDQoNCmNvbnNpZGVyYXRpb25zIGFyZSBuZWVkZWQgYW5kIHBhcnQg b2Ygd2hhdCBzaG91bGQgYmUgZXZhbHVhdGVkIGZvciBuZXcNCg0KcmVnaXN0cmF0aW9ucy4NCg0K DQoNCkQuIEVDTiBoYW5kbGluZw0KDQoNCg0KU2VjdGlvbiA1LjMgb2YgZHJhZnQtaWV0Zi1saXNw LXJmYzY4MzBiaXMgc3RhdGVzOg0KDQoNCg0KICAgbyAgVGhlICdFeHBsaWNpdCBDb25nZXN0aW9u IE5vdGlmaWNhdGlvbicgKEVDTikgZmllbGQgKGJpdHMgNiBhbmQgNw0KDQogICAgICBvZiB0aGUg SVB2NiAnVHJhZmZpYyBDbGFzcycgZmllbGQpIHJlcXVpcmVzIHNwZWNpYWwgdHJlYXRtZW50IGlu DQoNCiAgICAgIG9yZGVyIHRvIGF2b2lkIGRpc2NhcmRpbmcgaW5kaWNhdGlvbnMgb2YgY29uZ2Vz dGlvbiBbUkZDMzE2OF0uDQoNCiAgICAgIElUUiBlbmNhcHN1bGF0aW9uIE1VU1QgY29weSB0aGUg Mi1iaXQgJ0VDTicgZmllbGQgZnJvbSB0aGUgaW5uZXINCg0KICAgICAgaGVhZGVyIHRvIHRoZSBv dXRlciBoZWFkZXIuICBSZS1lbmNhcHN1bGF0aW9uIE1VU1QgY29weSB0aGUgMi1iaXQNCg0KICAg ICAgJ0VDTicgZmllbGQgZnJvbSB0aGUgc3RyaXBwZWQgb3V0ZXIgaGVhZGVyIHRvIHRoZSBuZXcg b3V0ZXINCg0KICAgICAgaGVhZGVyLg0KDQoNCg0KVGhlIGFib3ZlIHJ1bGVzIG1heSBub3QgYmUg YXBwbGljYWJsZSBmb3IgYWxsIHRyYW5zcG9ydCBwcm90b2NvbHMuIFRodXMgSSB0aGluaw0KDQpp dCBpcyByZXF1aXJlZCB0aGF0IG9uZSBkbyBwcm90b2NvbCBzcGVjaWZpYyBjb25zaWRlcmF0aW9u cyBvZiBFQ04uIFRTVldHIGFyZQ0KDQp3b3JraW5nIG9uIHJlY29tbWVuZGF0aW9ucyBmb3IgdHVu bmVscyBoYW5kbGluZyBvZiAgRUNOIGhlcmUsIHNlZToNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZW5jYXAtZ3VpZGVsaW5lcy88aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tl ci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEdHN2d2ctMkRlY24tMkRlbmNhcC0yRGd1aWRl bGluZXNfJmQ9RHdNRGFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPTZVaEdwVzlsd2k5ZE03 allseFhEOHcmbT14aHYtdmlwVHd0V3dnNUFjUXRNclpDclFBMUpBZllYTUFnR1dxYmpqNEF3JnM9 ZXlPNGM3RDNTaE5RaGFhOG9WRHFDaWRIYkVwM21XN0FrTTUxZHV2OFF3NCZlPT4gVGh1cywNCg0K bXkgZXhwZWN0YXRpb24gd291bGQgYmUgdG8gZW5zdXJlIHRoYXQgdGhlIHJlZ2lzdGVyZWQgcHJv dG9jb2xzIGhhdmUgZGVmaW5lZA0KDQpFQ04gaGFuZGxpbmcsIGV4cGxpY2l0bHkgb3IgYnkgcmVm ZXJlbmNlLiBTZWNvbmRseSB0aGF0IHJlZ2lzdHJhdGlvbg0KDQpyZXF1aXJlbWVudCBzdGF0ZXMg dGhlIG5lZWQgZm9yIHRoaXMgY29uc2lkZXJhdGlvbi4NCg0KDQoNClN1bW1hcnk6IFRvIGVuc3Vy ZSB0aGF0IGZ1dHVyZSBhZGRlZCBwcm90b2NvbHMgdGhhdCBhcmUgZW5jYXBzdWxhdGVkIHdpbGwg d29yaw0KDQp3ZWxsIGZyb20gYSB0cmFuc3BvcnQgaW50ZXJhY3Rpb24gcGVyc3BlY3RpdmUgdGhl cmUgbmVlZCB0byBiZSBhIHJlcXVpcmVtZW50IG9uDQoNCm5ldyByZWdpc3RyYXRpb24gdG8gY29u c2lkZXIgYW5kIGRlZmluZSBob3cgdGhleSB1c2UgemVybyBjaGVja3N1bSwgYW55IERTQ1ANCg0K bWFwcGluZyBhbmQgRUNOIGJpdHMuIEluIGFkZGl0aW9uIHRoZSBjdXJyZW50IGRvY3VtZW50IG5l ZWRzIHRvIGVuc3VyZSB0aGVzZQ0KDQp0aGluZ3MgYXJlIGNsZWFybHkgc3BlY2lmaWVkIGZvciB0 aGUgZW5jYXBzdWxhdGVkIHByb3RvY29scyBpbiB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KDQoNCg0K --_000_F64C10EAA68C8044B33656FA214632C88841A9D9MISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+VGhhbmtzIE1hZ251cyBmb3IgeW91ciBjYXJlZnVs IHJldmlldyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZhYmlv LCBvbiB5b3VyIHN1Z2dlc3RlZCB0ZXh0IGJlbG93LCBpdCBpcyBub3QgbmVlZGVkIHRvIGR1cGxp Y2F0ZSB0aGlzIGluIHRoZSBJQU5BIHNlY3Rpb24uIFRoZSBJQU5BIHNlY3Rpb24gcHJvdmlkZXMg Z3VpZGVsaW5lcyBvbiBhc3NpZ25tZW50IGZvciBJQU5BLCBub3QgdG8gZnV0dXJlIGF1dGhvcnMg LSBpdCB3b3VsZCBub3QgYmUgZm9yIElBTkEgdG8NCiBlbnN1cmUgcmVxdWVzdHMgZm9yIHJlZ2lz dHJhdGlvbiBwcm92aWRlIHRoZSBwcm9wZXIgYW5hbHlzaXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkRlYm9yYWg8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gRmFiaW8gTWFpbm8gJmx0O2Zt YWlub0BjaXNjby5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgU2VwdGVtYmVy IDE4LCAyMDE4IDM6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IE1hZ251cyBXZXN0ZXJsdW5kICZsdDtt YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20mZ3Q7OyB0c3YtYXJ0QGlldGYub3JnPGJyPg0K PGI+Q2M6PC9iPiBsaXNwQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBkcmFmdC1pZXRmLWxpc3At Z3BlLmFsbEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVHN2YXJ0IGxhc3QgY2Fs bCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1saXNwLWdwZS0wNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBNYWdudXMsIDxicj4NCnRoYW5rcyBm b3IgeW91ciBjb21tZW50cy4gPGJyPg0KPGJyPg0KSSB0aGluayBJIHNlZSB0aGUgcG9pbnRzIHlv dSBhcmUgbWFraW5nLiA8YnI+DQo8YnI+DQpJJ2xsIGFkZCB0aGUgc2VjdGlvbiAzLjEgYmVsb3cg dG8gc3BlY2lmeSB0aGUgZ2VuZXJhbCB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIGZvciB0aGUgcmVn aXN0cmF0aW9uIG9mIG5ldyBMSVNQLUdQRSBwYXlsb2FkcywgYW5kIEkgd2lsbCBpbnRyb2R1Y2Ug dHdvIHN1YnNlY3Rpb25zIHRvIGluc3RhbnRpYXRlIHRob3NlIHJlcXVpcmVtZW50cyBmb3IgRXRo ZXJuZXQgYW5kIE5TSCAoc2VjdGlvbiA0LjIgYW5kIDQuMyB3aWxsIGJlIG1vdmVkIGhlcmUpLg0K IEluIHRoZSAmcXVvdDtJQU5BIENvbnNpZGVyYXRpb25zJnF1b3Q7IHNlY3Rpb24gSSdsbCByZWZl ciB0byB0aGlzIG5ldyBzZWN0aW9uIDMuMSBhcyBhIHJlcXVpcmVtZW50IGZvciByZWdpc3RyYXRp b24gb2YgbmV3IGVuY2Fwc3VsYXRlZCBwYXlsb2FkLg0KPGJyPg0KPGJyPg0KJnF1b3Q7My4xIFBh eWxvYWQgU3BlY2lmaWMgVHJhbnNwb3J0IEludGVyYWN0aW9uczxicj4NCjxicj4NClRvIGVuc3Vy ZSB0aGF0IHByb3RvY29scyB0aGF0IGFyZSBlbmNhcHN1bGF0ZWQgaW4gTElTUC1HUEUgd2lsbCB3 b3JrIHdlbGwgZnJvbSBhIHRyYW5zcG9ydCBpbnRlcmFjdGlvbiBwZXJzcGVjdGl2ZSwgdGhlIHNw ZWNpZmljYXRpb24gb2YgYSBuZXcgZW5jYXBzdWxhdGVkIHBheWxvYWQgTVVTVCBjb250YWluIGFu IGFuYWx5c2lzIG9mIGhvdyBMSVNQLUdQRSBTSE9VTEQgZGVhbCB3aXRoIG91dGVyIFVEUCBDaGVj a3N1bSwgRFNDUCBtYXBwaW5nLCBhbmQNCiBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlv biAoRUNOKSBiaXRzIHdoZW5ldmVyIHRoZXkgYXBwbHkgdG8gdGhlIG5ldyBlbmNhcHN1bGF0ZWQg cGF5bG9hZC48YnI+DQo8YnI+DQpGb3IgSVAgcGF5bG9hZHMsIHNlY3Rpb24gNS4zIG9mIFtkcmFm dC1pZXRmLWxpc3AtcmZjNjgzMGJpc10gc3BlY2lmaWVzIGhvdyB0byBoYW5kbGUgVURQIENoZWNr c3VtcyBlbmNvdXJhZ2luZyBpbXBsZW1lbnRvcnMgdG8gY29uc2lkZXIgVURQIGNoZWNrc3VtIHVz YWdlIGd1aWRlbGluZXMgaW4gc2VjdGlvbiAzLjQgb2YgW1JGQzgwODVdIHdoZW4gaXQgaXMgZGVz aXJhYmxlIHRvIHByb3RlY3QgVURQIGFuZCBMSVNQIGhlYWRlcnMgYWdhaW5zdCBjb3JydXB0aW9u Lg0KIEVhY2ggbmV3IGVuY2Fwc3VsYXRlZCBwYXlsb2Fkcywgd2hlbiByZWdpc3RlcmVkIHdpdGgg TElTUC1HUEUsIE1VU1QgYmUgYWNjb21wYW5pZWQgYnkgYSBzaW1pbGFyIGFuYWx5c2lzLjxicj4N Cjxicj4NCkVuY2Fwc3VsYXRlZCBwYXlsb2FkcyBtYXkgaGF2ZSBhIHByaW9yaXR5IGZpZWxkIHRo YXQgbWF5IG9yIG1heSBub3QgYmUgbWFwcGVkIHRvIHRoZSBEU0NQIGZpZWxkIG9mIHRoZSBvdXRl ciBJUCBoZWFkZXIgKHBhcnQgb2YgVHlwZSBvZiBTZXJ2aWNlIGluIElQdjQgb3IgVHJhZmZpYyBD bGFzcyBpbiBJUHY2KS4gU3VjaCBuZXcgZW5jYXBzdWxhdGVkIHBheWxvYWRzLCB3aGVuIHJlZ2lz dGVyZWQgd2l0aCBMSVNQLUdQRSwgTVVTVCBiZSBhY2NvbXBhbmllZA0KIGJ5IGFuIGFuYWx5c2lz IHNpbWlsYXIgdG8gdGhlIG9uZSBwZXJmb3JtZWQgaW4gU2VjdGlvbiAzLjEuMSBvZiB0aGlzIGRv Y3VtZW50IGZvciBFdGhlcm5ldCBwYXlsb2Fkcy4NCjxicj4NCjxicj4NCkVuY2Fwc3VsYXRlZCBw YXlsb2FkcyBtYXkgaGF2ZSBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiBtZWNoYW5p c21zIHRoYXQgbWF5IG9yIG1heSBub3QgYmUgbWFwcGVkIHRvIHRoZSBvdXRlciBJUCBoZWFkZXIg RUNOIGZpZWxkLiBTdWNoIG5ldyBlbmNhcHN1bGF0ZWQgcGF5b2xhZHMsIHdoZW4gcmVnaXN0ZXJl ZCB3aXRoIExJU1AtR1BFLCBNVVNUJm5ic3A7IGJlIGFjY29tcGFuaWVkIGJ5IGEgc2V0IG9mIGd1 aWRlbGluZXMgZGVyaXZlZCBmcm9tDQogW2RyYWZ0LWlldGYtdHN2d2ctZWNuLWVuY2FwLWd1aWRl bGluZXNdIGFuZCBbUkZDNjA0MF0uIDxicj4NCjxicj4NClRoZSByZXN0IG9mIHRoaXMgc2VjdGlv biBzcGVjaWZpZXMgcGF5bG9hZCBzcGVjaWZpYyB0cmFuc3BvcnQgaW50ZXJhY3Rpb25zIGNvbnNp ZGVyYXRpb25zIGZvciB0aGUgdHdvIG5ldyBMSVNQLUdQRSBlbmNhcHN1bGF0ZWQgcGF5bG9hZHMg c3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQ6IEV0aGVybmV0IGFuZCBOU0guDQo8YnI+DQo8YnI+ DQozLjEuMSBQYXlsb2FkIFNwZWNpZmljIFRyYW5zcG9ydCBJbnRlcmFjdGlvbnMgZm9yIEV0aGVy bmV0IEVuY2Fwc3VsYXRlZCBQYXlsb2Fkczxicj4NCjxicj4NClRoZSBVRFAgQ2hlY2tzdW0gY29u c2lkZXJhdGlvbnMgc3BlY2lmaWVkIGluIHNlY3Rpb24gNS4zIG9mIFtkcmFmdC1pZXRmLWxpc3At cmZjNjgzMGJpc10gYXBwbHkgdG8gRXRoZXJuZXQgRW5jYXBzdWxhdGVkIFBheWxvYWRzLiBJbXBs ZW1lbnRvcnMgYXJlIGVuY291cmFnZWQgdG8gY29uc2lkZXIgdGhlIFVEUCBjaGVja3N1bSB1c2Fn ZSBndWlkZWxpbmVzIGluIHNlY3Rpb24gMy40IG9mIFtSRkM4MDg1XSB3aGVuIGl0IGlzIGRlc2ly YWJsZSB0byBwcm90ZWN0DQogVURQLCBMSVNQIGFuZCBFdGhlcm5ldCBoZWFkZXJzIGFnYWluc3Qg Y29ycnVwdGlvbi48YnI+DQo8YnI+DQpXaGVuIGEgTElTUC1HUEUgcm91dGVyIHBlcmZvcm1zIEV0 aGVybmV0IGVuY2Fwc3VsYXRpb24sIHRoZSBpbm5lciA4MDIuMVEgW0lFRUUuODAyLjFRXzIwMTRd IHByaW9yaXR5IGNvZGUgcG9pbnQgKFBDUCkgZmllbGQgTUFZIGJlIG1hcHBlZCBmcm9tIHRoZSBl bmNhcHN1bGF0ZWQgZnJhbWUgdG8gdGhlIFR5cGUgb2YgU2VydmljZSBmaWVsZCBpbiB0aGUgb3V0 ZXIgSVB2NCBoZWFkZXIsIG9yIGluIHRoZSBjYXNlIG9mIElQdjYgdGhlICdUcmFmZmljDQogQ2xh c3MnIGZpZWxkIGFzIHBlciBndWlkZWxpbmVzIHByb3ZpZGVkIGJ5IFtSRkM4MzI1XS48YnI+DQo8 YnI+DQpXaGVuIGEgTElTUC1HUEUgcm91dGVyIHBlcmZvcm1zIEV0aGVybmV0IGVuY2Fwc3VsYXRp b24sIHRoZSBpbm5lciBoZWFkZXIgODAyLjFRIFtJRUVFODAyMVFdIFZMQU4gSWRlbnRpZmllciAo VklEKSBNQVkgYmUgbWFwcGVkIHRvLCBvciB1c2VkIHRvIGRldGVybWluZSB0aGUgTElTUCBJbnN0 YW5jZSBJRCBmaWVsZC48YnI+DQo8YnI+DQozLjEuMiBQYXlsb2FkIFNwZWNpZmljIFRyYW5zcG9y dCBJbnRlcmFjdGlvbnMgZm9yIE5TSCBFbmNhcHN1bGF0ZWQgUGF5bG9hZHMgPGJyPg0KPGJyPg0K VGhlIFVEUCBDaGVja3N1bSBjb25zaWRlcmF0aW9ucyBzcGVjaWZpZWQgaW4gc2VjdGlvbiA1LjMg b2YgW2RyYWZ0LWlldGYtbGlzcC1yZmM2ODMwYmlzXSBhcHBseSB0byBOU0ggRW5jYXBzdWxhdGVk IFBheWxvYWRzLiBJbXBsZW1lbnRvcnMgYXJlIGVuY291cmFnZWQgdG8gY29uc2lkZXIgdGhlIFVE UCBjaGVja3N1bSB1c2FnZSBndWlkZWxpbmVzIGluIHNlY3Rpb24gMy40IG9mIFtSRkM4MDg1XSB3 aGVuIGl0IGlzIGRlc2lyYWJsZSB0byBwcm90ZWN0DQogVURQLCBMSVNQLCBhbmQgTlNIIGhlYWRl cnMgYWdhaW5zdCBjb3JydXB0aW9uLjxicj4NCjxicj4NCldoZW4gYSBMSVNQLUdQRSByb3V0ZXIg cGVyZm9ybXMgYW4gTlNIIGVuY2Fwc3VsYXRpb24sIERTQ1AgYW5kIEVDTiB2YWx1ZXMgTUFZIGJl IG1hcHBlZCBhcyBzcGVjaWZpZWQgZm9yIHRoZSBOZXh0IFByb3RvY29sIGVuY2Fwc3VsYXRlZCBi eSBOU0ggKG5hbWVseSBJUHY0LCBJUHY2IGFuZCBFdGhlcm5ldCkuJnF1b3Q7Jm5ic3A7DQo8YnI+ DQo8YnI+DQo8YnI+DQpJIHdpbGwgYWxzbyBhZGQgYSBwYXJhZ3JhcGggdG8gJnF1b3Q7SWFuYSBD b25zaWRlcmF0aW9ucyZxdW90OyB0aGF0IHNheXM6IDxicj4NCjxicj4NCjxicj4NCiZxdW90O1Rv IGVuc3VyZSB0aGF0IHByb3RvY29scyB0aGF0IGFyZSBlbmNhcHN1bGF0ZWQgaW4gTElTUC1HUEUg d2lsbCB3b3JrIHdlbGwgZnJvbSBhIHRyYW5zcG9ydCBpbnRlcmFjdGlvbiBwZXJzcGVjdGl2ZSwg dGhlIHJlZ2lzdHJhdGlvbiBvZiBhIG5ldyBlbmNhcHN1bGF0ZWQgcGF5bG9hZCBNVVNUIGNvbnRh aW4gYW4gYW5hbHlzaXMgb2YgaG93IExJU1AtR1BFIFNIT1VMRCBkZWFsIHdpdGggb3V0ZXIgVURQ IENoZWNrc3VtLCBEU0NQIG1hcHBpbmcsIGFuZA0KIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZp Y2F0aW9uIChFQ04pIGJpdHMgd2hlbmV2ZXIgdGhleSBhcHBseSB0byB0aGUgbmV3IGVuY2Fwc3Vs YXRlZCBwYXlsb2FkLiBUaGUgYW5hbHlzaXMgZm9yIHRoZSBuZXcgZW5jYXBzdWxhdGVkIHBheWxv YWQgcmVnaXN0ZXJlZCBpbiB0aGlzIGRvY3VtZW50IGlzIGluIHNlY3Rpb24gMy4xLiZxdW90Ozxi cj4NCjxicj4NClBsZWFzZSwgbGV0IG1lIGtub3cgaWYgdGhpcyBhZGRyZXNzIHlvdXIgY29tbWVu dHMuIDxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpGYWJpbzxicj4NCjxicj4NCjxicj4NCjxicj4N Ck9uIDgvMjkvMTggMjoxNyBBTSwgTWFnbnVzIFdlc3Rlcmx1bmQgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHByZT5SZXZpZXdlcjogTWFnbnVzIFdlc3Rlcmx1bmQ8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5SZXZpZXcgcmVzdWx0OiBOb3QgUmVhZHk8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGRvY3VtZW50IGhhcyBiZWVu IHJldmlld2VkIGFzIHBhcnQgb2YgdGhlIHRyYW5zcG9ydCBhcmVhIGRpcmVjdG9yYXRlJ3M8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5vbmdvaW5nIGVmZm9ydCB0byByZXZpZXcga2V5IElFVEYgZG9j dW1lbnRzLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5wcmltYXJpbHkgZm9yIHRoZSB0cmFuc3BvcnQgYXJlYSBkaXJlY3RvcnMsIGJ1dCBhcmUgY29w aWVkIHRvIHRoZSBkb2N1bWVudCdzPG86cD48L286cD48L3ByZT4NCjxwcmU+YXV0aG9ycyBhbmQg V0cgZm9yIHRoZWlyIGluZm9ybWF0aW9uIGFuZCB0byBhbGxvdyB0aGVtIHRvIGFkZHJlc3MgYW55 IGlzc3VlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJhaXNlZC48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5XaGVuIGRvbmUgYXQgdGhlIHRpbWUg b2YgSUVURiBMYXN0IENhbGwsIHRoZSBhdXRob3JzIHNob3VsZCBjb25zaWRlciB0aGlzPG86cD48 L286cD48L3ByZT4NCjxwcmU+cmV2aWV3IHRvZ2V0aGVyIHdpdGggYW55IG90aGVyIGxhc3QtY2Fs bCBjb21tZW50cyB0aGV5IHJlY2VpdmUuPG86cD48L286cD48L3ByZT4NCjxwcmU+UGxlYXNlIGFs d2F5cyBDQyA8YSBocmVmPSJtYWlsdG86dHN2LWFydEBpZXRmLm9yZyI+dHN2LWFydEBpZXRmLm9y ZzwvYT4gaWYgeW91IHJlcGx5IHRvIG9yIGZvcndhcmQgdGhpcyByZXZpZXcuPG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SXNzdWUgQS48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgcmVhc29u IEkgc3RhdGUgTm90IFJlYWR5IGhhcyB0byBkbyB3aXRoIHRoaXMgZG9jdW1lbnRzIGZhaWx1cmUg dG8gY29uc2lkZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGUgdXNlIG9mIHplcm8gY2hlY2tz dW0gZm9yIElQdjYgd2hlbiB0dW5uZWxpbmcgb3RoZXIgdGhpbmdzIHRoYW4gSVAuIFRoZSBub25l PG86cD48L286cD48L3ByZT4NCjxwcmU+R1BFIHZlcnNpb24gaXMgbGltaXRlZCB0byB0dW5uZWwg SVAgZm9yIHdoaWNoIHRoZSBhbmFseXNpcyBmb3IgdXNlIG9mIHplcm88bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5jaGVja3N1bSBoYXMgYmVlbiBkb25lLiBFYWNoIG9mIHRoZSBuZXcgdHVubmVsZWQg cHJvdG9jb2xzIHRoYXQgYXJlIHNwZWNpZmllZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmluIHRo aXMgZG9jdW1lbnQsIGkuZS4gZXRoZXJuZXQgYW5kIE5IUywgd2lsbCBuZWVkIHRvIHBlcmZvcm0g dGhlIGFuYWx5c2lzIGlmPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhleSBhcmUgc2FmZSB0byB1 c2UgemVybyBjaGVja3N1bSBvciBub3QsIGFuZCBpZiBub3QgZGlzYWxsb3cgemVybyBjaGVja3N1 bTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmZvciBJUHY2L1VEUC4gVGhlIGRvY3VtZXRuIGFsc28g bmVlZCBhIHJlcXVpcmVtZW50IGluIHRoZSByZWdpc3RyYXRpb248bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5yZXF1aXJlbWVudHMgdG8gcGVyZm9ybSB0aGlzIGFuYWx5c2lzIGFuZCBkZWZpbmVkIGlm IHplcm8gY2hlY2tzdW0gaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hY2NlcHRhYmxlIG9yIG5v dC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5D aXRpbmcgU2VjdGlvbiA1LjMgb2YgZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBiaXM8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg VURQIENoZWNrc3VtOiZuYnNwOyBUaGUgJ1VEUCBDaGVja3N1bScgZmllbGQgU0hPVUxEIGJlIHRy YW5zbWl0dGVkIGFzIHplcm88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgYnkgYW4gSVRSIGZvciBlaXRoZXIgSVB2NCBbUkZDMDc2OF0gYW5kIElQ djYgZW5jYXBzdWxhdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBbUkZDNjkzNV0gW1JGQzY5MzZdLiZuYnNwOyBXaGVuIGEgcGFja2V0IHdp dGggYSB6ZXJvIFVEUCBjaGVja3N1bSBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWNlaXZlZCBieSBhbiBFVFIsIHRoZSBFVFIgTVVTVCBh Y2NlcHQgdGhlIHBhY2tldCBmb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZGVjYXBzdWxhdGlvbi4mbmJzcDsgV2hlbiBhbiBJVFIgdHJhbnNt aXRzIGEgbm9uLXplcm8gdmFsdWUgZm9yIHRoZSBVRFA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2hlY2tzdW0sIGl0IE1VU1Qgc2VuZCBhIGNv cnJlY3RseSBjb21wdXRlZCB2YWx1ZSBpbiB0aGlzIGZpZWxkLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaGVuIGFuIEVUUiByZWNlaXZlcyBh IHBhY2tldCB3aXRoIGEgbm9uLXplcm8gVURQIGNoZWNrc3VtLCBpdCBNQVk8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2hvb3NlIHRvIHZlcmlm eSB0aGUgY2hlY2tzdW0gdmFsdWUuJm5ic3A7IElmIGl0IGNob29zZXMgdG8gcGVyZm9ybTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdWNoIHZl cmlmaWNhdGlvbiwgYW5kIHRoZSB2ZXJpZmljYXRpb24gZmFpbHMsIHRoZSBwYWNrZXQgTVVTVCBi ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBz aWxlbnRseSBkcm9wcGVkLiZuYnNwOyBJZiB0aGUgRVRSIGNob29zZXMgbm90IHRvIHBlcmZvcm0g dGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHZlcmlmaWNhdGlvbiwgb3IgcGVyZm9ybXMgdGhlIHZlcmlmaWNhdGlvbiBzdWNjZXNzZnVsbHks IHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBwYWNrZXQgTVVTVCBiZSBhY2NlcHRlZCBmb3IgZGVjYXBzdWxhdGlvbi4mbmJzcDsgVGhlIGhh bmRsaW5nIG9mIFVEUDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB6ZXJvIGNoZWNrc3VtcyBvdmVyIElQdjYgZm9yIGFsbCB0dW5uZWxpbmcgcHJv dG9jb2xzLCBpbmNsdWRpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgTElTUCwgaXMgc3ViamVjdCB0byB0aGUgYXBwbGljYWJpbGl0eSBzdGF0 ZW1lbnQgaW4gW1JGQzY5MzZdLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPlRoZSBpc3N1ZSBpcyB0aGF0IHdoZW4gTElTUCBlbmNhcHN1bGF0ZSBv dGhlciBwcm90b2NvbHMgdGhlIGltcGFjdCBvZiBhPG86cD48L286cD48L3ByZT4NCjxwcmU+bWlz c2RlbGl2ZXJlZCB0dW5uZWwgcGFja2V0IHRvIHRoZSB3cm9uZyBFVFIgY2FuIGhhdmUgZGlmZmVy ZW50IGltcGFjdHMuIEFzPG86cD48L286cD48L3ByZT4NCjxwcmU+d2VsbCBhcyBlcnJvcnMgaW4g dGhlIGhlYWRlcnMgb2YgdGhlIGVuY2Fwc3VsYXRlZCBwYWNrZXQgdGhhdCBtYXkgYmUgYXNzdW1l ZCB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmJlIHByb3RlY3RlZCBieSB0aGUgZW5jYXBzdWxh dGluZyBsYXllci4gVGh1cywgaW5kaXZpZHVhbCBhbmFseXNpcyBvZiBlYWNoPG86cD48L286cD48 L3ByZT4NCjxwcmU+cHJvdG9jb2wgdGhhdCBhcmUgdHVubmVsZWQgYXJlIG5lZWRlZC48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5CLikgNC4yLiZu YnNwOyBUeXBlIG9mIFNlcnZpY2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgV2hlbiBhIExJU1AtR1BFIHJvdXRlciBwZXJm b3JtcyBFdGhlcm5ldCBlbmNhcHN1bGF0aW9uLCB0aGUgaW5uZXI8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgODAyLjFRIFtJRUVFLjgwMi4xUV8yMDE0XSBwcmlvcml0eSBjb2Rl IHBvaW50IChQQ1ApIGZpZWxkIE1BWSBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBtYXBwZWQgZnJvbSB0aGUgZW5jYXBzdWxhdGVkIGZyYW1lIHRvIHRoZSBUeXBlIG9mIFNl cnZpY2UgZmllbGQgaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhlIG91 dGVyIElQdjQgaGVhZGVyLCBvciBpbiB0aGUgY2FzZSBvZiBJUHY2IHRoZSAnVHJhZmZpYyBDbGFz cyc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZmllbGQuPG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QW55IHJlY29tbWVuZGF0 aW9uIGFib3V0IGhvdyB0byBwZXJmb3JtIHRoYXQgbWFwcGluZz8gTWF5YmUgcGFydHMgb2Y8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19yZmM4MzI1 XyZhbXA7ZD1Ed01EYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj02VWhHcFc5 bHdpOWRNN2pZbHhYRDh3JmFtcDttPXhodi12aXBUd3RXd2c1QWNRdE1yWkNyUUExSkFmWVhNQWdH V3Fiamo0QXcmYW1wO3M9OGdpZHBySVVDZmhhZEZkV2k3eGxXRDBiUHNiM2RQZGZDdzlRZjhrZHdU SSZhbXA7ZT0iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzgzMjUvPC9hPiBh cmUgcmVsZXZhbnQgaW4gdGhpcyBjb250ZXh0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkMuIEdlbmVyYWwgY2FzZSBvZiA0LjI6PG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSBleHBlY3Qgb3Ro ZXIgcHJvdG9jb2xzIHRoYW4gRXRoZXJuZXQgbWF5IGhhdmUgYSBwcmlvcml0eSBmaWVsZCB0aGF0 IG1heSBvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm1heSBub3QgYmUgbWFwcGVkIHRvIHRoZSBE U0NQIGZpZWxkIG9mIHRoZSB0dW5uZWwgcGFja2V0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkkgd291bGQgZXhwZWN0IHRoYXQgZm9yIG5ldyBw cm90b2NvbCByZWdpc3RyYXRpb24gaW4gdGhlIExJU1AtR1BFIE5leHQgUHJvdG9jb2w8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5SZWdpc3RyeSBzaG91bGQgY29uc2lkZXIgdGhpcy4gVGh1cywgaXQg d291bGQgYmUgZ29vZCB0byBub3RlIHRoYXQgc3VjaDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNv bnNpZGVyYXRpb25zIGFyZSBuZWVkZWQgYW5kIHBhcnQgb2Ygd2hhdCBzaG91bGQgYmUgZXZhbHVh dGVkIGZvciBuZXc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZWdpc3RyYXRpb25zLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkQuIEVDTiBoYW5k bGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PlNlY3Rpb24gNS4zIG9mIGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMwYmlzIHN0YXRlczo8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgbyZuYnNwOyBUaGUgJ0V4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uJyAoRUNOKSBm aWVsZCAoYml0cyA2IGFuZCA3PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG9mIHRoZSBJUHY2ICdUcmFmZmljIENsYXNzJyBmaWVsZCkgcmVxdWly ZXMgc3BlY2lhbCB0cmVhdG1lbnQgaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgb3JkZXIgdG8gYXZvaWQgZGlzY2FyZGluZyBpbmRpY2F0aW9u cyBvZiBjb25nZXN0aW9uIFtSRkMzMTY4XS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSVRSIGVuY2Fwc3VsYXRpb24gTVVTVCBjb3B5IHRoZSAy LWJpdCAnRUNOJyBmaWVsZCBmcm9tIHRoZSBpbm5lcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBoZWFkZXIgdG8gdGhlIG91dGVyIGhlYWRlci4m bmJzcDsgUmUtZW5jYXBzdWxhdGlvbiBNVVNUIGNvcHkgdGhlIDItYml0PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICdFQ04nIGZpZWxkIGZyb20g dGhlIHN0cmlwcGVkIG91dGVyIGhlYWRlciB0byB0aGUgbmV3IG91dGVyPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhlYWRlci48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgYWJvdmUgcnVs ZXMgbWF5IG5vdCBiZSBhcHBsaWNhYmxlIGZvciBhbGwgdHJhbnNwb3J0IHByb3RvY29scy4gVGh1 cyBJIHRoaW5rPG86cD48L286cD48L3ByZT4NCjxwcmU+aXQgaXMgcmVxdWlyZWQgdGhhdCBvbmUg ZG8gcHJvdG9jb2wgc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMgb2YgRUNOLiBUU1ZXRyBhcmU8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT53b3JraW5nIG9uIHJlY29tbWVuZGF0aW9ucyBmb3IgdHVubmVs cyBoYW5kbGluZyBvZiZuYnNwOyBFQ04gaGVyZSwgc2VlOiA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkR0c3Z3Zy0yRGVj bi0yRGVuY2FwLTJEZ3VpZGVsaW5lc18mYW1wO2Q9RHdNRGFRJmFtcDtjPUxGWVotbzlfSFVNZU1U U1FpY3ZqSWcmYW1wO3I9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZhbXA7bT14aHYtdmlwVHd0V3dn NUFjUXRNclpDclFBMUpBZllYTUFnR1dxYmpqNEF3JmFtcDtzPWV5TzRjN0QzU2hOUWhhYThvVkRx Q2lkSGJFcDNtVzdBa001MWR1djhRdzQmYW1wO2U9Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXRzdndnLWVjbi1lbmNhcC1ndWlkZWxpbmVzLzwvYT4gVGh1cyw8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5teSBleHBlY3RhdGlvbiB3b3VsZCBiZSB0byBlbnN1cmUg dGhhdCB0aGUgcmVnaXN0ZXJlZCBwcm90b2NvbHMgaGF2ZSBkZWZpbmVkPG86cD48L286cD48L3By ZT4NCjxwcmU+RUNOIGhhbmRsaW5nLCBleHBsaWNpdGx5IG9yIGJ5IHJlZmVyZW5jZS4gU2Vjb25k bHkgdGhhdCByZWdpc3RyYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZXF1aXJlbWVudCBz dGF0ZXMgdGhlIG5lZWQgZm9yIHRoaXMgY29uc2lkZXJhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5TdW1tYXJ5OiBUbyBlbnN1cmUgdGhh dCBmdXR1cmUgYWRkZWQgcHJvdG9jb2xzIHRoYXQgYXJlIGVuY2Fwc3VsYXRlZCB3aWxsIHdvcms8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53ZWxsIGZyb20gYSB0cmFuc3BvcnQgaW50ZXJhY3Rpb24g cGVyc3BlY3RpdmUgdGhlcmUgbmVlZCB0byBiZSBhIHJlcXVpcmVtZW50IG9uPG86cD48L286cD48 L3ByZT4NCjxwcmU+bmV3IHJlZ2lzdHJhdGlvbiB0byBjb25zaWRlciBhbmQgZGVmaW5lIGhvdyB0 aGV5IHVzZSB6ZXJvIGNoZWNrc3VtLCBhbnkgRFNDUDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm1h cHBpbmcgYW5kIEVDTiBiaXRzLiBJbiBhZGRpdGlvbiB0aGUgY3VycmVudCBkb2N1bWVudCBuZWVk cyB0byBlbnN1cmUgdGhlc2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGluZ3MgYXJlIGNsZWFy bHkgc3BlY2lmaWVkIGZvciB0aGUgZW5jYXBzdWxhdGVkIHByb3RvY29scyBpbiB0aGlzIGRvY3Vt ZW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F64C10EAA68C8044B33656FA214632C88841A9D9MISOUT7MSGUSRDE_-- From nobody Thu Sep 20 01:14:40 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F442130E8D for ; Thu, 20 Sep 2018 01:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 IyJKuHN5wiLz for ; Thu, 20 Sep 2018 01:14:25 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F6A130E50 for ; Thu, 20 Sep 2018 01:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537431259; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YotHdRlQlhcGARnc2+VkzQ3spalJe6J3RLr1eTLPap8=; b=VbYCmLKGVGb5S6zpVYsvbvoDXvrJ5SBtAIsyYaRL1fC/dPjKo9u8lR6aPae410rV W5uKUXxBYYk31bcBkJfAGptcUvz8YwVJuvBXrLx0MNQMdnamS0PPCYiO3LXMoSuN XfrkEa3+g9vCJaKwr1H8GDxlG04MCgyoAkK9X9T9YDM=; X-AuditID: c1b4fb30-fe1ff700000055da-3d-5ba356dbb463 Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3B.6A.21978.BD653AB5; Thu, 20 Sep 2018 10:14:19 +0200 (CEST) Received: from [100.94.33.105] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 20 Sep 2018 10:14:18 +0200 To: "BRUNGARD, DEBORAH A" , Fabio Maino , "tsv-art@ietf.org" CC: "lisp@ietf.org" , "ietf@ietf.org" , "draft-ietf-lisp-gpe.all@ietf.org" References: <153553422964.14784.628403975182959075@ietfa.amsl.com> From: Magnus Westerlund Message-ID: Date: Thu, 20 Sep 2018 10:14:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090805030703070701080904" X-Originating-IP: [153.88.183.153] X-ClientProxiedBy: ESESSMB502.ericsson.se (153.88.183.163) To ESESSMB502.ericsson.se (153.88.183.163) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUyM2J7he7tsMXRBofb+Cwud3WzW7R+3cdo cWHHP0aLZxvns1hMOatuMWvPIhYHNo+X/XMYPab83sjqsWTJT6YA5igum5TUnMyy1CJ9uwSu jCc/VrEXtJ5kqmh4/IWpgfFEO1MXIyeHhICJxId3a9i7GLk4hASOMkq0HPrJCJIQEnjPKPH9 SDqILSxgJ/G1rYUZxBYRKJZYd3MuI0gDs0Avo0T3vP0scN1dHUfAutkELCRu/mhk62Lk4OAV sJdYf8oRJMwioCqxZs5DJpCwqEC0xKf/mSBhXgFBiZMzn7CA2JwCURJTv35gg5jfzSix+90c doiDtCUamjpYIa5Wkrg+7zoLhJ0ucXnFHvYJjIKzkMyahawfJMEsECbx48NVNghbXOLWk/lM ELaZxLzND5khbG2JZQtfA9kcQLaaxLJWJVRhENtaYsavg1BjFCWmdD+EGm8q8froR0YI21hi 2bq/bAsYeVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbvwS2/DXYwvnzueIhRgINRiYdX yXdxtBBrYllxZe4hRhWgOY82rL7AKMWSl5+XqiTCa2IClOZNSaysSi3Kjy8qzUktPsQozcGi JM5r4bc5SkggPbEkNTs1tSC1CCbLxMEp1cBYm8228+9n/s0Coi+3Msnf4Zi3ja9y3rJHTcvT rj7pYbZWL9pfFzbXKZz/yqHNKW2hQmEnFpYu//Bqioxu9NXEk84FxgeWO5Zyitwwaffc5779 eZvu92rmg4E+QprWHzlDJ/w9zjLhnMhtgzkFnpvXbg9Pv9vOn36havLb1WnnW+8uOhyUlX5d iaU4I9FQi7moOBEASGPW6eYCAAA= Archived-At: Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 20 Sep 2018 08:14:29 -0000 --------------ms090805030703070701080904 Content-Type: multipart/alternative; boundary="------------AF484D5F7797A3852245E11A" Content-Language: en-US This is a multi-part message in MIME format. --------------AF484D5F7797A3852245E11A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On 9/19/2018 11:17 PM, BRUNGARD, DEBORAH A wrote: > > Thanks Magnus for your careful review! > > Fabio, on your suggested text below, it is not needed to duplicate=20 > this in the IANA section. The IANA section provides guidelines on=20 > assignment for IANA, not to future authors - it would not be for IANA=20 > to ensure requests for registration provide the proper analysis. > Deborah I am disagreeing about this. The IANA section may contain=20 requirements on the registration that further entries are required to=20 fulfill. This becomes especially important in expert review registries.=20 And in this case as a Standards Action registry, making explicit the=20 expectations on new registries from the creators of the registries are=20 very appropriate. It helps ensure that future extensions do think about=20 important things. So I would really like to see the text stay in. Cheers Magnus > Thanks, > > Deborah > > *From:*Fabio Maino > *Sent:* Tuesday, September 18, 2018 3:53 PM > *To:* Magnus Westerlund ; tsv-art@ietf.= org > *Cc:* lisp@ietf.org; ietf@ietf.org; draft-ietf-lisp-gpe.all@ietf.org > *Subject:* Re: Tsvart last call review of draft-ietf-lisp-gpe-05 > > Hi Magnus, > thanks for your comments. > > I think I see the points you are making. > > I'll add the section 3.1 below to specify the general transport=20 > requirements for the registration of new LISP-GPE payloads, and I will = > introduce two subsections to instantiate those requirements for=20 > Ethernet and NSH (section 4.2 and 4.3 will be moved here). In the=20 > "IANA Considerations" section I'll refer to this new section 3.1 as a=20 > requirement for registration of new encapsulated payload. > > "3.1 Payload Specific Transport Interactions > > To ensure that protocols that are encapsulated in LISP-GPE will work=20 > well from a transport interaction perspective, the specification of a=20 > new encapsulated payload MUST contain an analysis of how LISP-GPE=20 > SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit=20 > Congestion Notification (ECN) bits whenever they apply to the new=20 > encapsulated payload. > > For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] specifies = > how to handle UDP Checksums encouraging implementors to consider UDP=20 > checksum usage guidelines in section 3.4 of [RFC8085] when it is=20 > desirable to protect UDP and LISP headers against corruption. Each new = > encapsulated payloads, when registered with LISP-GPE, MUST be=20 > accompanied by a similar analysis. > > Encapsulated payloads may have a priority field that may or may not be = > mapped to the DSCP field of the outer IP header (part of Type of=20 > Service in IPv4 or Traffic Class in IPv6). Such new encapsulated=20 > payloads, when registered with LISP-GPE, MUST be accompanied by an=20 > analysis similar to the one performed in Section 3.1.1 of this=20 > document for Ethernet payloads. > > Encapsulated payloads may have Explicit Congestion Notification=20 > mechanisms that may or may not be mapped to the outer IP header ECN=20 > field. Such new encapsulated payolads, when registered with LISP-GPE,=20 > MUST=C2=A0 be accompanied by a set of guidelines derived from=20 > [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. > > The rest of this section specifies payload specific transport=20 > interactions considerations for the two new LISP-GPE encapsulated=20 > payloads specified in this document: Ethernet and NSH. > > 3.1.1 Payload Specific Transport Interactions for Ethernet=20 > Encapsulated Payloads > > The UDP Checksum considerations specified in section 5.3 of=20 > [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads.=20 > Implementors are encouraged to consider the UDP checksum usage=20 > guidelines in section 3.4 of [RFC8085] when it is desirable to protect = > UDP, LISP and Ethernet headers against corruption. > > When a LISP-GPE router performs Ethernet encapsulation, the inner=20 > 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be=20 > mapped from the encapsulated frame to the Type of Service field in the = > outer IPv4 header, or in the case of IPv6 the 'Traffic Class' field as = > per guidelines provided by [RFC8325]. > > When a LISP-GPE router performs Ethernet encapsulation, the inner=20 > header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or=20 > used to determine the LISP Instance ID field. > > 3.1.2 Payload Specific Transport Interactions for NSH Encapsulated=20 > Payloads > > The UDP Checksum considerations specified in section 5.3 of=20 > [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads.=20 > Implementors are encouraged to consider the UDP checksum usage=20 > guidelines in section 3.4 of [RFC8085] when it is desirable to protect = > UDP, LISP, and NSH headers against corruption. > > When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN=20 > values MAY be mapped as specified for the Next Protocol encapsulated=20 > by NSH (namely IPv4, IPv6 and Ethernet)." > > > I will also add a paragraph to "Iana Considerations" that says: > > > "To ensure that protocols that are encapsulated in LISP-GPE will work=20 > well from a transport interaction perspective, the registration of a=20 > new encapsulated payload MUST contain an analysis of how LISP-GPE=20 > SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit=20 > Congestion Notification (ECN) bits whenever they apply to the new=20 > encapsulated payload. The analysis for the new encapsulated payload=20 > registered in this document is in section 3.1." > > Please, let me know if this address your comments. > > Thanks, > Fabio > > > > On 8/29/18 2:17 AM, Magnus Westerlund wrote: > > Reviewer: Magnus Westerlund > > Review result: Not Ready > > This document has been reviewed as part of the transport area direc= torate's > > ongoing effort to review key IETF documents. These comments were wr= itten > > primarily for the transport area directors, but are copied to the d= ocument's > > authors and WG for their information and to allow them to address a= ny issues > > raised. > > When done at the time of IETF Last Call, the authors should conside= r this > > review together with any other last-call comments they receive. > > Please always CCtsv-art@ietf.org if you= reply to or forward this review. > > Issue A. > > The reason I state Not Ready has to do with this documents failure = to consider > > the use of zero checksum for IPv6 when tunneling other things than = IP. The none > > GPE version is limited to tunnel IP for which the analysis for use = of zero > > checksum has been done. Each of the new tunneled protocols that are= specified > > in this document, i.e. ethernet and NHS, will need to perform the a= nalysis if > > they are safe to use zero checksum or not, and if not disallow zero= checksum > > for IPv6/UDP. The documetn also need a requirement in the registrat= ion > > requirements to perform this analysis and defined if zero checksum = is > > acceptable or not. > > Citing Section 5.3 of draft-ietf-lisp-rfc6830bis > > =C2=A0=C2=A0 UDP Checksum:=C2=A0 The 'UDP Checksum' field SHOULD b= e transmitted as zero > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by an ITR for either IPv4 [RFC0768]= and IPv6 encapsulation > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [RFC6935] [RFC6936].=C2=A0 When a p= acket with a zero UDP checksum is > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 received by an ETR, the ETR MUST ac= cept the packet for > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 decapsulation.=C2=A0 When an ITR tr= ansmits a non-zero value for the UDP > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 checksum, it MUST send a correctly = computed value in this field. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When an ETR receives a packet with = a non-zero UDP checksum, it MAY > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 choose to verify the checksum value= =2E=C2=A0 If it chooses to perform > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 such verification, and the verifica= tion fails, the packet MUST be > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 silently dropped.=C2=A0 If the ETR = chooses not to perform the > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 verification, or performs the verif= ication successfully, the > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 packet MUST be accepted for decapsu= lation.=C2=A0 The handling of UDP > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 zero checksums over IPv6 for all tu= nneling protocols, including > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LISP, is subject to the applicabili= ty statement in [RFC6936]. > > The issue is that when LISP encapsulate other protocols the impact = of a > > missdelivered tunnel packet to the wrong ETR can have different imp= acts. As > > well as errors in the headers of the encapsulated packet that may b= e assumed to > > be protected by the encapsulating layer. Thus, individual analysis = of each > > protocol that are tunneled are needed. > > B.) 4.2.=C2=A0 Type of Service > > =C2=A0=C2=A0 When a LISP-GPE router performs Ethernet encapsulatio= n, the inner > > =C2=A0=C2=A0 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) f= ield MAY be > > =C2=A0=C2=A0 mapped from the encapsulated frame to the Type of Ser= vice field in > > =C2=A0=C2=A0 the outer IPv4 header, or in the case of IPv6 the 'Tr= affic Class' > > =C2=A0=C2=A0 field. > > Any recommendation about how to perform that mapping? Maybe parts o= f > > https://datatracker.ietf.org/doc/rfc8325/ are relevant in this context. > > C. General case of 4.2: > > I expect other protocols than Ethernet may have a priority field th= at may or > > may not be mapped to the DSCP field of the tunnel packet. > > I would expect that for new protocol registration in the LISP-GPE N= ext Protocol > > Registry should consider this. Thus, it would be good to note that = such > > considerations are needed and part of what should be evaluated for = new > > registrations. > > D. ECN handling > > Section 5.3 of draft-ietf-lisp-rfc6830bis states: > > =C2=A0=C2=A0 o=C2=A0 The 'Explicit Congestion Notification' (ECN) = field (bits 6 and 7 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the IPv6 'Traffic Class' field) = requires special treatment in > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 order to avoid discarding indicatio= ns of congestion [RFC3168]. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ITR encapsulation MUST copy the 2-b= it 'ECN' field from the inner > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 header to the outer header.=C2=A0 R= e-encapsulation MUST copy the 2-bit > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 'ECN' field from the stripped outer= header to the new outer > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 header. > > The above rules may not be applicable for all transport protocols. = Thus I think > > it is required that one do protocol specific considerations of ECN.= TSVWG are > > working on recommendations for tunnels handling of=C2=A0 ECN here, = see: > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guideli= nes/ Thus, > > my expectation would be to ensure that the registered protocols hav= e defined > > ECN handling, explicitly or by reference. Secondly that registratio= n > > requirement states the need for this consideration. > > Summary: To ensure that future added protocols that are encapsulate= d will work > > well from a transport interaction perspective there need to be a re= quirement on > > new registration to consider and define how they use zero checksum,= any DSCP > > mapping and ECN bits. In addition the current document needs to ens= ure these > > things are clearly specified for the encapsulated protocols in this= document. > --=20 Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------AF484D5F7797A3852245E11A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

On 9/19/2018 11:17 PM, BRUNGARD, DEBORAH A wrote:

Thanks Magnus for your careful review!

=C2=A0=

Fabio, on= your suggested text below, it is not needed to duplicate this in the IANA section. The IANA section provides guidelines on assignment for IANA, not to future authors - it would not be for IANA to ensure requests for registration provide the proper analysis.


Deborah I am disagreeing about this. The IANA section may contain requirements on the registration that further entries are required to fulfill. This becomes especially important in expert review registries. And in this case as a Standards Action registry, making explicit the expectations on new registries from the creators of the registries are very appropriate. It helps ensure that future extensions do think about important things.

So I would really like to see the text stay in.

Cheers

Magnus


=C2=A0=

Thanks,

Deborah

=C2=A0=

=C2=A0=

Fr= om: Fabio Maino <fmaino@cisco.com>
Sent: Tuesday, September 18, 2018 3:53 PM
To: Magnus Westerlund <magnus.westerlund@ericsson.com>; tsv-ar= t@ietf.org
Cc: lisp@ietf.org; ietf@ietf.org; draft-ietf-lisp-gpe.all@ietf.org
Subject: Re: Tsvart last call review of draft-ietf-lisp-gpe-05

=C2=A0

Hi Magnus,
thanks for your comments.

I think I see the points you are making.

I'll add the section 3.1 below to specify the general transport requirements for the registration of new LISP-GPE payloads, and I will introduce two subsections to instantiate those requirements for Ethernet and NSH (section 4.2 and 4.3 will be moved here). In the "IANA Considerations" section I'll refer to this new section 3.1 as a requirement for registration of new encapsulated payload.

"3.1 Payload Specific Transport Interactions

To ensure that protocols that are encapsulated in LISP-GPE will work well from a transport interaction perspective, the specification of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion Notification (ECN) bits whenever they apply to the new encapsulated payload.

For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] specifies how to handle UDP Checksums encouraging implementors to consider UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP and LISP headers against corruption. Each new encapsulated payloads, when registered with LISP-GPE, MUST be accompanied by a similar analysis.

Encapsulated payloads may have a priority field that may or may not be mapped to the DSCP field of the outer IP header (part of Type of Service in IPv4 or Traffic Class in IPv6). Such new encapsulated payloads, when registered with LISP-GPE, MUST be accompanied by an analysis similar to the one performed in Section 3.1.1 of this document for Ethernet payloads.

Encapsulated payloads may have Explicit Congestion Notification mechanisms that may or may not be mapped to the outer IP header ECN field. Such new encapsulated payolads, when registered with LISP-GPE, MUST=C2=A0 be accompanied by a= set of guidelines derived from [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].

The rest of this section specifies payload specific transport interactions considerations for the two new LISP-GPE encapsulated payloads specified in this document: Ethernet and NSH.

3.1.1 Payload Specific Transport Interactions for Ethernet Encapsulated Payloads

The UDP Checksum considerations specified in section 5.3 of [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. Implementors are encouraged to consider the UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP, LISP and Ethernet headers against corruption.

When a LISP-GPE router performs Ethernet encapsulation, the inner 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be mapped from the encapsulated frame to the Type of Service field in the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' field as per guidelines provided by [RFC8325].

When a LISP-GPE router performs Ethernet encapsulation, the inner header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or used to determine the LISP Instance ID field.
3.1.2 Payload Specific Transport Interactions for NSH Encapsulated Payloads

The UDP Checksum considerations specified in section 5.3 of [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. Implementors are encouraged to consider the UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP, LISP, and NSH headers against corruption.

When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN values MAY be mapped as specified for the Next Protocol encapsulated by NSH (namely IPv4, IPv6 and Ethernet)."=C2=A0


I will also add a paragraph to "Iana Considerations" that says:


"To ensure that protocols that are encapsulated in LISP-GPE will work well from a transport interaction perspective, the registration of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion Notification (ECN) bits whenever they apply to the new encapsulated payload. The analysis for the new encapsulated payload registered in this document is in section 3.1."

Please, let me know if this address your comments.

Thanks,
Fabio



On 8/29/18 2:17 AM, Magnus Westerlund wrote:

Reviewer: Magnus Westerlund
Review result: Not Ready
=C2=A0
This document has been reviewed as part of the transport a=
rea directorate's
ongoing effort to review key IETF documents. These comment=
s were written
primarily for the transport area directors, but are copied=
 to the document's
authors and WG for their information and to allow them to =
address any issues
raised.
=C2=A0
When done at the time of IETF Last Call, the authors shoul=
d consider this
review together with any other last-call comments they rec=
eive.
Please always CC tsv-art@ietf.org if you reply to or forward this =
review.
=C2=A0
Issue A.
=C2=A0
The reason I state Not Ready has to do with this documents=
 failure to consider
the use of zero checksum for IPv6 when tunneling other thi=
ngs than IP. The none
GPE version is limited to tunnel IP for which the analysis=
 for use of zero
checksum has been done. Each of the new tunneled protocols=
 that are specified
in this document, i.e. ethernet and NHS, will need to perf=
orm the analysis if
they are safe to use zero checksum or not, and if not disa=
llow zero checksum
for IPv6/UDP. The documetn also need a requirement in the =
registration
requirements to perform this analysis and defined if zero =
checksum is
acceptable or not.
=C2=A0
Citing Section 5.3 of draft-ietf-lisp-rfc6830bis
=C2=A0
=C2=A0=C2=A0 UDP Checksum:=C2=A0 The 'UDP Checksum' field =
SHOULD be transmitted as zero
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by an ITR for either IPv4 [=
RFC0768] and IPv6 encapsulation
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [RFC6935] [RFC6936].=C2=A0 =
When a packet with a zero UDP checksum is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 received by an ETR, the ETR=
 MUST accept the packet for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 decapsulation.=C2=A0 When a=
n ITR transmits a non-zero value for the UDP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 checksum, it MUST send a co=
rrectly computed value in this field.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When an ETR receives a pack=
et with a non-zero UDP checksum, it MAY
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 choose to verify the checks=
um value.=C2=A0 If it chooses to perform
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 such verification, and the =
verification fails, the packet MUST be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 silently dropped.=C2=A0 If =
the ETR chooses not to perform the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 verification, or performs t=
he verification successfully, the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 packet MUST be accepted for=
 decapsulation.=C2=A0 The handling of UDP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 zero checksums over IPv6 fo=
r all tunneling protocols, including
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LISP, is subject to the app=
licability statement in [RFC6936].
=C2=A0
The issue is that when LISP encapsulate other protocols th=
e impact of a
missdelivered tunnel packet to the wrong ETR can have diff=
erent impacts. As
well as errors in the headers of the encapsulated packet t=
hat may be assumed to
be protected by the encapsulating layer. Thus, individual =
analysis of each
protocol that are tunneled are needed.
=C2=A0
B.) 4.2.=C2=A0 Type of Service
=C2=A0
=C2=A0=C2=A0 When a LISP-GPE router performs Ethernet enca=
psulation, the inner
=C2=A0=C2=A0 802.1Q [IEEE.802.1Q_2014] priority code point=
 (PCP) field MAY be
=C2=A0=C2=A0 mapped from the encapsulated frame to the Typ=
e of Service field in
=C2=A0=C2=A0 the outer IPv4 header, or in the case of IPv6=
 the 'Traffic Class'
=C2=A0=C2=A0 field.
=C2=A0
Any recommendation about how to perform that mapping? Mayb=
e parts of
https://datatracker.ietf.org/doc/r=
fc8325/ are relevant in this context.
=C2=A0
C. General case of 4.2:
=C2=A0
I expect other protocols than Ethernet may have a priority=
 field that may or
may not be mapped to the DSCP field of the tunnel packet.<=
o:p>
=C2=A0
I would expect that for new protocol registration in the L=
ISP-GPE Next Protocol
Registry should consider this. Thus, it would be good to n=
ote that such
considerations are needed and part of what should be evalu=
ated for new
registrations.
=C2=A0
D. ECN handling
=C2=A0
Section 5.3 of draft-ietf-lisp-rfc6830bis states:
=C2=A0
=C2=A0=C2=A0 o=C2=A0 The 'Explicit Congestion Notification=
' (ECN) field (bits 6 and 7
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the IPv6 'Traffic Class'=
 field) requires special treatment in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 order to avoid discarding i=
ndications of congestion [RFC3168].
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ITR encapsulation MUST copy=
 the 2-bit 'ECN' field from the inner
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 header to the outer header.=
=C2=A0 Re-encapsulation MUST copy the 2-bit
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 'ECN' field from the stripp=
ed outer header to the new outer
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 header.
=C2=A0
The above rules may not be applicable for all transport pr=
otocols. Thus I think
it is required that one do protocol specific consideration=
s of ECN. TSVWG are
working on recommendations for tunnels handling of=C2=A0 E=
CN here, see: 
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guideli=
nes/ Thus,
my expectation would be to ensure that the registered prot=
ocols have defined
ECN handling, explicitly or by reference. Secondly that re=
gistration
requirement states the need for this consideration.
=C2=A0
Summary: To ensure that future added protocols that are en=
capsulated will work
well from a transport interaction perspective there need t=
o be a requirement on
new registration to consider and define how they use zero =
checksum, any DSCP
mapping and ECN bits. In addition the current document nee=
ds to ensure these
things are clearly specified for the encapsulated protocol=
s in this document.
=C2=A0
=C2=A0

=C2=A0

--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------AF484D5F7797A3852245E11A--

--------------ms090805030703070701080904
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DNEwggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNV
BAoMCEVyaWNzc29uMRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJ
ARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+
laqg5eXTqonqnzT9ykEGL2dx9mBT+2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJ
HGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iV
IiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpigGFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36o
gzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkrbdmdnjKGrYSnJigmxw14pJugxL/Vb2Ee
VcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov
L2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYI
KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t
MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29u
bmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJp
Y3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0
dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD
VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3
DQEBCwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4Q
ihhoQR3cvhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXD
yF9mhWYbSAkJyx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6
H3zO3nsq++KBmsOiSKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvE
lup5n7l864FqxnC2friDo4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl
60rmc8SJlt6QXKw0wXEOE1MubauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwD
ig3SZi1qP7D/Ds4V+JLIjjUJc25l9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8K
v7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLCQaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3
UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Zla71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzY
VBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd//n4YbY2QhDCCBsIwggSqoAMCAQICEFO4
foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx
HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUx
MDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM
HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw
ggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfS
Tm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbX
ILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfp
VdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2
PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2
H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4
rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX
1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjv
Zibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FN
VSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsG
AQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEu
Y29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j
b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE
TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnku
dHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3Js
LTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud
JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7
GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G
CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDU
JQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHG
vw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYn
nl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwf
ixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ8
5AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4Hd
Dc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOE
EHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd
3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/du
jp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEB
MFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMA0GCWCGSAFlAwQCAQUA
oIIBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODA5MjAw
ODE0MThaMC8GCSqGSIb3DQEJBDEiBCBUUOE7ISHlVPGpcC6OAR9AjFFyLfV1Vc+5hM3JeZON
aTBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjEl
MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBlrrZreXF5
7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMGwGCyqGSIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nz
b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62
a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAZ6GeWS6Uy10zRnalciTtqoIoIv8iQP6AFiP2BSQz
QvRtB/YghDNC66m/dL+qzMvbrAXqDrcHc7JaAJl9A4oOXMFrWHYaXk1hGXZE/KQG+JckObkq
hJQg5G3C4nJTAdfJXrcv2Fbpwhm4BXkii9zjfoAHtlLkPuguNIfjk8yqusGeRaj/g/w2T+Q7
cLJAExzhVZWyw41J/uY6s38LLb53c5aDnLfyAc2s4G2fsDbNEdNLJa8jLxgxDDIseM1GOf43
v8bfb8EuoV5wHzDSNkRyfjecs0TNOoP77GWoFosB8jJICMW4hfwD7quD9BC9axa/2T0zSyKL
9ujJl0COaQncZQAAAAAAAA==
--------------ms090805030703070701080904--


From nobody Thu Sep 20 02:39:53 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72CF130E98 for ; Thu, 20 Sep 2018 02:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level: 
X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 vL2ZZFa5ZaIt for ; Thu, 20 Sep 2018 02:39:37 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0E3130E8D for ; Thu, 20 Sep 2018 02:39:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537436371; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Azb9OR0mey9/XFhldolcmViUC1r7TXX2tj5E/JGzmTQ=; b=OG5Mr/HNXVGg1cR7bvr1DmzZ/X9pqzoDas1HDC6BWLYx6OokNTKtEWGDjDzRpYRV BPHvn++/SG7qaXGZjV2w53VOR+ofpH8Z1tJ0W9BcnGA0nos1PxnsrxTyIi6/noNh L+jXgC9x3ghTxzYLX2mWkivyvm0zBV/jXYYAvAQ/e4g=;
X-AuditID: c1b4fb30-3cd869c0000055da-d4-5ba36ad3a0e7
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E8.90.21978.3DA63AB5; Thu, 20 Sep 2018 11:39:31 +0200 (CEST)
Received: from [100.94.33.105] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 20 Sep 2018 11:39:29 +0200
To: Fabio Maino , 
CC: , , 
References: <153553422964.14784.628403975182959075@ietfa.amsl.com> 
From: Magnus Westerlund 
Message-ID: <5dd519c0-6810-8596-37e9-377e38175a7d@ericsson.com>
Date: Thu, 20 Sep 2018 11:39:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080906050305060108070809"
X-Originating-IP: [153.88.183.153]
X-ClientProxiedBy: ESESSMB502.ericsson.se (153.88.183.163) To ESESSMB502.ericsson.se (153.88.183.163)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUyM2J7he7lrMXRBmunyVm0ft3HaHFhxz9G i2cb57NYTDmrbjFrzyIWB1aPKb83snosWfKTKYApissmJTUnsyy1SN8ugStjx6x9zAVv/zNW rPh7hr2B8cwFxi5GTg4JAROJf/veMHUxcnEICRxllHh8dBszhPOeUaJ70XdWkCphATuJr20t zCC2iICZxN27S9lBbGYBD4mJr1cAxTmAGkolJjaUgYTZBCwkbv5oZAOxeQXsJQ7v2wnWyiKg KnHu8F02kHJRgWiJT/8zIUoEJU7OfMICYnMK2Eq8erWPEeQEZoFuRomuC+fBThAS0JZoaOpg hThaSeL6vOssEHa6xOUVe9gnMArOQjJrFrL+WWCnhkl83DudDcIWl7j1ZD4ThG0mMW/zQ2YI W1ti2cLXQDYHkK0msaxVCVUYxLaWmPHrINQYRYkp3Q/ZIWxTiddHPzJC2MYSy9b9ZVvAyLOK UbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzBOD275bbCD8eVzx0OMAhyMSjy8Sr6Lo4VYE8uK K3MPMaoAzXm0YfUFRimWvPy8VCUR3v+JQGnelMTKqtSi/Pii0pzU4kOM0hwsSuK8Fn6bo4QE 0hNLUrNTUwtSi2CyTBycUg2MAbcuFGhYXWw14Am+KKduntvdxKrpcMUnolXr+NRHYSHFm63W vbG/mcX8SfHbj6tLxR/uyzR1XP1DoJnZ6eukM92sq1cvE+zbYtETdKZcRidb77ijz+rJAna/ dee8OfLcYVOpls6riLWtyn/Px7y/GSG7WXhzTDB7b2FHQvVczQ63NbnSjqlKLMUZiYZazEXF iQBUdMjc2wIAAA==
Archived-At: 
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Sep 2018 09:39:44 -0000

--------------ms080906050305060108070809
Content-Type: multipart/alternative;
 boundary="------------C2D1AE5F161528FB1838BD3E"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------C2D1AE5F161528FB1838BD3E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Fabio,

Most of the below text is excellent. Some comments inline for needed=20
clarifications and additions.

On 9/18/2018 9:52 PM, Fabio Maino wrote:
> Hi Magnus,
> thanks for your comments.
>
> I think I see the points you are making.
>
> I'll add the section 3.1 below to specify the general transport=20
> requirements for the registration of new LISP-GPE payloads, and I will =

> introduce two subsections to instantiate those requirements for=20
> Ethernet and NSH (section 4.2 and 4.3 will be moved here). In the=20
> "IANA Considerations" section I'll refer to this new section 3.1 as a=20
> requirement for registration of new encapsulated payload.
>
> "3.1 Payload Specific Transport Interactions
>
> To ensure that protocols that are encapsulated in LISP-GPE will work=20
> well from a transport interaction perspective, the specification of a=20
> new encapsulated payload MUST contain an analysis of how LISP-GPE=20
> SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit=20
> Congestion Notification (ECN) bits whenever they apply to the new=20
> encapsulated payload.
>
> For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] specifies =

> how to handle UDP Checksums encouraging implementors to consider UDP=20
> checksum usage guidelines in section 3.4 of [RFC8085] when it is=20
> desirable to protect UDP and LISP headers against corruption. Each new =

> encapsulated payloads, when registered with LISP-GPE, MUST be=20
> accompanied by a similar analysis.
>
> Encapsulated payloads may have a priority field that may or may not be =

> mapped to the DSCP field of the outer IP header (part of Type of=20
> Service in IPv4 or Traffic Class in IPv6). Such new encapsulated=20
> payloads, when registered with LISP-GPE, MUST be accompanied by an=20
> analysis similar to the one performed in Section 3.1.1 of this=20
> document for Ethernet payloads.
>
> Encapsulated payloads may have Explicit Congestion Notification=20
> mechanisms that may or may not be mapped to the outer IP header ECN=20
> field. Such new encapsulated payolads, when registered with LISP-GPE,=20
> MUST=C2=A0 be accompanied by a set of guidelines derived from=20
> [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].
>
> The rest of this section specifies payload specific transport=20
> interactions considerations for the two new LISP-GPE encapsulated=20
> payloads specified in this document: Ethernet and NSH.
>
> 3.1.1 Payload Specific Transport Interactions for Ethernet=20
> Encapsulated Payloads
>
> The UDP Checksum considerations specified in section 5.3 of=20
> [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads.=20
> Implementors are encouraged to consider the UDP checksum usage=20
> guidelines in section 3.4 of [RFC8085] when it is desirable to protect =

> UDP, LISP and Ethernet headers against corruption.

So this is not the necessary documentation of the analysis that=20
IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use.=20
There needs to be an analysis here to verify that this protocol=20
combination do work. You will actually have to discuss how the Ethernet=20
encapsulation fulfills the requirements listed in Section 4 of RFC 6936.

https://datatracker.ietf.org/doc/rfc7510/ is an example where such an=20
analysis was included. I would also note the applicability limitations=20
this has.

Which actually brings up an additional issue for Ethernet encapsulation. =

For IP the assumption is that the IP traffic that is encapsulated is=20
congestion controlled. This assumption is even less certain when having=20
Ethernet. Thus, some consideration of that issue is likely needed.


>
> When a LISP-GPE router performs Ethernet encapsulation, the inner=20
> 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be=20
> mapped from the encapsulated frame to the Type of Service field in the =

> outer IPv4 header, or in the case of IPv6 the 'Traffic Class' field as =

> per guidelines provided by [RFC8325].

I don't know enough about IEEE and the various versions of Ethernet and=20
WLAN here to be certain that 802.1Q PCP's can be mapped directly to the=20
802.11 User Priorities discussed in RFC8325. Please investigate if they=20
are the same, and if they are the same priorities, then make a explicit=20
statement that they are applicable.

>
> When a LISP-GPE router performs Ethernet encapsulation, the inner=20
> header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or=20
> used to determine the LISP Instance ID field.
>
> 3.1.2 Payload Specific Transport Interactions for NSH Encapsulated=20
> Payloads
>
> The UDP Checksum considerations specified in section 5.3 of=20
> [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads.=20
> Implementors are encouraged to consider the UDP checksum usage=20
> guidelines in section 3.4 of [RFC8085] when it is desirable to protect =

> UDP, LISP, and NSH headers against corruption.

Same as for Ethernet also the NSH header needs to have a documented=20
analsysis of fulfillment of the requirements.


>
> When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN=20
> values MAY be mapped as specified for the Next Protocol encapsulated=20
> by NSH (namely IPv4, IPv6 and Ethernet)."
>
>
> I will also add a paragraph to "Iana Considerations" that says:
>
>
> "To ensure that protocols that are encapsulated in LISP-GPE will work=20
> well from a transport interaction perspective, the registration of a=20
> new encapsulated payload MUST contain an analysis of how LISP-GPE=20
> SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit=20
> Congestion Notification (ECN) bits whenever they apply to the new=20
> encapsulated payload. The analysis for the new encapsulated payload=20
> registered in this document is in section 3.1."
>
> Please, let me know if this address your comments.
>
> Thanks,
> Fabio
>
>
>
> On 8/29/18 2:17 AM, Magnus Westerlund wrote:
>> Reviewer: Magnus Westerlund
>> Review result: Not Ready
>>
>> This document has been reviewed as part of the transport area director=
ate's
>> ongoing effort to review key IETF documents. These comments were writt=
en
>> primarily for the transport area directors, but are copied to the docu=
ment's
>> authors and WG for their information and to allow them to address any =
issues
>> raised.
>>
>> When done at the time of IETF Last Call, the authors should consider t=
his
>> review together with any other last-call comments they receive.
>> Please always CCtsv-art@ietf.org  if you reply to or forward this revi=
ew.
>>
>> Issue A.
>>
>> The reason I state Not Ready has to do with this documents failure to =
consider
>> the use of zero checksum for IPv6 when tunneling other things than IP.=
 The none
>> GPE version is limited to tunnel IP for which the analysis for use of =
zero
>> checksum has been done. Each of the new tunneled protocols that are sp=
ecified
>> in this document, i.e. ethernet and NHS, will need to perform the anal=
ysis if
>> they are safe to use zero checksum or not, and if not disallow zero ch=
ecksum
>> for IPv6/UDP. The documetn also need a requirement in the registration=

>> requirements to perform this analysis and defined if zero checksum is
>> acceptable or not.
>>
>> Citing Section 5.3 of draft-ietf-lisp-rfc6830bis
>>
>>     UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as z=
ero
>>        by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
>>        [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is=

>>        received by an ETR, the ETR MUST accept the packet for
>>        decapsulation.  When an ITR transmits a non-zero value for the =
UDP
>>        checksum, it MUST send a correctly computed value in this field=
=2E
>>        When an ETR receives a packet with a non-zero UDP checksum, it =
MAY
>>        choose to verify the checksum value.  If it chooses to perform
>>        such verification, and the verification fails, the packet MUST =
be
>>        silently dropped.  If the ETR chooses not to perform the
>>        verification, or performs the verification successfully, the
>>        packet MUST be accepted for decapsulation.  The handling of UDP=

>>        zero checksums over IPv6 for all tunneling protocols, including=

>>        LISP, is subject to the applicability statement in [RFC6936].
>>
>> The issue is that when LISP encapsulate other protocols the impact of =
a
>> missdelivered tunnel packet to the wrong ETR can have different impact=
s. As
>> well as errors in the headers of the encapsulated packet that may be a=
ssumed to
>> be protected by the encapsulating layer. Thus, individual analysis of =
each
>> protocol that are tunneled are needed.
>>
>> B.) 4.2.  Type of Service
>>
>>     When a LISP-GPE router performs Ethernet encapsulation, the inner
>>     802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be
>>     mapped from the encapsulated frame to the Type of Service field in=

>>     the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'
>>     field.
>>
>> Any recommendation about how to perform that mapping? Maybe parts of
>> https://datatracker.ietf.org/doc/rfc8325/  are relevant in this contex=
t.
>>
>> C. General case of 4.2:
>>
>> I expect other protocols than Ethernet may have a priority field that =
may or
>> may not be mapped to the DSCP field of the tunnel packet.
>>
>> I would expect that for new protocol registration in the LISP-GPE Next=
 Protocol
>> Registry should consider this. Thus, it would be good to note that suc=
h
>> considerations are needed and part of what should be evaluated for new=

>> registrations.
>>
>> D. ECN handling
>>
>> Section 5.3 of draft-ietf-lisp-rfc6830bis states:
>>
>>     o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and =
7
>>        of the IPv6 'Traffic Class' field) requires special treatment i=
n
>>        order to avoid discarding indications of congestion [RFC3168].
>>        ITR encapsulation MUST copy the 2-bit 'ECN' field from the inne=
r
>>        header to the outer header.  Re-encapsulation MUST copy the 2-b=
it
>>        'ECN' field from the stripped outer header to the new outer
>>        header.
>>
>> The above rules may not be applicable for all transport protocols. Thu=
s I think
>> it is required that one do protocol specific considerations of ECN. TS=
VWG are
>> working on recommendations for tunnels handling of  ECN here, see:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines=
/  Thus,
>> my expectation would be to ensure that the registered protocols have d=
efined
>> ECN handling, explicitly or by reference. Secondly that registration
>> requirement states the need for this consideration.
>>
>> Summary: To ensure that future added protocols that are encapsulated w=
ill work
>> well from a transport interaction perspective there need to be a requi=
rement on
>> new registration to consider and define how they use zero checksum, an=
y DSCP
>> mapping and ECN bits. In addition the current document needs to ensure=
 these
>> things are clearly specified for the encapsulated protocols in this do=
cument.
>>
>>
>
--=20

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--------------C2D1AE5F161528FB1838BD3E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Fabio,

    
Most of the below text is excellent. Some comments inline for
      needed clarifications and additions.=C2=A0

    
On 9/18/2018 9:52 PM, Fabio Maino
      wrote:

    

    

      
      
Hi Magnus, 

        thanks for your comments. 

        

        I think I see the points you are making. 

        

        I'll add the section 3.1 below to specify the general transport
        requirements for the registration of new LISP-GPE payloads, and
        I will introduce two subsections to instantiate those
        requirements for Ethernet and NSH (section 4.2 and 4.3 will be
        moved here). In the "IANA Considerations" section I'll refer to
        this new section 3.1 as a requirement for registration of new
        encapsulated payload. 

        

        "3.1 Payload Specific Transport Interactions

        

        To ensure that protocols that are encapsulated in LISP-GPE will
        work well from a transport interaction perspective, the
        specification of a new encapsulated payload MUST contain an
        analysis of how LISP-GPE SHOULD deal with outer UDP Checksum,
        DSCP mapping, and Explicit Congestion Notification (ECN) bits
        whenever they apply to the new encapsulated payload.

        

        For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis]
        specifies how to handle UDP Checksums encouraging implementors
        to consider UDP checksum usage guidelines in section 3.4 of
        [RFC8085] when it is desirable to protect UDP and LISP headers
        against corruption. Each new encapsulated payloads, when
        registered with LISP-GPE, MUST be accompanied by a similar
        analysis.

        

        Encapsulated payloads may have a priority field that may or may
        not be mapped to the DSCP field of the outer IP header (part of
        Type of Service in IPv4 or Traffic Class in IPv6). Such new
        encapsulated payloads, when registered with LISP-GPE, MUST be
        accompanied by an analysis similar to the one performed in
        Section 3.1.1 of this document for Ethernet payloads. 

        

        Encapsulated payloads may have Explicit Congestion Notification
        mechanisms that may or may not be mapped to the outer IP header
        ECN field. Such new encapsulated payolads, when registered with
        LISP-GPE, MUST=C2=A0 be accompanied by a set of guidelines derive=
d
        from [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. 

        

        The rest of this section specifies payload specific transport
        interactions considerations for the two new LISP-GPE
        encapsulated payloads specified in this document: Ethernet and
        NSH. 

        

        3.1.1 Payload Specific Transport Interactions for Ethernet
        Encapsulated Payloads

        

        The UDP Checksum considerations specified in section 5.3 of
        [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated
        Payloads. Implementors are encouraged to consider the UDP
        checksum usage guidelines in section 3.4 of [RFC8085] when it is
        desirable to protect UDP, LISP and Ethernet headers against
        corruption.

      

    

    
So this is not the necessary documentation of the analysis that
      IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to
      use. There needs to be an analysis here to verify that this
      protocol combination do work. You will actually have to discuss
      how the Ethernet encapsulation fulfills the requirements listed in
      Section 4 of RFC 6936.=C2=A0 

    

    
https://datatracker.ietf.org/doc/rfc7510/ is an e=
xample where
      such an analysis was included. I would also note the applicability
      limitations this has. 

    

    
Which actually brings up an additional issue for Ethernet
      encapsulation. For IP the assumption is that the IP traffic that
      is encapsulated is congestion controlled. This assumption is even
      less certain when having Ethernet. Thus, some consideration of
      that issue is likely needed. 

    

    


    

    

      
 

        When a LISP-GPE router performs Ethernet encapsulation, the
        inner 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field
        MAY be mapped from the encapsulated frame to the Type of Service
        field in the outer IPv4 header, or in the case of IPv6 the
        'Traffic Class' field as per guidelines provided by [RFC8325].
      

    

    
I don't know enough about IEEE and the various versions of
      Ethernet and WLAN here to be certain that 802.1Q PCP's can be
      mapped directly to the 802.11 User Priorities discussed in
      RFC8325. Please investigate if they are the same, and if they are
      the same priorities, then make a explicit statement that they are
      applicable. 

    

    

      
 

        When a LISP-GPE router performs Ethernet encapsulation, the
        inner header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be
        mapped to, or used to determine the LISP Instance ID field.

        

        3.1.2 Payload Specific Transport Interactions for NSH
        Encapsulated Payloads 

        

        The UDP Checksum considerations specified in section 5.3 of
        [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads.
        Implementors are encouraged to consider the UDP checksum usage
        guidelines in section 3.4 of [RFC8085] when it is desirable to
        protect UDP, LISP, and NSH headers against corruption.

      

    

    
Same as for Ethernet also the NSH header needs to have a
      documented analsysis of fulfillment of the requirements.

    


    

    

      
 

        When a LISP-GPE router performs an NSH encapsulation, DSCP and
        ECN values MAY be mapped as specified for the Next Protocol
        encapsulated by NSH (namely IPv4, IPv6 and Ethernet)."=C2=A0 
=

        

        

        I will also add a paragraph to "Iana Considerations" that says:
        

        

        

        "To ensure that protocols that are encapsulated in LISP-GPE will
        work well from a transport interaction perspective, the
        registration of a new encapsulated payload MUST contain an
        analysis of how LISP-GPE SHOULD deal with outer UDP Checksum,
        DSCP mapping, and Explicit Congestion Notification (ECN) bits
        whenever they apply to the new encapsulated payload. The
        analysis for the new encapsulated payload registered in this
        document is in section 3.1."

        

        Please, let me know if this address your comments. 

        

        Thanks,

        Fabio

        

        

        

        On 8/29/18 2:17 AM, Magnus Westerlund wrote:

      

      

        
Reviewer: Magnus Westerlund
Review result: Not Ready

This document has been reviewed as part of the transport area directorate=
's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the documen=
t's
authors and WG for their information and to allow them to address any iss=
ues
raised.

When done at the time of IETF Last Call, the authors should consider this=

review together with any other last-call comments they receive.
Please always CC tsv-art@ietf.org if you reply=
 to or forward this review.

Issue A.

The reason I state Not Ready has to do with this documents failure to con=
sider
the use of zero checksum for IPv6 when tunneling other things than IP. Th=
e none
GPE version is limited to tunnel IP for which the analysis for use of zer=
o
checksum has been done. Each of the new tunneled protocols that are speci=
fied
in this document, i.e. ethernet and NHS, will need to perform the analysi=
s if
they are safe to use zero checksum or not, and if not disallow zero check=
sum
for IPv6/UDP. The documetn also need a requirement in the registration
requirements to perform this analysis and defined if zero checksum is
acceptable or not.

Citing Section 5.3 of draft-ietf-lisp-rfc6830bis

   UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as zero
      by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
      [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is
      received by an ETR, the ETR MUST accept the packet for
      decapsulation.  When an ITR transmits a non-zero value for the UDP
      checksum, it MUST send a correctly computed value in this field.
      When an ETR receives a packet with a non-zero UDP checksum, it MAY
      choose to verify the checksum value.  If it chooses to perform
      such verification, and the verification fails, the packet MUST be
      silently dropped.  If the ETR chooses not to perform the
      verification, or performs the verification successfully, the
      packet MUST be accepted for decapsulation.  The handling of UDP
      zero checksums over IPv6 for all tunneling protocols, including
      LISP, is subject to the applicability statement in [RFC6936].

The issue is that when LISP encapsulate other protocols the impact of a
missdelivered tunnel packet to the wrong ETR can have different impacts. =
As
well as errors in the headers of the encapsulated packet that may be assu=
med to
be protected by the encapsulating layer. Thus, individual analysis of eac=
h
protocol that are tunneled are needed.

B.) 4.2.  Type of Service

   When a LISP-GPE router performs Ethernet encapsulation, the inner
   802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be
   mapped from the encapsulated frame to the Type of Service field in
   the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'
   field.

Any recommendation about how to perform that mapping? Maybe parts of
https://datatracker.ietf.org/doc/rf=
c8325/ are relevant in this context.

C. General case of 4.2:

I expect other protocols than Ethernet may have a priority field that may=
 or
may not be mapped to the DSCP field of the tunnel packet.

I would expect that for new protocol registration in the LISP-GPE Next Pr=
otocol
Registry should consider this. Thus, it would be good to note that such
considerations are needed and part of what should be evaluated for new
registrations.

D. ECN handling

Section 5.3 of draft-ietf-lisp-rfc6830bis states:

   o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion [RFC3168].
      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
      header to the outer header.  Re-encapsulation MUST copy the 2-bit
      'ECN' field from the stripped outer header to the new outer
      header.

The above rules may not be applicable for all transport protocols. Thus I=
 think
it is required that one do protocol specific considerations of ECN. TSVWG=
 are
working on recommendations for tunnels handling of  ECN here, see:=20
https=
://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ Th=
us,
my expectation would be to ensure that the registered protocols have defi=
ned
ECN handling, explicitly or by reference. Secondly that registration
requirement states the need for this consideration.

Summary: To ensure that future added protocols that are encapsulated will=
 work
well from a transport interaction perspective there need to be a requirem=
ent on
new registration to consider and define how they use zero checksum, any D=
SCP
mapping and ECN bits. In addition the current document needs to ensure th=
ese
things are clearly specified for the encapsulated protocols in this docum=
ent.




      

      


      

    

    
--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------C2D1AE5F161528FB1838BD3E--

--------------ms080906050305060108070809
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DNEwggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNV
BAoMCEVyaWNzc29uMRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJ
ARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+
laqg5eXTqonqnzT9ykEGL2dx9mBT+2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJ
HGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iV
IiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpigGFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36o
gzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkrbdmdnjKGrYSnJigmxw14pJugxL/Vb2Ee
VcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov
L2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYI
KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t
MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29u
bmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJp
Y3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0
dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD
VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3
DQEBCwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4Q
ihhoQR3cvhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXD
yF9mhWYbSAkJyx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6
H3zO3nsq++KBmsOiSKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvE
lup5n7l864FqxnC2friDo4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl
60rmc8SJlt6QXKw0wXEOE1MubauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwD
ig3SZi1qP7D/Ds4V+JLIjjUJc25l9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8K
v7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLCQaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3
UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Zla71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzY
VBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd//n4YbY2QhDCCBsIwggSqoAMCAQICEFO4
foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx
HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUx
MDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM
HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw
ggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfS
Tm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbX
ILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfp
VdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2
PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2
H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4
rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX
1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjv
Zibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FN
VSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsG
AQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEu
Y29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j
b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE
TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnku
dHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3Js
LTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud
JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7
GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G
CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDU
JQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHG
vw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYn
nl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwf
ixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ8
5AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4Hd
Dc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOE
EHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd
3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/du
jp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEB
MFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMA0GCWCGSAFlAwQCAQUA
oIIBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODA5MjAw
OTM5MjlaMC8GCSqGSIb3DQEJBDEiBCA7+W3IMfHzLGNDuhi4VDezTKrQOmuffc2zVv5vAsi+
bjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjEl
MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBlrrZreXF5
7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMGwGCyqGSIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nz
b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62
a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAIN4MPNzrbsrt8i4nPzkOWKrdNpz1Ahoy8KKwaRXx
/ZdzdiJNmTkSbZ5BzllRucYUD9+5ixPiGUI3+0fSHVFnfWU/CHjJWxJYc5nYSybXShzkdY0O
LtRfi6vSTYE5uEzk6j8+ZVkI1CLio42DaIgC4SRq0b7MdlSot03aYdIGTdwWoyS1RsxyFfht
S184mIRygQuU4Vygopi9CVPxdOWrdP5QbApZ+XHsIchRPryl+e//rAMloorTsXJmLtFN5Y15
m0QBIgezou4qQUqIKd3r6CmGBo5L2FAwdYof9ClDshz+0c/hcC/2XY9tosau1rP4Alcy1g/u
03tZxk/x5pwnXwAAAAAAAA==
--------------ms080906050305060108070809--


From nobody Thu Sep 20 03:51:26 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E011B130E74 for ; Thu, 20 Sep 2018 03:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 Dx9PNH_BwQv4 for ; Thu, 20 Sep 2018 03:51:23 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89AF9127133 for ; Thu, 20 Sep 2018 03:51:22 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=Jy3lQdQkmfJq2iwfDfKeWCSOoFh3Syq6T8L6sIZ45DGXt1JzrxCNqEP1Pfb6vHkRqqBLqA0SR6CNPI/xVNzgWxdCsC9B1ZHl+KMxKkoAJrIVc9X+eKNfvkN8JgZXg1w8N2SqR3Fp7nt9jLsBJVugJlS7VbWRY8gD6uc7ded/zSw=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 18261 invoked from network); 20 Sep 2018 12:51:20 +0200
Received: from mue-88-130-61-247.dsl.tropolys.de (HELO ?192.168.178.24?) (88.130.61.247) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Sep 2018 12:51:20 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: 
Date: Thu, 20 Sep 2018 12:51:18 +0200
Cc: Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org, The IESG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net>
References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net>  <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com>  
To: Dino Farinacci 
X-Mailer: Apple Mail (2.3445.9.1)
X-PPP-Message-ID: <20180920105120.18252.23156@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
Subject: Re: [lisp]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Sep 2018 10:51:25 -0000

Hi Dino,

it=E2=80=99s fine with me to leave the details to rfc6040 but then also =
the details in the current text should be removed (because giving only =
half the details really doesn=E2=80=99t seem right).

However, I totally disagree with your comment on providing details that =
are not implemented. If they are not implemented correctly, it might =
even be more important to spell them out in this document, so =
implementors have chance to update their (future) implementation to do =
the correct thing. Having deployed implementations that are non =
standard-conform always happens and in this case it is probably not =
specifically problematic as it doesn=E2=80=99t impact interoperability. =
However, it is important though that the spec is correct.

Mirja


> Am 18.09.2018 um 18:56 schrieb Dino Farinacci :
>=20
> As I already said, this text is too detailed and repeats what is in =
other RFCs. And since implementations do what they already do, adding =
more details that are not implemented, IMO, is not good form.
>=20
> Dino
>=20
>> On Sep 18, 2018, at 3:32 AM, Mirja Kuehlewind (IETF) =
 wrote:
>>=20
>> Hi Dino,
>>=20
>> please see below.
>>=20
>>> Am 17.09.2018 um 19:48 schrieb Dino Farinacci :
>>>=20
>>>> PROPOSED
>>>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>>>>   of the IPv6 'Traffic Class' field) [RFC3168] requires special =
treatment in
>>>>   order to preserve the use of ECN on the path.
>>>>   ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
>>>>   header to the outer header, inline with the =E2=80=99Normal =
Mode=E2=80=99 in section 4.1=20
>>>>   of [RFC6040].  Re-encapsulation SHOULD follow the decapsulation =
as described=20
>>>>   below and then 2-bit 'ECN' field from the stripped inner header =
to the=20
>>>>   new outer header.=E2=80=9C
>>>=20
>>> I did not include this text because the last sentence is not formed =
well. Please restate. A verb is missing.
>>=20
>> copy
>>=20
>>>=20
>>>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>>>>   of the IPv6 'Traffic Class' field) requires special treatment on=20=

>>>>   decapsulation in
>>>>   order to avoid discarding indications of congestion,=20
>>>>   inline with section 4.2 of [RFC6040]. If
>>>>   the 'ECN=E2=80=98 field of the outer header contains a congestion =
indication =09
>>>>   codepoint (the
>>>>   value is '11', the Congestion Experienced (CE) codepoint) and the =
inner=20
>>>>   header indicates ECN support (either ECT(0) or ECT(1) codepoint =
is set),=20
>>>>   then ETR decapsulation MUST also set CE field in the inner header =
that is=20
>>>>   used
>>>>   to forward the packet beyond the ETR. If the inner packet is =
marked as non-
>>>>   ECT but the outer header has the CE mark set, the packet MUST be =
dropped=20
>>>>   instead. Any discrepancy between the inner and outer header for =
non-ECT,=20
>>>>   ECT(0) and ECT(1) MUST NOT be copied from the outer header. These=20=

>>>>   requirements preserve
>>>>   CE indications when a packet that is ECN-capable traverses a LISP =
tunnel
>>>>   and becomes marked with a CE indication due to congestion between
>>>>   the tunnel endpoints or transforms an CE into loss if that packet =
is not=20
>>>>   ECN-capable conserving the congestion indication towards a =
non-ECN enables=20
>>>>   endpoint.=E2=80=9D
>>>=20
>>> I didn=E2=80=99t include this text because (1) it under states what =
to do with IPv4, (2) it has too much detail that is already in RFC6040, =
and (3) it undoes text that other reviewers have offered.
>>=20
>> I didn=E2=80=99t change the mentioning of IPv6 here. Yes please at =
IPv4.
>>=20
>> You can remove all this text and only point to rfc6040. That would =
actually my preferred solution. I don=E2=80=99t think it =E2=80=9Eundoes=E2=
=80=9C text; it just adds what was missing in compliance with RFC6040. =
Anyway it doesn=E2=80=99t matter point being that it should specify the =
same things as RFC6040 does not matter what other have ofter because =
RFC6040 is the IETF-consensus doc how describing how to handle this.
>>=20
>>>=20
>>>=20
>>>> Please also remove the duplicated text after these bullet lists in =
the draft!
>>>=20
>>> You have to tell me what text. I am too confused at this point on =
what you want.
>>=20
>> This is the text in the en-/ and decapsulation lists:
>>=20
>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>>     of the IPv6 'Traffic Class' field) requires special treatment in
>>     order to avoid discarding indications of congestion [RFC3168].
>>     ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
>>     header to the outer header.  Re-encapsulation MUST copy the 2-bit
>>     'ECN' field from the stripped outer header to the new outer
>>     header."
>>=20
>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>>     of the IPv6 'Traffic Class' field) requires special treatment in
>>     order to avoid discarding indications of congestion [RFC6040].  =
If
>>     the 'ECN' field contains a congestion indication codepoint (the
>>     value is '11', the Congestion Experienced (CE) codepoint), then
>>     ETR decapsulation MUST copy the 2-bit 'ECN' field from the
>>     stripped outer header to the surviving inner header that is used
>>     to forward the packet beyond the ETR.  These requirements =
preserve
>>     CE indications when a packet that uses ECN traverses a LISP =
tunnel
>>     and becomes marked with a CE indication due to congestion between
>>     the tunnel endpoints."
>>=20
>> And this text comes up right after the list in the same section:
>>=20
>> "The Explicit Congestion Notification ('ECN') field occupies bits 6
>>  and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic
>>  Class' field [RFC6040].  The 'ECN' field requires special treatment
>>  in order to avoid discarding indications of congestion [RFC6040].  =
An
>>  ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the =
inner
>>  header to the outer header.  Re-encapsulation MUST copy the 2-bit
>>  'ECN' field from the stripped outer header to the new outer header.
>>  If the 'ECN' field contains a congestion indication codepoint (the
>>  value is '11', the Congestion Experienced (CE) codepoint), then ETR/
>>  PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped
>>  outer header to the surviving inner header that is used to forward
>>  the packet beyond the ETR.  These requirements preserve CE
>>  indications when a packet that uses ECN traverses a LISP tunnel and
>>  becomes marked with a CE indication due to congestion between the
>>  tunnel endpoints."
>>=20
>> The last text bit does not add any information; it just states all =
normative requirement twice, even using basically exactly the some =
words. This can lead to discrepancies and it really not necessary. I=E2=80=
=99d recommend to just remove the last text block here (and fix the =
IPv6/IPv4 issue in the other blocks).
>>=20
>> Mirja
>>=20
>>=20
>>>=20
>>>> Further I believe my discuss points 2) and 4) are not fully =
resolved yet. Also I would like to at least see more explanation about =
the approach for extensibility that was taken in this doc (point 6).
>>>=20
>>> You are going to have to repeat what they are because too many =
emails have flown by since your initial post. And for extensibility, we =
discuss it in RFC8060 and don=E2=80=99t think anything more should be =
said here otherwise, we will duplicate unnecessary text.
>>>=20
>>> Another new diff file enclosed.
>>>=20
>>> Dino
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>=20


From nobody Thu Sep 20 06:16:04 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A275B130F1D; Thu, 20 Sep 2018 06:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.601
X-Spam-Level: 
X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 4wmzpkmRI8dj; Thu, 20 Sep 2018 06:15:41 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36802130F32; Thu, 20 Sep 2018 06:15:41 -0700 (PDT)
Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w8KDF3F4011103; Thu, 20 Sep 2018 09:15:34 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2mm9hgmkf7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Sep 2018 09:15:33 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8KDFVd0002953; Thu, 20 Sep 2018 09:15:32 -0400
Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [135.66.87.38]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8KDFPoY002798; Thu, 20 Sep 2018 09:15:25 -0400
Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [127.0.0.1]) by zlp27130.vci.att.com (Service) with ESMTP id F395440F6CEF; Thu, 20 Sep 2018 13:15:24 +0000 (GMT)
Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (unknown [130.9.129.149]) by zlp27130.vci.att.com (Service) with ESMTPS id CA03E40F6CEE; Thu, 20 Sep 2018 13:15:24 +0000 (GMT)
Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.5]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0415.000; Thu, 20 Sep 2018 09:15:24 -0400
From: "BRUNGARD, DEBORAH A" 
To: Magnus Westerlund , Fabio Maino , "tsv-art@ietf.org" 
CC: "lisp@ietf.org" , "ietf@ietf.org" , "draft-ietf-lisp-gpe.all@ietf.org" 
Thread-Topic: Tsvart last call review of draft-ietf-lisp-gpe-05
Thread-Index: AQHUP3kdKafKjKdpRUWhrwqxilH4EaT21n4AgAFiGGCAAP9gAIAAByIg
Date: Thu, 20 Sep 2018 13:15:23 +0000
Message-ID: 
References: <153553422964.14784.628403975182959075@ietfa.amsl.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.199.184]
Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C88841C523MISOUT7MSGUSRDE_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-20_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809200135
Archived-At: 
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Sep 2018 13:15:55 -0000

--_000_F64C10EAA68C8044B33656FA214632C88841C523MISOUT7MSGUSRDE_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgTWFnbnVzLA0KDQpJbnRlcmVzdGluZyDigJMgSSBoYXZlbuKAmXQgc2VlbiBpdCBpbiBSb3V0
aW5nIEFyZWEgZG9jdW1lbnRzIOKAkyB0aGUgKHRlY2huaWNhbCkgYWR2aWNlIGlzIGdpdmVuIGlu
IHRoZSBhcHBsaWNhYmxlIHNlY3Rpb25zIG9mIHRoZSBSRkMgaXRzZWxmLiBEbyB5b3UgaGF2ZSBl
eGFtcGxlcyBmcm9tIHRoZSBUcmFuc3BvcnQgQXJlYT8NCg0KQWx3YXlzIG9wZW4gdG8gZGlzY3Vz
c2lvbiDigJMgbGV04oCZcyB0YWtlIHRvIGEgc21hbGxlciBsaXN0IGFtb25nIHRoZSB3b3JraW5n
IGdyb3VwIGNoYWlycyBhbmQgSUFOQSDigJMgYW5kIHRoZW4gY2FuIGdldCBiYWNrIHRvIHRoZSBs
YXJnZXIgbGlzdC4gSSB3b3VsZCAoaG9wZWZ1bGx5KSBzYXkgd2hlbiB0aGUgd29ya2luZyBncm91
cCBjaG9vc2VzIHRvIHVwZGF0ZSAob3IgdGhlIFJGQ+KAmXMgZXhwZXJ0IHJldmlld2VyKSB0aGUg
cmVnaXN0cnksIHRoZXkgZm9sbG93IHRoZWlyIFJGQywgbm90IGp1c3QgdGhlIElBTkEgc2VjdGlv
bi4gTm90IHRvIGp1bXAgb24gcHJvY2VzcyB0byByYXRpb25hbGl6ZSDigJMgUkZDODEyNiBpcyBx
dWl0ZSBjbGVhciB0byBrZWVwIElBTkEgY29uc2lkZXJhdGlvbnMgZm9yIElBTkEuIElmIG90aGVy
cyBmZWVsIHRoZSBzYW1lLCBjYW4gYWx3YXlzIHVwZGF0ZSB0byBjbGFyaWZ5LiBMZXTigJlzIHRh
bGsgbW9yZS4NCg0KVGhhbmtzLA0KRGVib3JhaA0KDQoNCkZyb206IE1hZ251cyBXZXN0ZXJsdW5k
IDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQpTZW50OiBUaHVyc2RheSwgU2VwdGVt
YmVyIDIwLCAyMDE4IDQ6MTQgQU0NClRvOiBCUlVOR0FSRCwgREVCT1JBSCBBIDxkYjM1NDZAYXR0
LmNvbT47IEZhYmlvIE1haW5vIDxmbWFpbm9AY2lzY28uY29tPjsgdHN2LWFydEBpZXRmLm9yZw0K
Q2M6IGxpc3BAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbGlzcC1ncGUuYWxs
QGlldGYub3JnDQpTdWJqZWN0OiBSZTogVHN2YXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQt
aWV0Zi1saXNwLWdwZS0wNQ0KDQoNCkhpLA0KT24gOS8xOS8yMDE4IDExOjE3IFBNLCBCUlVOR0FS
RCwgREVCT1JBSCBBIHdyb3RlOg0KVGhhbmtzIE1hZ251cyBmb3IgeW91ciBjYXJlZnVsIHJldmll
dyENCg0KRmFiaW8sIG9uIHlvdXIgc3VnZ2VzdGVkIHRleHQgYmVsb3csIGl0IGlzIG5vdCBuZWVk
ZWQgdG8gZHVwbGljYXRlIHRoaXMgaW4gdGhlIElBTkEgc2VjdGlvbi4gVGhlIElBTkEgc2VjdGlv
biBwcm92aWRlcyBndWlkZWxpbmVzIG9uIGFzc2lnbm1lbnQgZm9yIElBTkEsIG5vdCB0byBmdXR1
cmUgYXV0aG9ycyAtIGl0IHdvdWxkIG5vdCBiZSBmb3IgSUFOQSB0byBlbnN1cmUgcmVxdWVzdHMg
Zm9yIHJlZ2lzdHJhdGlvbiBwcm92aWRlIHRoZSBwcm9wZXIgYW5hbHlzaXMuDQoNCg0KDQpEZWJv
cmFoIEkgYW0gZGlzYWdyZWVpbmcgYWJvdXQgdGhpcy4gVGhlIElBTkEgc2VjdGlvbiBtYXkgY29u
dGFpbiByZXF1aXJlbWVudHMgb24gdGhlIHJlZ2lzdHJhdGlvbiB0aGF0IGZ1cnRoZXIgZW50cmll
cyBhcmUgcmVxdWlyZWQgdG8gZnVsZmlsbC4gVGhpcyBiZWNvbWVzIGVzcGVjaWFsbHkgaW1wb3J0
YW50IGluIGV4cGVydCByZXZpZXcgcmVnaXN0cmllcy4gQW5kIGluIHRoaXMgY2FzZSBhcyBhIFN0
YW5kYXJkcyBBY3Rpb24gcmVnaXN0cnksIG1ha2luZyBleHBsaWNpdCB0aGUgZXhwZWN0YXRpb25z
IG9uIG5ldyByZWdpc3RyaWVzIGZyb20gdGhlIGNyZWF0b3JzIG9mIHRoZSByZWdpc3RyaWVzIGFy
ZSB2ZXJ5IGFwcHJvcHJpYXRlLiBJdCBoZWxwcyBlbnN1cmUgdGhhdCBmdXR1cmUgZXh0ZW5zaW9u
cyBkbyB0aGluayBhYm91dCBpbXBvcnRhbnQgdGhpbmdzLg0KDQpTbyBJIHdvdWxkIHJlYWxseSBs
aWtlIHRvIHNlZSB0aGUgdGV4dCBzdGF5IGluLg0KDQpDaGVlcnMNCg0KTWFnbnVzDQoNCg0KDQpU
aGFua3MsDQpEZWJvcmFoDQoNCg0KRnJvbTogRmFiaW8gTWFpbm8gPGZtYWlub0BjaXNjby5jb20+
PG1haWx0bzpmbWFpbm9AY2lzY28uY29tPg0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDE4LCAy
MDE4IDM6NTMgUE0NClRvOiBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rlcmx1bmRAZXJp
Y3Nzb24uY29tPjxtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPjsgdHN2LWFy
dEBpZXRmLm9yZzxtYWlsdG86dHN2LWFydEBpZXRmLm9yZz4NCkNjOiBsaXNwQGlldGYub3JnPG1h
aWx0bzpsaXNwQGlldGYub3JnPjsgaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz47
IGRyYWZ0LWlldGYtbGlzcC1ncGUuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWxpc3At
Z3BlLmFsbEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBUc3ZhcnQgbGFzdCBjYWxsIHJldmlldyBv
ZiBkcmFmdC1pZXRmLWxpc3AtZ3BlLTA1DQoNCkhpIE1hZ251cywNCnRoYW5rcyBmb3IgeW91ciBj
b21tZW50cy4NCg0KSSB0aGluayBJIHNlZSB0aGUgcG9pbnRzIHlvdSBhcmUgbWFraW5nLg0KDQpJ
J2xsIGFkZCB0aGUgc2VjdGlvbiAzLjEgYmVsb3cgdG8gc3BlY2lmeSB0aGUgZ2VuZXJhbCB0cmFu
c3BvcnQgcmVxdWlyZW1lbnRzIGZvciB0aGUgcmVnaXN0cmF0aW9uIG9mIG5ldyBMSVNQLUdQRSBw
YXlsb2FkcywgYW5kIEkgd2lsbCBpbnRyb2R1Y2UgdHdvIHN1YnNlY3Rpb25zIHRvIGluc3RhbnRp
YXRlIHRob3NlIHJlcXVpcmVtZW50cyBmb3IgRXRoZXJuZXQgYW5kIE5TSCAoc2VjdGlvbiA0LjIg
YW5kIDQuMyB3aWxsIGJlIG1vdmVkIGhlcmUpLiBJbiB0aGUgIklBTkEgQ29uc2lkZXJhdGlvbnMi
IHNlY3Rpb24gSSdsbCByZWZlciB0byB0aGlzIG5ldyBzZWN0aW9uIDMuMSBhcyBhIHJlcXVpcmVt
ZW50IGZvciByZWdpc3RyYXRpb24gb2YgbmV3IGVuY2Fwc3VsYXRlZCBwYXlsb2FkLg0KDQoiMy4x
IFBheWxvYWQgU3BlY2lmaWMgVHJhbnNwb3J0IEludGVyYWN0aW9ucw0KDQpUbyBlbnN1cmUgdGhh
dCBwcm90b2NvbHMgdGhhdCBhcmUgZW5jYXBzdWxhdGVkIGluIExJU1AtR1BFIHdpbGwgd29yayB3
ZWxsIGZyb20gYSB0cmFuc3BvcnQgaW50ZXJhY3Rpb24gcGVyc3BlY3RpdmUsIHRoZSBzcGVjaWZp
Y2F0aW9uIG9mIGEgbmV3IGVuY2Fwc3VsYXRlZCBwYXlsb2FkIE1VU1QgY29udGFpbiBhbiBhbmFs
eXNpcyBvZiBob3cgTElTUC1HUEUgU0hPVUxEIGRlYWwgd2l0aCBvdXRlciBVRFAgQ2hlY2tzdW0s
IERTQ1AgbWFwcGluZywgYW5kIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04p
IGJpdHMgd2hlbmV2ZXIgdGhleSBhcHBseSB0byB0aGUgbmV3IGVuY2Fwc3VsYXRlZCBwYXlsb2Fk
Lg0KDQpGb3IgSVAgcGF5bG9hZHMsIHNlY3Rpb24gNS4zIG9mIFtkcmFmdC1pZXRmLWxpc3AtcmZj
NjgzMGJpc10gc3BlY2lmaWVzIGhvdyB0byBoYW5kbGUgVURQIENoZWNrc3VtcyBlbmNvdXJhZ2lu
ZyBpbXBsZW1lbnRvcnMgdG8gY29uc2lkZXIgVURQIGNoZWNrc3VtIHVzYWdlIGd1aWRlbGluZXMg
aW4gc2VjdGlvbiAzLjQgb2YgW1JGQzgwODVdIHdoZW4gaXQgaXMgZGVzaXJhYmxlIHRvIHByb3Rl
Y3QgVURQIGFuZCBMSVNQIGhlYWRlcnMgYWdhaW5zdCBjb3JydXB0aW9uLiBFYWNoIG5ldyBlbmNh
cHN1bGF0ZWQgcGF5bG9hZHMsIHdoZW4gcmVnaXN0ZXJlZCB3aXRoIExJU1AtR1BFLCBNVVNUIGJl
IGFjY29tcGFuaWVkIGJ5IGEgc2ltaWxhciBhbmFseXNpcy4NCg0KRW5jYXBzdWxhdGVkIHBheWxv
YWRzIG1heSBoYXZlIGEgcHJpb3JpdHkgZmllbGQgdGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBtYXBw
ZWQgdG8gdGhlIERTQ1AgZmllbGQgb2YgdGhlIG91dGVyIElQIGhlYWRlciAocGFydCBvZiBUeXBl
IG9mIFNlcnZpY2UgaW4gSVB2NCBvciBUcmFmZmljIENsYXNzIGluIElQdjYpLiBTdWNoIG5ldyBl
bmNhcHN1bGF0ZWQgcGF5bG9hZHMsIHdoZW4gcmVnaXN0ZXJlZCB3aXRoIExJU1AtR1BFLCBNVVNU
IGJlIGFjY29tcGFuaWVkIGJ5IGFuIGFuYWx5c2lzIHNpbWlsYXIgdG8gdGhlIG9uZSBwZXJmb3Jt
ZWQgaW4gU2VjdGlvbiAzLjEuMSBvZiB0aGlzIGRvY3VtZW50IGZvciBFdGhlcm5ldCBwYXlsb2Fk
cy4NCg0KRW5jYXBzdWxhdGVkIHBheWxvYWRzIG1heSBoYXZlIEV4cGxpY2l0IENvbmdlc3Rpb24g
Tm90aWZpY2F0aW9uIG1lY2hhbmlzbXMgdGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBtYXBwZWQgdG8g
dGhlIG91dGVyIElQIGhlYWRlciBFQ04gZmllbGQuIFN1Y2ggbmV3IGVuY2Fwc3VsYXRlZCBwYXlv
bGFkcywgd2hlbiByZWdpc3RlcmVkIHdpdGggTElTUC1HUEUsIE1VU1QgIGJlIGFjY29tcGFuaWVk
IGJ5IGEgc2V0IG9mIGd1aWRlbGluZXMgZGVyaXZlZCBmcm9tIFtkcmFmdC1pZXRmLXRzdndnLWVj
bi1lbmNhcC1ndWlkZWxpbmVzXSBhbmQgW1JGQzYwNDBdLg0KDQpUaGUgcmVzdCBvZiB0aGlzIHNl
Y3Rpb24gc3BlY2lmaWVzIHBheWxvYWQgc3BlY2lmaWMgdHJhbnNwb3J0IGludGVyYWN0aW9ucyBj
b25zaWRlcmF0aW9ucyBmb3IgdGhlIHR3byBuZXcgTElTUC1HUEUgZW5jYXBzdWxhdGVkIHBheWxv
YWRzIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50OiBFdGhlcm5ldCBhbmQgTlNILg0KDQozLjEu
MSBQYXlsb2FkIFNwZWNpZmljIFRyYW5zcG9ydCBJbnRlcmFjdGlvbnMgZm9yIEV0aGVybmV0IEVu
Y2Fwc3VsYXRlZCBQYXlsb2Fkcw0KDQpUaGUgVURQIENoZWNrc3VtIGNvbnNpZGVyYXRpb25zIHNw
ZWNpZmllZCBpbiBzZWN0aW9uIDUuMyBvZiBbZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBiaXNdIGFw
cGx5IHRvIEV0aGVybmV0IEVuY2Fwc3VsYXRlZCBQYXlsb2Fkcy4gSW1wbGVtZW50b3JzIGFyZSBl
bmNvdXJhZ2VkIHRvIGNvbnNpZGVyIHRoZSBVRFAgY2hlY2tzdW0gdXNhZ2UgZ3VpZGVsaW5lcyBp
biBzZWN0aW9uIDMuNCBvZiBbUkZDODA4NV0gd2hlbiBpdCBpcyBkZXNpcmFibGUgdG8gcHJvdGVj
dCBVRFAsIExJU1AgYW5kIEV0aGVybmV0IGhlYWRlcnMgYWdhaW5zdCBjb3JydXB0aW9uLg0KDQpX
aGVuIGEgTElTUC1HUEUgcm91dGVyIHBlcmZvcm1zIEV0aGVybmV0IGVuY2Fwc3VsYXRpb24sIHRo
ZSBpbm5lciA4MDIuMVEgW0lFRUUuODAyLjFRXzIwMTRdIHByaW9yaXR5IGNvZGUgcG9pbnQgKFBD
UCkgZmllbGQgTUFZIGJlIG1hcHBlZCBmcm9tIHRoZSBlbmNhcHN1bGF0ZWQgZnJhbWUgdG8gdGhl
IFR5cGUgb2YgU2VydmljZSBmaWVsZCBpbiB0aGUgb3V0ZXIgSVB2NCBoZWFkZXIsIG9yIGluIHRo
ZSBjYXNlIG9mIElQdjYgdGhlICdUcmFmZmljIENsYXNzJyBmaWVsZCBhcyBwZXIgZ3VpZGVsaW5l
cyBwcm92aWRlZCBieSBbUkZDODMyNV0uDQoNCldoZW4gYSBMSVNQLUdQRSByb3V0ZXIgcGVyZm9y
bXMgRXRoZXJuZXQgZW5jYXBzdWxhdGlvbiwgdGhlIGlubmVyIGhlYWRlciA4MDIuMVEgW0lFRUU4
MDIxUV0gVkxBTiBJZGVudGlmaWVyIChWSUQpIE1BWSBiZSBtYXBwZWQgdG8sIG9yIHVzZWQgdG8g
ZGV0ZXJtaW5lIHRoZSBMSVNQIEluc3RhbmNlIElEIGZpZWxkLg0KDQozLjEuMiBQYXlsb2FkIFNw
ZWNpZmljIFRyYW5zcG9ydCBJbnRlcmFjdGlvbnMgZm9yIE5TSCBFbmNhcHN1bGF0ZWQgUGF5bG9h
ZHMNCg0KVGhlIFVEUCBDaGVja3N1bSBjb25zaWRlcmF0aW9ucyBzcGVjaWZpZWQgaW4gc2VjdGlv
biA1LjMgb2YgW2RyYWZ0LWlldGYtbGlzcC1yZmM2ODMwYmlzXSBhcHBseSB0byBOU0ggRW5jYXBz
dWxhdGVkIFBheWxvYWRzLiBJbXBsZW1lbnRvcnMgYXJlIGVuY291cmFnZWQgdG8gY29uc2lkZXIg
dGhlIFVEUCBjaGVja3N1bSB1c2FnZSBndWlkZWxpbmVzIGluIHNlY3Rpb24gMy40IG9mIFtSRkM4
MDg1XSB3aGVuIGl0IGlzIGRlc2lyYWJsZSB0byBwcm90ZWN0IFVEUCwgTElTUCwgYW5kIE5TSCBo
ZWFkZXJzIGFnYWluc3QgY29ycnVwdGlvbi4NCg0KV2hlbiBhIExJU1AtR1BFIHJvdXRlciBwZXJm
b3JtcyBhbiBOU0ggZW5jYXBzdWxhdGlvbiwgRFNDUCBhbmQgRUNOIHZhbHVlcyBNQVkgYmUgbWFw
cGVkIGFzIHNwZWNpZmllZCBmb3IgdGhlIE5leHQgUHJvdG9jb2wgZW5jYXBzdWxhdGVkIGJ5IE5T
SCAobmFtZWx5IElQdjQsIElQdjYgYW5kIEV0aGVybmV0KS4iDQoNCg0KSSB3aWxsIGFsc28gYWRk
IGEgcGFyYWdyYXBoIHRvICJJYW5hIENvbnNpZGVyYXRpb25zIiB0aGF0IHNheXM6DQoNCg0KIlRv
IGVuc3VyZSB0aGF0IHByb3RvY29scyB0aGF0IGFyZSBlbmNhcHN1bGF0ZWQgaW4gTElTUC1HUEUg
d2lsbCB3b3JrIHdlbGwgZnJvbSBhIHRyYW5zcG9ydCBpbnRlcmFjdGlvbiBwZXJzcGVjdGl2ZSwg
dGhlIHJlZ2lzdHJhdGlvbiBvZiBhIG5ldyBlbmNhcHN1bGF0ZWQgcGF5bG9hZCBNVVNUIGNvbnRh
aW4gYW4gYW5hbHlzaXMgb2YgaG93IExJU1AtR1BFIFNIT1VMRCBkZWFsIHdpdGggb3V0ZXIgVURQ
IENoZWNrc3VtLCBEU0NQIG1hcHBpbmcsIGFuZCBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNh
dGlvbiAoRUNOKSBiaXRzIHdoZW5ldmVyIHRoZXkgYXBwbHkgdG8gdGhlIG5ldyBlbmNhcHN1bGF0
ZWQgcGF5bG9hZC4gVGhlIGFuYWx5c2lzIGZvciB0aGUgbmV3IGVuY2Fwc3VsYXRlZCBwYXlsb2Fk
IHJlZ2lzdGVyZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBpbiBzZWN0aW9uIDMuMS4iDQoNClBsZWFz
ZSwgbGV0IG1lIGtub3cgaWYgdGhpcyBhZGRyZXNzIHlvdXIgY29tbWVudHMuDQoNClRoYW5rcywN
CkZhYmlvDQoNCg0KDQpPbiA4LzI5LzE4IDI6MTcgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIHdyb3Rl
Og0KDQpSZXZpZXdlcjogTWFnbnVzIFdlc3Rlcmx1bmQNCg0KUmV2aWV3IHJlc3VsdDogTm90IFJl
YWR5DQoNCg0KDQpUaGlzIGRvY3VtZW50IGhhcyBiZWVuIHJldmlld2VkIGFzIHBhcnQgb2YgdGhl
IHRyYW5zcG9ydCBhcmVhIGRpcmVjdG9yYXRlJ3MNCg0Kb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3
IGtleSBJRVRGIGRvY3VtZW50cy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuDQoNCnByaW1h
cmlseSBmb3IgdGhlIHRyYW5zcG9ydCBhcmVhIGRpcmVjdG9ycywgYnV0IGFyZSBjb3BpZWQgdG8g
dGhlIGRvY3VtZW50J3MNCg0KYXV0aG9ycyBhbmQgV0cgZm9yIHRoZWlyIGluZm9ybWF0aW9uIGFu
ZCB0byBhbGxvdyB0aGVtIHRvIGFkZHJlc3MgYW55IGlzc3Vlcw0KDQpyYWlzZWQuDQoNCg0KDQpX
aGVuIGRvbmUgYXQgdGhlIHRpbWUgb2YgSUVURiBMYXN0IENhbGwsIHRoZSBhdXRob3JzIHNob3Vs
ZCBjb25zaWRlciB0aGlzDQoNCnJldmlldyB0b2dldGhlciB3aXRoIGFueSBvdGhlciBsYXN0LWNh
bGwgY29tbWVudHMgdGhleSByZWNlaXZlLg0KDQpQbGVhc2UgYWx3YXlzIENDIHRzdi1hcnRAaWV0
Zi5vcmc8bWFpbHRvOnRzdi1hcnRAaWV0Zi5vcmc+IGlmIHlvdSByZXBseSB0byBvciBmb3J3YXJk
IHRoaXMgcmV2aWV3Lg0KDQoNCg0KSXNzdWUgQS4NCg0KDQoNClRoZSByZWFzb24gSSBzdGF0ZSBO
b3QgUmVhZHkgaGFzIHRvIGRvIHdpdGggdGhpcyBkb2N1bWVudHMgZmFpbHVyZSB0byBjb25zaWRl
cg0KDQp0aGUgdXNlIG9mIHplcm8gY2hlY2tzdW0gZm9yIElQdjYgd2hlbiB0dW5uZWxpbmcgb3Ro
ZXIgdGhpbmdzIHRoYW4gSVAuIFRoZSBub25lDQoNCkdQRSB2ZXJzaW9uIGlzIGxpbWl0ZWQgdG8g
dHVubmVsIElQIGZvciB3aGljaCB0aGUgYW5hbHlzaXMgZm9yIHVzZSBvZiB6ZXJvDQoNCmNoZWNr
c3VtIGhhcyBiZWVuIGRvbmUuIEVhY2ggb2YgdGhlIG5ldyB0dW5uZWxlZCBwcm90b2NvbHMgdGhh
dCBhcmUgc3BlY2lmaWVkDQoNCmluIHRoaXMgZG9jdW1lbnQsIGkuZS4gZXRoZXJuZXQgYW5kIE5I
Uywgd2lsbCBuZWVkIHRvIHBlcmZvcm0gdGhlIGFuYWx5c2lzIGlmDQoNCnRoZXkgYXJlIHNhZmUg
dG8gdXNlIHplcm8gY2hlY2tzdW0gb3Igbm90LCBhbmQgaWYgbm90IGRpc2FsbG93IHplcm8gY2hl
Y2tzdW0NCg0KZm9yIElQdjYvVURQLiBUaGUgZG9jdW1ldG4gYWxzbyBuZWVkIGEgcmVxdWlyZW1l
bnQgaW4gdGhlIHJlZ2lzdHJhdGlvbg0KDQpyZXF1aXJlbWVudHMgdG8gcGVyZm9ybSB0aGlzIGFu
YWx5c2lzIGFuZCBkZWZpbmVkIGlmIHplcm8gY2hlY2tzdW0gaXMNCg0KYWNjZXB0YWJsZSBvciBu
b3QuDQoNCg0KDQpDaXRpbmcgU2VjdGlvbiA1LjMgb2YgZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBi
aXMNCg0KDQoNCiAgIFVEUCBDaGVja3N1bTogIFRoZSAnVURQIENoZWNrc3VtJyBmaWVsZCBTSE9V
TEQgYmUgdHJhbnNtaXR0ZWQgYXMgemVybw0KDQogICAgICBieSBhbiBJVFIgZm9yIGVpdGhlciBJ
UHY0IFtSRkMwNzY4XSBhbmQgSVB2NiBlbmNhcHN1bGF0aW9uDQoNCiAgICAgIFtSRkM2OTM1XSBb
UkZDNjkzNl0uICBXaGVuIGEgcGFja2V0IHdpdGggYSB6ZXJvIFVEUCBjaGVja3N1bSBpcw0KDQog
ICAgICByZWNlaXZlZCBieSBhbiBFVFIsIHRoZSBFVFIgTVVTVCBhY2NlcHQgdGhlIHBhY2tldCBm
b3INCg0KICAgICAgZGVjYXBzdWxhdGlvbi4gIFdoZW4gYW4gSVRSIHRyYW5zbWl0cyBhIG5vbi16
ZXJvIHZhbHVlIGZvciB0aGUgVURQDQoNCiAgICAgIGNoZWNrc3VtLCBpdCBNVVNUIHNlbmQgYSBj
b3JyZWN0bHkgY29tcHV0ZWQgdmFsdWUgaW4gdGhpcyBmaWVsZC4NCg0KICAgICAgV2hlbiBhbiBF
VFIgcmVjZWl2ZXMgYSBwYWNrZXQgd2l0aCBhIG5vbi16ZXJvIFVEUCBjaGVja3N1bSwgaXQgTUFZ
DQoNCiAgICAgIGNob29zZSB0byB2ZXJpZnkgdGhlIGNoZWNrc3VtIHZhbHVlLiAgSWYgaXQgY2hv
b3NlcyB0byBwZXJmb3JtDQoNCiAgICAgIHN1Y2ggdmVyaWZpY2F0aW9uLCBhbmQgdGhlIHZlcmlm
aWNhdGlvbiBmYWlscywgdGhlIHBhY2tldCBNVVNUIGJlDQoNCiAgICAgIHNpbGVudGx5IGRyb3Bw
ZWQuICBJZiB0aGUgRVRSIGNob29zZXMgbm90IHRvIHBlcmZvcm0gdGhlDQoNCiAgICAgIHZlcmlm
aWNhdGlvbiwgb3IgcGVyZm9ybXMgdGhlIHZlcmlmaWNhdGlvbiBzdWNjZXNzZnVsbHksIHRoZQ0K
DQogICAgICBwYWNrZXQgTVVTVCBiZSBhY2NlcHRlZCBmb3IgZGVjYXBzdWxhdGlvbi4gIFRoZSBo
YW5kbGluZyBvZiBVRFANCg0KICAgICAgemVybyBjaGVja3N1bXMgb3ZlciBJUHY2IGZvciBhbGwg
dHVubmVsaW5nIHByb3RvY29scywgaW5jbHVkaW5nDQoNCiAgICAgIExJU1AsIGlzIHN1YmplY3Qg
dG8gdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGluIFtSRkM2OTM2XS4NCg0KDQoNClRoZSBp
c3N1ZSBpcyB0aGF0IHdoZW4gTElTUCBlbmNhcHN1bGF0ZSBvdGhlciBwcm90b2NvbHMgdGhlIGlt
cGFjdCBvZiBhDQoNCm1pc3NkZWxpdmVyZWQgdHVubmVsIHBhY2tldCB0byB0aGUgd3JvbmcgRVRS
IGNhbiBoYXZlIGRpZmZlcmVudCBpbXBhY3RzLiBBcw0KDQp3ZWxsIGFzIGVycm9ycyBpbiB0aGUg
aGVhZGVycyBvZiB0aGUgZW5jYXBzdWxhdGVkIHBhY2tldCB0aGF0IG1heSBiZSBhc3N1bWVkIHRv
DQoNCmJlIHByb3RlY3RlZCBieSB0aGUgZW5jYXBzdWxhdGluZyBsYXllci4gVGh1cywgaW5kaXZp
ZHVhbCBhbmFseXNpcyBvZiBlYWNoDQoNCnByb3RvY29sIHRoYXQgYXJlIHR1bm5lbGVkIGFyZSBu
ZWVkZWQuDQoNCg0KDQpCLikgNC4yLiAgVHlwZSBvZiBTZXJ2aWNlDQoNCg0KDQogICBXaGVuIGEg
TElTUC1HUEUgcm91dGVyIHBlcmZvcm1zIEV0aGVybmV0IGVuY2Fwc3VsYXRpb24sIHRoZSBpbm5l
cg0KDQogICA4MDIuMVEgW0lFRUUuODAyLjFRXzIwMTRdIHByaW9yaXR5IGNvZGUgcG9pbnQgKFBD
UCkgZmllbGQgTUFZIGJlDQoNCiAgIG1hcHBlZCBmcm9tIHRoZSBlbmNhcHN1bGF0ZWQgZnJhbWUg
dG8gdGhlIFR5cGUgb2YgU2VydmljZSBmaWVsZCBpbg0KDQogICB0aGUgb3V0ZXIgSVB2NCBoZWFk
ZXIsIG9yIGluIHRoZSBjYXNlIG9mIElQdjYgdGhlICdUcmFmZmljIENsYXNzJw0KDQogICBmaWVs
ZC4NCg0KDQoNCkFueSByZWNvbW1lbmRhdGlvbiBhYm91dCBob3cgdG8gcGVyZm9ybSB0aGF0IG1h
cHBpbmc/IE1heWJlIHBhcnRzIG9mDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L3JmYzgzMjUvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw
cy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX3JmYzgzMjVfJmQ9RHdNRGFRJmM9TEZZWi1v
OV9IVU1lTVRTUWljdmpJZyZyPTZVaEdwVzlsd2k5ZE03allseFhEOHcmbT14aHYtdmlwVHd0V3dn
NUFjUXRNclpDclFBMUpBZllYTUFnR1dxYmpqNEF3JnM9OGdpZHBySVVDZmhhZEZkV2k3eGxXRDBi
UHNiM2RQZGZDdzlRZjhrZHdUSSZlPT4gYXJlIHJlbGV2YW50IGluIHRoaXMgY29udGV4dC4NCg0K
DQoNCkMuIEdlbmVyYWwgY2FzZSBvZiA0LjI6DQoNCg0KDQpJIGV4cGVjdCBvdGhlciBwcm90b2Nv
bHMgdGhhbiBFdGhlcm5ldCBtYXkgaGF2ZSBhIHByaW9yaXR5IGZpZWxkIHRoYXQgbWF5IG9yDQoN
Cm1heSBub3QgYmUgbWFwcGVkIHRvIHRoZSBEU0NQIGZpZWxkIG9mIHRoZSB0dW5uZWwgcGFja2V0
Lg0KDQoNCg0KSSB3b3VsZCBleHBlY3QgdGhhdCBmb3IgbmV3IHByb3RvY29sIHJlZ2lzdHJhdGlv
biBpbiB0aGUgTElTUC1HUEUgTmV4dCBQcm90b2NvbA0KDQpSZWdpc3RyeSBzaG91bGQgY29uc2lk
ZXIgdGhpcy4gVGh1cywgaXQgd291bGQgYmUgZ29vZCB0byBub3RlIHRoYXQgc3VjaA0KDQpjb25z
aWRlcmF0aW9ucyBhcmUgbmVlZGVkIGFuZCBwYXJ0IG9mIHdoYXQgc2hvdWxkIGJlIGV2YWx1YXRl
ZCBmb3IgbmV3DQoNCnJlZ2lzdHJhdGlvbnMuDQoNCg0KDQpELiBFQ04gaGFuZGxpbmcNCg0KDQoN
ClNlY3Rpb24gNS4zIG9mIGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMwYmlzIHN0YXRlczoNCg0KDQoN
CiAgIG8gIFRoZSAnRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24nIChFQ04pIGZpZWxk
IChiaXRzIDYgYW5kIDcNCg0KICAgICAgb2YgdGhlIElQdjYgJ1RyYWZmaWMgQ2xhc3MnIGZpZWxk
KSByZXF1aXJlcyBzcGVjaWFsIHRyZWF0bWVudCBpbg0KDQogICAgICBvcmRlciB0byBhdm9pZCBk
aXNjYXJkaW5nIGluZGljYXRpb25zIG9mIGNvbmdlc3Rpb24gW1JGQzMxNjhdLg0KDQogICAgICBJ
VFIgZW5jYXBzdWxhdGlvbiBNVVNUIGNvcHkgdGhlIDItYml0ICdFQ04nIGZpZWxkIGZyb20gdGhl
IGlubmVyDQoNCiAgICAgIGhlYWRlciB0byB0aGUgb3V0ZXIgaGVhZGVyLiAgUmUtZW5jYXBzdWxh
dGlvbiBNVVNUIGNvcHkgdGhlIDItYml0DQoNCiAgICAgICdFQ04nIGZpZWxkIGZyb20gdGhlIHN0
cmlwcGVkIG91dGVyIGhlYWRlciB0byB0aGUgbmV3IG91dGVyDQoNCiAgICAgIGhlYWRlci4NCg0K
DQoNClRoZSBhYm92ZSBydWxlcyBtYXkgbm90IGJlIGFwcGxpY2FibGUgZm9yIGFsbCB0cmFuc3Bv
cnQgcHJvdG9jb2xzLiBUaHVzIEkgdGhpbmsNCg0KaXQgaXMgcmVxdWlyZWQgdGhhdCBvbmUgZG8g
cHJvdG9jb2wgc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMgb2YgRUNOLiBUU1ZXRyBhcmUNCg0Kd29y
a2luZyBvbiByZWNvbW1lbmRhdGlvbnMgZm9yIHR1bm5lbHMgaGFuZGxpbmcgb2YgIEVDTiBoZXJl
LCBzZWU6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2
d2ctZWNuLWVuY2FwLWd1aWRlbGluZXMvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv
bS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0
Zi0yRHRzdndnLTJEZWNuLTJEZW5jYXAtMkRndWlkZWxpbmVzXyZkPUR3TURhUSZjPUxGWVotbzlf
SFVNZU1UU1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3Jm09eGh2LXZpcFR3dFd3ZzVB
Y1F0TXJaQ3JRQTFKQWZZWE1BZ0dXcWJqajRBdyZzPWV5TzRjN0QzU2hOUWhhYThvVkRxQ2lkSGJF
cDNtVzdBa001MWR1djhRdzQmZT0+IFRodXMsDQoNCm15IGV4cGVjdGF0aW9uIHdvdWxkIGJlIHRv
IGVuc3VyZSB0aGF0IHRoZSByZWdpc3RlcmVkIHByb3RvY29scyBoYXZlIGRlZmluZWQNCg0KRUNO
IGhhbmRsaW5nLCBleHBsaWNpdGx5IG9yIGJ5IHJlZmVyZW5jZS4gU2Vjb25kbHkgdGhhdCByZWdp
c3RyYXRpb24NCg0KcmVxdWlyZW1lbnQgc3RhdGVzIHRoZSBuZWVkIGZvciB0aGlzIGNvbnNpZGVy
YXRpb24uDQoNCg0KDQpTdW1tYXJ5OiBUbyBlbnN1cmUgdGhhdCBmdXR1cmUgYWRkZWQgcHJvdG9j
b2xzIHRoYXQgYXJlIGVuY2Fwc3VsYXRlZCB3aWxsIHdvcmsNCg0Kd2VsbCBmcm9tIGEgdHJhbnNw
b3J0IGludGVyYWN0aW9uIHBlcnNwZWN0aXZlIHRoZXJlIG5lZWQgdG8gYmUgYSByZXF1aXJlbWVu
dCBvbg0KDQpuZXcgcmVnaXN0cmF0aW9uIHRvIGNvbnNpZGVyIGFuZCBkZWZpbmUgaG93IHRoZXkg
dXNlIHplcm8gY2hlY2tzdW0sIGFueSBEU0NQDQoNCm1hcHBpbmcgYW5kIEVDTiBiaXRzLiBJbiBh
ZGRpdGlvbiB0aGUgY3VycmVudCBkb2N1bWVudCBuZWVkcyB0byBlbnN1cmUgdGhlc2UNCg0KdGhp
bmdzIGFyZSBjbGVhcmx5IHNwZWNpZmllZCBmb3IgdGhlIGVuY2Fwc3VsYXRlZCBwcm90b2NvbHMg
aW4gdGhpcyBkb2N1bWVudC4NCg0KDQoNCg0KDQoNCg0KLS0NCg0KDQoNCk1hZ251cyBXZXN0ZXJs
dW5kDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk5ldHdvcmsgQXJjaGl0ZWN0dXJlICYgUHJvdG9j
b2xzLCBFcmljc3NvbiBSZXNlYXJjaA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkVyaWNzc29uIEFCICAg
ICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KDQpUb3JzaGFtbnNnYXRhbiAy
MyAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNCg0KU0UtMTY0IDgwIFN0b2NraG9s
bSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208bWFpbHRv
Om1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K

--_000_F64C10EAA68C8044B33656FA214632C88841C523MISOUT7MSGUSRDE_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj
b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww
DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7
bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt
aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s
b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt
b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu
NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg
Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs
YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8
L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y
PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj
bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj
b2xvcjp3aW5kb3d0ZXh0Ij5IaSBNYWdudXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjp3aW5kb3d0ZXh0Ij5JbnRlcmVzdGluZyDigJMgSSBoYXZlbuKAmXQgc2VlbiBpdCBpbiBSb3V0
aW5nIEFyZWEgZG9jdW1lbnRzIOKAkyB0aGUgKHRlY2huaWNhbCkgYWR2aWNlIGlzIGdpdmVuIGlu
IHRoZSBhcHBsaWNhYmxlIHNlY3Rpb25zIG9mIHRoZSBSRkMgaXRzZWxmLiBEbyB5b3UgaGF2ZSBl
eGFtcGxlcyBmcm9tIHRoZSBUcmFuc3BvcnQgQXJlYT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImNvbG9yOndpbmRvd3RleHQiPkFsd2F5cyBvcGVuIHRvIGRpc2N1c3Npb24g4oCTIGxldOKAmXMg
dGFrZSB0byBhIHNtYWxsZXIgbGlzdCBhbW9uZyB0aGUgd29ya2luZyBncm91cCBjaGFpcnMgYW5k
IElBTkEg4oCTIGFuZCB0aGVuIGNhbiBnZXQgYmFjayB0byB0aGUgbGFyZ2VyIGxpc3QuIEkgd291
bGQgKGhvcGVmdWxseSkgc2F5IHdoZW4gdGhlIHdvcmtpbmcgZ3JvdXAgY2hvb3NlcyB0byB1cGRh
dGUNCiAob3IgdGhlIFJGQ+KAmXMgZXhwZXJ0IHJldmlld2VyKSB0aGUgcmVnaXN0cnksIHRoZXkg
Zm9sbG93IHRoZWlyIFJGQywgbm90IGp1c3QgdGhlIElBTkEgc2VjdGlvbi4gTm90IHRvIGp1bXAg
b24gcHJvY2VzcyB0byByYXRpb25hbGl6ZSDigJMgUkZDODEyNiBpcyBxdWl0ZSBjbGVhciB0byBr
ZWVwIElBTkEgY29uc2lkZXJhdGlvbnMgZm9yIElBTkEuIElmIG90aGVycyBmZWVsIHRoZSBzYW1l
LCBjYW4gYWx3YXlzIHVwZGF0ZSB0byBjbGFyaWZ5LiBMZXTigJlzDQogdGFsayBtb3JlLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+VGhhbmtzLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k
b3d0ZXh0Ij5EZWJvcmFoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp
biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv
d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IE1h
Z251cyBXZXN0ZXJsdW5kICZsdDttYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20mZ3Q7DQo8
YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIFNlcHRlbWJlciAyMCwgMjAxOCA0OjE0IEFNPGJy
Pg0KPGI+VG86PC9iPiBCUlVOR0FSRCwgREVCT1JBSCBBICZsdDtkYjM1NDZAYXR0LmNvbSZndDs7
IEZhYmlvIE1haW5vICZsdDtmbWFpbm9AY2lzY28uY29tJmd0OzsgdHN2LWFydEBpZXRmLm9yZzxi
cj4NCjxiPkNjOjwvYj4gbGlzcEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1s
aXNwLWdwZS5hbGxAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFRzdmFydCBsYXN0
IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1ncGUtMDU8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cD5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiA5LzE5LzIwMTggMTE6MTcgUE0sIEJSVU5HQVJELCBERUJPUkFIIEEgd3JvdGU6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOndpbmRvd3RleHQiPlRoYW5rcyBNYWdudXMgZm9yIHlvdXIgY2FyZWZ1bCByZXZpZXchPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5GYWJpbywgb24geW91ciBz
dWdnZXN0ZWQgdGV4dCBiZWxvdywgaXQgaXMgbm90IG5lZWRlZCB0byBkdXBsaWNhdGUgdGhpcyBp
biB0aGUgSUFOQSBzZWN0aW9uLiBUaGUgSUFOQSBzZWN0aW9uIHByb3ZpZGVzIGd1aWRlbGluZXMg
b24gYXNzaWdubWVudCBmb3IgSUFOQSwgbm90IHRvIGZ1dHVyZSBhdXRob3JzIC0gaXQgd291bGQg
bm90IGJlIGZvciBJQU5BIHRvDQogZW5zdXJlIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24gcHJv
dmlkZSB0aGUgcHJvcGVyIGFuYWx5c2lzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx
dW90ZT4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+RGVib3JhaCBJIGFtIGRpc2FncmVl
aW5nIGFib3V0IHRoaXMuIFRoZSBJQU5BIHNlY3Rpb24gbWF5IGNvbnRhaW4gcmVxdWlyZW1lbnRz
IG9uIHRoZSByZWdpc3RyYXRpb24gdGhhdCBmdXJ0aGVyIGVudHJpZXMgYXJlIHJlcXVpcmVkIHRv
IGZ1bGZpbGwuIFRoaXMgYmVjb21lcyBlc3BlY2lhbGx5IGltcG9ydGFudCBpbiBleHBlcnQgcmV2
aWV3IHJlZ2lzdHJpZXMuIEFuZCBpbiB0aGlzIGNhc2UgYXMgYSBTdGFuZGFyZHMgQWN0aW9uIHJl
Z2lzdHJ5LA0KIG1ha2luZyBleHBsaWNpdCB0aGUgZXhwZWN0YXRpb25zIG9uIG5ldyByZWdpc3Ry
aWVzIGZyb20gdGhlIGNyZWF0b3JzIG9mIHRoZSByZWdpc3RyaWVzIGFyZSB2ZXJ5IGFwcHJvcHJp
YXRlLiBJdCBoZWxwcyBlbnN1cmUgdGhhdCBmdXR1cmUgZXh0ZW5zaW9ucyBkbyB0aGluayBhYm91
dCBpbXBvcnRhbnQgdGhpbmdzLg0KPG86cD48L286cD48L3A+DQo8cD5TbyBJIHdvdWxkIHJlYWxs
eSBsaWtlIHRvIHNlZSB0aGUgdGV4dCBzdGF5IGluLiA8bzpwPjwvbzpwPjwvcD4NCjxwPkNoZWVy
czxvOnA+PC9vOnA+PC9wPg0KPHA+TWFnbnVzPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndp
bmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5UaGFua3MsPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl
eHQiPkRlYm9yYWg8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp
biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4
dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gRmFiaW8g
TWFpbm8NCjxhIGhyZWY9Im1haWx0bzpmbWFpbm9AY2lzY28uY29tIj4mbHQ7Zm1haW5vQGNpc2Nv
LmNvbSZndDs8L2E+IDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTgsIDIw
MTggMzo1MyBQTTxicj4NCjxiPlRvOjwvYj4gTWFnbnVzIFdlc3Rlcmx1bmQgPGEgaHJlZj0ibWFp
bHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbSI+Jmx0O21hZ251cy53ZXN0ZXJsdW5k
QGVyaWNzc29uLmNvbSZndDs8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnRzdi1hcnRAaWV0Zi5vcmci
PnRzdi1hcnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bGlz
cEBpZXRmLm9yZyI+bGlzcEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYu
b3JnIj4NCmlldGZAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1saXNw
LWdwZS5hbGxAaWV0Zi5vcmciPmRyYWZ0LWlldGYtbGlzcC1ncGUuYWxsQGlldGYub3JnPC9hPjxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVHN2YXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQt
aWV0Zi1saXNwLWdwZS0wNTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5IaSBNYWdudXMsIDxicj4NCnRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4g
PGJyPg0KPGJyPg0KSSB0aGluayBJIHNlZSB0aGUgcG9pbnRzIHlvdSBhcmUgbWFraW5nLiA8YnI+
DQo8YnI+DQpJJ2xsIGFkZCB0aGUgc2VjdGlvbiAzLjEgYmVsb3cgdG8gc3BlY2lmeSB0aGUgZ2Vu
ZXJhbCB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIGZvciB0aGUgcmVnaXN0cmF0aW9uIG9mIG5ldyBM
SVNQLUdQRSBwYXlsb2FkcywgYW5kIEkgd2lsbCBpbnRyb2R1Y2UgdHdvIHN1YnNlY3Rpb25zIHRv
IGluc3RhbnRpYXRlIHRob3NlIHJlcXVpcmVtZW50cyBmb3IgRXRoZXJuZXQgYW5kIE5TSCAoc2Vj
dGlvbiA0LjIgYW5kIDQuMyB3aWxsIGJlIG1vdmVkIGhlcmUpLg0KIEluIHRoZSAmcXVvdDtJQU5B
IENvbnNpZGVyYXRpb25zJnF1b3Q7IHNlY3Rpb24gSSdsbCByZWZlciB0byB0aGlzIG5ldyBzZWN0
aW9uIDMuMSBhcyBhIHJlcXVpcmVtZW50IGZvciByZWdpc3RyYXRpb24gb2YgbmV3IGVuY2Fwc3Vs
YXRlZCBwYXlsb2FkLg0KPGJyPg0KPGJyPg0KJnF1b3Q7My4xIFBheWxvYWQgU3BlY2lmaWMgVHJh
bnNwb3J0IEludGVyYWN0aW9uczxicj4NCjxicj4NClRvIGVuc3VyZSB0aGF0IHByb3RvY29scyB0
aGF0IGFyZSBlbmNhcHN1bGF0ZWQgaW4gTElTUC1HUEUgd2lsbCB3b3JrIHdlbGwgZnJvbSBhIHRy
YW5zcG9ydCBpbnRlcmFjdGlvbiBwZXJzcGVjdGl2ZSwgdGhlIHNwZWNpZmljYXRpb24gb2YgYSBu
ZXcgZW5jYXBzdWxhdGVkIHBheWxvYWQgTVVTVCBjb250YWluIGFuIGFuYWx5c2lzIG9mIGhvdyBM
SVNQLUdQRSBTSE9VTEQgZGVhbCB3aXRoIG91dGVyIFVEUCBDaGVja3N1bSwgRFNDUCBtYXBwaW5n
LCBhbmQNCiBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSBiaXRzIHdoZW5l
dmVyIHRoZXkgYXBwbHkgdG8gdGhlIG5ldyBlbmNhcHN1bGF0ZWQgcGF5bG9hZC48YnI+DQo8YnI+
DQpGb3IgSVAgcGF5bG9hZHMsIHNlY3Rpb24gNS4zIG9mIFtkcmFmdC1pZXRmLWxpc3AtcmZjNjgz
MGJpc10gc3BlY2lmaWVzIGhvdyB0byBoYW5kbGUgVURQIENoZWNrc3VtcyBlbmNvdXJhZ2luZyBp
bXBsZW1lbnRvcnMgdG8gY29uc2lkZXIgVURQIGNoZWNrc3VtIHVzYWdlIGd1aWRlbGluZXMgaW4g
c2VjdGlvbiAzLjQgb2YgW1JGQzgwODVdIHdoZW4gaXQgaXMgZGVzaXJhYmxlIHRvIHByb3RlY3Qg
VURQIGFuZCBMSVNQIGhlYWRlcnMgYWdhaW5zdCBjb3JydXB0aW9uLg0KIEVhY2ggbmV3IGVuY2Fw
c3VsYXRlZCBwYXlsb2Fkcywgd2hlbiByZWdpc3RlcmVkIHdpdGggTElTUC1HUEUsIE1VU1QgYmUg
YWNjb21wYW5pZWQgYnkgYSBzaW1pbGFyIGFuYWx5c2lzLjxicj4NCjxicj4NCkVuY2Fwc3VsYXRl
ZCBwYXlsb2FkcyBtYXkgaGF2ZSBhIHByaW9yaXR5IGZpZWxkIHRoYXQgbWF5IG9yIG1heSBub3Qg
YmUgbWFwcGVkIHRvIHRoZSBEU0NQIGZpZWxkIG9mIHRoZSBvdXRlciBJUCBoZWFkZXIgKHBhcnQg
b2YgVHlwZSBvZiBTZXJ2aWNlIGluIElQdjQgb3IgVHJhZmZpYyBDbGFzcyBpbiBJUHY2KS4gU3Vj
aCBuZXcgZW5jYXBzdWxhdGVkIHBheWxvYWRzLCB3aGVuIHJlZ2lzdGVyZWQgd2l0aCBMSVNQLUdQ
RSwgTVVTVCBiZSBhY2NvbXBhbmllZA0KIGJ5IGFuIGFuYWx5c2lzIHNpbWlsYXIgdG8gdGhlIG9u
ZSBwZXJmb3JtZWQgaW4gU2VjdGlvbiAzLjEuMSBvZiB0aGlzIGRvY3VtZW50IGZvciBFdGhlcm5l
dCBwYXlsb2Fkcy4NCjxicj4NCjxicj4NCkVuY2Fwc3VsYXRlZCBwYXlsb2FkcyBtYXkgaGF2ZSBF
eHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiBtZWNoYW5pc21zIHRoYXQgbWF5IG9yIG1h
eSBub3QgYmUgbWFwcGVkIHRvIHRoZSBvdXRlciBJUCBoZWFkZXIgRUNOIGZpZWxkLiBTdWNoIG5l
dyBlbmNhcHN1bGF0ZWQgcGF5b2xhZHMsIHdoZW4gcmVnaXN0ZXJlZCB3aXRoIExJU1AtR1BFLCBN
VVNUJm5ic3A7IGJlIGFjY29tcGFuaWVkIGJ5IGEgc2V0IG9mIGd1aWRlbGluZXMgZGVyaXZlZCBm
cm9tDQogW2RyYWZ0LWlldGYtdHN2d2ctZWNuLWVuY2FwLWd1aWRlbGluZXNdIGFuZCBbUkZDNjA0
MF0uIDxicj4NCjxicj4NClRoZSByZXN0IG9mIHRoaXMgc2VjdGlvbiBzcGVjaWZpZXMgcGF5bG9h
ZCBzcGVjaWZpYyB0cmFuc3BvcnQgaW50ZXJhY3Rpb25zIGNvbnNpZGVyYXRpb25zIGZvciB0aGUg
dHdvIG5ldyBMSVNQLUdQRSBlbmNhcHN1bGF0ZWQgcGF5bG9hZHMgc3BlY2lmaWVkIGluIHRoaXMg
ZG9jdW1lbnQ6IEV0aGVybmV0IGFuZCBOU0guDQo8YnI+DQo8YnI+DQozLjEuMSBQYXlsb2FkIFNw
ZWNpZmljIFRyYW5zcG9ydCBJbnRlcmFjdGlvbnMgZm9yIEV0aGVybmV0IEVuY2Fwc3VsYXRlZCBQ
YXlsb2Fkczxicj4NCjxicj4NClRoZSBVRFAgQ2hlY2tzdW0gY29uc2lkZXJhdGlvbnMgc3BlY2lm
aWVkIGluIHNlY3Rpb24gNS4zIG9mIFtkcmFmdC1pZXRmLWxpc3AtcmZjNjgzMGJpc10gYXBwbHkg
dG8gRXRoZXJuZXQgRW5jYXBzdWxhdGVkIFBheWxvYWRzLiBJbXBsZW1lbnRvcnMgYXJlIGVuY291
cmFnZWQgdG8gY29uc2lkZXIgdGhlIFVEUCBjaGVja3N1bSB1c2FnZSBndWlkZWxpbmVzIGluIHNl
Y3Rpb24gMy40IG9mIFtSRkM4MDg1XSB3aGVuIGl0IGlzIGRlc2lyYWJsZSB0byBwcm90ZWN0DQog
VURQLCBMSVNQIGFuZCBFdGhlcm5ldCBoZWFkZXJzIGFnYWluc3QgY29ycnVwdGlvbi48YnI+DQo8
YnI+DQpXaGVuIGEgTElTUC1HUEUgcm91dGVyIHBlcmZvcm1zIEV0aGVybmV0IGVuY2Fwc3VsYXRp
b24sIHRoZSBpbm5lciA4MDIuMVEgW0lFRUUuODAyLjFRXzIwMTRdIHByaW9yaXR5IGNvZGUgcG9p
bnQgKFBDUCkgZmllbGQgTUFZIGJlIG1hcHBlZCBmcm9tIHRoZSBlbmNhcHN1bGF0ZWQgZnJhbWUg
dG8gdGhlIFR5cGUgb2YgU2VydmljZSBmaWVsZCBpbiB0aGUgb3V0ZXIgSVB2NCBoZWFkZXIsIG9y
IGluIHRoZSBjYXNlIG9mIElQdjYgdGhlICdUcmFmZmljDQogQ2xhc3MnIGZpZWxkIGFzIHBlciBn
dWlkZWxpbmVzIHByb3ZpZGVkIGJ5IFtSRkM4MzI1XS48YnI+DQo8YnI+DQpXaGVuIGEgTElTUC1H
UEUgcm91dGVyIHBlcmZvcm1zIEV0aGVybmV0IGVuY2Fwc3VsYXRpb24sIHRoZSBpbm5lciBoZWFk
ZXIgODAyLjFRIFtJRUVFODAyMVFdIFZMQU4gSWRlbnRpZmllciAoVklEKSBNQVkgYmUgbWFwcGVk
IHRvLCBvciB1c2VkIHRvIGRldGVybWluZSB0aGUgTElTUCBJbnN0YW5jZSBJRCBmaWVsZC48YnI+
DQo8YnI+DQozLjEuMiBQYXlsb2FkIFNwZWNpZmljIFRyYW5zcG9ydCBJbnRlcmFjdGlvbnMgZm9y
IE5TSCBFbmNhcHN1bGF0ZWQgUGF5bG9hZHMgPGJyPg0KPGJyPg0KVGhlIFVEUCBDaGVja3N1bSBj
b25zaWRlcmF0aW9ucyBzcGVjaWZpZWQgaW4gc2VjdGlvbiA1LjMgb2YgW2RyYWZ0LWlldGYtbGlz
cC1yZmM2ODMwYmlzXSBhcHBseSB0byBOU0ggRW5jYXBzdWxhdGVkIFBheWxvYWRzLiBJbXBsZW1l
bnRvcnMgYXJlIGVuY291cmFnZWQgdG8gY29uc2lkZXIgdGhlIFVEUCBjaGVja3N1bSB1c2FnZSBn
dWlkZWxpbmVzIGluIHNlY3Rpb24gMy40IG9mIFtSRkM4MDg1XSB3aGVuIGl0IGlzIGRlc2lyYWJs
ZSB0byBwcm90ZWN0DQogVURQLCBMSVNQLCBhbmQgTlNIIGhlYWRlcnMgYWdhaW5zdCBjb3JydXB0
aW9uLjxicj4NCjxicj4NCldoZW4gYSBMSVNQLUdQRSByb3V0ZXIgcGVyZm9ybXMgYW4gTlNIIGVu
Y2Fwc3VsYXRpb24sIERTQ1AgYW5kIEVDTiB2YWx1ZXMgTUFZIGJlIG1hcHBlZCBhcyBzcGVjaWZp
ZWQgZm9yIHRoZSBOZXh0IFByb3RvY29sIGVuY2Fwc3VsYXRlZCBieSBOU0ggKG5hbWVseSBJUHY0
LCBJUHY2IGFuZCBFdGhlcm5ldCkuJnF1b3Q7Jm5ic3A7DQo8YnI+DQo8YnI+DQo8YnI+DQpJIHdp
bGwgYWxzbyBhZGQgYSBwYXJhZ3JhcGggdG8gJnF1b3Q7SWFuYSBDb25zaWRlcmF0aW9ucyZxdW90
OyB0aGF0IHNheXM6IDxicj4NCjxicj4NCjxicj4NCiZxdW90O1RvIGVuc3VyZSB0aGF0IHByb3Rv
Y29scyB0aGF0IGFyZSBlbmNhcHN1bGF0ZWQgaW4gTElTUC1HUEUgd2lsbCB3b3JrIHdlbGwgZnJv
bSBhIHRyYW5zcG9ydCBpbnRlcmFjdGlvbiBwZXJzcGVjdGl2ZSwgdGhlIHJlZ2lzdHJhdGlvbiBv
ZiBhIG5ldyBlbmNhcHN1bGF0ZWQgcGF5bG9hZCBNVVNUIGNvbnRhaW4gYW4gYW5hbHlzaXMgb2Yg
aG93IExJU1AtR1BFIFNIT1VMRCBkZWFsIHdpdGggb3V0ZXIgVURQIENoZWNrc3VtLCBEU0NQIG1h
cHBpbmcsIGFuZA0KIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIGJpdHMg
d2hlbmV2ZXIgdGhleSBhcHBseSB0byB0aGUgbmV3IGVuY2Fwc3VsYXRlZCBwYXlsb2FkLiBUaGUg
YW5hbHlzaXMgZm9yIHRoZSBuZXcgZW5jYXBzdWxhdGVkIHBheWxvYWQgcmVnaXN0ZXJlZCBpbiB0
aGlzIGRvY3VtZW50IGlzIGluIHNlY3Rpb24gMy4xLiZxdW90Ozxicj4NCjxicj4NClBsZWFzZSwg
bGV0IG1lIGtub3cgaWYgdGhpcyBhZGRyZXNzIHlvdXIgY29tbWVudHMuIDxicj4NCjxicj4NClRo
YW5rcyw8YnI+DQpGYWJpbzxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIDgvMjkvMTggMjoxNyBB
TSwgTWFnbnVzIFdlc3Rlcmx1bmQgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHBy
ZT5SZXZpZXdlcjogTWFnbnVzIFdlc3Rlcmx1bmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZXZp
ZXcgcmVzdWx0OiBOb3QgUmVhZHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5UaGlzIGRvY3VtZW50IGhhcyBiZWVuIHJldmlld2VkIGFzIHBhcnQg
b2YgdGhlIHRyYW5zcG9ydCBhcmVhIGRpcmVjdG9yYXRlJ3M8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5vbmdvaW5nIGVmZm9ydCB0byByZXZpZXcga2V5IElFVEYgZG9jdW1lbnRzLiBUaGVzZSBjb21t
ZW50cyB3ZXJlIHdyaXR0ZW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wcmltYXJpbHkgZm9yIHRo
ZSB0cmFuc3BvcnQgYXJlYSBkaXJlY3RvcnMsIGJ1dCBhcmUgY29waWVkIHRvIHRoZSBkb2N1bWVu
dCdzPG86cD48L286cD48L3ByZT4NCjxwcmU+YXV0aG9ycyBhbmQgV0cgZm9yIHRoZWlyIGluZm9y
bWF0aW9uIGFuZCB0byBhbGxvdyB0aGVtIHRvIGFkZHJlc3MgYW55IGlzc3VlczxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPnJhaXNlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5XaGVuIGRvbmUgYXQgdGhlIHRpbWUgb2YgSUVURiBMYXN0IENhbGws
IHRoZSBhdXRob3JzIHNob3VsZCBjb25zaWRlciB0aGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+
cmV2aWV3IHRvZ2V0aGVyIHdpdGggYW55IG90aGVyIGxhc3QtY2FsbCBjb21tZW50cyB0aGV5IHJl
Y2VpdmUuPG86cD48L286cD48L3ByZT4NCjxwcmU+UGxlYXNlIGFsd2F5cyBDQyA8YSBocmVmPSJt
YWlsdG86dHN2LWFydEBpZXRmLm9yZyI+dHN2LWFydEBpZXRmLm9yZzwvYT4gaWYgeW91IHJlcGx5
IHRvIG9yIGZvcndhcmQgdGhpcyByZXZpZXcuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
PG86cD48L286cD48L3ByZT4NCjxwcmU+SXNzdWUgQS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgcmVhc29uIEkgc3RhdGUgTm90IFJlYWR5
IGhhcyB0byBkbyB3aXRoIHRoaXMgZG9jdW1lbnRzIGZhaWx1cmUgdG8gY29uc2lkZXI8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT50aGUgdXNlIG9mIHplcm8gY2hlY2tzdW0gZm9yIElQdjYgd2hlbiB0
dW5uZWxpbmcgb3RoZXIgdGhpbmdzIHRoYW4gSVAuIFRoZSBub25lPG86cD48L286cD48L3ByZT4N
CjxwcmU+R1BFIHZlcnNpb24gaXMgbGltaXRlZCB0byB0dW5uZWwgSVAgZm9yIHdoaWNoIHRoZSBh
bmFseXNpcyBmb3IgdXNlIG9mIHplcm88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jaGVja3N1bSBo
YXMgYmVlbiBkb25lLiBFYWNoIG9mIHRoZSBuZXcgdHVubmVsZWQgcHJvdG9jb2xzIHRoYXQgYXJl
IHNwZWNpZmllZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmluIHRoaXMgZG9jdW1lbnQsIGkuZS4g
ZXRoZXJuZXQgYW5kIE5IUywgd2lsbCBuZWVkIHRvIHBlcmZvcm0gdGhlIGFuYWx5c2lzIGlmPG86
cD48L286cD48L3ByZT4NCjxwcmU+dGhleSBhcmUgc2FmZSB0byB1c2UgemVybyBjaGVja3N1bSBv
ciBub3QsIGFuZCBpZiBub3QgZGlzYWxsb3cgemVybyBjaGVja3N1bTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPmZvciBJUHY2L1VEUC4gVGhlIGRvY3VtZXRuIGFsc28gbmVlZCBhIHJlcXVpcmVtZW50
IGluIHRoZSByZWdpc3RyYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZXF1aXJlbWVudHMg
dG8gcGVyZm9ybSB0aGlzIGFuYWx5c2lzIGFuZCBkZWZpbmVkIGlmIHplcm8gY2hlY2tzdW0gaXM8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hY2NlcHRhYmxlIG9yIG5vdC48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DaXRpbmcgU2VjdGlvbiA1LjMg
b2YgZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBiaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVURQIENoZWNrc3VtOiZuYnNw
OyBUaGUgJ1VEUCBDaGVja3N1bScgZmllbGQgU0hPVUxEIGJlIHRyYW5zbWl0dGVkIGFzIHplcm88
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnkg
YW4gSVRSIGZvciBlaXRoZXIgSVB2NCBbUkZDMDc2OF0gYW5kIElQdjYgZW5jYXBzdWxhdGlvbjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUkZD
NjkzNV0gW1JGQzY5MzZdLiZuYnNwOyBXaGVuIGEgcGFja2V0IHdpdGggYSB6ZXJvIFVEUCBjaGVj
a3N1bSBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyByZWNlaXZlZCBieSBhbiBFVFIsIHRoZSBFVFIgTVVTVCBhY2NlcHQgdGhlIHBhY2tldCBm
b3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
ZGVjYXBzdWxhdGlvbi4mbmJzcDsgV2hlbiBhbiBJVFIgdHJhbnNtaXRzIGEgbm9uLXplcm8gdmFs
dWUgZm9yIHRoZSBVRFA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgY2hlY2tzdW0sIGl0IE1VU1Qgc2VuZCBhIGNvcnJlY3RseSBjb21wdXRlZCB2
YWx1ZSBpbiB0aGlzIGZpZWxkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBXaGVuIGFuIEVUUiByZWNlaXZlcyBhIHBhY2tldCB3aXRoIGEgbm9u
LXplcm8gVURQIGNoZWNrc3VtLCBpdCBNQVk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2hvb3NlIHRvIHZlcmlmeSB0aGUgY2hlY2tzdW0gdmFs
dWUuJm5ic3A7IElmIGl0IGNob29zZXMgdG8gcGVyZm9ybTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdWNoIHZlcmlmaWNhdGlvbiwgYW5kIHRo
ZSB2ZXJpZmljYXRpb24gZmFpbHMsIHRoZSBwYWNrZXQgTVVTVCBiZTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaWxlbnRseSBkcm9wcGVkLiZu
YnNwOyBJZiB0aGUgRVRSIGNob29zZXMgbm90IHRvIHBlcmZvcm0gdGhlPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZlcmlmaWNhdGlvbiwgb3Ig
cGVyZm9ybXMgdGhlIHZlcmlmaWNhdGlvbiBzdWNjZXNzZnVsbHksIHRoZTxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYWNrZXQgTVVTVCBiZSBh
Y2NlcHRlZCBmb3IgZGVjYXBzdWxhdGlvbi4mbmJzcDsgVGhlIGhhbmRsaW5nIG9mIFVEUDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB6ZXJvIGNo
ZWNrc3VtcyBvdmVyIElQdjYgZm9yIGFsbCB0dW5uZWxpbmcgcHJvdG9jb2xzLCBpbmNsdWRpbmc8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTElT
UCwgaXMgc3ViamVjdCB0byB0aGUgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgaW4gW1JGQzY5MzZd
LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRo
ZSBpc3N1ZSBpcyB0aGF0IHdoZW4gTElTUCBlbmNhcHN1bGF0ZSBvdGhlciBwcm90b2NvbHMgdGhl
IGltcGFjdCBvZiBhPG86cD48L286cD48L3ByZT4NCjxwcmU+bWlzc2RlbGl2ZXJlZCB0dW5uZWwg
cGFja2V0IHRvIHRoZSB3cm9uZyBFVFIgY2FuIGhhdmUgZGlmZmVyZW50IGltcGFjdHMuIEFzPG86
cD48L286cD48L3ByZT4NCjxwcmU+d2VsbCBhcyBlcnJvcnMgaW4gdGhlIGhlYWRlcnMgb2YgdGhl
IGVuY2Fwc3VsYXRlZCBwYWNrZXQgdGhhdCBtYXkgYmUgYXNzdW1lZCB0bzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPmJlIHByb3RlY3RlZCBieSB0aGUgZW5jYXBzdWxhdGluZyBsYXllci4gVGh1cywg
aW5kaXZpZHVhbCBhbmFseXNpcyBvZiBlYWNoPG86cD48L286cD48L3ByZT4NCjxwcmU+cHJvdG9j
b2wgdGhhdCBhcmUgdHVubmVsZWQgYXJlIG5lZWRlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5CLikgNC4yLiZuYnNwOyBUeXBlIG9mIFNlcnZp
Y2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDsmbmJzcDsgV2hlbiBhIExJU1AtR1BFIHJvdXRlciBwZXJmb3JtcyBFdGhlcm5ldCBlbmNh
cHN1bGF0aW9uLCB0aGUgaW5uZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg
ODAyLjFRIFtJRUVFLjgwMi4xUV8yMDE0XSBwcmlvcml0eSBjb2RlIHBvaW50IChQQ1ApIGZpZWxk
IE1BWSBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBtYXBwZWQgZnJvbSB0
aGUgZW5jYXBzdWxhdGVkIGZyYW1lIHRvIHRoZSBUeXBlIG9mIFNlcnZpY2UgZmllbGQgaW48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhlIG91dGVyIElQdjQgaGVhZGVyLCBv
ciBpbiB0aGUgY2FzZSBvZiBJUHY2IHRoZSAnVHJhZmZpYyBDbGFzcyc8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsgZmllbGQuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
PG86cD48L286cD48L3ByZT4NCjxwcmU+QW55IHJlY29tbWVuZGF0aW9uIGFib3V0IGhvdyB0byBw
ZXJmb3JtIHRoYXQgbWFwcGluZz8gTWF5YmUgcGFydHMgb2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0
cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19yZmM4MzI1XyZhbXA7ZD1Ed01EYVEmYW1w
O2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3JmFt
cDttPXhodi12aXBUd3RXd2c1QWNRdE1yWkNyUUExSkFmWVhNQWdHV3Fiamo0QXcmYW1wO3M9OGdp
ZHBySVVDZmhhZEZkV2k3eGxXRDBiUHNiM2RQZGZDdzlRZjhrZHdUSSZhbXA7ZT0iPmh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzgzMjUvPC9hPiBhcmUgcmVsZXZhbnQgaW4gdGhp
cyBjb250ZXh0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPkMuIEdlbmVyYWwgY2FzZSBvZiA0LjI6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SSBleHBlY3Qgb3RoZXIgcHJvdG9jb2xzIHRoYW4g
RXRoZXJuZXQgbWF5IGhhdmUgYSBwcmlvcml0eSBmaWVsZCB0aGF0IG1heSBvcjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPm1heSBub3QgYmUgbWFwcGVkIHRvIHRoZSBEU0NQIGZpZWxkIG9mIHRoZSB0
dW5uZWwgcGFja2V0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkkgd291bGQgZXhwZWN0IHRoYXQgZm9yIG5ldyBwcm90b2NvbCByZWdpc3RyYXRp
b24gaW4gdGhlIExJU1AtR1BFIE5leHQgUHJvdG9jb2w8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5S
ZWdpc3RyeSBzaG91bGQgY29uc2lkZXIgdGhpcy4gVGh1cywgaXQgd291bGQgYmUgZ29vZCB0byBu
b3RlIHRoYXQgc3VjaDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvbnNpZGVyYXRpb25zIGFyZSBu
ZWVkZWQgYW5kIHBhcnQgb2Ygd2hhdCBzaG91bGQgYmUgZXZhbHVhdGVkIGZvciBuZXc8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5yZWdpc3RyYXRpb25zLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkQuIEVDTiBoYW5kbGluZzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlY3Rpb24gNS4zIG9mIGRy
YWZ0LWlldGYtbGlzcC1yZmM2ODMwYmlzIHN0YXRlczo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyBUaGUgJ0V4
cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uJyAoRUNOKSBmaWVsZCAoYml0cyA2IGFuZCA3
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9m
IHRoZSBJUHY2ICdUcmFmZmljIENsYXNzJyBmaWVsZCkgcmVxdWlyZXMgc3BlY2lhbCB0cmVhdG1l
bnQgaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgb3JkZXIgdG8gYXZvaWQgZGlzY2FyZGluZyBpbmRpY2F0aW9ucyBvZiBjb25nZXN0aW9uIFtS
RkMzMTY4XS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgSVRSIGVuY2Fwc3VsYXRpb24gTVVTVCBjb3B5IHRoZSAyLWJpdCAnRUNOJyBmaWVsZCBm
cm9tIHRoZSBpbm5lcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBoZWFkZXIgdG8gdGhlIG91dGVyIGhlYWRlci4mbmJzcDsgUmUtZW5jYXBzdWxh
dGlvbiBNVVNUIGNvcHkgdGhlIDItYml0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICdFQ04nIGZpZWxkIGZyb20gdGhlIHN0cmlwcGVkIG91dGVy
IGhlYWRlciB0byB0aGUgbmV3IG91dGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhlYWRlci48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgYWJvdmUgcnVsZXMgbWF5IG5vdCBiZSBhcHBs
aWNhYmxlIGZvciBhbGwgdHJhbnNwb3J0IHByb3RvY29scy4gVGh1cyBJIHRoaW5rPG86cD48L286
cD48L3ByZT4NCjxwcmU+aXQgaXMgcmVxdWlyZWQgdGhhdCBvbmUgZG8gcHJvdG9jb2wgc3BlY2lm
aWMgY29uc2lkZXJhdGlvbnMgb2YgRUNOLiBUU1ZXRyBhcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT53b3JraW5nIG9uIHJlY29tbWVuZGF0aW9ucyBmb3IgdHVubmVscyBoYW5kbGluZyBvZiZuYnNw
OyBFQ04gaGVyZSwgc2VlOiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczov
L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2Vy
LmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkR0c3Z3Zy0yRGVjbi0yRGVuY2FwLTJEZ3VpZGVs
aW5lc18mYW1wO2Q9RHdNRGFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9NlVo
R3BXOWx3aTlkTTdqWWx4WEQ4dyZhbXA7bT14aHYtdmlwVHd0V3dnNUFjUXRNclpDclFBMUpBZllY
TUFnR1dxYmpqNEF3JmFtcDtzPWV5TzRjN0QzU2hOUWhhYThvVkRxQ2lkSGJFcDNtVzdBa001MWR1
djhRdzQmYW1wO2U9Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm
LXRzdndnLWVjbi1lbmNhcC1ndWlkZWxpbmVzLzwvYT4gVGh1cyw8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5teSBleHBlY3RhdGlvbiB3b3VsZCBiZSB0byBlbnN1cmUgdGhhdCB0aGUgcmVnaXN0ZXJl
ZCBwcm90b2NvbHMgaGF2ZSBkZWZpbmVkPG86cD48L286cD48L3ByZT4NCjxwcmU+RUNOIGhhbmRs
aW5nLCBleHBsaWNpdGx5IG9yIGJ5IHJlZmVyZW5jZS4gU2Vjb25kbHkgdGhhdCByZWdpc3RyYXRp
b248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZXF1aXJlbWVudCBzdGF0ZXMgdGhlIG5lZWQgZm9y
IHRoaXMgY29uc2lkZXJhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5TdW1tYXJ5OiBUbyBlbnN1cmUgdGhhdCBmdXR1cmUgYWRkZWQgcHJv
dG9jb2xzIHRoYXQgYXJlIGVuY2Fwc3VsYXRlZCB3aWxsIHdvcms8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT53ZWxsIGZyb20gYSB0cmFuc3BvcnQgaW50ZXJhY3Rpb24gcGVyc3BlY3RpdmUgdGhlcmUg
bmVlZCB0byBiZSBhIHJlcXVpcmVtZW50IG9uPG86cD48L286cD48L3ByZT4NCjxwcmU+bmV3IHJl
Z2lzdHJhdGlvbiB0byBjb25zaWRlciBhbmQgZGVmaW5lIGhvdyB0aGV5IHVzZSB6ZXJvIGNoZWNr
c3VtLCBhbnkgRFNDUDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm1hcHBpbmcgYW5kIEVDTiBiaXRz
LiBJbiBhZGRpdGlvbiB0aGUgY3VycmVudCBkb2N1bWVudCBuZWVkcyB0byBlbnN1cmUgdGhlc2U8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGluZ3MgYXJlIGNsZWFybHkgc3BlY2lmaWVkIGZvciB0
aGUgZW5jYXBzdWxhdGVkIHByb3RvY29scyBpbiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+
PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx
dW90ZT4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+TWFnbnVzIFdlc3Rlcmx1bmQgPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPk5ldHdvcmsgQXJjaGl0ZWN0dXJlICZhbXA7IFByb3RvY29scywgRXJpY3Nzb24gUmVz
ZWFyY2g8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3By
ZT4NCjxwcmU+RXJpY3Nzb24gQUImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgfCBQaG9uZSZuYnNwOyAmIzQzOzQ2IDEwIDcxNDgyODc8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5Ub3JzaGFtbnNnYXRhbiAyMyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IE1vYmlsZSAmIzQzOzQ2IDczIDA5NDkwNzk8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5TRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IDxh
IGhyZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iPm1hZ251cy53ZXN0
ZXJsdW5kQGVyaWNzc29uLmNvbTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_F64C10EAA68C8044B33656FA214632C88841C523MISOUT7MSGUSRDE_--


From nobody Thu Sep 20 06:45:10 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9596A129619; Thu, 20 Sep 2018 06:45:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 XVS79g0UyHf9; Thu, 20 Sep 2018 06:44:59 -0700 (PDT)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 CF055130DEB; Thu, 20 Sep 2018 06:44:58 -0700 (PDT)
Received: by mail-yb1-xb2e.google.com with SMTP id d9-v6so3911852ybr.12; Thu, 20 Sep 2018 06:44:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x29Q071ZWDFDQXEeWMaNb/H/Y8wcfVXNM94B267yMwE=; b=F+TEiHB1QWqwC5q3Q/ARsA2tRrQNWKonbfYmT540Mbj+zILyHVMcvIWR5cJZoiUI4c gJqmN0nql9ZrMTwmMv5vYRZqlbhKpDd+JUfYLo2/3O8rMUAJrDqMBvZVJrDP+bPjQCx3 RYvaP/tOIyBIZ7Zisq/2isxLlmQGPlC0tW4Vm68Td07ppEgaKprU0xrRBsUbsl/qdO/s B1WVMvNTCWGRqk8EJvWHm4ckIpx4Jqn8wuhwcGQ+5Xuxmc9Pas8drGZ2SyT3dRRzGBKC VL9ig29gSV7W8YGpR6lGOPFyEhCzljTMZ9kfKXlHaDYLk6qSE3qLag+oX4wd4PJE6XMD oL2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x29Q071ZWDFDQXEeWMaNb/H/Y8wcfVXNM94B267yMwE=; b=eFlz3ZVYkwbhuTQB04SbNmfWvycbzaUa8LoqUbiu3vfMqrm6F6pSzB2J6lRAm78nmc 5dKfMY+/SdpKP05LtkFrKRULcSW9CMk1C6bN4zudapVWxldtFbpodTdDj8SUN+7O/vhp pqczejryzwErEOUNWGNAGliAvJnXDuw/Ghu4twWLHBsVdhiPbPj6OhkF5BkR99DGCPx7 rUv4HS6o9I/usfmn9Ak5pTARqmSJeGKCo4rT3/5EHMHwQh/xYFtshrtrbe9vxDgeHBEu Fuz1XILuwxkeZ+N4sEEEWaL6F2SZFZCp47058VQJ3d8//SjnLVestsq0osYEmUivCcKG W1Og==
X-Gm-Message-State: APzg51DRRrt/r09hIwxcH3X3Ufeo9a6Izd4bNUsKMaBIgm89bFkZAQTY QCQSG0SQWvpP0qQZC9xXiclXRkvzfZbY6Xmpffk=
X-Google-Smtp-Source: ANB0Vda8gme4nYvbnJVaJZQhaJIXxIPld1omDfgmClj6WiL2OpxR2W5DqJFRy8beDbSUTvLSQi0JRDQvQ6u/H680ez0=
X-Received: by 2002:a25:854e:: with SMTP id f14-v6mr18541405ybn.292.1537451097682;  Thu, 20 Sep 2018 06:44:57 -0700 (PDT)
MIME-Version: 1.0
References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net>  <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com>   <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net>
In-Reply-To: <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net>
From: Spencer Dawkins at IETF 
Date: Thu, 20 Sep 2018 08:44:45 -0500
Message-ID: 
To: Mirja Kuehlewind 
Cc: Dino Farinacci , Luigi Iannone , lisp-chairs@ietf.org,  IESG , lisp@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org
Content-Type: multipart/alternative; boundary="00000000000089781605764dba11"
Archived-At: 
Subject: Re: [lisp]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Sep 2018 13:45:02 -0000

--00000000000089781605764dba11
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I haven't balloted on this document yet, but since I will, and would love
to ballot No-Objection ...

On Thu, Sep 20, 2018 at 5:58 AM Mirja Kuehlewind (IETF) 
wrote:

> Hi Dino,
>
> it=E2=80=99s fine with me to leave the details to rfc6040 but then also t=
he
> details in the current text should be removed (because giving only half t=
he
> details really doesn=E2=80=99t seem right).
>
> However, I totally disagree with your comment on providing details that
> are not implemented. If they are not implemented correctly, it might even
> be more important to spell them out in this document, so implementors hav=
e
> chance to update their (future) implementation to do the correct thing.
> Having deployed implementations that are non standard-conform always
> happens and in this case it is probably not specifically problematic as i=
t
> doesn=E2=80=99t impact interoperability. However, it is important though =
that the
> spec is correct.
>

Tl;dr - you're both right. Do the right thing.

If I'm following this conversation correctly, the situation is

- IP fragmentation can be problematic, roughly as a function of the number
of fragments that any given IP packet is fragmented into, but
- most deployed LISP implementations don't do path MTU discovery now

Is that it?

If so, what I'd suggest, is actually saying it that way.

Mirja's right, that we're advising people to do path MTU discovery of some
type (and I'm pretty sure https://tools.ietf.org/html/rfc4821#section-10.3
is what we would recommend in this case).

Dino's right, that putting out a standard that doesn't reflect deployed
implementations won't inspire people to conform to standards.

But do the right thing, of course ...

Spencer


> Mirja
>
>
> > Am 18.09.2018 um 18:56 schrieb Dino Farinacci :
> >
> > As I already said, this text is too detailed and repeats what is in
> other RFCs. And since implementations do what they already do, adding mor=
e
> details that are not implemented, IMO, is not good form.
> >
> > Dino
> >
> >> On Sep 18, 2018, at 3:32 AM, Mirja Kuehlewind (IETF) <
> ietf@kuehlewind.net> wrote:
> >>
> >> Hi Dino,
> >>
> >> please see below.
> >>
> >>> Am 17.09.2018 um 19:48 schrieb Dino Farinacci :
> >>>
> >>>> PROPOSED
> >>>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
> >>>>   of the IPv6 'Traffic Class' field) [RFC3168] requires special
> treatment in
> >>>>   order to preserve the use of ECN on the path.
> >>>>   ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
> >>>>   header to the outer header, inline with the =E2=80=99Normal Mode=
=E2=80=99 in
> section 4.1
> >>>>   of [RFC6040].  Re-encapsulation SHOULD follow the decapsulation as
> described
> >>>>   below and then 2-bit 'ECN' field from the stripped inner header to
> the
> >>>>   new outer header.=E2=80=9C
> >>>
> >>> I did not include this text because the last sentence is not formed
> well. Please restate. A verb is missing.
> >>
> >> copy
> >>
> >>>
> >>>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
> >>>>   of the IPv6 'Traffic Class' field) requires special treatment on
> >>>>   decapsulation in
> >>>>   order to avoid discarding indications of congestion,
> >>>>   inline with section 4.2 of [RFC6040]. If
> >>>>   the 'ECN=E2=80=98 field of the outer header contains a congestion
> indication
> >>>>   codepoint (the
> >>>>   value is '11', the Congestion Experienced (CE) codepoint) and the
> inner
> >>>>   header indicates ECN support (either ECT(0) or ECT(1) codepoint is
> set),
> >>>>   then ETR decapsulation MUST also set CE field in the inner header
> that is
> >>>>   used
> >>>>   to forward the packet beyond the ETR. If the inner packet is marke=
d
> as non-
> >>>>   ECT but the outer header has the CE mark set, the packet MUST be
> dropped
> >>>>   instead. Any discrepancy between the inner and outer header for
> non-ECT,
> >>>>   ECT(0) and ECT(1) MUST NOT be copied from the outer header. These
> >>>>   requirements preserve
> >>>>   CE indications when a packet that is ECN-capable traverses a LISP
> tunnel
> >>>>   and becomes marked with a CE indication due to congestion between
> >>>>   the tunnel endpoints or transforms an CE into loss if that packet
> is not
> >>>>   ECN-capable conserving the congestion indication towards a non-ECN
> enables
> >>>>   endpoint.=E2=80=9D
> >>>
> >>> I didn=E2=80=99t include this text because (1) it under states what t=
o do with
> IPv4, (2) it has too much detail that is already in RFC6040, and (3) it
> undoes text that other reviewers have offered.
> >>
> >> I didn=E2=80=99t change the mentioning of IPv6 here. Yes please at IPv=
4.
> >>
> >> You can remove all this text and only point to rfc6040. That would
> actually my preferred solution. I don=E2=80=99t think it =E2=80=9Eundoes=
=E2=80=9C text; it just
> adds what was missing in compliance with RFC6040. Anyway it doesn=E2=80=
=99t matter
> point being that it should specify the same things as RFC6040 does not
> matter what other have ofter because RFC6040 is the IETF-consensus doc ho=
w
> describing how to handle this.
> >>
> >>>
> >>>
> >>>> Please also remove the duplicated text after these bullet lists in
> the draft!
> >>>
> >>> You have to tell me what text. I am too confused at this point on wha=
t
> you want.
> >>
> >> This is the text in the en-/ and decapsulation lists:
> >>
> >> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
> >>     of the IPv6 'Traffic Class' field) requires special treatment in
> >>     order to avoid discarding indications of congestion [RFC3168].
> >>     ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
> >>     header to the outer header.  Re-encapsulation MUST copy the 2-bit
> >>     'ECN' field from the stripped outer header to the new outer
> >>     header."
> >>
> >> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
> >>     of the IPv6 'Traffic Class' field) requires special treatment in
> >>     order to avoid discarding indications of congestion [RFC6040].  If
> >>     the 'ECN' field contains a congestion indication codepoint (the
> >>     value is '11', the Congestion Experienced (CE) codepoint), then
> >>     ETR decapsulation MUST copy the 2-bit 'ECN' field from the
> >>     stripped outer header to the surviving inner header that is used
> >>     to forward the packet beyond the ETR.  These requirements preserve
> >>     CE indications when a packet that uses ECN traverses a LISP tunnel
> >>     and becomes marked with a CE indication due to congestion between
> >>     the tunnel endpoints."
> >>
> >> And this text comes up right after the list in the same section:
> >>
> >> "The Explicit Congestion Notification ('ECN') field occupies bits 6
> >>  and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic
> >>  Class' field [RFC6040].  The 'ECN' field requires special treatment
> >>  in order to avoid discarding indications of congestion [RFC6040].  An
> >>  ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
> >>  header to the outer header.  Re-encapsulation MUST copy the 2-bit
> >>  'ECN' field from the stripped outer header to the new outer header.
> >>  If the 'ECN' field contains a congestion indication codepoint (the
> >>  value is '11', the Congestion Experienced (CE) codepoint), then ETR/
> >>  PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped
> >>  outer header to the surviving inner header that is used to forward
> >>  the packet beyond the ETR.  These requirements preserve CE
> >>  indications when a packet that uses ECN traverses a LISP tunnel and
> >>  becomes marked with a CE indication due to congestion between the
> >>  tunnel endpoints."
> >>
> >> The last text bit does not add any information; it just states all
> normative requirement twice, even using basically exactly the some words.
> This can lead to discrepancies and it really not necessary. I=E2=80=99d r=
ecommend
> to just remove the last text block here (and fix the IPv6/IPv4 issue in t=
he
> other blocks).
> >>
> >> Mirja
> >>
> >>
> >>>
> >>>> Further I believe my discuss points 2) and 4) are not fully resolved
> yet. Also I would like to at least see more explanation about the approac=
h
> for extensibility that was taken in this doc (point 6).
> >>>
> >>> You are going to have to repeat what they are because too many emails
> have flown by since your initial post. And for extensibility, we discuss =
it
> in RFC8060 and don=E2=80=99t think anything more should be said here othe=
rwise, we
> will duplicate unnecessary text.
> >>>
> >>> Another new diff file enclosed.
> >>>
> >>> Dino
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
>
>

--00000000000089781605764dba11
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I haven't balloted on this document y=
et, but since I will, and would love to ballot No-Objection ...=C2=A0
<=
br>
On Thu, Sep 20, 2018 at 5:58=
 AM Mirja Kuehlewind (IETF) <ietf=
@kuehlewind.net> wrote:
Hi Dino,



it=E2=80=99s fine with me to leave the details to rfc6040 but then also the=
 details in the current text should be removed (because giving only half th=
e details really doesn=E2=80=99t seem right).



However, I totally disagree with your comment on providing details that are=
 not implemented. If they are not implemented correctly, it might even be m=
ore important to spell them out in this document, so implementors have chan=
ce to update their (future) implementation to do the correct thing. Having =
deployed implementations that are non standard-conform always happens and i=
n this case it is probably not specifically problematic as it doesn=E2=80=
=99t impact interoperability. However, it is important though that the spec=
 is correct.

Tl;dr - you're both ri=
ght. Do the right thing.=C2=A0

If I'm followin=
g this conversation correctly, the situation is=C2=A0

<=
div>- IP fragmentation can be problematic, roughly as a function of the num=
ber of fragments that any given IP packet is fragmented into, but=C2=A0
- most deployed LISP implementations don't do path MTU discovery=
 now

Is that it?

If so, w=
hat I'd suggest, is actually saying it that way.=C2=A0

Mirja's right, that we're advising people to do path MTU d=
iscovery of some type (and I'm pretty sure=C2=A0https://tools.ietf.org/html/rfc4821#s=
ection-10.3 is what we would recommend in this case).=C2=A0
<=
br>
Dino's right, that putting out a standard that doesn'=
t reflect deployed implementations won't inspire people to conform to s=
tandards.=C2=A0

But do the right thing, of course =
...

Spencer
=C2=A0
Mirja





> Am 18.09.2018 um 18:56 schrieb Dino Farinacci <farinacci@gmail.com>:

> 

> As I already said, this text is too detailed and repeats what is in ot=
her RFCs. And since implementations do what they already do, adding more de=
tails that are not implemented, IMO, is not good form.

> 

> Dino

> 

>> On Sep 18, 2018, at 3:32 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net&g=
t; wrote:

>> 

>> Hi Dino,

>> 

>> please see below.

>> 

>>> Am 17.09.2018 um 19:48 schrieb Dino Farinacci <farinacci@gmail.com>:
>>> 

>>>> PROPOSED

>>>> "The 'Explicit Congestion Notification' (ECN)=
 field (bits 6 and 7

>>>>=C2=A0 =C2=A0of the IPv6 'Traffic Class' field) [RF=
C3168] requires special treatment in

>>>>=C2=A0 =C2=A0order to preserve the use of ECN on the path.<=
br>
>>>>=C2=A0 =C2=A0ITR encapsulation MUST copy the 2-bit 'ECN=
' field from the inner

>>>>=C2=A0 =C2=A0header to the outer header, inline with the =
=E2=80=99Normal Mode=E2=80=99 in section 4.1 

>>>>=C2=A0 =C2=A0of [RFC6040].=C2=A0 Re-encapsulation SHOULD fo=
llow the decapsulation as described 

>>>>=C2=A0 =C2=A0below and then 2-bit 'ECN' field from =
the stripped inner header to the 

>>>>=C2=A0 =C2=A0new outer header.=E2=80=9C

>>> 

>>> I did not include this text because the last sentence is not f=
ormed well. Please restate. A verb is missing.

>> 

>> copy

>> 

>>> 

>>>> "The 'Explicit Congestion Notification' (ECN)=
 field (bits 6 and 7

>>>>=C2=A0 =C2=A0of the IPv6 'Traffic Class' field) req=
uires special treatment on 

>>>>=C2=A0 =C2=A0decapsulation in

>>>>=C2=A0 =C2=A0order to avoid discarding indications of conge=
stion, 

>>>>=C2=A0 =C2=A0inline with section 4.2 of [RFC6040]. If

>>>>=C2=A0 =C2=A0the 'ECN=E2=80=98 field of the outer heade=
r contains a congestion indication=C2=A0 =C2=A0 =C2=A0

>>>>=C2=A0 =C2=A0codepoint (the

>>>>=C2=A0 =C2=A0value is '11', the Congestion Experien=
ced (CE) codepoint) and the inner 

>>>>=C2=A0 =C2=A0header indicates ECN support (either ECT(0) or=
 ECT(1) codepoint is set), 

>>>>=C2=A0 =C2=A0then ETR decapsulation MUST also set CE field =
in the inner header that is 

>>>>=C2=A0 =C2=A0used

>>>>=C2=A0 =C2=A0to forward the packet beyond the ETR. If the i=
nner packet is marked as non-

>>>>=C2=A0 =C2=A0ECT but the outer header has the CE mark set, =
the packet MUST be dropped 

>>>>=C2=A0 =C2=A0instead. Any discrepancy between the inner and=
 outer header for non-ECT, 

>>>>=C2=A0 =C2=A0ECT(0) and ECT(1) MUST NOT be copied from the =
outer header. These 

>>>>=C2=A0 =C2=A0requirements preserve

>>>>=C2=A0 =C2=A0CE indications when a packet that is ECN-capab=
le traverses a LISP tunnel

>>>>=C2=A0 =C2=A0and becomes marked with a CE indication due to=
 congestion between

>>>>=C2=A0 =C2=A0the tunnel endpoints or transforms an CE into =
loss if that packet is not 

>>>>=C2=A0 =C2=A0ECN-capable conserving the congestion indicati=
on towards a non-ECN enables 

>>>>=C2=A0 =C2=A0endpoint.=E2=80=9D

>>> 

>>> I didn=E2=80=99t include this text because (1) it under states=
 what to do with IPv4, (2) it has too much detail that is already in RFC604=
0, and (3) it undoes text that other reviewers have offered.

>> 

>> I didn=E2=80=99t change the mentioning of IPv6 here. Yes please at=
 IPv4.

>> 

>> You can remove all this text and only point to rfc6040. That would=
 actually my preferred solution. I don=E2=80=99t think it =E2=80=9Eundoes=
=E2=80=9C text; it just adds what was missing in compliance with RFC6040. A=
nyway it doesn=E2=80=99t matter point being that it should specify the same=
 things as RFC6040 does not matter what other have ofter because RFC6040 is=
 the IETF-consensus doc how describing how to handle this.

>> 

>>> 

>>> 

>>>> Please also remove the duplicated text after these bullet =
lists in the draft!

>>> 

>>> You have to tell me what text. I am too confused at this point=
 on what you want.

>> 

>> This is the text in the en-/ and decapsulation lists:

>> 

>> "The 'Explicit Congestion Notification' (ECN) field (=
bits 6 and 7

>>=C2=A0 =C2=A0 =C2=A0of the IPv6 'Traffic Class' field) requ=
ires special treatment in

>>=C2=A0 =C2=A0 =C2=A0order to avoid discarding indications of conges=
tion [RFC3168].

>>=C2=A0 =C2=A0 =C2=A0ITR encapsulation MUST copy the 2-bit 'ECN&=
#39; field from the inner

>>=C2=A0 =C2=A0 =C2=A0header to the outer header.=C2=A0 Re-encapsulat=
ion MUST copy the 2-bit

>>=C2=A0 =C2=A0 =C2=A0'ECN' field from the stripped outer hea=
der to the new outer

>>=C2=A0 =C2=A0 =C2=A0header."

>> 

>> "The 'Explicit Congestion Notification' (ECN) field (=
bits 6 and 7

>>=C2=A0 =C2=A0 =C2=A0of the IPv6 'Traffic Class' field) requ=
ires special treatment in

>>=C2=A0 =C2=A0 =C2=A0order to avoid discarding indications of conges=
tion [RFC6040].=C2=A0 If

>>=C2=A0 =C2=A0 =C2=A0the 'ECN' field contains a congestion i=
ndication codepoint (the

>>=C2=A0 =C2=A0 =C2=A0value is '11', the Congestion Experienc=
ed (CE) codepoint), then

>>=C2=A0 =C2=A0 =C2=A0ETR decapsulation MUST copy the 2-bit 'ECN&=
#39; field from the

>>=C2=A0 =C2=A0 =C2=A0stripped outer header to the surviving inner he=
ader that is used

>>=C2=A0 =C2=A0 =C2=A0to forward the packet beyond the ETR.=C2=A0 The=
se requirements preserve

>>=C2=A0 =C2=A0 =C2=A0CE indications when a packet that uses ECN trav=
erses a LISP tunnel

>>=C2=A0 =C2=A0 =C2=A0and becomes marked with a CE indication due to =
congestion between

>>=C2=A0 =C2=A0 =C2=A0the tunnel endpoints."

>> 

>> And this text comes up right after the list in the same section:
>> 

>> "The Explicit Congestion Notification ('ECN') field o=
ccupies bits 6

>>=C2=A0 and 7 of both the IPv4 'Type of Service' field and t=
he IPv6 'Traffic

>>=C2=A0 Class' field [RFC6040].=C2=A0 The 'ECN' field re=
quires special treatment

>>=C2=A0 in order to avoid discarding indications of congestion [RFC6=
040].=C2=A0 An

>>=C2=A0 ITR/PITR encapsulation MUST copy the 2-bit 'ECN' fie=
ld from the inner

>>=C2=A0 header to the outer header.=C2=A0 Re-encapsulation MUST copy=
 the 2-bit

>>=C2=A0 'ECN' field from the stripped outer header to the ne=
w outer header.

>>=C2=A0 If the 'ECN' field contains a congestion indication =
codepoint (the

>>=C2=A0 value is '11', the Congestion Experienced (CE) codep=
oint), then ETR/

>>=C2=A0 PETR decapsulation MUST copy the 2-bit 'ECN' field f=
rom the stripped

>>=C2=A0 outer header to the surviving inner header that is used to f=
orward

>>=C2=A0 the packet beyond the ETR.=C2=A0 These requirements preserve=
 CE

>>=C2=A0 indications when a packet that uses ECN traverses a LISP tun=
nel and

>>=C2=A0 becomes marked with a CE indication due to congestion betwee=
n the

>>=C2=A0 tunnel endpoints."

>> 

>> The last text bit does not add any information; it just states all=
 normative requirement twice, even using basically exactly the some words. =
This can lead to discrepancies and it really not necessary. I=E2=80=99d rec=
ommend to just remove the last text block here (and fix the IPv6/IPv4 issue=
 in the other blocks).

>> 

>> Mirja

>> 

>> 

>>> 

>>>> Further I believe my discuss points 2) and 4) are not full=
y resolved yet. Also I would like to at least see more explanation about th=
e approach for extensibility that was taken in this doc (point 6).

>>> 

>>> You are going to have to repeat what they are because too many=
 emails have flown by since your initial post. And for extensibility, we di=
scuss it in RFC8060 and don=E2=80=99t think anything more should be said he=
re otherwise, we will duplicate unnecessary text.

>>> 

>>> Another new diff file enclosed.

>>> 

>>> Dino

>>> 

>>> 

>>> 

>>> 

>>> 

>>> 

>> 

> 






--00000000000089781605764dba11--


From nobody Thu Sep 20 08:10:12 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DDA1277CC for ; Thu, 20 Sep 2018 08:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 eB2aTvGTqpZI for ; Thu, 20 Sep 2018 08:10:08 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A66130DD9 for ; Thu, 20 Sep 2018 08:10:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=bLFbsGVZjRDsC5SxYVZ/wQ0uHw5qS07epJ7GZU/c7x/kCvFyjN+aKJ309Y4Gl+d9TIMb/e364chlUY4ne7gYujWclcyPvaiQ/z62McrykK4zSmIv5Chp9YGxYLTOYO2YqSrKZn9+MHqEBbKkMkl0x7a7cyEpSU1I8sl3SV27m5I=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 25940 invoked from network); 20 Sep 2018 17:03:18 +0200
Received: from mue-88-130-61-247.dsl.tropolys.de (HELO ?192.168.178.24?) (88.130.61.247) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Sep 2018 17:03:18 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: 
Date: Thu, 20 Sep 2018 17:03:16 +0200
Cc: lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, IESG , Dino Farinacci , Luigi Iannone , lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B314B5A-5F7C-45B3-B1B3-690F050A5424@kuehlewind.net>
References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net>  <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com>   <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net> 
To: Spencer Dawkins at IETF 
X-Mailer: Apple Mail (2.3445.9.1)
X-PPP-Message-ID: <20180920150318.25930.38263@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
Subject: Re: [lisp]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Sep 2018 15:10:10 -0000

Hi Spencer,

this conversation was mostly on ECN. For the MTU issue, I think the =
solution is to restrict the message size of lisp messages such that no =
PMTU discovery is needed.

Mirja


> Am 20.09.2018 um 15:44 schrieb Spencer Dawkins at IETF =
:
>=20
> I haven't balloted on this document yet, but since I will, and would =
love to ballot No-Objection ...=20
>=20
> On Thu, Sep 20, 2018 at 5:58 AM Mirja Kuehlewind (IETF) =
 wrote:
> Hi Dino,
>=20
> it=E2=80=99s fine with me to leave the details to rfc6040 but then =
also the details in the current text should be removed (because giving =
only half the details really doesn=E2=80=99t seem right).
>=20
> However, I totally disagree with your comment on providing details =
that are not implemented. If they are not implemented correctly, it =
might even be more important to spell them out in this document, so =
implementors have chance to update their (future) implementation to do =
the correct thing. Having deployed implementations that are non =
standard-conform always happens and in this case it is probably not =
specifically problematic as it doesn=E2=80=99t impact interoperability. =
However, it is important though that the spec is correct.
>=20
> Tl;dr - you're both right. Do the right thing.=20
>=20
> If I'm following this conversation correctly, the situation is=20
>=20
> - IP fragmentation can be problematic, roughly as a function of the =
number of fragments that any given IP packet is fragmented into, but=20
> - most deployed LISP implementations don't do path MTU discovery now
>=20
> Is that it?
>=20
> If so, what I'd suggest, is actually saying it that way.=20
>=20
> Mirja's right, that we're advising people to do path MTU discovery of =
some type (and I'm pretty sure =
https://tools.ietf.org/html/rfc4821#section-10.3 is what we would =
recommend in this case).=20
>=20
> Dino's right, that putting out a standard that doesn't reflect =
deployed implementations won't inspire people to conform to standards.=20=

>=20
> But do the right thing, of course ....
>=20
> Spencer
> =20
> Mirja
>=20
>=20
> > Am 18.09.2018 um 18:56 schrieb Dino Farinacci :
> >=20
> > As I already said, this text is too detailed and repeats what is in =
other RFCs. And since implementations do what they already do, adding =
more details that are not implemented, IMO, is not good form.
> >=20
> > Dino
> >=20
> >> On Sep 18, 2018, at 3:32 AM, Mirja Kuehlewind (IETF) =
 wrote:
> >>=20
> >> Hi Dino,
> >>=20
> >> please see below.
> >>=20
> >>> Am 17.09.2018 um 19:48 schrieb Dino Farinacci =
:
> >>>=20
> >>>> PROPOSED
> >>>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
> >>>>   of the IPv6 'Traffic Class' field) [RFC3168] requires special =
treatment in
> >>>>   order to preserve the use of ECN on the path.
> >>>>   ITR encapsulation MUST copy the 2-bit 'ECN' field from the =
inner
> >>>>   header to the outer header, inline with the =E2=80=99Normal =
Mode=E2=80=99 in section 4.1=20
> >>>>   of [RFC6040].  Re-encapsulation SHOULD follow the decapsulation =
as described=20
> >>>>   below and then 2-bit 'ECN' field from the stripped inner header =
to the=20
> >>>>   new outer header.=E2=80=9C
> >>>=20
> >>> I did not include this text because the last sentence is not =
formed well. Please restate. A verb is missing.
> >>=20
> >> copy
> >>=20
> >>>=20
> >>>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
> >>>>   of the IPv6 'Traffic Class' field) requires special treatment =
on=20
> >>>>   decapsulation in
> >>>>   order to avoid discarding indications of congestion,=20
> >>>>   inline with section 4.2 of [RFC6040]. If
> >>>>   the 'ECN=E2=80=98 field of the outer header contains a =
congestion indication    =20
> >>>>   codepoint (the
> >>>>   value is '11', the Congestion Experienced (CE) codepoint) and =
the inner=20
> >>>>   header indicates ECN support (either ECT(0) or ECT(1) codepoint =
is set),=20
> >>>>   then ETR decapsulation MUST also set CE field in the inner =
header that is=20
> >>>>   used
> >>>>   to forward the packet beyond the ETR. If the inner packet is =
marked as non-
> >>>>   ECT but the outer header has the CE mark set, the packet MUST =
be dropped=20
> >>>>   instead. Any discrepancy between the inner and outer header for =
non-ECT,=20
> >>>>   ECT(0) and ECT(1) MUST NOT be copied from the outer header. =
These=20
> >>>>   requirements preserve
> >>>>   CE indications when a packet that is ECN-capable traverses a =
LISP tunnel
> >>>>   and becomes marked with a CE indication due to congestion =
between
> >>>>   the tunnel endpoints or transforms an CE into loss if that =
packet is not=20
> >>>>   ECN-capable conserving the congestion indication towards a =
non-ECN enables=20
> >>>>   endpoint.=E2=80=9D
> >>>=20
> >>> I didn=E2=80=99t include this text because (1) it under states =
what to do with IPv4, (2) it has too much detail that is already in =
RFC6040, and (3) it undoes text that other reviewers have offered.
> >>=20
> >> I didn=E2=80=99t change the mentioning of IPv6 here. Yes please at =
IPv4.
> >>=20
> >> You can remove all this text and only point to rfc6040. That would =
actually my preferred solution. I don=E2=80=99t think it =E2=80=9Eundoes=E2=
=80=9C text; it just adds what was missing in compliance with RFC6040. =
Anyway it doesn=E2=80=99t matter point being that it should specify the =
same things as RFC6040 does not matter what other have ofter because =
RFC6040 is the IETF-consensus doc how describing how to handle this.
> >>=20
> >>>=20
> >>>=20
> >>>> Please also remove the duplicated text after these bullet lists =
in the draft!
> >>>=20
> >>> You have to tell me what text. I am too confused at this point on =
what you want.
> >>=20
> >> This is the text in the en-/ and decapsulation lists:
> >>=20
> >> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
> >>     of the IPv6 'Traffic Class' field) requires special treatment =
in
> >>     order to avoid discarding indications of congestion [RFC3168].
> >>     ITR encapsulation MUST copy the 2-bit 'ECN' field from the =
inner
> >>     header to the outer header.  Re-encapsulation MUST copy the =
2-bit
> >>     'ECN' field from the stripped outer header to the new outer
> >>     header."
> >>=20
> >> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
> >>     of the IPv6 'Traffic Class' field) requires special treatment =
in
> >>     order to avoid discarding indications of congestion [RFC6040].  =
If
> >>     the 'ECN' field contains a congestion indication codepoint (the
> >>     value is '11', the Congestion Experienced (CE) codepoint), then
> >>     ETR decapsulation MUST copy the 2-bit 'ECN' field from the
> >>     stripped outer header to the surviving inner header that is =
used
> >>     to forward the packet beyond the ETR.  These requirements =
preserve
> >>     CE indications when a packet that uses ECN traverses a LISP =
tunnel
> >>     and becomes marked with a CE indication due to congestion =
between
> >>     the tunnel endpoints."
> >>=20
> >> And this text comes up right after the list in the same section:
> >>=20
> >> "The Explicit Congestion Notification ('ECN') field occupies bits 6
> >>  and 7 of both the IPv4 'Type of Service' field and the IPv6 =
'Traffic
> >>  Class' field [RFC6040].  The 'ECN' field requires special =
treatment
> >>  in order to avoid discarding indications of congestion [RFC6040].  =
An
> >>  ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the =
inner
> >>  header to the outer header.  Re-encapsulation MUST copy the 2-bit
> >>  'ECN' field from the stripped outer header to the new outer =
header.
> >>  If the 'ECN' field contains a congestion indication codepoint (the
> >>  value is '11', the Congestion Experienced (CE) codepoint), then =
ETR/
> >>  PETR decapsulation MUST copy the 2-bit 'ECN' field from the =
stripped
> >>  outer header to the surviving inner header that is used to forward
> >>  the packet beyond the ETR.  These requirements preserve CE
> >>  indications when a packet that uses ECN traverses a LISP tunnel =
and
> >>  becomes marked with a CE indication due to congestion between the
> >>  tunnel endpoints."
> >>=20
> >> The last text bit does not add any information; it just states all =
normative requirement twice, even using basically exactly the some =
words. This can lead to discrepancies and it really not necessary. I=E2=80=
=99d recommend to just remove the last text block here (and fix the =
IPv6/IPv4 issue in the other blocks).
> >>=20
> >> Mirja
> >>=20
> >>=20
> >>>=20
> >>>> Further I believe my discuss points 2) and 4) are not fully =
resolved yet. Also I would like to at least see more explanation about =
the approach for extensibility that was taken in this doc (point 6).
> >>>=20
> >>> You are going to have to repeat what they are because too many =
emails have flown by since your initial post. And for extensibility, we =
discuss it in RFC8060 and don=E2=80=99t think anything more should be =
said here otherwise, we will duplicate unnecessary text.
> >>>=20
> >>> Another new diff file enclosed.
> >>>=20
> >>> Dino
> >>>=20
> >>>=20
> >>>=20
> >>>=20
> >>>=20
> >>>=20
> >>=20
> >=20
>=20


From nobody Thu Sep 20 08:23:18 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F209130EB2 for ; Thu, 20 Sep 2018 08:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level: 
X-Spam-Status: No, score=-2.311 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 drLnR6ABBO8n for ; Thu, 20 Sep 2018 08:23:11 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC67A130E96 for ; Thu, 20 Sep 2018 08:23:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537456988; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mAK/4kmW56GVcupmEtWpLbZ+G8cyT8acVqQsiv3yZgA=; b=ByAR/KVQIG4ah//GlbpyKoaHh6K1JiaF3x3GY/SuK54ghwpG5DSx/8qjTx0khblt 1NPY8deU/8ho4ccES/fra0FANmu3e1qaFmhCv8pdm/YCMHPRW3YRl9chc+aOZUU5 JHUnTMeIyibLi84jjRHgnW+ANxKhJo1m+tNo2biTygM=;
X-AuditID: c1b4fb30-fe1ff700000055da-eb-5ba3bb5c98e9
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 59.50.21978.C5BB3AB5; Thu, 20 Sep 2018 17:23:08 +0200 (CEST)
Received: from [147.214.20.163] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 20 Sep 2018 17:23:08 +0200
To: "BRUNGARD, DEBORAH A" , Fabio Maino , "tsv-art@ietf.org" 
CC: "lisp@ietf.org" , "ietf@ietf.org" , "draft-ietf-lisp-gpe.all@ietf.org" 
References: <153553422964.14784.628403975182959075@ietfa.amsl.com>    
From: Magnus Westerlund 
Message-ID: <6b946442-36fc-b43d-39a7-2c6363c33857@ericsson.com>
Date: Thu, 20 Sep 2018 17:23:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D6F9556F7FE8EA3586FF082F"
Content-Language: en-US
X-Originating-IP: [153.88.183.153]
X-ClientProxiedBy: ESESSMB501.ericsson.se (153.88.183.162) To ESESSMB502.ericsson.se (153.88.183.163)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2J7hW7M7sXRBu/7VCwud3WzW7R+3cdo cWHHP0aLZxvns1hMOatuMWvPIhYHNo+X/XMYPab83sjqsWTJT6YA5igum5TUnMyy1CJ9uwSu jJenEgp2vGSqWLp8JXMD49k+pi5GTg4JAROJr4eeMHYxcnEICRxllPiwbhYbhPOBUeLBtYMs IFXCAnYSX9tamEFsEYFiiXU354J1MAv0Mkp0z9sPViQkcJpJ4sikcBCbTcBC4uaPRjYQm1fA XmLT8kusIDaLgKpEQ/9+oEEcHKIC0RKf/mdClAhKnJz5BGwMp0CUxIMPy8BamQXCJG5fusEI YYtL3HoynwlilbZEQ1MHK8QHShLX511nARkpIZAu8fo03wRGoVlIps5CMmkWkkkQtoXEzPnn oeLaEssWvmaGsDUkWufMZYew5SWat85mXsDIvopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMj MLIObvltsIPx5XPHQ4wCHIxKPLy5WxZHC7EmlhVX5h5ilOBgVhLhLeoBCvGmJFZWpRblxxeV 5qQWH2KU5mBREue18NscJSSQnliSmp2aWpBaBJNl4uCUamCcwbgqTzbxVSGbuORjr/vmxad2 LZx0WcqrY8+Ox9ahzkmiOjJaDMpR09tvrHCJr/UUvHF9ModT+E2pb6/+9W6PP3jyUK1j7Ht7 pSMbGarWbSnpauszLC04pjt/9qRnIq/nqi5qX7aXnV+frfttpLxA3w7rOVFF5bv5TgtyWa3b wfdxykXeS9ZKLMUZiYZazEXFiQBTS4ZdqAIAAA==
Archived-At: 
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Sep 2018 15:23:16 -0000

--------------D6F9556F7FE8EA3586FF082F
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: quoted-printable


On 9/20/2018 3:15 PM, BRUNGARD, DEBORAH A wrote:
>
> Hi Magnus,
>
> Interesting =E2=80=93 I haven=E2=80=99t seen it in Routing Area documen=
ts =E2=80=93 the=20
> (technical) advice is given in the applicable sections of the RFC=20
> itself. Do you have examples from the Transport Area?
>

Yes, varying practices between area is not that uncommon. We have done=20
this quite common in ART. This is one example of a registry I an the=20
designated expert for. Where

https://tools.ietf.org/html/rfc8285#section-10.1

As you can see the IANA section contains fairly detailed review=20
consideration for the expert.

Similar rules but less extensive as the need was less in one of the=20
RFC's I have co-authored:

https://tools.ietf.org/html/rfc7826#section-22.9

This IANA section was reviewed multiple times by IANA, including a first =

case when the document was finishing up the WG process due to its=20
extensive nature (13 new registries, 22 pages). So IANA appears to have=20
no issues with this information.

Even if the requirements are not in the IANA section, there need to be=20
an explicit reference from the IANA section to the relevant text in the=20
document that provides the requirements, otherwise they are easily=20
missed in my experience.


> Always open to discussion =E2=80=93 let=E2=80=99s take to a smaller lis=
t among the=20
> working group chairs and IANA =E2=80=93 and then can get back to the la=
rger=20
> list. I would (hopefully) say when the working group chooses to update =

> (or the RFC=E2=80=99s expert reviewer) the registry, they follow their =
RFC,=20
> not just the IANA section. Not to jump on process to rationalize =E2=80=
=93=20
> RFC8126 is quite clear to keep IANA considerations for IANA. If others =

> feel the same, can always update to clarify. Let=E2=80=99s talk more.
>

Please consider it, my experience is that having known requirements=20
easily found and accessible helps a lot and avoid late surprises.

Cheers

Magnus Westerlund


>
> Thanks,
>
> Deborah
>
> *From:*Magnus Westerlund 
> *Sent:* Thursday, September 20, 2018 4:14 AM
> *To:* BRUNGARD, DEBORAH A ; Fabio Maino=20
> ; tsv-art@ietf.org
> *Cc:* lisp@ietf.org; ietf@ietf.org; draft-ietf-lisp-gpe.all@ietf.org
> *Subject:* Re: Tsvart last call review of draft-ietf-lisp-gpe-05
>
> Hi,
>
> On 9/19/2018 11:17 PM, BRUNGARD, DEBORAH A wrote:
>
>     Thanks Magnus for your careful review!
>
>     Fabio, on your suggested text below, it is not needed to duplicate
>     this in the IANA section. The IANA section provides guidelines on
>     assignment for IANA, not to future authors - it would not be for
>     IANA to ensure requests for registration provide the proper analysi=
s.
>
> Deborah I am disagreeing about this. The IANA section may contain=20
> requirements on the registration that further entries are required to=20
> fulfill. This becomes especially important in expert review=20
> registries. And in this case as a Standards Action registry, making=20
> explicit the expectations on new registries from the creators of the=20
> registries are very appropriate. It helps ensure that future=20
> extensions do think about important things.
>
> So I would really like to see the text stay in.
>
> Cheers
>
> Magnus
>
>     Thanks,
>
>     Deborah
>
>     *From:*Fabio Maino  
>     *Sent:* Tuesday, September 18, 2018 3:53 PM
>     *To:* Magnus Westerlund 
>     ; tsv-art@ietf.org
>     
>     *Cc:* lisp@ietf.org ; ietf@ietf.org
>     ; draft-ietf-lisp-gpe.all@ietf.org
>     
>     *Subject:* Re: Tsvart last call review of draft-ietf-lisp-gpe-05
>
>     Hi Magnus,
>     thanks for your comments.
>
>     I think I see the points you are making.
>
>     I'll add the section 3.1 below to specify the general transport
>     requirements for the registration of new LISP-GPE payloads, and I
>     will introduce two subsections to instantiate those requirements
>     for Ethernet and NSH (section 4.2 and 4.3 will be moved here). In
>     the "IANA Considerations" section I'll refer to this new section
>     3.1 as a requirement for registration of new encapsulated payload.
>
>     "3.1 Payload Specific Transport Interactions
>
>     To ensure that protocols that are encapsulated in LISP-GPE will
>     work well from a transport interaction perspective, the
>     specification of a new encapsulated payload MUST contain an
>     analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP
>     mapping, and Explicit Congestion Notification (ECN) bits whenever
>     they apply to the new encapsulated payload.
>
>     For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis]
>     specifies how to handle UDP Checksums encouraging implementors to
>     consider UDP checksum usage guidelines in section 3.4 of [RFC8085]
>     when it is desirable to protect UDP and LISP headers against
>     corruption. Each new encapsulated payloads, when registered with
>     LISP-GPE, MUST be accompanied by a similar analysis.
>
>     Encapsulated payloads may have a priority field that may or may
>     not be mapped to the DSCP field of the outer IP header (part of
>     Type of Service in IPv4 or Traffic Class in IPv6). Such new
>     encapsulated payloads, when registered with LISP-GPE, MUST be
>     accompanied by an analysis similar to the one performed in Section
>     3.1.1 of this document for Ethernet payloads.
>
>     Encapsulated payloads may have Explicit Congestion Notification
>     mechanisms that may or may not be mapped to the outer IP header
>     ECN field. Such new encapsulated payolads, when registered with
>     LISP-GPE, MUST=C2=A0 be accompanied by a set of guidelines derived =
from
>     [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].
>
>     The rest of this section specifies payload specific transport
>     interactions considerations for the two new LISP-GPE encapsulated
>     payloads specified in this document: Ethernet and NSH.
>
>     3.1.1 Payload Specific Transport Interactions for Ethernet
>     Encapsulated Payloads
>
>     The UDP Checksum considerations specified in section 5.3 of
>     [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated
>     Payloads. Implementors are encouraged to consider the UDP checksum
>     usage guidelines in section 3.4 of [RFC8085] when it is desirable
>     to protect UDP, LISP and Ethernet headers against corruption.
>
>     When a LISP-GPE router performs Ethernet encapsulation, the inner
>     802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be
>     mapped from the encapsulated frame to the Type of Service field in
>     the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'
>     field as per guidelines provided by [RFC8325].
>
>     When a LISP-GPE router performs Ethernet encapsulation, the inner
>     header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to,
>     or used to determine the LISP Instance ID field.
>
>     3.1.2 Payload Specific Transport Interactions for NSH Encapsulated
>     Payloads
>
>     The UDP Checksum considerations specified in section 5.3 of
>     [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads.
>     Implementors are encouraged to consider the UDP checksum usage
>     guidelines in section 3.4 of [RFC8085] when it is desirable to
>     protect UDP, LISP, and NSH headers against corruption.
>
>     When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN
>     values MAY be mapped as specified for the Next Protocol
>     encapsulated by NSH (namely IPv4, IPv6 and Ethernet)."
>
>
>     I will also add a paragraph to "Iana Considerations" that says:
>
>
>     "To ensure that protocols that are encapsulated in LISP-GPE will
>     work well from a transport interaction perspective, the
>     registration of a new encapsulated payload MUST contain an
>     analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP
>     mapping, and Explicit Congestion Notification (ECN) bits whenever
>     they apply to the new encapsulated payload. The analysis for the
>     new encapsulated payload registered in this document is in section
>     3.1."
>
>     Please, let me know if this address your comments.
>
>     Thanks,
>     Fabio
>
>
>
>     On 8/29/18 2:17 AM, Magnus Westerlund wrote:
>
>         Reviewer: Magnus Westerlund
>
>         Review result: Not Ready
>
>          =20
>
>         This document has been reviewed as part of the transport area d=
irectorate's
>
>         ongoing effort to review key IETF documents. These comments wer=
e written
>
>         primarily for the transport area directors, but are copied to t=
he document's
>
>         authors and WG for their information and to allow them to addre=
ss any issues
>
>         raised.
>
>          =20
>
>         When done at the time of IETF Last Call, the authors should con=
sider this
>
>         review together with any other last-call comments they receive.=

>
>         Please always CCtsv-art@ietf.org    if=
 you reply to or forward this review.
>
>          =20
>
>         Issue A.
>
>          =20
>
>         The reason I state Not Ready has to do with this documents fail=
ure to consider
>
>         the use of zero checksum for IPv6 when tunneling other things t=
han IP. The none
>
>         GPE version is limited to tunnel IP for which the analysis for =
use of zero
>
>         checksum has been done. Each of the new tunneled protocols that=
 are specified
>
>         in this document, i.e. ethernet and NHS, will need to perform t=
he analysis if
>
>         they are safe to use zero checksum or not, and if not disallow =
zero checksum
>
>         for IPv6/UDP. The documetn also need a requirement in the regis=
tration
>
>         requirements to perform this analysis and defined if zero check=
sum is
>
>         acceptable or not.
>
>          =20
>
>         Citing Section 5.3 of draft-ietf-lisp-rfc6830bis
>
>          =20
>
>          =C2=A0=C2=A0 UDP Checksum:=C2=A0 The 'UDP Checksum' field SHOU=
LD be transmitted as zero
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by an ITR for either IPv4 [RFC0=
768] and IPv6 encapsulation
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [RFC6935] [RFC6936].=C2=A0 When=
 a packet with a zero UDP checksum is
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 received by an ETR, the ETR MUS=
T accept the packet for
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 decapsulation.=C2=A0 When an IT=
R transmits a non-zero value for the UDP
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 checksum, it MUST send a correc=
tly computed value in this field.
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When an ETR receives a packet w=
ith a non-zero UDP checksum, it MAY
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 choose to verify the checksum v=
alue.=C2=A0 If it chooses to perform
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 such verification, and the veri=
fication fails, the packet MUST be
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 silently dropped.=C2=A0 If the =
ETR chooses not to perform the
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 verification, or performs the v=
erification successfully, the
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 packet MUST be accepted for dec=
apsulation.=C2=A0 The handling of UDP
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 zero checksums over IPv6 for al=
l tunneling protocols, including
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LISP, is subject to the applica=
bility statement in [RFC6936].
>
>          =20
>
>         The issue is that when LISP encapsulate other protocols the imp=
act of a
>
>         missdelivered tunnel packet to the wrong ETR can have different=
 impacts. As
>
>         well as errors in the headers of the encapsulated packet that m=
ay be assumed to
>
>         be protected by the encapsulating layer. Thus, individual analy=
sis of each
>
>         protocol that are tunneled are needed.
>
>          =20
>
>         B.) 4.2.=C2=A0 Type of Service
>
>          =20
>
>          =C2=A0=C2=A0 When a LISP-GPE router performs Ethernet encapsul=
ation, the inner
>
>          =C2=A0=C2=A0 802.1Q [IEEE.802.1Q_2014] priority code point (PC=
P) field MAY be
>
>          =C2=A0=C2=A0 mapped from the encapsulated frame to the Type of=
 Service field in
>
>          =C2=A0=C2=A0 the outer IPv4 header, or in the case of IPv6 the=
 'Traffic Class'
>
>          =C2=A0=C2=A0 field.
>
>          =20
>
>         Any recommendation about how to perform that mapping? Maybe par=
ts of
>
>         https://datatracker.ietf.org/doc/rfc8325/    are relevant in this context.
>
>          =20
>
>         C. General case of 4.2:
>
>          =20
>
>         I expect other protocols than Ethernet may have a priority fiel=
d that may or
>
>         may not be mapped to the DSCP field of the tunnel packet.
>
>          =20
>
>         I would expect that for new protocol registration in the LISP-G=
PE Next Protocol
>
>         Registry should consider this. Thus, it would be good to note t=
hat such
>
>         considerations are needed and part of what should be evaluated =
for new
>
>         registrations.
>
>          =20
>
>         D. ECN handling
>
>          =20
>
>         Section 5.3 of draft-ietf-lisp-rfc6830bis states:
>
>          =20
>
>          =C2=A0=C2=A0 o=C2=A0 The 'Explicit Congestion Notification' (E=
CN) field (bits 6 and 7
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the IPv6 'Traffic Class' fie=
ld) requires special treatment in
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 order to avoid discarding indic=
ations of congestion [RFC3168].
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ITR encapsulation MUST copy the=
 2-bit 'ECN' field from the inner
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 header to the outer header.=C2=A0=
 Re-encapsulation MUST copy the 2-bit
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 'ECN' field from the stripped o=
uter header to the new outer
>
>          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 header.
>
>          =20
>
>         The above rules may not be applicable for all transport protoco=
ls. Thus I think
>
>         it is required that one do protocol specific considerations of =
ECN. TSVWG are
>
>         working on recommendations for tunnels handling of=C2=A0 ECN he=
re, see:
>
>         https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-gui=
delines/    Thus,
>
>         my expectation would be to ensure that the registered protocols=
 have defined
>
>         ECN handling, explicitly or by reference. Secondly that registr=
ation
>
>         requirement states the need for this consideration.
>
>          =20
>
>         Summary: To ensure that future added protocols that are encapsu=
lated will work
>
>         well from a transport interaction perspective there need to be =
a requirement on
>
>         new registration to consider and define how they use zero check=
sum, any DSCP
>
>         mapping and ECN bits. In addition the current document needs to=
 ensure these
>
>         things are clearly specified for the encapsulated protocols in =
this document.
>
>          =20
>
>          =20
>
> --=20
> Magnus Westerlund
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Phone=C2=A0 +46 10 7148287
> Torshamnsgatan 23=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com  
> ----------------------------------------------------------------------

--=20

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--------------D6F9556F7FE8EA3586FF082F
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
On 9/20/2018 3:15 PM, BRUNGARD, DEBORAH
      A wrote:

    

    

      
      
      
      

        
Hi Magnus,

        
 

        
Interesting
            – I haven’t seen it in Routing Area documents – the
            (technical) advice is given in the applicable sections of
            the RFC itself. Do you have examples from the Transport
            Area?

      

    

    


    

    
Yes, varying practices between area is not that uncommon. We have
      done this quite common in ART. This is one example of a registry I
      an the designated expert for. Where

    

    
https://tools.ietf.org/html/rfc8285#section-10.1

    
As you can see the IANA section contains fairly detailed review
      consideration for the expert. 

    

    
Similar rules but less extensive as the need was less in one of
      the RFC's I have co-authored:

    
https://tools.ietf.org/html/rfc7826#section-22.9

    
This IANA section was reviewed multiple times by IANA, including
      a first case when the document was finishing up the WG process due
      to its extensive nature (13 new registries, 22 pages). So IANA
      appears to have no issues with this information. 

    

    
Even if the requirements are not in the IANA section, there need
      to be an explicit reference from the IANA section to the relevant
      text in the document that provides the requirements, otherwise
      they are easily missed in my experience. 

    

    


    

    

      

        

        
 

        
Always open
            to discussion – let’s take to a smaller list among the
            working group chairs and IANA – and then can get back to the
            larger list. I would (hopefully) say when the working group
            chooses to update (or the RFC’s expert reviewer) the
            registry, they follow their RFC, not just the IANA section.
            Not to jump on process to rationalize – RFC8126 is quite
            clear to keep IANA considerations for IANA. If others feel
            the same, can always update to clarify. Let’s talk more.

      

    

    


    

    
Please consider it, my experience is that having known
      requirements easily found and accessible helps a lot and avoid
      late surprises. 

    

    
Cheers

    
Magnus Westerlund

    

    


    

    

      

        


            

        
 

        
Thanks,

        
Deborah

        
 

        
 

        

          

            
From: Magnus Westerlund
                <magnus.westerlund@ericsson.com>
                

                Sent: Thursday, September 20, 2018 4:14 AM

                To: BRUNGARD, DEBORAH A <db3546@att.com>;
                Fabio Maino <fmaino@cisco.com>; tsv-art@ietf.org

                Cc: lisp@ietf.org; ietf@ietf.org;
                draft-ietf-lisp-gpe.all@ietf.org

                Subject: Re: Tsvart last call review of
                draft-ietf-lisp-gpe-05

          

        

        
 

        
Hi,

        

          
On 9/19/2018 11:17 PM, BRUNGARD, DEBORAH
            A wrote:

        

        

          
Thanks
              Magnus for your careful review!

          
 

          
Fabio, on
              your suggested text below, it is not needed to duplicate
              this in the IANA section. The IANA section provides
              guidelines on assignment for IANA, not to future authors -
              it would not be for IANA to ensure requests for
              registration provide the proper analysis.

        

        
 

        
Deborah I am disagreeing about this. The IANA section may
          contain requirements on the registration that further entries
          are required to fulfill. This becomes especially important in
          expert review registries. And in this case as a Standards
          Action registry, making explicit the expectations on new
          registries from the creators of the registries are very
          appropriate. It helps ensure that future extensions do think
          about important things.
          

        
So I would really like to see the text stay in. 

        
Cheers

        
Magnus

        
 

        

          
 

          
Thanks,

          
Deborah

          
 

          
 

          

            

              
From: Fabio Maino
                  <fmaino@cisco.com>
                  

                  Sent: Tuesday, September 18, 2018 3:53 PM

                  To: Magnus Westerlund <magnus.westerlund@ericsson.com>;
                  tsv-art@ietf.org

                  Cc: lisp@ietf.org; 
                    ietf@ietf.org; draft-ietf-lisp-gpe.all@ietf.org

                  Subject: Re: Tsvart last call review of
                  draft-ietf-lisp-gpe-05

            

          

          
 

          

            
Hi Magnus, 

              thanks for your comments. 

              

              I think I see the points you are making. 

              

              I'll add the section 3.1 below to specify the general
              transport requirements for the registration of new
              LISP-GPE payloads, and I will introduce two subsections to
              instantiate those requirements for Ethernet and NSH
              (section 4.2 and 4.3 will be moved here). In the "IANA
              Considerations" section I'll refer to this new section 3.1
              as a requirement for registration of new encapsulated
              payload.
              

              

              "3.1 Payload Specific Transport Interactions

              

              To ensure that protocols that are encapsulated in LISP-GPE
              will work well from a transport interaction perspective,
              the specification of a new encapsulated payload MUST
              contain an analysis of how LISP-GPE SHOULD deal with outer
              UDP Checksum, DSCP mapping, and Explicit Congestion
              Notification (ECN) bits whenever they apply to the new
              encapsulated payload.

              

              For IP payloads, section 5.3 of
              [draft-ietf-lisp-rfc6830bis] specifies how to handle UDP
              Checksums encouraging implementors to consider UDP
              checksum usage guidelines in section 3.4 of [RFC8085] when
              it is desirable to protect UDP and LISP headers against
              corruption. Each new encapsulated payloads, when
              registered with LISP-GPE, MUST be accompanied by a similar
              analysis.

              

              Encapsulated payloads may have a priority field that may
              or may not be mapped to the DSCP field of the outer IP
              header (part of Type of Service in IPv4 or Traffic Class
              in IPv6). Such new encapsulated payloads, when registered
              with LISP-GPE, MUST be accompanied by an analysis similar
              to the one performed in Section 3.1.1 of this document for
              Ethernet payloads.
              

              

              Encapsulated payloads may have Explicit Congestion
              Notification mechanisms that may or may not be mapped to
              the outer IP header ECN field. Such new encapsulated
              payolads, when registered with LISP-GPE, MUST  be
              accompanied by a set of guidelines derived from
              [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. 

              

              The rest of this section specifies payload specific
              transport interactions considerations for the two new
              LISP-GPE encapsulated payloads specified in this document:
              Ethernet and NSH.
              

              

              3.1.1 Payload Specific Transport Interactions for Ethernet
              Encapsulated Payloads

              

              The UDP Checksum considerations specified in section 5.3
              of [draft-ietf-lisp-rfc6830bis] apply to Ethernet
              Encapsulated Payloads. Implementors are encouraged to
              consider the UDP checksum usage guidelines in section 3.4
              of [RFC8085] when it is desirable to protect UDP, LISP and
              Ethernet headers against corruption.

              

              When a LISP-GPE router performs Ethernet encapsulation,
              the inner 802.1Q [IEEE.802.1Q_2014] priority code point
              (PCP) field MAY be mapped from the encapsulated frame to
              the Type of Service field in the outer IPv4 header, or in
              the case of IPv6 the 'Traffic Class' field as per
              guidelines provided by [RFC8325].

              

              When a LISP-GPE router performs Ethernet encapsulation,
              the inner header 802.1Q [IEEE8021Q] VLAN Identifier (VID)
              MAY be mapped to, or used to determine the LISP Instance
              ID field.

              

              3.1.2 Payload Specific Transport Interactions for NSH
              Encapsulated Payloads 

              

              The UDP Checksum considerations specified in section 5.3
              of [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated
              Payloads. Implementors are encouraged to consider the UDP
              checksum usage guidelines in section 3.4 of [RFC8085] when
              it is desirable to protect UDP, LISP, and NSH headers
              against corruption.

              

              When a LISP-GPE router performs an NSH encapsulation, DSCP
              and ECN values MAY be mapped as specified for the Next
              Protocol encapsulated by NSH (namely IPv4, IPv6 and
              Ethernet)." 
              

              

              

              I will also add a paragraph to "Iana Considerations" that
              says: 

              

              

              "To ensure that protocols that are encapsulated in
              LISP-GPE will work well from a transport interaction
              perspective, the registration of a new encapsulated
              payload MUST contain an analysis of how LISP-GPE SHOULD
              deal with outer UDP Checksum, DSCP mapping, and Explicit
              Congestion Notification (ECN) bits whenever they apply to
              the new encapsulated payload. The analysis for the new
              encapsulated payload registered in this document is in
              section 3.1."

              

              Please, let me know if this address your comments. 

              

              Thanks,

              Fabio

              

              

              

              On 8/29/18 2:17 AM, Magnus Westerlund wrote:

          

          

            
Reviewer: Magnus Westerlund

            
Review result: Not Ready

            
 

            
This document has been reviewed as part of the transport area directorate's

            
ongoing effort to review key IETF documents. These comments were written

            
primarily for the transport area directors, but are copied to the document's

            
authors and WG for their information and to allow them to address any issues

            
raised.

            
 

            
When done at the time of IETF Last Call, the authors should consider this

            
review together with any other last-call comments they receive.

            
Please always CC tsv-art@ietf.org if you reply to or forward this review.

            
 

            
Issue A.

            
 

            
The reason I state Not Ready has to do with this documents failure to consider

            
the use of zero checksum for IPv6 when tunneling other things than IP. The none

            
GPE version is limited to tunnel IP for which the analysis for use of zero

            
checksum has been done. Each of the new tunneled protocols that are specified

            
in this document, i.e. ethernet and NHS, will need to perform the analysis if

            
they are safe to use zero checksum or not, and if not disallow zero checksum

            
for IPv6/UDP. The documetn also need a requirement in the registration

            
requirements to perform this analysis and defined if zero checksum is

            
acceptable or not.

            
 

            
Citing Section 5.3 of draft-ietf-lisp-rfc6830bis

            
 

            
   UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as zero

            
      by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation

            
      [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is

            
      received by an ETR, the ETR MUST accept the packet for

            
      decapsulation.  When an ITR transmits a non-zero value for the UDP

            
      checksum, it MUST send a correctly computed value in this field.

            
      When an ETR receives a packet with a non-zero UDP checksum, it MAY

            
      choose to verify the checksum value.  If it chooses to perform

            
      such verification, and the verification fails, the packet MUST be

            
      silently dropped.  If the ETR chooses not to perform the

            
      verification, or performs the verification successfully, the

            
      packet MUST be accepted for decapsulation.  The handling of UDP

            
      zero checksums over IPv6 for all tunneling protocols, including

            
      LISP, is subject to the applicability statement in [RFC6936].

            
 

            
The issue is that when LISP encapsulate other protocols the impact of a

            
missdelivered tunnel packet to the wrong ETR can have different impacts. As

            
well as errors in the headers of the encapsulated packet that may be assumed to

            
be protected by the encapsulating layer. Thus, individual analysis of each

            
protocol that are tunneled are needed.

            
 

            
B.) 4.2.  Type of Service

            
 

            
   When a LISP-GPE router performs Ethernet encapsulation, the inner

            
   802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be

            
   mapped from the encapsulated frame to the Type of Service field in

            
   the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'

            
   field.

            
 

            
Any recommendation about how to perform that mapping? Maybe parts of

            
https://datatracker.ietf.org/doc/rfc8325/ are relevant in this context.

            
 

            
C. General case of 4.2:

            
 

            
I expect other protocols than Ethernet may have a priority field that may or

            
may not be mapped to the DSCP field of the tunnel packet.

            
 

            
I would expect that for new protocol registration in the LISP-GPE Next Protocol

            
Registry should consider this. Thus, it would be good to note that such

            
considerations are needed and part of what should be evaluated for new

            
registrations.

            
 

            
D. ECN handling

            
 

            
Section 5.3 of draft-ietf-lisp-rfc6830bis states:

            
 

            
   o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7

            
      of the IPv6 'Traffic Class' field) requires special treatment in

            
      order to avoid discarding indications of congestion [RFC3168].

            
      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner

            
      header to the outer header.  Re-encapsulation MUST copy the 2-bit

            
      'ECN' field from the stripped outer header to the new outer

            
      header.

            
 

            
The above rules may not be applicable for all transport protocols. Thus I think

            
it is required that one do protocol specific considerations of ECN. TSVWG are

            
working on recommendations for tunnels handling of  ECN here, see: 

            
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ Thus,

            
my expectation would be to ensure that the registered protocols have defined

            
ECN handling, explicitly or by reference. Secondly that registration

            
requirement states the need for this consideration.

            
 

            
Summary: To ensure that future added protocols that are encapsulated will work

            
well from a transport interaction perspective there need to be a requirement on

            
new registration to consider and define how they use zero checksum, any DSCP

            
mapping and ECN bits. In addition the current document needs to ensure these

            
things are clearly specified for the encapsulated protocols in this document.

            
 

            
 

          

          
 

        

        
-- 

        
 

        
Magnus Westerlund 

        
 

        
----------------------------------------------------------------------

        
Network Architecture & Protocols, Ericsson Research

        
----------------------------------------------------------------------

        
Ericsson AB                 | Phone  +46 10 7148287

        
Torshamnsgatan 23           | Mobile +46 73 0949079

        
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

        
----------------------------------------------------------------------

      

    

    
-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

  


--------------D6F9556F7FE8EA3586FF082F--


From nobody Thu Sep 20 09:40:05 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B98812D7F8; Thu, 20 Sep 2018 09:39:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 yXIm4KK_P5b5; Thu, 20 Sep 2018 09:39:51 -0700 (PDT)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 235441292AD; Thu, 20 Sep 2018 09:39:51 -0700 (PDT)
Received: by mail-yb1-xb30.google.com with SMTP id 5-v6so4190846ybf.3; Thu, 20 Sep 2018 09:39:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZMedDYB1zMwp85gR0RnxUWBEssUwQNHgtqnLFcI8Yzo=; b=k5HA5LbmWaBP7a8fCkWZClVTLq6ylDPAC8ENhDfC3iAMRtwuWR61Nt0MdTQoY0TZ7T SlPSuzej7MTHevVlecMQ8oIrMTU9biKkIJ/vEmK0T18tiUSwOIQWj9AsLdfpMfBeKKSI BtAxKNNnpWtMlzNs36rhX1xK80/hAlJVWtKs9nqS3jElCPQJzs2+KLYALdch9OcEpm02 W8VjjHCrOwJ3fcecNJPMjpaFZkH2O36sWtPaH41cXDwXAWSYIUGMeKBqsevCt527F10x a6wy/0Xap1+OUgg8j0r8R64ExY4ztVdew01LIgN73S2JK54f7QmOLMSoyGhD1chwFEEj vXXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZMedDYB1zMwp85gR0RnxUWBEssUwQNHgtqnLFcI8Yzo=; b=TYPDtH0U5+zJV6XPxgnfAdnfbWvNXhXFnHFyGagFRafjPSPe+po5b/f7TssvQUxb5r JAFPLibSFfJU9aIBTvXiFqJcA8lbPlXjaDlR2k5s0y/TtFuWX6iYQ4VE9aNaVcMv+4y9 HEtRZ31xZRKOIge+ARTWS4KVrZt1LsVAQZZwdPm2Gh3ZAwS0dE+ZhoJ8nR1GmvsrcECs r+fA7hZ4Ac8wZD9lV7zy34vdLyC+tcJOnFu7IhkZ1wrQHtZYIg0vtH2Z7WrSlI5NoRTJ gyttxQnSjqalqCllb12bsQ6YcRAZph24RqzABGMbdRQpnbGVj2ELfrQLG4N7uZNfm2SK ITrw==
X-Gm-Message-State: APzg51CVAYv8IiLgh+ex6NmGxKh7d6QbUgsljTNXhEIvuO0Zm0mIDnjo nBGgs3ydgUfeHnlBNpUWHb2C2NVcPi3TqQcbKSg=
X-Google-Smtp-Source: ANB0VdbjBYP06A6rSqx/1v00ebgKacbmpUpAiDSmKFWC+/SJv9GkY8dm8oPHEgBi3ADLeZ8wETupso4Qh6qGfLvE0lM=
X-Received: by 2002:a25:dc05:: with SMTP id y5-v6mr4927378ybe.389.1537461590178;  Thu, 20 Sep 2018 09:39:50 -0700 (PDT)
MIME-Version: 1.0
References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net>  <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com>   <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net>  <0B314B5A-5F7C-45B3-B1B3-690F050A5424@kuehlewind.net>
In-Reply-To: <0B314B5A-5F7C-45B3-B1B3-690F050A5424@kuehlewind.net>
From: Spencer Dawkins at IETF 
Date: Thu, 20 Sep 2018 11:39:37 -0500
Message-ID: 
To: Mirja Kuehlewind 
Cc: lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org,  IESG , Dino Farinacci , Luigi Iannone , lisp@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f0430c0576502b9f"
Archived-At: 
Subject: Re: [lisp]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Sep 2018 16:39:53 -0000

--000000000000f0430c0576502b9f
Content-Type: text/plain; charset="UTF-8"

Hi, Mirja,

On Thu, Sep 20, 2018 at 10:04 AM Mirja Kuehlewind (IETF) <
ietf@kuehlewind.net> wrote:

> Hi Spencer,
>
> this conversation was mostly on ECN.


My apologies to all, for helping unhelpfully. I'll do the right thing on my
ballot.


> For the MTU issue, I think the solution is to restrict the message size of
> lisp messages such that no PMTU discovery is needed.


Also works for me.

Spencer, who really can't send comments on documents in IESG evaluation
during QUIC interim meetings, no matter how much he wishes he could.

--000000000000f0430c0576502b9f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi, Mirja,=C2=A0

On Thu, Sep 20, 2018 at 10:04 AM Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
<=
/div>
Hi Spencer,



this conversation was mostly on ECN. 

My ap=
ologies to all, for helping unhelpfully. I'll do the right thing on my =
ballot.=C2=A0
=C2=A0
For the =
MTU issue, I think the solution is to restrict the message size of lisp mes=
sages such that no PMTU discovery is needed.

Also works for me.

Spencer, who really can't=
 send comments on documents in IESG evaluation during QUIC interim meetings=
, no matter how much he wishes he could.=C2=A0


--000000000000f0430c0576502b9f--


From nobody Thu Sep 20 11:24:01 2018
Return-Path: 
X-Original-To: lisp@ietf.org
Delivered-To: lisp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F2F130E67; Thu, 20 Sep 2018 11:23:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kyle Rose 
To: 
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153746783815.5331.10419091174803926555@ietfa.amsl.com>
Date: Thu, 20 Sep 2018 11:23:58 -0700
Archived-At: 
Subject: [lisp] Secdir telechat review of draft-ietf-lisp-rfc6830bis-18
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: 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, 20 Sep 2018 18:23:58 -0000

Reviewer: Kyle Rose
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

I have reviewed the -15/-18 diff and found no changes relevant to the points I
raised in the first review and its subsequent discussion. I maintain that some
reorganization is warranted to clarify the intended security properties of the
system, especially given the complexity of the overall LISP ecosystem and the
choice to move documents separately, complicating the realistic need to review
them as a block. Otherwise, I have nothing further to add.


From nobody Thu Sep 20 13:04:01 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A1D130E2D; Thu, 20 Sep 2018 13:03:59 -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_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 cMSItOPvSM6z; Thu, 20 Sep 2018 13:03:55 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493D3130DF6; Thu, 20 Sep 2018 13:03:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27676; q=dns/txt; s=iport; t=1537473834; x=1538683434; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=y9fKvxhiXB2vAgXaefotbxtipXqbLZwtW/2ah+mYrxg=; b=YBFPaXQNt6UPJghWJCn8oizHo4syXRAuwoS8aWK/H3WLXGAMdqX9PtDp 8C61UJIWyEk2BDUaBBEUqsT+I9J+Ph5UsGybfKMVCyeb0qLaGaC29gW5N pN3rHT6i5BscYn4hz4t4OaCf2QuDy6zTo9Sd1h7lT8mm4kGiGa+RwpijS A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAACV/KNb/51dJa1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYFTgVYFKmV/KINzlESCDXiVaoFmCyOESQKDQiE3FQEDAQECAQE?= =?us-ascii?q?CbRwMhTkBBRoJJDIOAgsSBicDAgIbKwMOBgEMBgIBAYMdAYIBD6N8gS4fgwq?= =?us-ascii?q?BCgc9hQ8FBYpqF4FBP4ESJ4I2NYMbAgMBgSoBCwcBJYJ7glcCiCIgBCyFdY4?= =?us-ascii?q?HCYZDgwaGVQYXgUSEUIJfhi+LcokDgVgiZHEzGggbFYMngiUXewEDBIdXhV4?= =?us-ascii?q?fMIsmDxeCJgEB?=
X-IronPort-AV: E=Sophos;i="5.54,281,1534809600";  d="scan'208,217";a="451942747"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2018 20:03:52 +0000
Received: from [10.32.173.108] ([10.32.173.108]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTP id w8KK3pvi021391; Thu, 20 Sep 2018 20:03:51 GMT
To: Magnus Westerlund , tsv-art@ietf.org
Cc: lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org
References: <153553422964.14784.628403975182959075@ietfa.amsl.com>  <5dd519c0-6810-8596-37e9-377e38175a7d@ericsson.com>
From: Fabio Maino 
Message-ID: <8856bfce-8d2f-baae-d85c-fea09ba86f69@cisco.com>
Date: Thu, 20 Sep 2018 13:03:51 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <5dd519c0-6810-8596-37e9-377e38175a7d@ericsson.com>
Content-Type: multipart/alternative; boundary="------------DB63CE837FBE5182ABD673B0"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.32.173.108, [10.32.173.108]
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: 
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Sep 2018 20:03:59 -0000

This is a multi-part message in MIME format.
--------------DB63CE837FBE5182ABD673B0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks Magnus,
I'll consolidate the changes we have agreed so far in the next rev that 
I plan to publish later today.

I'll then work on the comments on this email and will send you the 
corresponding actions.

Fabio

On 9/20/18 2:39 AM, Magnus Westerlund wrote:
>
> Hi Fabio,
>
> Most of the below text is excellent. Some comments inline for needed 
> clarifications and additions.
>
> On 9/18/2018 9:52 PM, Fabio Maino wrote:
>> Hi Magnus,
>> thanks for your comments.
>>
>> I think I see the points you are making.
>>
>> I'll add the section 3.1 below to specify the general transport 
>> requirements for the registration of new LISP-GPE payloads, and I 
>> will introduce two subsections to instantiate those requirements for 
>> Ethernet and NSH (section 4.2 and 4.3 will be moved here). In the 
>> "IANA Considerations" section I'll refer to this new section 3.1 as a 
>> requirement for registration of new encapsulated payload.
>>
>> "3.1 Payload Specific Transport Interactions
>>
>> To ensure that protocols that are encapsulated in LISP-GPE will work 
>> well from a transport interaction perspective, the specification of a 
>> new encapsulated payload MUST contain an analysis of how LISP-GPE 
>> SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit 
>> Congestion Notification (ECN) bits whenever they apply to the new 
>> encapsulated payload.
>>
>> For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] 
>> specifies how to handle UDP Checksums encouraging implementors to 
>> consider UDP checksum usage guidelines in section 3.4 of [RFC8085] 
>> when it is desirable to protect UDP and LISP headers against 
>> corruption. Each new encapsulated payloads, when registered with 
>> LISP-GPE, MUST be accompanied by a similar analysis.
>>
>> Encapsulated payloads may have a priority field that may or may not 
>> be mapped to the DSCP field of the outer IP header (part of Type of 
>> Service in IPv4 or Traffic Class in IPv6). Such new encapsulated 
>> payloads, when registered with LISP-GPE, MUST be accompanied by an 
>> analysis similar to the one performed in Section 3.1.1 of this 
>> document for Ethernet payloads.
>>
>> Encapsulated payloads may have Explicit Congestion Notification 
>> mechanisms that may or may not be mapped to the outer IP header ECN 
>> field. Such new encapsulated payolads, when registered with LISP-GPE, 
>> MUST  be accompanied by a set of guidelines derived from 
>> [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].
>>
>> The rest of this section specifies payload specific transport 
>> interactions considerations for the two new LISP-GPE encapsulated 
>> payloads specified in this document: Ethernet and NSH.
>>
>> 3.1.1 Payload Specific Transport Interactions for Ethernet 
>> Encapsulated Payloads
>>
>> The UDP Checksum considerations specified in section 5.3 of 
>> [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. 
>> Implementors are encouraged to consider the UDP checksum usage 
>> guidelines in section 3.4 of [RFC8085] when it is desirable to 
>> protect UDP, LISP and Ethernet headers against corruption.
>
> So this is not the necessary documentation of the analysis that 
> IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. 
> There needs to be an analysis here to verify that this protocol 
> combination do work. You will actually have to discuss how the 
> Ethernet encapsulation fulfills the requirements listed in Section 4 
> of RFC 6936.
>
> https://datatracker.ietf.org/doc/rfc7510/ is an example where such an 
> analysis was included. I would also note the applicability limitations 
> this has.
>
> Which actually brings up an additional issue for Ethernet 
> encapsulation. For IP the assumption is that the IP traffic that is 
> encapsulated is congestion controlled. This assumption is even less 
> certain when having Ethernet. Thus, some consideration of that issue 
> is likely needed.
>
>
>>
>> When a LISP-GPE router performs Ethernet encapsulation, the inner 
>> 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be 
>> mapped from the encapsulated frame to the Type of Service field in 
>> the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' 
>> field as per guidelines provided by [RFC8325].
>
> I don't know enough about IEEE and the various versions of Ethernet 
> and WLAN here to be certain that 802.1Q PCP's can be mapped directly 
> to the 802.11 User Priorities discussed in RFC8325. Please investigate 
> if they are the same, and if they are the same priorities, then make a 
> explicit statement that they are applicable.
>
>>
>> When a LISP-GPE router performs Ethernet encapsulation, the inner 
>> header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or 
>> used to determine the LISP Instance ID field.
>>
>> 3.1.2 Payload Specific Transport Interactions for NSH Encapsulated 
>> Payloads
>>
>> The UDP Checksum considerations specified in section 5.3 of 
>> [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. 
>> Implementors are encouraged to consider the UDP checksum usage 
>> guidelines in section 3.4 of [RFC8085] when it is desirable to 
>> protect UDP, LISP, and NSH headers against corruption.
>
> Same as for Ethernet also the NSH header needs to have a documented 
> analsysis of fulfillment of the requirements.
>
>
>>
>> When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN 
>> values MAY be mapped as specified for the Next Protocol encapsulated 
>> by NSH (namely IPv4, IPv6 and Ethernet)."
>>
>>
>> I will also add a paragraph to "Iana Considerations" that says:
>>
>>
>> "To ensure that protocols that are encapsulated in LISP-GPE will work 
>> well from a transport interaction perspective, the registration of a 
>> new encapsulated payload MUST contain an analysis of how LISP-GPE 
>> SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit 
>> Congestion Notification (ECN) bits whenever they apply to the new 
>> encapsulated payload. The analysis for the new encapsulated payload 
>> registered in this document is in section 3.1."
>>
>> Please, let me know if this address your comments.
>>
>> Thanks,
>> Fabio
>>
>>
>>
>> On 8/29/18 2:17 AM, Magnus Westerlund wrote:
>>> Reviewer: Magnus Westerlund
>>> Review result: Not Ready
>>>
>>> This document has been reviewed as part of the transport area directorate's
>>> ongoing effort to review key IETF documents. These comments were written
>>> primarily for the transport area directors, but are copied to the document's
>>> authors and WG for their information and to allow them to address any issues
>>> raised.
>>>
>>> When done at the time of IETF Last Call, the authors should consider this
>>> review together with any other last-call comments they receive.
>>> Please always CCtsv-art@ietf.org  if you reply to or forward this review.
>>>
>>> Issue A.
>>>
>>> The reason I state Not Ready has to do with this documents failure to consider
>>> the use of zero checksum for IPv6 when tunneling other things than IP. The none
>>> GPE version is limited to tunnel IP for which the analysis for use of zero
>>> checksum has been done. Each of the new tunneled protocols that are specified
>>> in this document, i.e. ethernet and NHS, will need to perform the analysis if
>>> they are safe to use zero checksum or not, and if not disallow zero checksum
>>> for IPv6/UDP. The documetn also need a requirement in the registration
>>> requirements to perform this analysis and defined if zero checksum is
>>> acceptable or not.
>>>
>>> Citing Section 5.3 of draft-ietf-lisp-rfc6830bis
>>>
>>>     UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as zero
>>>        by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
>>>        [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is
>>>        received by an ETR, the ETR MUST accept the packet for
>>>        decapsulation.  When an ITR transmits a non-zero value for the UDP
>>>        checksum, it MUST send a correctly computed value in this field.
>>>        When an ETR receives a packet with a non-zero UDP checksum, it MAY
>>>        choose to verify the checksum value.  If it chooses to perform
>>>        such verification, and the verification fails, the packet MUST be
>>>        silently dropped.  If the ETR chooses not to perform the
>>>        verification, or performs the verification successfully, the
>>>        packet MUST be accepted for decapsulation.  The handling of UDP
>>>        zero checksums over IPv6 for all tunneling protocols, including
>>>        LISP, is subject to the applicability statement in [RFC6936].
>>>
>>> The issue is that when LISP encapsulate other protocols the impact of a
>>> missdelivered tunnel packet to the wrong ETR can have different impacts. As
>>> well as errors in the headers of the encapsulated packet that may be assumed to
>>> be protected by the encapsulating layer. Thus, individual analysis of each
>>> protocol that are tunneled are needed.
>>>
>>> B.) 4.2.  Type of Service
>>>
>>>     When a LISP-GPE router performs Ethernet encapsulation, the inner
>>>     802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be
>>>     mapped from the encapsulated frame to the Type of Service field in
>>>     the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'
>>>     field.
>>>
>>> Any recommendation about how to perform that mapping? Maybe parts of
>>> https://datatracker.ietf.org/doc/rfc8325/  are relevant in this context.
>>>
>>> C. General case of 4.2:
>>>
>>> I expect other protocols than Ethernet may have a priority field that may or
>>> may not be mapped to the DSCP field of the tunnel packet.
>>>
>>> I would expect that for new protocol registration in the LISP-GPE Next Protocol
>>> Registry should consider this. Thus, it would be good to note that such
>>> considerations are needed and part of what should be evaluated for new
>>> registrations.
>>>
>>> D. ECN handling
>>>
>>> Section 5.3 of draft-ietf-lisp-rfc6830bis states:
>>>
>>>     o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>>>        of the IPv6 'Traffic Class' field) requires special treatment in
>>>        order to avoid discarding indications of congestion [RFC3168].
>>>        ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
>>>        header to the outer header.  Re-encapsulation MUST copy the 2-bit
>>>        'ECN' field from the stripped outer header to the new outer
>>>        header.
>>>
>>> The above rules may not be applicable for all transport protocols. Thus I think
>>> it is required that one do protocol specific considerations of ECN. TSVWG are
>>> working on recommendations for tunnels handling of  ECN here, see:
>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/  Thus,
>>> my expectation would be to ensure that the registered protocols have defined
>>> ECN handling, explicitly or by reference. Secondly that registration
>>> requirement states the need for this consideration.
>>>
>>> Summary: To ensure that future added protocols that are encapsulated will work
>>> well from a transport interaction perspective there need to be a requirement on
>>> new registration to consider and define how they use zero checksum, any DSCP
>>> mapping and ECN bits. In addition the current document needs to ensure these
>>> things are clearly specified for the encapsulated protocols in this document.
>>>
>>>
>>
> -- 
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------



--------------DB63CE837FBE5182ABD673B0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thanks Magnus, 

      I'll consolidate the changes we have agreed so far in the next rev
      that I plan to publish later today. 

      

      I'll then work on the comments on this email and will send you the
      corresponding actions. 

      

      Fabio

      

      On 9/20/18 2:39 AM, Magnus Westerlund wrote:

    

    

      
      
Hi Fabio,

      
Most of the below text is excellent. Some comments inline for
        needed clarifications and additions. 

      
On 9/18/2018 9:52 PM, Fabio Maino
        wrote:

      

      

        
        
Hi Magnus, 

          thanks for your comments. 

          

          I think I see the points you are making. 

          

          I'll add the section 3.1 below to specify the general
          transport requirements for the registration of new LISP-GPE
          payloads, and I will introduce two subsections to instantiate
          those requirements for Ethernet and NSH (section 4.2 and 4.3
          will be moved here). In the "IANA Considerations" section I'll
          refer to this new section 3.1 as a requirement for
          registration of new encapsulated payload. 

          

          "3.1 Payload Specific Transport Interactions

          

          To ensure that protocols that are encapsulated in LISP-GPE
          will work well from a transport interaction perspective, the
          specification of a new encapsulated payload MUST contain an
          analysis of how LISP-GPE SHOULD deal with outer UDP Checksum,
          DSCP mapping, and Explicit Congestion Notification (ECN) bits
          whenever they apply to the new encapsulated payload.

          

          For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis]
          specifies how to handle UDP Checksums encouraging implementors
          to consider UDP checksum usage guidelines in section 3.4 of
          [RFC8085] when it is desirable to protect UDP and LISP headers
          against corruption. Each new encapsulated payloads, when
          registered with LISP-GPE, MUST be accompanied by a similar
          analysis.

          

          Encapsulated payloads may have a priority field that may or
          may not be mapped to the DSCP field of the outer IP header
          (part of Type of Service in IPv4 or Traffic Class in IPv6).
          Such new encapsulated payloads, when registered with LISP-GPE,
          MUST be accompanied by an analysis similar to the one
          performed in Section 3.1.1 of this document for Ethernet
          payloads. 

          

          Encapsulated payloads may have Explicit Congestion
          Notification mechanisms that may or may not be mapped to the
          outer IP header ECN field. Such new encapsulated payolads,
          when registered with LISP-GPE, MUST  be accompanied by a set
          of guidelines derived from
          [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. 

          

          The rest of this section specifies payload specific transport
          interactions considerations for the two new LISP-GPE
          encapsulated payloads specified in this document: Ethernet and
          NSH. 

          

          3.1.1 Payload Specific Transport Interactions for Ethernet
          Encapsulated Payloads

          

          The UDP Checksum considerations specified in section 5.3 of
          [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated
          Payloads. Implementors are encouraged to consider the UDP
          checksum usage guidelines in section 3.4 of [RFC8085] when it
          is desirable to protect UDP, LISP and Ethernet headers against
          corruption.

        

      

      
So this is not the necessary documentation of the analysis that
        IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to
        use. There needs to be an analysis here to verify that this
        protocol combination do work. You will actually have to discuss
        how the Ethernet encapsulation fulfills the requirements listed
        in Section 4 of RFC 6936.  

      

      
https://datatracker.ietf.org/doc/rfc7510/
        is an example where such an analysis was included. I would also
        note the applicability limitations this has. 

      

      
Which actually brings up an additional issue for Ethernet
        encapsulation. For IP the assumption is that the IP traffic that
        is encapsulated is congestion controlled. This assumption is
        even less certain when having Ethernet. Thus, some consideration
        of that issue is likely needed. 

      

      


      

      

        
 

          When a LISP-GPE router performs Ethernet encapsulation, the
          inner 802.1Q [IEEE.802.1Q_2014] priority code point (PCP)
          field MAY be mapped from the encapsulated frame to the Type of
          Service field in the outer IPv4 header, or in the case of IPv6
          the 'Traffic Class' field as per guidelines provided by
          [RFC8325].

        

      

      
I don't know enough about IEEE and the various versions of
        Ethernet and WLAN here to be certain that 802.1Q PCP's can be
        mapped directly to the 802.11 User Priorities discussed in
        RFC8325. Please investigate if they are the same, and if they
        are the same priorities, then make a explicit statement that
        they are applicable. 

      

      

        
 

          When a LISP-GPE router performs Ethernet encapsulation, the
          inner header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be
          mapped to, or used to determine the LISP Instance ID field.

          

          3.1.2 Payload Specific Transport Interactions for NSH
          Encapsulated Payloads 

          

          The UDP Checksum considerations specified in section 5.3 of
          [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated
          Payloads. Implementors are encouraged to consider the UDP
          checksum usage guidelines in section 3.4 of [RFC8085] when it
          is desirable to protect UDP, LISP, and NSH headers against
          corruption.

        

      

      
Same as for Ethernet also the NSH header needs to have a
        documented analsysis of fulfillment of the requirements.

      


      

      

        
 

          When a LISP-GPE router performs an NSH encapsulation, DSCP and
          ECN values MAY be mapped as specified for the Next Protocol
          encapsulated by NSH (namely IPv4, IPv6 and Ethernet)."  

          

          

          I will also add a paragraph to "Iana Considerations" that
          says: 

          

          

          "To ensure that protocols that are encapsulated in LISP-GPE
          will work well from a transport interaction perspective, the
          registration of a new encapsulated payload MUST contain an
          analysis of how LISP-GPE SHOULD deal with outer UDP Checksum,
          DSCP mapping, and Explicit Congestion Notification (ECN) bits
          whenever they apply to the new encapsulated payload. The
          analysis for the new encapsulated payload registered in this
          document is in section 3.1."

          

          Please, let me know if this address your comments. 

          

          Thanks,

          Fabio

          

          

          

          On 8/29/18 2:17 AM, Magnus Westerlund wrote:

        

        

          
Reviewer: Magnus Westerlund
Review result: Not Ready

This document has been reviewed as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG for their information and to allow them to address any issues
raised.

When done at the time of IETF Last Call, the authors should consider this
review together with any other last-call comments they receive.
Please always CC tsv-art@ietf.org if you reply to or forward this review.

Issue A.

The reason I state Not Ready has to do with this documents failure to consider
the use of zero checksum for IPv6 when tunneling other things than IP. The none
GPE version is limited to tunnel IP for which the analysis for use of zero
checksum has been done. Each of the new tunneled protocols that are specified
in this document, i.e. ethernet and NHS, will need to perform the analysis if
they are safe to use zero checksum or not, and if not disallow zero checksum
for IPv6/UDP. The documetn also need a requirement in the registration
requirements to perform this analysis and defined if zero checksum is
acceptable or not.

Citing Section 5.3 of draft-ietf-lisp-rfc6830bis

   UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as zero
      by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
      [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is
      received by an ETR, the ETR MUST accept the packet for
      decapsulation.  When an ITR transmits a non-zero value for the UDP
      checksum, it MUST send a correctly computed value in this field.
      When an ETR receives a packet with a non-zero UDP checksum, it MAY
      choose to verify the checksum value.  If it chooses to perform
      such verification, and the verification fails, the packet MUST be
      silently dropped.  If the ETR chooses not to perform the
      verification, or performs the verification successfully, the
      packet MUST be accepted for decapsulation.  The handling of UDP
      zero checksums over IPv6 for all tunneling protocols, including
      LISP, is subject to the applicability statement in [RFC6936].

The issue is that when LISP encapsulate other protocols the impact of a
missdelivered tunnel packet to the wrong ETR can have different impacts. As
well as errors in the headers of the encapsulated packet that may be assumed to
be protected by the encapsulating layer. Thus, individual analysis of each
protocol that are tunneled are needed.

B.) 4.2.  Type of Service

   When a LISP-GPE router performs Ethernet encapsulation, the inner
   802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be
   mapped from the encapsulated frame to the Type of Service field in
   the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'
   field.

Any recommendation about how to perform that mapping? Maybe parts of
https://datatracker.ietf.org/doc/rfc8325/ are relevant in this context.

C. General case of 4.2:

I expect other protocols than Ethernet may have a priority field that may or
may not be mapped to the DSCP field of the tunnel packet.

I would expect that for new protocol registration in the LISP-GPE Next Protocol
Registry should consider this. Thus, it would be good to note that such
considerations are needed and part of what should be evaluated for new
registrations.

D. ECN handling

Section 5.3 of draft-ietf-lisp-rfc6830bis states:

   o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion [RFC3168].
      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
      header to the outer header.  Re-encapsulation MUST copy the 2-bit
      'ECN' field from the stripped outer header to the new outer
      header.

The above rules may not be applicable for all transport protocols. Thus I think
it is required that one do protocol specific considerations of ECN. TSVWG are
working on recommendations for tunnels handling of  ECN here, see: 
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ Thus,
my expectation would be to ensure that the registered protocols have defined
ECN handling, explicitly or by reference. Secondly that registration
requirement states the need for this consideration.

Summary: To ensure that future added protocols that are encapsulated will work
well from a transport interaction perspective there need to be a requirement on
new registration to consider and define how they use zero checksum, any DSCP
mapping and ECN bits. In addition the current document needs to ensure these
things are clearly specified for the encapsulated protocols in this document.




        

        


        

      

      
-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

    

    


    

  


--------------DB63CE837FBE5182ABD673B0--


From nobody Thu Sep 20 13:22:41 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B5F1200D6; Thu, 20 Sep 2018 13:22:34 -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_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 YEnqN8slfoC3; Thu, 20 Sep 2018 13:22:32 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695731200D7; Thu, 20 Sep 2018 13:22:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2710; q=dns/txt; s=iport; t=1537474952; x=1538684552; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=S/kr+Agfs9ccBV36FXp7R4GAW+e/7268GvTWrqjCfyI=; b=G9j7Kyg8O0rJK4jHv5MQ0TgRHCe2nlKaBnyEapx31LJIxgAeJsyORItI SJTjnufAsfEKAMhVPb4K6jQ3FNUfZfGMs7ny6Uu9J++T96tuNpQn08p7X 4PhOqVlnYXdIAueSOFEK9jEdvAaba2cEWnTf3Fm7jcRSWcRUagMJDw+Ms Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuAAAaAaRb/5BdJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYFSggZlfyiDc5REgWgllk4UgWYLI4RJAoNCITYWAQMBAQI?= =?us-ascii?q?BAQJtHAyFOAEBAQECASMPAQUzDhALGAICJgICVwYBDAgBAReDBgGBeQgPo2K?= =?us-ascii?q?BLoQzBz2FDwWBC4lkF4FBP4E5DIIqNYMbAgECAYEqARIBgyCCVwKIRoYhhGu?= =?us-ascii?q?JHAmGQ4lbBheBRIRQgl+GL4hogwqJA4FJAy5kWBEIMxoIGxWDJ4IlFxGISYV?= =?us-ascii?q?eHzABizSCPQEB?=
X-IronPort-AV: E=Sophos;i="5.54,281,1534809600"; d="scan'208";a="458298303"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2018 20:22:11 +0000
Received: from [10.32.173.108] ([10.32.173.108]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTP id w8KKMAV8008972; Thu, 20 Sep 2018 20:22:11 GMT
To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG 
Cc: draft-ietf-lisp-gpe@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org
References: <153738612868.21424.5753365080841918983.idtracker@ietfa.amsl.com>
From: Fabio Maino 
Message-ID: 
Date: Thu, 20 Sep 2018 13:22:09 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <153738612868.21424.5753365080841918983.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.32.173.108, [10.32.173.108]
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: 
Subject: Re: [lisp]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-gpe-05=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Sep 2018 20:22:34 -0000

Thanks for your notes Mirja.

I'll publish an updated rev this evening to consolidate the changes that 
I believe we have agreed upon, and then I'll work on those that are 
still open.

Please see below.


On 9/19/18 12:42 PM, Mirja Kühlewind wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-lisp-gpe-05: 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 https://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:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks for addressing the TSV-ART review (and Magnus for doing the review)! I
> assume that the proposed text will be incorporated in the next version. (Would
> have been even better if those (larger) changes would have been added before
> the doc was put on the telechat; please update as soon as possible so other AD
> can review that text as well).
>
> However, I think the text still needs to say more about HOW the PCP should be
> mapped to DSCPs. RFC8325 doesn't provide guidelines but a mapping for 802.11.
> Is the same mapping applicable here?

Agree. As pointed out by Magnus' latest email there's more investigation 
needed here. I'll get back on this.

>
> Also, I'm not an expert for that part, but I guess there also is further
> guidance needed on HOW to map the VID...?

This is really straightforward, as the VID is a 12-bit field, and the 
IID is 24-bit. Implementation that I'm aware of typically carve a 
portion of the IID space to encode the VID.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Given this doc uses the last reserved bit in the lisp header, I would really
> like to see more discussion how the data plane lisp can still be extended. I
> think the solution is straight-forward (define a shim layer for the extension
> and announce this capability in the Map-Reply), however, spelling this out
> seems to be appropriate for this doc.

Correct, that's the idea. I'll add a sentence that states that a 
lisp-gpe next protocol header can be used to extend the lisp data-plane 
functions.


Thanks,
Fabio

>
>


From nobody Thu Sep 20 21:50:47 2018
Return-Path: 
X-Original-To: lisp@ietf.org
Delivered-To: lisp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F2B130DE7; Thu, 20 Sep 2018 21:50:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: lisp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: lisp@ietf.org
Message-ID: <153750543897.5327.2087156314852025297@ietfa.amsl.com>
Date: Thu, 20 Sep 2018 21:50:39 -0700
Archived-At: 
Subject: [lisp] I-D Action: draft-ietf-lisp-gpe-06.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: 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, 21 Sep 2018 04:50:39 -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 WG of the IETF.

        Title           : LISP Generic Protocol Extension
        Authors         : Fabio Maino
                          John Lemon
                          Puneet Agarwal
                          Darrel Lewis
                          Michael Smith
	Filename        : draft-ietf-lisp-gpe-06.txt
	Pages           : 12
	Date            : 2018-09-20

Abstract:
   This document describes extentions to the Locator/ID Separation
   Protocol (LISP) Data-Plane, via changes to the LISP header, to
   support multi-protocol encapsulation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lisp-gpe-06
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-gpe-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-gpe-06


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 Sep 20 22:12:59 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55917130DCA; Thu, 20 Sep 2018 22:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 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_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 TdetoeKp-dAB; Thu, 20 Sep 2018 22:12:45 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010F81292F1; Thu, 20 Sep 2018 22:12:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36870; q=dns/txt; s=iport; t=1537506765; x=1538716365; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to; bh=lGrAhDzGK447ImXnfqyzLYHWWCKLlprpTeYwd8Dwa5M=; b=iuK7jBLiPAXMPvrtQYiL6BB7crqJ0esicJLfBkTyEB+y73PEzP2bJNam cMOMuX8ex3S2DQj9StvoWUfKEwOoedFlBDI9OGFcmFh2qrqtHy4e3EaLK +dF5UV3gRWJTVkYOdVmkusYdTHZlaWH8Mm7uGBHxHhM4sars6zLwZVL43 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BJAAD6fKRb/5hdJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVIFWBSplfyiDc5RIgWAteJVqgWYLI4RJAoNCITcVAQM?= =?us-ascii?q?BAQIBAQJtHAyFOAEBAQECARoJJDIOAgsSBiAHAwICGysDDgYBDAYCAQGDHQG?= =?us-ascii?q?BeQgPojWBLh+DCoEKB4VUBYprF4FBP4ESJ4I2NYMbAgMBgSoBCwcBJYJ7glc?= =?us-ascii?q?CiCMYCAQshXhGjUIJhkODBoZXBheBRIRRgl+GMIt1iQiBWCJkcTMaCBsVgyc?= =?us-ascii?q?JghwXewEDBIQrgyyFXh8wARcBAYsjDxeCJgEB?=
X-IronPort-AV: E=Sophos;i="5.54,283,1534809600";  d="scan'208,217";a="174588174"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2018 05:12:42 +0000
Received: from [10.24.2.120] ([10.24.2.120]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w8L5Cfg1023093; Fri, 21 Sep 2018 05:12:41 GMT
From: Fabio Maino 
To: Magnus Westerlund , tsv-art@ietf.org
Cc: lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org, =?UTF-8?Q?Mirja_K=c3=bchlewind?= 
References: <153553422964.14784.628403975182959075@ietfa.amsl.com>  <5dd519c0-6810-8596-37e9-377e38175a7d@ericsson.com> <8856bfce-8d2f-baae-d85c-fea09ba86f69@cisco.com>
Message-ID: <29f21563-362e-e7cc-3e07-19ff14294eab@cisco.com>
Date: Thu, 20 Sep 2018 22:12:41 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <8856bfce-8d2f-baae-d85c-fea09ba86f69@cisco.com>
Content-Type: multipart/alternative; boundary="------------4DE0EC93AF321DDAAE0D180B"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.24.2.120, [10.24.2.120]
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: 
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 21 Sep 2018 05:12:50 -0000

This is a multi-part message in MIME format.
--------------4DE0EC93AF321DDAAE0D180B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I have incorporated the changes as discussed, so hopefully rev 6. can be 
used by reviewers before the telechat: 
https://www.ietf.org/id/draft-ietf-lisp-gpe-06.txt

Here is the diff: goo.gl/tCKD4A


I believe the following comments are still open. I'll work with the 
respective authors to address them in the next rev of the document.


A. [Deborah/Magnus] it is being discussed on a separate private thread 
if the following should be added to the IANA section:
"To ensure that protocols that are encapsulated in LISP-GPE will work 
well from a transport interaction perspective, the registration of a new 
encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD 
deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion 
Notification (ECN) bits whenever they apply to the new encapsulated 
payload. The analysis for the new encapsulated payload registered in 
this document is in section 3.1."


B. [Magnus] draft-ietf-tsvwg-ecn-encap-guidelines has expired yesterday, 
and cannot be referenced. I'll add it back to section 3.1 as soon as the 
draft is refreshed.

C. [Magnus/Mirja] in 3.1.1 Payload Specific Transport Interactions for 
Ethernet Encapsulated Payloads

 >>>The UDP Checksum considerations specified in section 5.3 of 
[draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. 
Implementors are encouraged to consider the UDP checksum usage 
guidelines in section 3.4 of [RFC8085] when it is desirable to protect 
UDP, LISP and Ethernet headers against corruption.

So this is not the necessary documentation of the analysis that 
IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. 
There needs to be an analysis here to verify that this protocol 
combination do work. You will actually have to discuss how the Ethernet 
encapsulation fulfills the requirements listed in Section 4 of RFC 6936.

https://datatracker.ietf.org/doc/rfc7510/ is an example where such an 
analysis was included. I would also note the applicability limitations 
this has.

Which actually brings up an additional issue for Ethernet encapsulation. 
For IP the assumption is that the IP traffic that is encapsulated is 
congestion controlled. This assumption is even less certain when having 
Ethernet. Thus, some consideration of that issue is likely needed.

 >>>When a LISP-GPE router performs Ethernet encapsulation, the inner 
802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be mapped 
from the encapsulated frame to the Type of Service field in the outer 
IPv4 header, or in the case of IPv6 the 'Traffic Class' field as per 
guidelines provided by [RFC8325].

I don't know enough about IEEE and the various versions of Ethernet and 
WLAN here to be certain that 802.1Q PCP's can be mapped directly to the 
802.11 User Priorities discussed in RFC8325. Please investigate if they 
are the same, and if they are the same priorities, then make a explicit 
statement that they are applicable.

D. [Magnus] 3.1.2 Payload Specific Transport Interactions for NSH 
Encapsulated Payloads

 >>> The UDP Checksum considerations specified in section 5.3 of 
[draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. 
Implementors are encouraged to consider the UDP checksum usage 
guidelines in section 3.4 of [RFC8085] when it is desirable to protect 
UDP, LISP, and NSH headers against corruption.

Same as for Ethernet also the NSH header needs to have a documented 
analsysis of fulfillment of the requirements.


Thanks,

Fabio






On 9/20/18 1:03 PM, Fabio Maino wrote:
> Thanks Magnus,
> I'll consolidate the changes we have agreed so far in the next rev 
> that I plan to publish later today.
>
> I'll then work on the comments on this email and will send you the 
> corresponding actions.
>
> Fabio
>
> On 9/20/18 2:39 AM, Magnus Westerlund wrote:
>>
>> Hi Fabio,
>>
>> Most of the below text is excellent. Some comments inline for needed 
>> clarifications and additions.
>>
>> On 9/18/2018 9:52 PM, Fabio Maino wrote:
>>> Hi Magnus,
>>> thanks for your comments.
>>>
>>> I think I see the points you are making.
>>>
>>> I'll add the section 3.1 below to specify the general transport 
>>> requirements for the registration of new LISP-GPE payloads, and I 
>>> will introduce two subsections to instantiate those requirements for 
>>> Ethernet and NSH (section 4.2 and 4.3 will be moved here). In the 
>>> "IANA Considerations" section I'll refer to this new section 3.1 as 
>>> a requirement for registration of new encapsulated payload.
>>>
>>> "3.1 Payload Specific Transport Interactions
>>>
>>> To ensure that protocols that are encapsulated in LISP-GPE will work 
>>> well from a transport interaction perspective, the specification of 
>>> a new encapsulated payload MUST contain an analysis of how LISP-GPE 
>>> SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit 
>>> Congestion Notification (ECN) bits whenever they apply to the new 
>>> encapsulated payload.
>>>
>>> For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] 
>>> specifies how to handle UDP Checksums encouraging implementors to 
>>> consider UDP checksum usage guidelines in section 3.4 of [RFC8085] 
>>> when it is desirable to protect UDP and LISP headers against 
>>> corruption. Each new encapsulated payloads, when registered with 
>>> LISP-GPE, MUST be accompanied by a similar analysis.
>>>
>>> Encapsulated payloads may have a priority field that may or may not 
>>> be mapped to the DSCP field of the outer IP header (part of Type of 
>>> Service in IPv4 or Traffic Class in IPv6). Such new encapsulated 
>>> payloads, when registered with LISP-GPE, MUST be accompanied by an 
>>> analysis similar to the one performed in Section 3.1.1 of this 
>>> document for Ethernet payloads.
>>>
>>> Encapsulated payloads may have Explicit Congestion Notification 
>>> mechanisms that may or may not be mapped to the outer IP header ECN 
>>> field. Such new encapsulated payolads, when registered with 
>>> LISP-GPE, MUST  be accompanied by a set of guidelines derived from 
>>> [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].
>>>
>>> The rest of this section specifies payload specific transport 
>>> interactions considerations for the two new LISP-GPE encapsulated 
>>> payloads specified in this document: Ethernet and NSH.
>>>
>>> 3.1.1 Payload Specific Transport Interactions for Ethernet 
>>> Encapsulated Payloads
>>>
>>> The UDP Checksum considerations specified in section 5.3 of 
>>> [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated 
>>> Payloads. Implementors are encouraged to consider the UDP checksum 
>>> usage guidelines in section 3.4 of [RFC8085] when it is desirable to 
>>> protect UDP, LISP and Ethernet headers against corruption.
>>
>> So this is not the necessary documentation of the analysis that 
>> IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. 
>> There needs to be an analysis here to verify that this protocol 
>> combination do work. You will actually have to discuss how the 
>> Ethernet encapsulation fulfills the requirements listed in Section 4 
>> of RFC 6936.
>>
>> https://datatracker.ietf.org/doc/rfc7510/ is an example where such an 
>> analysis was included. I would also note the applicability 
>> limitations this has.
>>
>> Which actually brings up an additional issue for Ethernet 
>> encapsulation. For IP the assumption is that the IP traffic that is 
>> encapsulated is congestion controlled. This assumption is even less 
>> certain when having Ethernet. Thus, some consideration of that issue 
>> is likely needed.
>>
>>
>>>
>>> When a LISP-GPE router performs Ethernet encapsulation, the inner 
>>> 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be 
>>> mapped from the encapsulated frame to the Type of Service field in 
>>> the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' 
>>> field as per guidelines provided by [RFC8325].
>>
>> I don't know enough about IEEE and the various versions of Ethernet 
>> and WLAN here to be certain that 802.1Q PCP's can be mapped directly 
>> to the 802.11 User Priorities discussed in RFC8325. Please 
>> investigate if they are the same, and if they are the same 
>> priorities, then make a explicit statement that they are applicable.
>>
>>>
>>> When a LISP-GPE router performs Ethernet encapsulation, the inner 
>>> header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or 
>>> used to determine the LISP Instance ID field.
>>>
>>> 3.1.2 Payload Specific Transport Interactions for NSH Encapsulated 
>>> Payloads
>>>
>>> The UDP Checksum considerations specified in section 5.3 of 
>>> [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. 
>>> Implementors are encouraged to consider the UDP checksum usage 
>>> guidelines in section 3.4 of [RFC8085] when it is desirable to 
>>> protect UDP, LISP, and NSH headers against corruption.
>>
>> Same as for Ethernet also the NSH header needs to have a documented 
>> analsysis of fulfillment of the requirements.
>>
>>
>>>
>>> When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN 
>>> values MAY be mapped as specified for the Next Protocol encapsulated 
>>> by NSH (namely IPv4, IPv6 and Ethernet)."
>>>
>>>
>>> I will also add a paragraph to "Iana Considerations" that says:
>>>
>>>
>>> "To ensure that protocols that are encapsulated in LISP-GPE will 
>>> work well from a transport interaction perspective, the registration 
>>> of a new encapsulated payload MUST contain an analysis of how 
>>> LISP-GPE SHOULD deal with outer UDP Checksum, DSCP mapping, and 
>>> Explicit Congestion Notification (ECN) bits whenever they apply to 
>>> the new encapsulated payload. The analysis for the new encapsulated 
>>> payload registered in this document is in section 3.1."
>>>
>>> Please, let me know if this address your comments.
>>>
>>> Thanks,
>>> Fabio
>>>
>>>
>>>
>>> On 8/29/18 2:17 AM, Magnus Westerlund wrote:
>>>> Reviewer: Magnus Westerlund
>>>> Review result: Not Ready
>>>>
>>>> This document has been reviewed as part of the transport area directorate's
>>>> ongoing effort to review key IETF documents. These comments were written
>>>> primarily for the transport area directors, but are copied to the document's
>>>> authors and WG for their information and to allow them to address any issues
>>>> raised.
>>>>
>>>> When done at the time of IETF Last Call, the authors should consider this
>>>> review together with any other last-call comments they receive.
>>>> Please always CCtsv-art@ietf.org  if you reply to or forward this review.
>>>>
>>>> Issue A.
>>>>
>>>> The reason I state Not Ready has to do with this documents failure to consider
>>>> the use of zero checksum for IPv6 when tunneling other things than IP. The none
>>>> GPE version is limited to tunnel IP for which the analysis for use of zero
>>>> checksum has been done. Each of the new tunneled protocols that are specified
>>>> in this document, i.e. ethernet and NHS, will need to perform the analysis if
>>>> they are safe to use zero checksum or not, and if not disallow zero checksum
>>>> for IPv6/UDP. The documetn also need a requirement in the registration
>>>> requirements to perform this analysis and defined if zero checksum is
>>>> acceptable or not.
>>>>
>>>> Citing Section 5.3 of draft-ietf-lisp-rfc6830bis
>>>>
>>>>     UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as zero
>>>>        by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
>>>>        [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is
>>>>        received by an ETR, the ETR MUST accept the packet for
>>>>        decapsulation.  When an ITR transmits a non-zero value for the UDP
>>>>        checksum, it MUST send a correctly computed value in this field.
>>>>        When an ETR receives a packet with a non-zero UDP checksum, it MAY
>>>>        choose to verify the checksum value.  If it chooses to perform
>>>>        such verification, and the verification fails, the packet MUST be
>>>>        silently dropped.  If the ETR chooses not to perform the
>>>>        verification, or performs the verification successfully, the
>>>>        packet MUST be accepted for decapsulation.  The handling of UDP
>>>>        zero checksums over IPv6 for all tunneling protocols, including
>>>>        LISP, is subject to the applicability statement in [RFC6936].
>>>>
>>>> The issue is that when LISP encapsulate other protocols the impact of a
>>>> missdelivered tunnel packet to the wrong ETR can have different impacts. As
>>>> well as errors in the headers of the encapsulated packet that may be assumed to
>>>> be protected by the encapsulating layer. Thus, individual analysis of each
>>>> protocol that are tunneled are needed.
>>>>
>>>> B.) 4.2.  Type of Service
>>>>
>>>>     When a LISP-GPE router performs Ethernet encapsulation, the inner
>>>>     802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be
>>>>     mapped from the encapsulated frame to the Type of Service field in
>>>>     the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'
>>>>     field.
>>>>
>>>> Any recommendation about how to perform that mapping? Maybe parts of
>>>> https://datatracker.ietf.org/doc/rfc8325/  are relevant in this context.
>>>>
>>>> C. General case of 4.2:
>>>>
>>>> I expect other protocols than Ethernet may have a priority field that may or
>>>> may not be mapped to the DSCP field of the tunnel packet.
>>>>
>>>> I would expect that for new protocol registration in the LISP-GPE Next Protocol
>>>> Registry should consider this. Thus, it would be good to note that such
>>>> considerations are needed and part of what should be evaluated for new
>>>> registrations.
>>>>
>>>> D. ECN handling
>>>>
>>>> Section 5.3 of draft-ietf-lisp-rfc6830bis states:
>>>>
>>>>     o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>>>>        of the IPv6 'Traffic Class' field) requires special treatment in
>>>>        order to avoid discarding indications of congestion [RFC3168].
>>>>        ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
>>>>        header to the outer header.  Re-encapsulation MUST copy the 2-bit
>>>>        'ECN' field from the stripped outer header to the new outer
>>>>        header.
>>>>
>>>> The above rules may not be applicable for all transport protocols. Thus I think
>>>> it is required that one do protocol specific considerations of ECN. TSVWG are
>>>> working on recommendations for tunnels handling of  ECN here, see:
>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/  Thus,
>>>> my expectation would be to ensure that the registered protocols have defined
>>>> ECN handling, explicitly or by reference. Secondly that registration
>>>> requirement states the need for this consideration.
>>>>
>>>> Summary: To ensure that future added protocols that are encapsulated will work
>>>> well from a transport interaction perspective there need to be a requirement on
>>>> new registration to consider and define how they use zero checksum, any DSCP
>>>> mapping and ECN bits. In addition the current document needs to ensure these
>>>> things are clearly specified for the encapsulated protocols in this document.
>>>>
>>>>
>>>
>> -- 
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Network Architecture & Protocols, Ericsson Research
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  +46 10 7148287
>> Torshamnsgatan 23           | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>
>


--------------4DE0EC93AF321DDAAE0D180B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I have incorporated the changes as
      discussed, so hopefully rev 6. can be used by reviewers before the
      telechat: https://www.ietf.org/id/draft-ietf-lisp-gpe-06.txt

      

      Here is the diff: goo.gl/tCKD4A

      

      

      I believe the following comments are still open. I'll work with
      the respective authors to address them in the next rev of the
      document.

      

      

      A. [Deborah/Magnus] it is being discussed on a separate private
      thread if the following should be added to the IANA section:

      "To ensure that protocols that are encapsulated in LISP-GPE will
      work well from a transport interaction perspective, the
      registration of a new encapsulated payload MUST contain an
      analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP
      mapping, and Explicit Congestion Notification (ECN) bits whenever
      they apply to the new encapsulated payload. The analysis for the
      new encapsulated payload registered in this document is in section
      3.1."

      

      

      B. [Magnus] draft-ietf-tsvwg-ecn-encap-guidelines has expired
      yesterday, and cannot be referenced. I'll add it back to section
      3.1 as soon as the draft is refreshed. 

      

      C. [Magnus/Mirja] in 3.1.1 Payload Specific Transport Interactions
      for Ethernet Encapsulated Payloads

      

      >>>The UDP Checksum considerations specified in section
      5.3 of [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated
      Payloads. Implementors are encouraged to consider the UDP checksum
      usage guidelines in section 3.4 of [RFC8085] when it is desirable
      to protect UDP, LISP and Ethernet headers against corruption.

      
So this is not the necessary documentation of the analysis that
        IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to
        use. There needs to be an analysis here to verify that this
        protocol combination do work. You will actually have to discuss
        how the Ethernet encapsulation fulfills the requirements listed
        in Section 4 of RFC 6936.  

      

      
https://datatracker.ietf.org/doc/rfc7510/
        is an example where such an analysis was included. I would also
        note the applicability limitations this has. 

      

      
Which actually brings up an additional issue for Ethernet
        encapsulation. For IP the assumption is that the IP traffic that
        is encapsulated is congestion controlled. This assumption is
        even less certain when having Ethernet. Thus, some consideration
        of that issue is likely needed. 

      

      
>>>When a LISP-GPE router performs Ethernet
        encapsulation, the inner 802.1Q [IEEE.802.1Q_2014] priority code
        point (PCP) field MAY be mapped from the encapsulated frame to
        the Type of Service field in the outer IPv4 header, or in the
        case of IPv6 the 'Traffic Class' field as per guidelines
        provided by [RFC8325].

      

      
I don't know enough about IEEE and the various versions of
        Ethernet and WLAN here to be certain that 802.1Q PCP's can be
        mapped directly to the 802.11 User Priorities discussed in
        RFC8325. Please investigate if they are the same, and if they
        are the same priorities, then make a explicit statement that
        they are applicable. 

      
D. [Magnus] 3.1.2 Payload Specific Transport Interactions for
        NSH Encapsulated Payloads 

        

        >>> The UDP Checksum considerations specified in
        section 5.3 of [draft-ietf-lisp-rfc6830bis] apply to NSH
        Encapsulated Payloads. Implementors are encouraged to consider
        the UDP checksum usage guidelines in section 3.4 of [RFC8085]
        when it is desirable to protect UDP, LISP, and NSH headers
        against corruption.

      

      
Same as for Ethernet also the NSH header needs to have a
        documented analsysis of fulfillment of the requirements.

      


      

      
Thanks,

      
Fabio

      

      


      

      


      

      

      

      

      On 9/20/18 1:03 PM, Fabio Maino wrote:

    

    

      
      
Thanks Magnus, 

        I'll consolidate the changes we have agreed so far in the next
        rev that I plan to publish later today. 

        

        I'll then work on the comments on this email and will send you
        the corresponding actions. 

        

        Fabio

        

        On 9/20/18 2:39 AM, Magnus Westerlund wrote:

      

      

        
        
Hi Fabio,

        
Most of the below text is excellent. Some comments inline for
          needed clarifications and additions. 

        
On 9/18/2018 9:52 PM, Fabio Maino
          wrote:

        

        

          
          
Hi Magnus, 

            thanks for your comments. 

            

            I think I see the points you are making. 

            

            I'll add the section 3.1 below to specify the general
            transport requirements for the registration of new LISP-GPE
            payloads, and I will introduce two subsections to
            instantiate those requirements for Ethernet and NSH (section
            4.2 and 4.3 will be moved here). In the "IANA
            Considerations" section I'll refer to this new section 3.1
            as a requirement for registration of new encapsulated
            payload. 

            

            "3.1 Payload Specific Transport Interactions

            

            To ensure that protocols that are encapsulated in LISP-GPE
            will work well from a transport interaction perspective, the
            specification of a new encapsulated payload MUST contain an
            analysis of how LISP-GPE SHOULD deal with outer UDP
            Checksum, DSCP mapping, and Explicit Congestion Notification
            (ECN) bits whenever they apply to the new encapsulated
            payload.

            

            For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis]
            specifies how to handle UDP Checksums encouraging
            implementors to consider UDP checksum usage guidelines in
            section 3.4 of [RFC8085] when it is desirable to protect UDP
            and LISP headers against corruption. Each new encapsulated
            payloads, when registered with LISP-GPE, MUST be accompanied
            by a similar analysis.

            

            Encapsulated payloads may have a priority field that may or
            may not be mapped to the DSCP field of the outer IP header
            (part of Type of Service in IPv4 or Traffic Class in IPv6).
            Such new encapsulated payloads, when registered with
            LISP-GPE, MUST be accompanied by an analysis similar to the
            one performed in Section 3.1.1 of this document for Ethernet
            payloads. 

            

            Encapsulated payloads may have Explicit Congestion
            Notification mechanisms that may or may not be mapped to the
            outer IP header ECN field. Such new encapsulated payolads,
            when registered with LISP-GPE, MUST  be accompanied by a set
            of guidelines derived from
            [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. 

            

            The rest of this section specifies payload specific
            transport interactions considerations for the two new
            LISP-GPE encapsulated payloads specified in this document:
            Ethernet and NSH. 

            

            3.1.1 Payload Specific Transport Interactions for Ethernet
            Encapsulated Payloads

            

            The UDP Checksum considerations specified in section 5.3 of
            [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated
            Payloads. Implementors are encouraged to consider the UDP
            checksum usage guidelines in section 3.4 of [RFC8085] when
            it is desirable to protect UDP, LISP and Ethernet headers
            against corruption.

          

        

        
So this is not the necessary documentation of the analysis
          that IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a
          safe to use. There needs to be an analysis here to verify that
          this protocol combination do work. You will actually have to
          discuss how the Ethernet encapsulation fulfills the
          requirements listed in Section 4 of RFC 6936.  

        

        
https://datatracker.ietf.org/doc/rfc7510/
          is an example where such an analysis was included. I would
          also note the applicability limitations this has. 

        

        
Which actually brings up an additional issue for Ethernet
          encapsulation. For IP the assumption is that the IP traffic
          that is encapsulated is congestion controlled. This assumption
          is even less certain when having Ethernet. Thus, some
          consideration of that issue is likely needed. 

        

        


        

        

          
 

            When a LISP-GPE router performs Ethernet encapsulation, the
            inner 802.1Q [IEEE.802.1Q_2014] priority code point (PCP)
            field MAY be mapped from the encapsulated frame to the Type
            of Service field in the outer IPv4 header, or in the case of
            IPv6 the 'Traffic Class' field as per guidelines provided by
            [RFC8325].

          

        

        
I don't know enough about IEEE and the various versions of
          Ethernet and WLAN here to be certain that 802.1Q PCP's can be
          mapped directly to the 802.11 User Priorities discussed in
          RFC8325. Please investigate if they are the same, and if they
          are the same priorities, then make a explicit statement that
          they are applicable. 

        

        

          
 

            When a LISP-GPE router performs Ethernet encapsulation, the
            inner header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be
            mapped to, or used to determine the LISP Instance ID field.

            

            3.1.2 Payload Specific Transport Interactions for NSH
            Encapsulated Payloads 

            

            The UDP Checksum considerations specified in section 5.3 of
            [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated
            Payloads. Implementors are encouraged to consider the UDP
            checksum usage guidelines in section 3.4 of [RFC8085] when
            it is desirable to protect UDP, LISP, and NSH headers
            against corruption.

          

        

        
Same as for Ethernet also the NSH header needs to have a
          documented analsysis of fulfillment of the requirements.

        


        

        

          
 

            When a LISP-GPE router performs an NSH encapsulation, DSCP
            and ECN values MAY be mapped as specified for the Next
            Protocol encapsulated by NSH (namely IPv4, IPv6 and
            Ethernet)."  

            

            

            I will also add a paragraph to "Iana Considerations" that
            says: 

            

            

            "To ensure that protocols that are encapsulated in LISP-GPE
            will work well from a transport interaction perspective, the
            registration of a new encapsulated payload MUST contain an
            analysis of how LISP-GPE SHOULD deal with outer UDP
            Checksum, DSCP mapping, and Explicit Congestion Notification
            (ECN) bits whenever they apply to the new encapsulated
            payload. The analysis for the new encapsulated payload
            registered in this document is in section 3.1."

            

            Please, let me know if this address your comments. 

            

            Thanks,

            Fabio

            

            

            

            On 8/29/18 2:17 AM, Magnus Westerlund wrote:

          

          

            
Reviewer: Magnus Westerlund
Review result: Not Ready

This document has been reviewed as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG for their information and to allow them to address any issues
raised.

When done at the time of IETF Last Call, the authors should consider this
review together with any other last-call comments they receive.
Please always CC tsv-art@ietf.org if you reply to or forward this review.

Issue A.

The reason I state Not Ready has to do with this documents failure to consider
the use of zero checksum for IPv6 when tunneling other things than IP. The none
GPE version is limited to tunnel IP for which the analysis for use of zero
checksum has been done. Each of the new tunneled protocols that are specified
in this document, i.e. ethernet and NHS, will need to perform the analysis if
they are safe to use zero checksum or not, and if not disallow zero checksum
for IPv6/UDP. The documetn also need a requirement in the registration
requirements to perform this analysis and defined if zero checksum is
acceptable or not.

Citing Section 5.3 of draft-ietf-lisp-rfc6830bis

   UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as zero
      by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
      [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is
      received by an ETR, the ETR MUST accept the packet for
      decapsulation.  When an ITR transmits a non-zero value for the UDP
      checksum, it MUST send a correctly computed value in this field.
      When an ETR receives a packet with a non-zero UDP checksum, it MAY
      choose to verify the checksum value.  If it chooses to perform
      such verification, and the verification fails, the packet MUST be
      silently dropped.  If the ETR chooses not to perform the
      verification, or performs the verification successfully, the
      packet MUST be accepted for decapsulation.  The handling of UDP
      zero checksums over IPv6 for all tunneling protocols, including
      LISP, is subject to the applicability statement in [RFC6936].

The issue is that when LISP encapsulate other protocols the impact of a
missdelivered tunnel packet to the wrong ETR can have different impacts. As
well as errors in the headers of the encapsulated packet that may be assumed to
be protected by the encapsulating layer. Thus, individual analysis of each
protocol that are tunneled are needed.

B.) 4.2.  Type of Service

   When a LISP-GPE router performs Ethernet encapsulation, the inner
   802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be
   mapped from the encapsulated frame to the Type of Service field in
   the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'
   field.

Any recommendation about how to perform that mapping? Maybe parts of
https://datatracker.ietf.org/doc/rfc8325/ are relevant in this context.

C. General case of 4.2:

I expect other protocols than Ethernet may have a priority field that may or
may not be mapped to the DSCP field of the tunnel packet.

I would expect that for new protocol registration in the LISP-GPE Next Protocol
Registry should consider this. Thus, it would be good to note that such
considerations are needed and part of what should be evaluated for new
registrations.

D. ECN handling

Section 5.3 of draft-ietf-lisp-rfc6830bis states:

   o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion [RFC3168].
      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
      header to the outer header.  Re-encapsulation MUST copy the 2-bit
      'ECN' field from the stripped outer header to the new outer
      header.

The above rules may not be applicable for all transport protocols. Thus I think
it is required that one do protocol specific considerations of ECN. TSVWG are
working on recommendations for tunnels handling of  ECN here, see: 
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ Thus,
my expectation would be to ensure that the registered protocols have defined
ECN handling, explicitly or by reference. Secondly that registration
requirement states the need for this consideration.

Summary: To ensure that future added protocols that are encapsulated will work
well from a transport interaction perspective there need to be a requirement on
new registration to consider and define how they use zero checksum, any DSCP
mapping and ECN bits. In addition the current document needs to ensure these
things are clearly specified for the encapsulated protocols in this document.




          

          


          

        

        
-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

      

      


      

    

    


    

  


--------------4DE0EC93AF321DDAAE0D180B--


From nobody Fri Sep 21 02:04:27 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F165126BED for ; Fri, 21 Sep 2018 02:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com
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 0uxkiuKHO-Bm for ; Fri, 21 Sep 2018 02:04:16 -0700 (PDT)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 56BE0130E47 for ; Fri, 21 Sep 2018 02:04:14 -0700 (PDT)
Received: by mail-wm1-x342.google.com with SMTP id j192-v6so2392912wmj.1 for ; Fri, 21 Sep 2018 02:04:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FqooU5l7+2jlx+ZUHDVOYdb/Hboke/XisznfNjV56Ww=; b=ycNlqmA86366/oo1n5F1TE3rQ4xCcho6gSI3CZmr0lz5I8TvQL7Yf3YkdzhRg6or1W rtN9DTlMPKpKDqWR++u5v6DGuXjoT0DxhXdxqhFBwwAs1A2bhp88PMZXJJeSQiMQkkWN o+oQ+sLEaJfgu8Lu0xcUfWKRqEy3a6ph5UTEq+fx3lLg785M/vwZjAie8kwqntEUa4lZ VcYPGBgauy8d7j0OzZaugb4OLgPOjv82nIsm8pmKRmFEkrbMDnOis7umKvkwFbmlgzXW lvwzuH9QvI87OWDUJkxvtR4ZqEaJsA/xOaXLKh+8Lwdeyn/lyQYlxVHtm8JSkMW+wOmq JBWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FqooU5l7+2jlx+ZUHDVOYdb/Hboke/XisznfNjV56Ww=; b=U8CM1Ws7FHhnr2Vd+jtYiXMDYwdqSZQ3pLA7AFgALhUxoTtFI1V8w/fnhL/N0tIgdR JRS5PqcprBSwwDLsaIwlFo2eFEuuE8v0/FXjrPQwTYwUd3MQYOn/QrfjyMA9a1HtgQwb FtW6sMPqsljXfrjxa5rjDZLJ9pUhGm3A21nLo3A7wW+t8PUZlbObGqR3TnZKc3+BfDtI Rl0ZaxYw4FYTgVkTIZ0KBGOKwpQ5ebVEUce9G81dpJimWJf1roQuzQbBQD0c4B+QzjOf x9Tvurm8ULdK5BV8EhCRu2LImA0PMAgqkQu5bTKAGvsRUWNi/AvwB1QKrYX6vj4jI5KN IJXw==
X-Gm-Message-State: APzg51AIth0gPHE5GWqGQYkUcoKz+sN1yzkRlClzGZuntvXb13Mm1/FB QOBGIe0RKfDu5wr+4/lSkAr5ng==
X-Google-Smtp-Source: ANB0VdbfNvHki0TNoZnwvWTyflbShQ+YuGlxAufWZox6tGDozhgLzhAhe6JJfQqJQ3/lRN8N/mtWxw==
X-Received: by 2002:a1c:e455:: with SMTP id b82-v6mr6366581wmh.93.1537520652346;  Fri, 21 Sep 2018 02:04:12 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:40ef:987a:99f5:96b8? ([2001:660:330f:a4:40ef:987a:99f5:96b8]) by smtp.gmail.com with ESMTPSA id 94-v6sm32409769wrc.10.2018.09.21.02.04.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Sep 2018 02:04:10 -0700 (PDT)
From: Luigi Iannone 
Message-Id: <368436FB-586D-4810-9A04-91CBD3C526D4@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_265884B5-C01A-48A6-A478-0B9826192F7B"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 21 Sep 2018 11:04:09 +0200
In-Reply-To: <29f21563-362e-e7cc-3e07-19ff14294eab@cisco.com>
Cc: Magnus Westerlund , tsv-art@ietf.org, lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org, =?utf-8?Q?Mirja_K=C3=BChlewind?= 
To: Fabio Maino 
References: <153553422964.14784.628403975182959075@ietfa.amsl.com>  <5dd519c0-6810-8596-37e9-377e38175a7d@ericsson.com> <8856bfce-8d2f-baae-d85c-fea09ba86f69@cisco.com> <29f21563-362e-e7cc-3e07-19ff14294eab@cisco.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 21 Sep 2018 09:04:20 -0000

--Apple-Mail=_265884B5-C01A-48A6-A478-0B9826192F7B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Fabio,

just one comment on the following sentence (section 1)

LISP-GPE MAY also be used to extend the LISP Data-Plane header, that	 =
	=09
   has allocated all by defining a Next Protocol "shim" header that	 =
	=09
   implements new data plane functions not supported in the LISP header.	=
 	=09

Something is missing in this sentence.=20

May be: LISP-GPE MAY also be used to extend the LISP Data-Plane header, =
**since 	 	=09
   all of the reserved bits have been allocated, **  by defining a Next =
Protocol "shim" header that	 	=09
   implements new data plane functions not supported in the LISP header.	=
 	=09
=20
Ciao

L.

                                                                         =
                          =20

> On 21 Sep 2018, at 07:12, Fabio Maino  wrote:
>=20
> I have incorporated the changes as discussed, so hopefully rev 6. can =
be used by reviewers before the telechat: =
https://www.ietf.org/id/draft-ietf-lisp-gpe-06.txt =

>=20
> Here is the diff: goo.gl/tCKD4A
>=20
>=20
> I believe the following comments are still open. I'll work with the =
respective authors to address them in the next rev of the document.
>=20
>=20
> A. [Deborah/Magnus] it is being discussed on a separate private thread =
if the following should be added to the IANA section:
> "To ensure that protocols that are encapsulated in LISP-GPE will work =
well from a transport interaction perspective, the registration of a new =
encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD =
deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion =
Notification (ECN) bits whenever they apply to the new encapsulated =
payload. The analysis for the new encapsulated payload registered in =
this document is in section 3.1."
>=20
>=20
> B. [Magnus] draft-ietf-tsvwg-ecn-encap-guidelines has expired =
yesterday, and cannot be referenced. I'll add it back to section 3.1 as =
soon as the draft is refreshed.=20
>=20
> C. [Magnus/Mirja] in 3.1.1 Payload Specific Transport Interactions for =
Ethernet Encapsulated Payloads
>=20
> >>>The UDP Checksum considerations specified in section 5.3 of =
[draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. =
Implementors are encouraged to consider the UDP checksum usage =
guidelines in section 3.4 of [RFC8085] when it is desirable to protect =
UDP, LISP and Ethernet headers against corruption.
> So this is not the necessary documentation of the analysis that =
IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. =
There needs to be an analysis here to verify that this protocol =
combination do work. You will actually have to discuss how the Ethernet =
encapsulation fulfills the requirements listed in Section 4 of RFC 6936. =
=20
> https://datatracker.ietf.org/doc/rfc7510/ =
 is an example where such an =
analysis was included. I would also note the applicability limitations =
this has.=20
> Which actually brings up an additional issue for Ethernet =
encapsulation. For IP the assumption is that the IP traffic that is =
encapsulated is congestion controlled. This assumption is even less =
certain when having Ethernet. Thus, some consideration of that issue is =
likely needed.=20
> >>>When a LISP-GPE router performs Ethernet encapsulation, the inner =
802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be mapped =
from the encapsulated frame to the Type of Service field in the outer =
IPv4 header, or in the case of IPv6 the 'Traffic Class' field as per =
guidelines provided by [RFC8325].
> I don't know enough about IEEE and the various versions of Ethernet =
and WLAN here to be certain that 802.1Q PCP's can be mapped directly to =
the 802.11 User Priorities discussed in RFC8325. Please investigate if =
they are the same, and if they are the same priorities, then make a =
explicit statement that they are applicable.
>=20
> D. [Magnus] 3.1.2 Payload Specific Transport Interactions for NSH =
Encapsulated Payloads=20
>=20
> >>> The UDP Checksum considerations specified in section 5.3 of =
[draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. =
Implementors are encouraged to consider the UDP checksum usage =
guidelines in section 3.4 of [RFC8085] when it is desirable to protect =
UDP, LISP, and NSH headers against corruption.
> Same as for Ethernet also the NSH header needs to have a documented =
analsysis of fulfillment of the requirements.
>=20
>=20
> Thanks,
>=20
> Fabio
>=20
>=20
>=20
>=20
>=20
> On 9/20/18 1:03 PM, Fabio Maino wrote:
>> Thanks Magnus,=20
>> I'll consolidate the changes we have agreed so far in the next rev =
that I plan to publish later today.=20
>>=20
>> I'll then work on the comments on this email and will send you the =
corresponding actions.=20
>>=20
>> Fabio
>>=20
>> On 9/20/18 2:39 AM, Magnus Westerlund wrote:
>>> Hi Fabio,
>>>=20
>>> Most of the below text is excellent. Some comments inline for needed =
clarifications and additions.=20
>>>=20
>>> On 9/18/2018 9:52 PM, Fabio Maino wrote:
>>>> Hi Magnus,=20
>>>> thanks for your comments.=20
>>>>=20
>>>> I think I see the points you are making.=20
>>>>=20
>>>> I'll add the section 3.1 below to specify the general transport =
requirements for the registration of new LISP-GPE payloads, and I will =
introduce two subsections to instantiate those requirements for Ethernet =
and NSH (section 4.2 and 4.3 will be moved here). In the "IANA =
Considerations" section I'll refer to this new section 3.1 as a =
requirement for registration of new encapsulated payload.=20
>>>>=20
>>>> "3.1 Payload Specific Transport Interactions
>>>>=20
>>>> To ensure that protocols that are encapsulated in LISP-GPE will =
work well from a transport interaction perspective, the specification of =
a new encapsulated payload MUST contain an analysis of how LISP-GPE =
SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit =
Congestion Notification (ECN) bits whenever they apply to the new =
encapsulated payload.
>>>>=20
>>>> For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] =
specifies how to handle UDP Checksums encouraging implementors to =
consider UDP checksum usage guidelines in section 3.4 of [RFC8085] when =
it is desirable to protect UDP and LISP headers against corruption. Each =
new encapsulated payloads, when registered with LISP-GPE, MUST be =
accompanied by a similar analysis.
>>>>=20
>>>> Encapsulated payloads may have a priority field that may or may not =
be mapped to the DSCP field of the outer IP header (part of Type of =
Service in IPv4 or Traffic Class in IPv6). Such new encapsulated =
payloads, when registered with LISP-GPE, MUST be accompanied by an =
analysis similar to the one performed in Section 3.1.1 of this document =
for Ethernet payloads.=20
>>>>=20
>>>> Encapsulated payloads may have Explicit Congestion Notification =
mechanisms that may or may not be mapped to the outer IP header ECN =
field. Such new encapsulated payolads, when registered with LISP-GPE, =
MUST  be accompanied by a set of guidelines derived from =
[draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].=20
>>>>=20
>>>> The rest of this section specifies payload specific transport =
interactions considerations for the two new LISP-GPE encapsulated =
payloads specified in this document: Ethernet and NSH.=20
>>>>=20
>>>> 3.1.1 Payload Specific Transport Interactions for Ethernet =
Encapsulated Payloads
>>>>=20
>>>> The UDP Checksum considerations specified in section 5.3 of =
[draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. =
Implementors are encouraged to consider the UDP checksum usage =
guidelines in section 3.4 of [RFC8085] when it is desirable to protect =
UDP, LISP and Ethernet headers against corruption.
>>> So this is not the necessary documentation of the analysis that =
IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. =
There needs to be an analysis here to verify that this protocol =
combination do work. You will actually have to discuss how the Ethernet =
encapsulation fulfills the requirements listed in Section 4 of RFC 6936. =
=20
>>> https://datatracker.ietf.org/doc/rfc7510/ =
 is an example where such an =
analysis was included. I would also note the applicability limitations =
this has.=20
>>> Which actually brings up an additional issue for Ethernet =
encapsulation. For IP the assumption is that the IP traffic that is =
encapsulated is congestion controlled. This assumption is even less =
certain when having Ethernet. Thus, some consideration of that issue is =
likely needed.=20
>>>=20
>>>>=20
>>>> When a LISP-GPE router performs Ethernet encapsulation, the inner =
802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be mapped =
from the encapsulated frame to the Type of Service field in the outer =
IPv4 header, or in the case of IPv6 the 'Traffic Class' field as per =
guidelines provided by [RFC8325].
>>> I don't know enough about IEEE and the various versions of Ethernet =
and WLAN here to be certain that 802.1Q PCP's can be mapped directly to =
the 802.11 User Priorities discussed in RFC8325. Please investigate if =
they are the same, and if they are the same priorities, then make a =
explicit statement that they are applicable.=20
>>>>=20
>>>> When a LISP-GPE router performs Ethernet encapsulation, the inner =
header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or =
used to determine the LISP Instance ID field.
>>>>=20
>>>> 3.1.2 Payload Specific Transport Interactions for NSH Encapsulated =
Payloads=20
>>>>=20
>>>> The UDP Checksum considerations specified in section 5.3 of =
[draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. =
Implementors are encouraged to consider the UDP checksum usage =
guidelines in section 3.4 of [RFC8085] when it is desirable to protect =
UDP, LISP, and NSH headers against corruption.
>>> Same as for Ethernet also the NSH header needs to have a documented =
analsysis of fulfillment of the requirements.
>>>=20
>>>=20
>>>>=20
>>>> When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN =
values MAY be mapped as specified for the Next Protocol encapsulated by =
NSH (namely IPv4, IPv6 and Ethernet)." =20
>>>>=20
>>>>=20
>>>> I will also add a paragraph to "Iana Considerations" that says:=20
>>>>=20
>>>>=20
>>>> "To ensure that protocols that are encapsulated in LISP-GPE will =
work well from a transport interaction perspective, the registration of =
a new encapsulated payload MUST contain an analysis of how LISP-GPE =
SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit =
Congestion Notification (ECN) bits whenever they apply to the new =
encapsulated payload. The analysis for the new encapsulated payload =
registered in this document is in section 3.1."
>>>>=20
>>>> Please, let me know if this address your comments.=20
>>>>=20
>>>> Thanks,
>>>> Fabio
>>>>=20
>>>>=20
>>>>=20
>>>> On 8/29/18 2:17 AM, Magnus Westerlund wrote:
>>>>> Reviewer: Magnus Westerlund
>>>>> Review result: Not Ready
>>>>>=20
>>>>> This document has been reviewed as part of the transport area =
directorate's
>>>>> ongoing effort to review key IETF documents. These comments were =
written
>>>>> primarily for the transport area directors, but are copied to the =
document's
>>>>> authors and WG for their information and to allow them to address =
any issues
>>>>> raised.
>>>>>=20
>>>>> When done at the time of IETF Last Call, the authors should =
consider this
>>>>> review together with any other last-call comments they receive.
>>>>> Please always CC tsv-art@ietf.org  if you =
reply to or forward this review.
>>>>>=20
>>>>> Issue A.
>>>>>=20
>>>>> The reason I state Not Ready has to do with this documents failure =
to consider
>>>>> the use of zero checksum for IPv6 when tunneling other things than =
IP. The none
>>>>> GPE version is limited to tunnel IP for which the analysis for use =
of zero
>>>>> checksum has been done. Each of the new tunneled protocols that =
are specified
>>>>> in this document, i.e. ethernet and NHS, will need to perform the =
analysis if
>>>>> they are safe to use zero checksum or not, and if not disallow =
zero checksum
>>>>> for IPv6/UDP. The documetn also need a requirement in the =
registration
>>>>> requirements to perform this analysis and defined if zero checksum =
is
>>>>> acceptable or not.
>>>>>=20
>>>>> Citing Section 5.3 of draft-ietf-lisp-rfc6830bis
>>>>>=20
>>>>>    UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted =
as zero
>>>>>       by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
>>>>>       [RFC6935] [RFC6936].  When a packet with a zero UDP checksum =
is
>>>>>       received by an ETR, the ETR MUST accept the packet for
>>>>>       decapsulation.  When an ITR transmits a non-zero value for =
the UDP
>>>>>       checksum, it MUST send a correctly computed value in this =
field.
>>>>>       When an ETR receives a packet with a non-zero UDP checksum, =
it MAY
>>>>>       choose to verify the checksum value.  If it chooses to =
perform
>>>>>       such verification, and the verification fails, the packet =
MUST be
>>>>>       silently dropped.  If the ETR chooses not to perform the
>>>>>       verification, or performs the verification successfully, the
>>>>>       packet MUST be accepted for decapsulation.  The handling of =
UDP
>>>>>       zero checksums over IPv6 for all tunneling protocols, =
including
>>>>>       LISP, is subject to the applicability statement in =
[RFC6936].
>>>>>=20
>>>>> The issue is that when LISP encapsulate other protocols the impact =
of a
>>>>> missdelivered tunnel packet to the wrong ETR can have different =
impacts. As
>>>>> well as errors in the headers of the encapsulated packet that may =
be assumed to
>>>>> be protected by the encapsulating layer. Thus, individual analysis =
of each
>>>>> protocol that are tunneled are needed.
>>>>>=20
>>>>> B.) 4.2.  Type of Service
>>>>>=20
>>>>>    When a LISP-GPE router performs Ethernet encapsulation, the =
inner
>>>>>    802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY =
be
>>>>>    mapped from the encapsulated frame to the Type of Service field =
in
>>>>>    the outer IPv4 header, or in the case of IPv6 the 'Traffic =
Class'
>>>>>    field.
>>>>>=20
>>>>> Any recommendation about how to perform that mapping? Maybe parts =
of
>>>>> https://datatracker.ietf.org/doc/rfc8325/ =
 are relevant in this =
context.
>>>>>=20
>>>>> C. General case of 4.2:
>>>>>=20
>>>>> I expect other protocols than Ethernet may have a priority field =
that may or
>>>>> may not be mapped to the DSCP field of the tunnel packet.
>>>>>=20
>>>>> I would expect that for new protocol registration in the LISP-GPE =
Next Protocol
>>>>> Registry should consider this. Thus, it would be good to note that =
such
>>>>> considerations are needed and part of what should be evaluated for =
new
>>>>> registrations.
>>>>>=20
>>>>> D. ECN handling
>>>>>=20
>>>>> Section 5.3 of draft-ietf-lisp-rfc6830bis states:
>>>>>=20
>>>>>    o  The 'Explicit Congestion Notification' (ECN) field (bits 6 =
and 7
>>>>>       of the IPv6 'Traffic Class' field) requires special =
treatment in
>>>>>       order to avoid discarding indications of congestion =
[RFC3168].
>>>>>       ITR encapsulation MUST copy the 2-bit 'ECN' field from the =
inner
>>>>>       header to the outer header.  Re-encapsulation MUST copy the =
2-bit
>>>>>       'ECN' field from the stripped outer header to the new outer
>>>>>       header.
>>>>>=20
>>>>> The above rules may not be applicable for all transport protocols. =
Thus I think
>>>>> it is required that one do protocol specific considerations of =
ECN. TSVWG are
>>>>> working on recommendations for tunnels handling of  ECN here, see:=20=

>>>>> =
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ =
 =
Thus,
>>>>> my expectation would be to ensure that the registered protocols =
have defined
>>>>> ECN handling, explicitly or by reference. Secondly that =
registration
>>>>> requirement states the need for this consideration.
>>>>>=20
>>>>> Summary: To ensure that future added protocols that are =
encapsulated will work
>>>>> well from a transport interaction perspective there need to be a =
requirement on
>>>>> new registration to consider and define how they use zero =
checksum, any DSCP
>>>>> mapping and ECN bits. In addition the current document needs to =
ensure these
>>>>> things are clearly specified for the encapsulated protocols in =
this document.
>>>>>=20
>>>>>=20
>>>>=20
>>> --=20
>>>=20
>>> Magnus Westerlund=20
>>>=20
>>> =
----------------------------------------------------------------------
>>> Network Architecture & Protocols, Ericsson Research
>>> =
----------------------------------------------------------------------
>>> Ericsson AB                 | Phone  +46 10 7148287
>>> Torshamnsgatan 23           | Mobile +46 73 0949079
>>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com =

>>> =
----------------------------------------------------------------------
>>=20
>=20


--Apple-Mail=_265884B5-C01A-48A6-A478-0B9826192F7B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Hi Fabio,

just one comment on the following sentence (section =
1)

LISP-GPE MAY also be used to extend the LISP =
Data-Plane header, that	 		
   has allocated all by defining a Next Protocol =
"shim" header that	 		
   implements new data plane functions not =
supported in the LISP header.	 		

Something is missing in this =
sentence. 

May be: LISP-GPE MAY also be used to extend the LISP =
Data-Plane header, **since 	 		=

   all of the reserved bits have been allocated, =
**  by defining a Next Protocol "shim" header that	=
 	=
	=

   implements new data plane functions =
not supported in the LISP header.	 		
 
Ciao

L.

      =
                    =
                    =
                    =
                    =
              

On 21 Sep 2018, at 07:12, Fabio Maino <fmaino@cisco.com> =
wrote:


 =20
    
 =20
  

    
I have incorporated the changes as
      discussed, so hopefully rev 6. can be used by reviewers before the
      telechat: https://www.ie=
tf.org/id/draft-ietf-lisp-gpe-06.txt

      

      Here is the diff: goo.gl/tCKD4A

      

      

      I believe the following comments are still open. I'll work with
      the respective authors to address them in the next rev of the
      document.

      

      

      A. [Deborah/Magnus] it is being discussed on a separate private
      thread if the following should be added to the IANA section:

      "To ensure that protocols that are encapsulated in LISP-GPE will
      work well from a transport interaction perspective, the
      registration of a new encapsulated payload MUST contain an
      analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP
      mapping, and Explicit Congestion Notification (ECN) bits whenever
      they apply to the new encapsulated payload. The analysis for the
      new encapsulated payload registered in this document is in section
      3.1."

      

      

      B. [Magnus] draft-ietf-tsvwg-ecn-encap-guidelines has expired
      yesterday, and cannot be referenced. I'll add it back to section
      3.1 as soon as the draft is refreshed. 

      

      C. [Magnus/Mirja] in 3.1.1 Payload Specific Transport Interactions
      for Ethernet Encapsulated Payloads

      

      >>>The UDP Checksum considerations specified in section
      5.3 of [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated
      Payloads. Implementors are encouraged to consider the UDP checksum
      usage guidelines in section 3.4 of [RFC8085] when it is desirable
      to protect UDP, LISP and Ethernet headers against corruption.
So this is not the necessary documentation of =
the analysis that
        IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to
        use. There needs to be an analysis here to verify that this
        protocol combination do work. You will actually have to discuss
        how the Ethernet encapsulation fulfills the requirements listed
        in Section 4 of RFC 6936.  

      
https://datatracker.iet=
f.org/doc/rfc7510/
        is an example where such an analysis was included. I would also
        note the applicability limitations this has. 

      
Which actually brings up an additional issue for =
Ethernet
        encapsulation. For IP the assumption is that the IP traffic that
        is encapsulated is congestion controlled. This assumption is
        even less certain when having Ethernet. Thus, some consideration
        of that issue is likely needed. 

      
>>>When a LISP-GPE router performs =
Ethernet
        encapsulation, the inner 802.1Q [IEEE.802.1Q_2014] priority code
        point (PCP) field MAY be mapped from the encapsulated frame to
        the Type of Service field in the outer IPv4 header, or in the
        case of IPv6 the 'Traffic Class' field as per guidelines
        provided by [RFC8325].

      
I don't know enough about IEEE and the various =
versions of
        Ethernet and WLAN here to be certain that 802.1Q PCP's can be
        mapped directly to the 802.11 User Priorities discussed in
        RFC8325. Please investigate if they are the same, and if they
        are the same priorities, then make a explicit statement that
        they are applicable. 
D. [Magnus] 3.1.2 Payload =
Specific Transport Interactions for
        NSH Encapsulated Payloads 

        

        >>> The UDP Checksum considerations specified in
        section 5.3 of [draft-ietf-lisp-rfc6830bis] apply to NSH
        Encapsulated Payloads. Implementors are encouraged to consider
        the UDP checksum usage guidelines in section 3.4 of [RFC8085]
        when it is desirable to protect UDP, LISP, and NSH headers
        against corruption.

      
Same as for Ethernet also the NSH header needs =
to have a
        documented analsysis of fulfillment of the requirements.


      
Thanks,
Fabio

      


      


      

      

      

      

      On 9/20/18 1:03 PM, Fabio Maino wrote:

    

    

      
      
Thanks Magnus, 

        I'll consolidate the changes we have agreed so far in the next
        rev that I plan to publish later today. 

        

        I'll then work on the comments on this email and will send you
        the corresponding actions. 

        

        Fabio

        

        On 9/20/18 2:39 AM, Magnus Westerlund wrote:

      

      
=

        
Hi Fabio,
Most of the below text is excellent. Some comments inline for
          needed clarifications and additions. 

        
On 9/18/2018 9:52 PM, Fabio Maino
          wrote:

        

        

          
          
Hi Magnus, 

            thanks for your comments. 

            

            I think I see the points you are making. 

            

            I'll add the section 3.1 below to specify the general
            transport requirements for the registration of new LISP-GPE
            payloads, and I will introduce two subsections to
            instantiate those requirements for Ethernet and NSH (section
            4.2 and 4.3 will be moved here). In the "IANA
            Considerations" section I'll refer to this new section 3.1
            as a requirement for registration of new encapsulated
            payload. 

            

            "3.1 Payload Specific Transport Interactions

            

            To ensure that protocols that are encapsulated in LISP-GPE
            will work well from a transport interaction perspective, the
            specification of a new encapsulated payload MUST contain an
            analysis of how LISP-GPE SHOULD deal with outer UDP
            Checksum, DSCP mapping, and Explicit Congestion Notification
            (ECN) bits whenever they apply to the new encapsulated
            payload.

            

            For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis]
            specifies how to handle UDP Checksums encouraging
            implementors to consider UDP checksum usage guidelines in
            section 3.4 of [RFC8085] when it is desirable to protect UDP
            and LISP headers against corruption. Each new encapsulated
            payloads, when registered with LISP-GPE, MUST be accompanied
            by a similar analysis.

            

            Encapsulated payloads may have a priority field that may or
            may not be mapped to the DSCP field of the outer IP header
            (part of Type of Service in IPv4 or Traffic Class in IPv6).
            Such new encapsulated payloads, when registered with
            LISP-GPE, MUST be accompanied by an analysis similar to the
            one performed in Section 3.1.1 of this document for Ethernet
            payloads. 

            

            Encapsulated payloads may have Explicit Congestion
            Notification mechanisms that may or may not be mapped to the
            outer IP header ECN field. Such new encapsulated payolads,
            when registered with LISP-GPE, MUST  be accompanied by =
a set
            of guidelines derived from
            [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. 

            

            The rest of this section specifies payload specific
            transport interactions considerations for the two new
            LISP-GPE encapsulated payloads specified in this document:
            Ethernet and NSH. 

            

            3.1.1 Payload Specific Transport Interactions for Ethernet
            Encapsulated Payloads

            

            The UDP Checksum considerations specified in section 5.3 of
            [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated
            Payloads. Implementors are encouraged to consider the UDP
            checksum usage guidelines in section 3.4 of [RFC8085] when
            it is desirable to protect UDP, LISP and Ethernet headers
            against corruption.

          

        
So this is not the necessary =
documentation of the analysis
          that IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a
          safe to use. There needs to be an analysis here to verify that
          this protocol combination do work. You will actually have to
          discuss how the Ethernet encapsulation fulfills the
          requirements listed in Section 4 of RFC 6936.  

        
https://datatracker.ietf.org/doc/rfc7510/
          is an example where such an analysis was included. I would
          also note the applicability limitations this has. 

        
Which actually brings up an additional issue =
for Ethernet
          encapsulation. For IP the assumption is that the IP traffic
          that is encapsulated is congestion controlled. This assumption
          is even less certain when having Ethernet. Thus, some
          consideration of that issue is likely needed. 

        


        

        

          
 

            When a LISP-GPE router performs Ethernet encapsulation, the
            inner 802.1Q [IEEE.802.1Q_2014] priority code point (PCP)
            field MAY be mapped from the encapsulated frame to the Type
            of Service field in the outer IPv4 header, or in the case of
            IPv6 the 'Traffic Class' field as per guidelines provided by
            [RFC8325].

          

        
I don't know enough about IEEE and =
the various versions of
          Ethernet and WLAN here to be certain that 802.1Q PCP's can be
          mapped directly to the 802.11 User Priorities discussed in
          RFC8325. Please investigate if they are the same, and if they
          are the same priorities, then make a explicit statement that
          they are applicable. 

        

        

          
 

            When a LISP-GPE router performs Ethernet encapsulation, the
            inner header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be
            mapped to, or used to determine the LISP Instance ID =
field.

            

            3.1.2 Payload Specific Transport Interactions for NSH
            Encapsulated Payloads 

            

            The UDP Checksum considerations specified in section 5.3 of
            [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated
            Payloads. Implementors are encouraged to consider the UDP
            checksum usage guidelines in section 3.4 of [RFC8085] when
            it is desirable to protect UDP, LISP, and NSH headers
            against corruption.

          

        
Same as for Ethernet also the NSH =
header needs to have a
          documented analsysis of fulfillment of the requirements.


        

        

          
 

            When a LISP-GPE router performs an NSH encapsulation, DSCP
            and ECN values MAY be mapped as specified for the Next
            Protocol encapsulated by NSH (namely IPv4, IPv6 and
            Ethernet)."  

            

            

            I will also add a paragraph to "Iana Considerations" that
            says: 

            

            

            "To ensure that protocols that are encapsulated in LISP-GPE
            will work well from a transport interaction perspective, the
            registration of a new encapsulated payload MUST contain an
            analysis of how LISP-GPE SHOULD deal with outer UDP
            Checksum, DSCP mapping, and Explicit Congestion Notification
            (ECN) bits whenever they apply to the new encapsulated
            payload. The analysis for the new encapsulated payload
            registered in this document is in section 3.1."
=

            

            Please, let me know if this address your comments. 

            

            Thanks,

            Fabio

            

            

            

            On 8/29/18 2:17 AM, Magnus Westerlund wrote:

          

          

            
Reviewer: Magnus Westerlund
Review result: Not Ready

This document has been reviewed as part of the transport area =
directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the =
document's
authors and WG for their information and to allow them to address any =
issues
raised.

When done at the time of IETF Last Call, the authors should consider =
this
review together with any other last-call comments they receive.
Please always CC tsv-art@ietf.org if you reply to or forward =
this review.

Issue A.

The reason I state Not Ready has to do with this documents failure to =
consider
the use of zero checksum for IPv6 when tunneling other things than IP. =
The none
GPE version is limited to tunnel IP for which the analysis for use of =
zero
checksum has been done. Each of the new tunneled protocols that are =
specified
in this document, i.e. ethernet and NHS, will need to perform the =
analysis if
they are safe to use zero checksum or not, and if not disallow zero =
checksum
for IPv6/UDP. The documetn also need a requirement in the registration
requirements to perform this analysis and defined if zero checksum is
acceptable or not.

Citing Section 5.3 of draft-ietf-lisp-rfc6830bis

   UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as zero
      by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
      [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is
      received by an ETR, the ETR MUST accept the packet for
      decapsulation.  When an ITR transmits a non-zero value for the UDP
      checksum, it MUST send a correctly computed value in this field.
      When an ETR receives a packet with a non-zero UDP checksum, it MAY
      choose to verify the checksum value.  If it chooses to perform
      such verification, and the verification fails, the packet MUST be
      silently dropped.  If the ETR chooses not to perform the
      verification, or performs the verification successfully, the
      packet MUST be accepted for decapsulation.  The handling of UDP
      zero checksums over IPv6 for all tunneling protocols, including
      LISP, is subject to the applicability statement in [RFC6936].

The issue is that when LISP encapsulate other protocols the impact of a
missdelivered tunnel packet to the wrong ETR can have different impacts. =
As
well as errors in the headers of the encapsulated packet that may be =
assumed to
be protected by the encapsulating layer. Thus, individual analysis of =
each
protocol that are tunneled are needed.

B.) 4.2.  Type of Service

   When a LISP-GPE router performs Ethernet encapsulation, the inner
   802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be
   mapped from the encapsulated frame to the Type of Service field in
   the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'
   field.

Any recommendation about how to perform that mapping? Maybe parts of
https://datatracker.ietf.org/doc/rfc8325/ =
are relevant in this context.

C. General case of 4.2:

I expect other protocols than Ethernet may have a priority field that =
may or
may not be mapped to the DSCP field of the tunnel packet.

I would expect that for new protocol registration in the LISP-GPE Next =
Protocol
Registry should consider this. Thus, it would be good to note that such
considerations are needed and part of what should be evaluated for new
registrations.

D. ECN handling

Section 5.3 of draft-ietf-lisp-rfc6830bis states:

   o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion [RFC3168].
      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
      header to the outer header.  Re-encapsulation MUST copy the 2-bit
      'ECN' field from the stripped outer header to the new outer
      header.

The above rules may not be applicable for all transport protocols. Thus =
I think
it is required that one do protocol specific considerations of ECN. =
TSVWG are
working on recommendations for tunnels handling of  ECN here, see:=20
https://datatracker.ietf.org/doc/draft-ietf-tsvwg=
-ecn-encap-guidelines/ Thus,
my expectation would be to ensure that the registered protocols have =
defined
ECN handling, explicitly or by reference. Secondly that registration
requirement states the need for this consideration.

Summary: To ensure that future added protocols that are encapsulated =
will work
well from a transport interaction perspective there need to be a =
requirement on
new registration to consider and define how they use zero checksum, any =
DSCP
mapping and ECN bits. In addition the current document needs to ensure =
these
things are clearly specified for the encapsulated protocols in this =
document.




          


          

        

        
--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
=
----------------------------------------------------------------------
      


      

    


    

  




=

--Apple-Mail=_265884B5-C01A-48A6-A478-0B9826192F7B--


From nobody Fri Sep 21 03:40:52 2018
Return-Path: 
X-Original-To: lisp@ietf.org
Delivered-To: lisp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E4D130E6C; Fri, 21 Sep 2018 03:40:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund 
To: 
Cc: lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153752645024.7431.2528449997753014329@ietfa.amsl.com>
Date: Fri, 21 Sep 2018 03:40:50 -0700
Archived-At: 
Subject: [lisp] Tsvart telechat review of draft-ietf-lisp-gpe-06
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: 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, 21 Sep 2018 10:40:50 -0000

Reviewer: Magnus Westerlund
Review result: On the Right Track

This new version resolved some of the issues, but there are still some issues
to resolve.

1. The document is missing the applicability analysis for using UDP zeron
checksum to carry either Ethernet or NHS. Each of the incapsulation formats
needs an individual analysis.

2. The Ethernet encapsulation and possible also the the NHS needs
considerations for congestion control. Where the regular LISP encapuslates only
IP, which is assumed to be congestion controlled traffic itself. The same
assumption cannot normally be made for Ethernet. So please provide either an
argumentation why that would work, or consider what mechanism are needed here
to at least prevent that a particular LISP tunnel results in persistent
congestion of the path it uses. I would think some type of circuit breaker is
appropriate for this usage. I make these comments from the assumption that LISP
will be run on top of a multi provider network without guarranted resources,
such as the Internet.



From nobody Fri Sep 21 21:52:39 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4F0130EB4; Fri, 21 Sep 2018 21:52:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 sC5UqrbprEgh; Fri, 21 Sep 2018 21:52:35 -0700 (PDT)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 A69EC130DDD; Fri, 21 Sep 2018 21:52:35 -0700 (PDT)
Received: by mail-pl1-x634.google.com with SMTP id s17-v6so6797739plp.7; Fri, 21 Sep 2018 21:52:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q8yKkvJF1HEos2ZpyM4jKyf/i1baugG/MjvHLxxAlRg=; b=aiKsoZON1ER9sI0EE/jtQaXZHUBZZbRQgI40CpT5SeQ1n7joO+dUvWqKiJU+1hG7VM 0odzHjdidf+ZoYhzldkrei2J9cPcNKChVJ47+fSm2ZrhcJrYVCB3BF3XRKBuN684kNw5 1HrfZC8LsNdFXmqXoAEhVMAgV7fp5UoP+baytFASg21yQGJMz1wL/jt9Ox93ZuT2N2SH BXu+8K67ZTyn4mq3s8sHvjwePmd/voA6IYFbrWOF8zfm8lpCr4IciXcSlUkp8cz7JjuY HK9uZVIwzq710F+jPjbeaVEQZH2YHHrAzuV0VtHlFmt9NaFTUDaoPHjUfZAECj1V0uvC iKmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q8yKkvJF1HEos2ZpyM4jKyf/i1baugG/MjvHLxxAlRg=; b=fi02JU4Ca7ddn5DHU1/Ti/jCRfDf+IT5xiWbTkymHDx5ExY9QZr7js7OhR1AwgTRNP eAOTCaGVbrhf8Z0q7P0SIa8JxPFQhw9l/e/ASICfHuaknsNeKdLoQg20bLttpbTkJcVf PzoQ5wwFZBs72QR+hVxWWRiw/4L8EVybkRWL6suuw/YXHD8EU1SXKPFxq6MihsnmhVYb a6LTi5hZALNjBq6Hz95qFh0bkvov4chxVQVc2G8IQH1jt/XwMeZg0+TwCuFNhBZFSgKu JWGBRBBem7YYuVf/8/hwECgRvDve6EcPI+cjO9cDkCxVf9fXC8HOAaddIMz6MSvt1krc dttw==
X-Gm-Message-State: ABuFfoigddgJwn7SFIrrURLjHeZyO6LsQYo7A5SJGJHLM0m9Cta1OoME A/mUQ5BZ1zitf0/EBAJkr65aW+HW
X-Google-Smtp-Source: ACcGV61HF0MfTIvchCwm8eijr+0jp0QcFBECVt3HFg5DaN8NF3F3WN7Q/XEktG71P5P0htFG72N+Jg==
X-Received: by 2002:a17:902:b947:: with SMTP id h7-v6mr836665pls.157.1537591955229;  Fri, 21 Sep 2018 21:52:35 -0700 (PDT)
Received: from [10.10.37.31] ([65.154.156.50]) by smtp.gmail.com with ESMTPSA id z19-v6sm37510410pgi.33.2018.09.21.21.52.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Sep 2018 21:52:34 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci 
In-Reply-To: <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net>
Date: Fri, 21 Sep 2018 21:52:33 -0700
Cc: Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org, The IESG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BE5C929-D2FA-4786-9F5E-0A93E7700880@gmail.com>
References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net>  <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com>   <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net>
To: "Mirja Kuehlewind (IETF)" 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 22 Sep 2018 04:52:37 -0000

> However, I totally disagree with your comment on providing details =
that are not implemented. If they are not implemented correctly, it =
might even be more important to spell them out in this document, so =
implementors have chance to update their (future) implementation to do =
the correct thing. Having deployed implementations that are non =
standard-conform always happens and in this case it is probably not =
specifically problematic as it doesn=E2=80=99t impact interoperability. =
However, it is important though that the spec is correct.

And why do you think they are implemented incorrectly?=20

Dino


From nobody Fri Sep 21 21:53:54 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C80D130DD8; Fri, 21 Sep 2018 21:53:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3VxNKKKKUIpg; Fri, 21 Sep 2018 21:53:43 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 173871277BB; Fri, 21 Sep 2018 21:53:43 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id x20-v6so1269647pln.9; Fri, 21 Sep 2018 21:53:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HlayRwz/rLpXxMH+WmXfuXqwGEFb2WhW4Y6ighoy9ZQ=; b=UFGHN121LPjGHUZiUmGFJFKTr4xU/3z8ERP0HB4W5z+M8hgsmfBFGKTqOc60wQ77ar P4DVNuBrVnqFWM+FhC92/RPLEGN6tZvBzCZPUFyfsZmyWGWHKA1+Tj/tK3EF+Fv0NbUR UH3+p9cR3F67X+waikz82pE2clC51ffUHdDHBVgCdGINMbx5BV402SPimrY9vdl3HNLy jfoG7m5qA6uKLRGuUdICBd76fmvA7E8j9hnbdjIeHyXEdRFJMUS/7G+U3usMpiA6pq/Q 044YUpT4O4G4zWSoVWcTb6VMAn/cmWnOti2hSb7zgPXGRmTNuLywtNy3TG7okc++Keel xS/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HlayRwz/rLpXxMH+WmXfuXqwGEFb2WhW4Y6ighoy9ZQ=; b=RaCYWatbz1/ko/SekYR0fHW6WaAqb9T1hMtlm+IIVZdovBNwh831YtQjr62lz8YAQ5 xyO6U+HQ+Y0Fv22IOz6wfeKn5xdA/2DTSdyWeBg1DSj1I7gTQDMJ8R2kykb1lleTfz4M o4DZvXd/z4KLtWFU6l2NWdRwO8mRBDuOKxXdt+G/LJGLjWStvyijFs2CR55MpqBp5Ilc xN/nnXmG7nXObxfxCZJKKv1aacYZiJotqhUFV+9foFfDvYYXZ9PpsZE6TzdAuReCfmvm 2v+OPEkotrtcOOYo+7a/6dQCB1GJJwL5pvT3Qg4Lu3CbbCMz/hHQbP2egl4Zjl0ybuE5 E/8g==
X-Gm-Message-State: ABuFfohMf06jsbmDMp7T9+9T0hzQHIgEUuO2tIX7hsUZbVRoHKbb+Ict pkXAtu6bc2U5PZcsYQPNy10=
X-Google-Smtp-Source: ACcGV62RjN4nT81CS5yHGSPHf+aTsht6c59uOe2wmrLtJ8neik0H5vHNjotjsTNhu9y3SmleolCgdQ==
X-Received: by 2002:a17:902:2f43:: with SMTP id s61-v6mr828527plb.176.1537592022681;  Fri, 21 Sep 2018 21:53:42 -0700 (PDT)
Received: from [10.10.37.31] ([65.154.156.50]) by smtp.gmail.com with ESMTPSA id j27-v6sm53948510pfj.91.2018.09.21.21.53.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Sep 2018 21:53:42 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci 
In-Reply-To: 
Date: Fri, 21 Sep 2018 21:53:41 -0700
Cc: Mirja Kuehlewind , Luigi Iannone , lisp-chairs@ietf.org, IESG , lisp@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B85EA78-B143-4D2F-90D5-EDF7A995A811@gmail.com>
References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net>  <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com>   <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net> 
To: Spencer Dawkins at IETF 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 22 Sep 2018 04:53:46 -0000

> Mirja's right, that we're advising people to do path MTU discovery of =
some type (and I'm pretty sure =
https://tools.ietf.org/html/rfc4821#section-10.3 is what we would =
recommend in this case).=20
>=20
> Dino's right, that putting out a standard that doesn't reflect =
deployed implementations won't inspire people to conform to standards.=20=

>=20
> But do the right thing, of course =E2=80=A6

And I believe the right thing is the newly added text I put in. We did =
not ignore the comment, we did try to address it.

Dino


From nobody Sat Sep 22 09:32:02 2018
Return-Path: 
X-Original-To: lisp@ietf.org
Delivered-To: lisp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 082DB12008A; Sat, 22 Sep 2018 09:31:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: lisp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: lisp@ietf.org
Message-ID: <153763391398.23999.4057414979062550345@ietfa.amsl.com>
Date: Sat, 22 Sep 2018 09:31:54 -0700
Archived-At: 
Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-19.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: 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, 22 Sep 2018 16:31:54 -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 WG of the IETF.

        Title           : The Locator/ID Separation Protocol (LISP)
        Authors         : Dino Farinacci
                          Vince Fuller
                          Dave Meyer
                          Darrel Lewis
                          Albert Cabellos
	Filename        : draft-ietf-lisp-rfc6830bis-19.txt
	Pages           : 45
	Date            : 2018-09-22

Abstract:
   This document describes the Data-Plane protocol for the Locator/ID
   Separation Protocol (LISP).  LISP defines two namespaces, End-point
   Identifiers (EIDs) that identify end-hosts and Routing Locators
   (RLOCs) that identify network attachment points.  With this, LISP
   effectively separates control from data, and allows routers to create
   overlay networks.  LISP-capable routers exchange encapsulated packets
   according to EID-to-RLOC mappings stored in a local Map-Cache.

   LISP requires no change to either host protocol stacks or to underlay
   routers and offers Traffic Engineering, multihoming and mobility,
   among other features.

   This document obsoletes RFC 6830.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-19
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-19


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 Sat Sep 22 09:35:23 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A2D130E5A; Sat, 22 Sep 2018 09:35:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 q8889_xfGiNz; Sat, 22 Sep 2018 09:35:14 -0700 (PDT)
Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 115E4130E7E; Sat, 22 Sep 2018 09:35:14 -0700 (PDT)
Received: by mail-pf1-x441.google.com with SMTP id i26-v6so7278313pfo.12; Sat, 22 Sep 2018 09:35:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7NAdC6vSd1zAbaxkbMcsGfgW782zYLzqn1qy0556ktw=; b=uEah4oqQr9NyjnVGOUSahRkgbKUjyIS0TT8uBLPRf1KUgPzQD/+hRDTu+i5430yitJ BKDKJBY3QhZ2GSE611ceTIiStPy21FLnyyuj1x/9bt25z4nhKRtMbs0TtP4SC3IHTzlU JYsZgRyLpPVqICWxrYv+ODUpWhDfWySQCkl1vXuJ4blbWUzjxoXnLvKY24unF3A+//vn 9jZdjhseurA0ce2azYT8uYWarhrsKtpZU6e9flLkk8PG7JJ/X6nmgtLqxLmRiEIrSOOv ObGB03QDDAvgYTblrU2anj2CeYRD06tM3ghGopa/ZmP6YXaH0KXzz/dy905oF/1d0296 HN1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7NAdC6vSd1zAbaxkbMcsGfgW782zYLzqn1qy0556ktw=; b=pkR5nEV4Gs3290wP50ETOJG9LhBBrnw4rgofnXqdvJVwaiBiNxi3/81V3xhBXb7dAZ 8+2urgBV1g223SJQb+sBCGHdu6vFRrOeq6hXkXgEiNcYvZOtKKXJd+5GF/PLIMWkzHtx 1yY8SZiYW2NUd3ACK1R2kLFkWGOUotvbi8pwLGuQdmQv8lcUhwb8MCp3tHtqVeTuXXSt lr4lB5nOCM+MI3jBacu7Ulmni646LnPWQVYDMB/6ZDs8Xdik7bwQMWHdVTtaz4i0k2kB 5lh6ZrkYA1P61hrQG+QmUlxMpe6QDUbWduNQjCXK5C4yo/MjIWvZWce8DolvvRCm0MPm qGGA==
X-Gm-Message-State: APzg51Ck72HGODSJUIl3RQp5V0qrnT9BLGU1IkCc1dDOvDNQqEgYMVUj 8DUxknQT2tpdZiOXg5CE/lZeQZ1m
X-Google-Smtp-Source: ANB0Vdaz27RRtvDCUk2YmySa3S2bVcVIulphhYhDwd002Ue57KoqLfOHLxKFpfvWro8ZdsNkppFVfw==
X-Received: by 2002:a62:ac12:: with SMTP id v18-v6mr3204539pfe.126.1537634113326;  Sat, 22 Sep 2018 09:35:13 -0700 (PDT)
Received: from [100.72.18.210] (ip67-155-240-118.z240-155-67.customer.algx.net. [67.155.240.118]) by smtp.gmail.com with ESMTPSA id v8-v6sm38439866pff.120.2018.09.22.09.35.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Sep 2018 09:35:12 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci 
In-Reply-To: <153763391398.23999.4057414979062550345@ietfa.amsl.com>
Date: Sat, 22 Sep 2018 09:35:12 -0700
Cc: i-d-announce@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D648F3D-6BDE-4992-89C3-28DF174FFE9D@gmail.com>
References: <153763391398.23999.4057414979062550345@ietfa.amsl.com>
To: lisp@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-19.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 22 Sep 2018 16:35:22 -0000

Folks, this was just a 2 line editing change.=20

Cheers and happy weekend,
Dino

> On Sep 22, 2018, at 9:31 AM, internet-drafts@ietf.org wrote:
>=20
>=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 WG of =
the IETF.
>=20
>        Title           : The Locator/ID Separation Protocol (LISP)
>        Authors         : Dino Farinacci
>                          Vince Fuller
>                          Dave Meyer
>                          Darrel Lewis
>                          Albert Cabellos
> 	Filename        : draft-ietf-lisp-rfc6830bis-19.txt
> 	Pages           : 45
> 	Date            : 2018-09-22
>=20
> Abstract:
>   This document describes the Data-Plane protocol for the Locator/ID
>   Separation Protocol (LISP).  LISP defines two namespaces, End-point
>   Identifiers (EIDs) that identify end-hosts and Routing Locators
>   (RLOCs) that identify network attachment points.  With this, LISP
>   effectively separates control from data, and allows routers to =
create
>   overlay networks.  LISP-capable routers exchange encapsulated =
packets
>   according to EID-to-RLOC mappings stored in a local Map-Cache.
>=20
>   LISP requires no change to either host protocol stacks or to =
underlay
>   routers and offers Traffic Engineering, multihoming and mobility,
>   among other features.
>=20
>   This document obsoletes RFC 6830.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-19
> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-19
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-rfc6830bis-19
>=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 Sat Sep 22 09:42:07 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67495130E29 for ; Sat, 22 Sep 2018 09:42:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Z2_jsMYrjw6L for ; Sat, 22 Sep 2018 09:42:01 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 A3780130E26 for ; Sat, 22 Sep 2018 09:42:01 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id 85-v6so4314711pge.6 for ; Sat, 22 Sep 2018 09:42:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:references:to:date; bh=JiRnc/TFgNKxSTqPqSVv2tZkkb8LCHMhq1P1ao8Rlgs=; b=lWdQLvXs+YgHLoBd5nyPK0ylo0Rne+kAX+rVErlzgePJongh/XFulg9mmrshxtk0hA IztQS3M+/JyDt0I3fqyiuzhrsJzoAfM44w1dVG+rMyxyfcGPfB7GSbmoI9MoKVUkrTpy L/IsZN1XDEgZ7R5YuoHnULa1TuxaBB16b1cEgurT8j/K7llATB5v/tsgRIvGC/KYXaJe mV92DeaCt6TtbDsd5twQAlL2X2zJRsbBVahYpH29bduaoZJCXBzmH1wEaGQsmp50qKvW vnRCQz84Su2dEG5G1+4+bOyYt0Le7mkMZpLGVDI6rQZ5CS0jcXKcChKgn6suZ127b2rt F6AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=JiRnc/TFgNKxSTqPqSVv2tZkkb8LCHMhq1P1ao8Rlgs=; b=kV2F6WJ6qJDYX8v47q/Qd1bWPwN1DFC78kkZnfHWvnrY47MGsYk7DQMBoS/prtzxih W+Yag7OhgaEy1uD9kyC5mD4cyoazIekPhZshDxm+bOnSaHK7XeIHKzNOAnuVJ7xh89Go gFySPHjhjvzUknjRb3jITACSWQO54iOQZNvHQJkjlcgFCBun+qdAVi7ffSCE4ANGSdD/ c6v9uTX97hSF195Ao0pudbbXZKk/23biAplD38ecXwv10xwx95ENzbQf1acHRrG3pnTt 8kE2qcI/LiNPZtP5A6WpKqPcu+JZ+nVRjf6NAHgbrUvvCWXo612L7R7ARzgnLYARMK4l NdUg==
X-Gm-Message-State: ABuFfoitv3byKFEWuc09jsuVpVcbeanCT2YT+NpNJvxjJ3+4zCsUZA0H ff2ECSbdaddmG0BIpygJPCWnuvoh
X-Google-Smtp-Source: ACcGV62othmcFNVInjBryK7nHA/qQp2YGPtugtvF9+pUQsGnqnaONOEUm4GpwVbvcG2qEm5tPRBKAA==
X-Received: by 2002:a63:5d55:: with SMTP id o21-v6mr2814172pgm.349.1537634520872;  Sat, 22 Sep 2018 09:42:00 -0700 (PDT)
Received: from ?IPv6:2600:380:7458:b26b:585:ebfa:1093:abed? ([2600:380:7458:b26b:585:ebfa:1093:abed]) by smtp.gmail.com with ESMTPSA id c78-v6sm42275716pfc.188.2018.09.22.09.41.59 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Sep 2018 09:42:00 -0700 (PDT)
From: Dino Farinacci 
Content-Type: multipart/alternative; boundary="Apple-Mail=_4AC17CFE-9EE6-46B5-9C3F-092622B3CFC8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: 
References: <153763391398.23999.4057414979062550345@ietfa.amsl.com>
To: "lisp@ietf.org list" 
Date: Sat, 22 Sep 2018 09:41:59 -0700
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-rfc6830bis-19.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 22 Sep 2018 16:42:06 -0000

--Apple-Mail=_4AC17CFE-9EE6-46B5-9C3F-092622B3CFC8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Folks, this was just a 2 line editing change.=20

Cheers and happy weekend,
Dino

> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: I-D Action: draft-ietf-lisp-rfc6830bis-19.txt
> Date: September 22, 2018 at 9:31:54 AM MST
> To: 
> Cc: lisp@ietf.org
> Reply-To: internet-drafts@ietf.org, lisp@ietf.org
>=20
>=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 WG of =
the IETF.
>=20
>        Title           : The Locator/ID Separation Protocol (LISP)
>        Authors         : Dino Farinacci
>                          Vince Fuller
>                          Dave Meyer
>                          Darrel Lewis
>                          Albert Cabellos
> 	Filename        : draft-ietf-lisp-rfc6830bis-19.txt
> 	Pages           : 45
> 	Date            : 2018-09-22
>=20
> Abstract:
>   This document describes the Data-Plane protocol for the Locator/ID
>   Separation Protocol (LISP).  LISP defines two namespaces, End-point
>   Identifiers (EIDs) that identify end-hosts and Routing Locators
>   (RLOCs) that identify network attachment points.  With this, LISP
>   effectively separates control from data, and allows routers to =
create
>   overlay networks.  LISP-capable routers exchange encapsulated =
packets
>   according to EID-to-RLOC mappings stored in a local Map-Cache.
>=20
>   LISP requires no change to either host protocol stacks or to =
underlay
>   routers and offers Traffic Engineering, multihoming and mobility,
>   among other features.
>=20
>   This document obsoletes RFC 6830.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-19
> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-19
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-rfc6830bis-19
>=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
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--Apple-Mail=_4AC17CFE-9EE6-46B5-9C3F-092622B3CFC8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Folks, this was just a 2 line editing change. 

Cheers and happy weekend,
Dino

Begin forwarded message:

From: =
internet-drafts@ietf.org
Subject: =
I-D Action: =
draft-ietf-lisp-rfc6830bis-19.txt
Date: =
September 22, 2018 at 9:31:54 =
AM MST
To: =
<i-d-announce@ietf.org>
Cc: lisp@ietf.org
Reply-To: =
internet-drafts@ietf.org, lisp@ietf.org


A New =
Internet-Draft is available from the on-line Internet-Drafts =
directories.
This draft is a work item of the Locator/ID =
Separation Protocol WG of the IETF.

 =
       Title =
          : The =
Locator/ID Separation Protocol (LISP)
 =
       Authors =
        : Dino Farinacci
 =
            &n=
bsp;           &nbs=
p;Vince Fuller
 =
            &n=
bsp;           &nbs=
p;Dave Meyer
 =
            &n=
bsp;           &nbs=
p;Darrel Lewis
 =
            &n=
bsp;           &nbs=
p;Albert Cabellos
	Filename =
       : =
draft-ietf-lisp-rfc6830bis-19.txt
	Pages =
          : 45
	=
Date =
           : =
2018-09-22

Abstract:
 =
  This document describes the Data-Plane protocol for the =
Locator/ID
   Separation Protocol (LISP). =
 LISP defines two namespaces, End-point
 =
  Identifiers (EIDs) that identify end-hosts and Routing =
Locators
   (RLOCs) that identify network =
attachment points.  With this, LISP
 =
  effectively separates control from data, and allows routers =
to create
   overlay networks. =
 LISP-capable routers exchange encapsulated packets
 =
  according to EID-to-RLOC mappings stored in a local =
Map-Cache.

   LISP requires no =
change to either host protocol stacks or to underlay
 =
  routers and offers Traffic Engineering, multihoming and =
mobility,
   among other features.

   This document obsoletes RFC =
6830.


The IETF datatracker =
status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/

There are also htmlized versions =
available at:
https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-19
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bi=
s-19

A diff from the previous version is =
available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-rfc6830bis-=
19


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: =
http://www.ietf.org/shadow.html
or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

=

--Apple-Mail=_4AC17CFE-9EE6-46B5-9C3F-092622B3CFC8--


From nobody Mon Sep 24 02:18:09 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92C8130DF3 for ; Mon, 24 Sep 2018 02:18:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com
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 b7bTc4B-M-Xf for ; Mon, 24 Sep 2018 02:18:01 -0700 (PDT)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 217BF130E76 for ; Mon, 24 Sep 2018 02:18:01 -0700 (PDT)
Received: by mail-wr1-x443.google.com with SMTP id z3-v6so7056715wrr.13 for ; Mon, 24 Sep 2018 02:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ryToZ5L535zglsWBXJUiVKsBn4Ex/IkXPuKmOlUYF6E=; b=UQmEsSxybVmbxUfV/E7mf56aGgffZxeYRhKPWC2dpwAWWSpTJwxzREshtmGLadNO+b fZJuS+uZ+XTqjcO7/zAMbbLkfEMXs4Zu8Cz4LCKYPWeoeWE9j3ec9R+TQnOnG1FrqY+u RPhKwvTyDCv0ZD6Q3PcILB3PkcrIhApRqrVF7aPJvElh+D0TngQ927CGJsXdLQXaal+t 4H7Y6dWb8hyOPg3uZQRQBX2ETuwr3KMesS0jxp5i4WKnnrGnLFBfLYHNOG4NcyFeYyVu zbGyCiqEy8ouKqpJf4O+38y+Ns379pcCBzLmPHCQ6MSPfqlNF0CpxTM2CYaZ2r4hPLJo V5RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ryToZ5L535zglsWBXJUiVKsBn4Ex/IkXPuKmOlUYF6E=; b=OWl2FgESw9t0l1m8/Hl4F1Ib/1faJtPO6jb7oiPWHmNNWW7HV9IrqAlzdB78zwmuf5 2S68SSfEVqn7UBsxu64fYNHLXqDToJqXmyefUgiQZcYVbGlS9DWuflt3q9+spn13zwFk 50t9Bg0WmnfxaNj8zGYN9JizMajBBZvppsmKlkYsXawj2YOVkkU6ECt8L2sPmTe31w8j yYR0Hrx8pIt+5JmZvvAcWVxe8et5k/gNbexIZzo2PHHVHOLZ/CJLxo/+BEGOpGzwYV4U MKZXbslJj61l9c42vb2l2qgjxwTR6nPR6+vglButZPqKeT18XAr3VcohAN9IrXkKYQsq CN9w==
X-Gm-Message-State: ABuFfogbqHK6ufgFcRMkSM5Kuaa+U0mctHAVXeDSUKj8Kk06bLBCnPBV Rr1OQ61U8hrTkLwQlLjJYaPnISAFRPg=
X-Google-Smtp-Source: ACcGV604Hrd6PS+EoEEBw/oybLT6nfAOosVUJ58XUq4X/zt+LFApJp63b4smjOhgbccxGTNUghEPUg==
X-Received: by 2002:adf:84c1:: with SMTP id 59-v6mr7372008wrg.97.1537780679217;  Mon, 24 Sep 2018 02:17:59 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:d1c9:b660:aa9d:3f5? ([2001:660:330f:a4:d1c9:b660:aa9d:3f5]) by smtp.gmail.com with ESMTPSA id k7-v6sm11936691wmf.41.2018.09.24.02.17.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Sep 2018 02:17:57 -0700 (PDT)
From: Luigi Iannone 
Message-Id: <87CD79A8-9A7E-40BA-8333-61E27235B852@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_62E08250-C133-4A33-B6AE-C73797A7660A"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 24 Sep 2018 11:18:16 +0200
In-Reply-To: 
Cc: Erik Nordmark , Dino Farinacci , lisp-chairs@ietf.org
To: "lisp@ietf.org list" 
References: <153608761426.14137.783984991533026116@ietfa.amsl.com>  
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Sep 2018 09:18:08 -0000

--Apple-Mail=_62E08250-C133-4A33-B6AE-C73797A7660A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi All,

the call for adoption for this document is now closed.

On the mailing list there were messages in support of the document, =
showing a consensus for adoption.

Authors are invited to submit a new version of the document named: =
draft-ietf-lisp-ecdsa-auth-00.txt

Thanks to all people that expressed their opinion.

Ciao

Luigi & Joel



> On 5 Sep 2018, at 09:46, Luigi Iannone  wrote:
>=20
> Folks,
>=20
> As you can see from Dino=E2=80=99s email (below) the authors are =
requesting that the document
>=20
> https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ =

>=20
> be adopted as WG item.
>=20
> This email starts the usual 14 days call for adoption, this call will =
end on
> Thursday the 19th September, 2018.
>=20
> Please email the WG list stating whether or not you support =
acceptance.
>=20
> If you email to support the acceptance of this document as a WG item, =
please
> also indicate if you are able and willing to either contribute to, or =
review, (or both) the draft.
>=20
> Sitting in silence does not indicate support, please respond =
appropriately.
>=20
> The Chairs
> Joel & Luigi
>=20
>=20
>> On 4 Sep 2018, at 21:05, Dino Farinacci > wrote:
>>=20
>> Folks, here is an update that reflects comments we received at the =
Montreal presentation:
>>=20
>> 
>>=20
>> A diff file is included for your convenience.=20
>>=20
>> At this time, I would like to request this document for working group =
adoption.
>>=20
>> Thanks,
>> Dino/Erik
>>=20
>> 
>>=20
>>=20
>>> Begin forwarded message:
>>>=20
>>> From: internet-drafts@ietf.org 
>>> Subject: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt
>>> Date: September 4, 2018 at 12:00:14 PM PDT
>>> To: >
>>> Reply-To: internet-drafts@ietf.org 
>>>=20
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>>=20
>>>=20
>>>        Title           : LISP Control-Plane ECDSA Authentication and =
Authorization
>>>        Authors         : Dino Farinacci
>>>                          Erik Nordmark
>>> 	Filename        : draft-farinacci-lisp-ecdsa-auth-03.txt
>>> 	Pages           : 17
>>> 	Date            : 2018-09-04
>>>=20
>>> Abstract:
>>>   This draft describes how LISP control-plane messages can be
>>>   individually authenticated and authorized without a a priori =
shared-
>>>   key configuration.  Public-key cryptography is used with no new =
PKI
>>>   infrastructure required.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/ =

>>>=20
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03 =

>>> =
https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecdsa-auth-03
>>>=20
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-ecdsa-auth-03=

>>>=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
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>=20
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org 
>> https://www.ietf.org/mailman/listinfo/lisp
>=20


--Apple-Mail=_62E08250-C133-4A33-B6AE-C73797A7660A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
All,

the call for =
adoption for this document is now closed.

On =
the mailing list there were messages in support of the document, showing =
a consensus for adoption.

Authors are =
invited to submit a new version of the document named: =
draft-ietf-lisp-ecdsa-auth-00.txt

Thanks to =
all people that expressed their opinion.

Ciao

Luigi & Joel



On 5 Sep 2018, at 09:46, Luigi =
Iannone <ggx@gigix.net> wrote:

Folks,

As you can see from =
Dino=E2=80=99s email (below) the authors are requesting that the =
document

https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-aut=
h/

be =
adopted as WG item.

This email starts the usual 14 days call for adoption, this =
call will end on
Thursday the 19th September, =
2018.

Please email the WG list stating =
whether or not you support acceptance.

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

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

The =
Chairs
Joel & Luigi


On 4 Sep 2018, at 21:05, Dino Farinacci =
<farinacci@gmail.com> wrote:

Folks, =
here is an update that reflects comments we received at the Montreal =
presentation:

<PastedGraphic-1.png>

A diff file is included for your =
convenience. 

At this time, I would like to request this document for =
working group adoption.

Thanks,
Dino/Erik
<rfcdiff-ecdsa.html>


Begin =
forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt
Date: September 4, 2018 at 12:00:14 PM PDT
To: <i-d-announce@ietf.org>
Reply-To: internet-drafts@ietf.org


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


 =
       Title =
          : LISP =
Control-Plane ECDSA Authentication and Authorization
 =
       Authors =
        : Dino Farinacci
 =
            &n=
bsp;           &nbs=
p;Erik Nordmark
	Filename =
       : =
draft-farinacci-lisp-ecdsa-auth-03.txt
	Pages =
          : 17
	=
Date =
           : =
2018-09-04

Abstract:
 =
  This draft describes how LISP control-plane messages can =
be
   individually authenticated and authorized =
without a a priori shared-
   key configuration. =
 Public-key cryptography is used with no new PKI
 =
  infrastructure required.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-aut=
h/

There are also htmlized versions =
available at:
https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03<=
/a>
https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecds=
a-auth-03

A diff from the previous =
version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-ecdsa-=
auth-03


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: =
http://www.ietf.org/shadow.html
or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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


=

--Apple-Mail=_62E08250-C133-4A33-B6AE-C73797A7660A--


From nobody Mon Sep 24 02:19:26 2018
Return-Path: 
X-Original-To: lisp@ietf.org
Delivered-To: lisp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA28130E8F; Mon, 24 Sep 2018 02:19:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153778076438.28139.13540727997057454192.idtracker@ietfa.amsl.com>
Date: Mon, 24 Sep 2018 02:19:24 -0700
Archived-At: 
Subject: [lisp] The LISP WG has placed draft-farinacci-lisp-ecdsa-auth in state "Adopted by a WG"
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: 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, 24 Sep 2018 09:19:25 -0000

The LISP WG has placed draft-farinacci-lisp-ecdsa-auth in state
Adopted by a WG (entered by Luigi Iannone)

The document is available at
https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/


From nobody Mon Sep 24 05:52:27 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2110130E9D for ; Mon, 24 Sep 2018 05:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 1v8X6LAf4nXd for ; Mon, 24 Sep 2018 05:52:24 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48CC130E98 for ; Mon, 24 Sep 2018 05:52:23 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=K/qPirK4umrlAGSwBinjipxkT9Z6+Fjttte0leadXFD5EMqixTKamXcuvwNW46DsVpdxP5boTLkfYW0nKKFSIx5lwKaEcWyT/WZhEYuE6L8pIqdtExV+mNQE0Nm8b5jV4G5dS5tcAm4WIKFZKMINvsx7UZqaVWucvtGT54tn8Nc=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 1363 invoked from network); 24 Sep 2018 14:52:20 +0200
Received: from mue-88-130-61-096.dsl.tropolys.de (HELO ?192.168.178.24?) (88.130.61.96) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 24 Sep 2018 14:52:20 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <0BE5C929-D2FA-4786-9F5E-0A93E7700880@gmail.com>
Date: Mon, 24 Sep 2018 14:52:19 +0200
Cc: Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org, The IESG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <11FBAC13-2859-4778-84CA-B546EB669727@kuehlewind.net>
References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net>  <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com>   <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net> <0BE5C929-D2FA-4786-9F5E-0A93E7700880@gmail.com>
To: Dino Farinacci 
X-Mailer: Apple Mail (2.3445.9.1)
X-PPP-Message-ID: <20180924125220.1354.72584@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
Subject: Re: [lisp]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Sep 2018 12:52:26 -0000

Because they don=E2=80=99t follow RFC6040 and therefore we do something =
different in some corner cases.



> Am 22.09.2018 um 06:52 schrieb Dino Farinacci :
>=20
>> However, I totally disagree with your comment on providing details =
that are not implemented. If they are not implemented correctly, it =
might even be more important to spell them out in this document, so =
implementors have chance to update their (future) implementation to do =
the correct thing. Having deployed implementations that are non =
standard-conform always happens and in this case it is probably not =
specifically problematic as it doesn=E2=80=99t impact interoperability. =
However, it is important though that the spec is correct.
>=20
> And why do you think they are implemented incorrectly?=20
>=20
> Dino
>=20


From nobody Mon Sep 24 08:30:50 2018
Return-Path: 
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E2C130EE2; Mon, 24 Sep 2018 08:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 n4gjBlDSXv3Z; Mon, 24 Sep 2018 08:30:36 -0700 (PDT)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 79E71130EC4; Mon, 24 Sep 2018 08:30:36 -0700 (PDT)
Received: by mail-ot1-x32a.google.com with SMTP id c18-v6so2940213otm.3; Mon, 24 Sep 2018 08:30:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=uOlORzr6/HT0w69oB9EPaIpDxUSmG22fm9fwdmdo+2c=; b=LRiuTwwQbLSZBvtjMIvpsOCw0T5FeZuhP67BoN/qdRM17ibtK7Veb2ZcQctibma4IC ml3V0zBbCsmjwyMCxpM2BCfp3o/4pwu+qapExA+RDtquP+8P3cj+wZHge4u3tW0Qwq67 l1AcdRwto3/8ybf9xUskIm5bgW3YT/n68t77aZIBFY+QP0nrNZJQnBRGpw2x/EuYckWj F3Mp25XvDGiCv/lLW87VuvVnutZBWdCIUexqTagB5DSz0EvCS7eXWlReZ413SPvmxrwi APo4a2+Kkha5mtsdO7T0GhuYPfFSIpM6xfYvbfpsuHge67hx+7amvjT/IC0SoHBcYWmF 3Zxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=uOlORzr6/HT0w69oB9EPaIpDxUSmG22fm9fwdmdo+2c=; b=cp5BNkqibY0ISZKfUe6E6DTGVwWRhLJ/pYcbSSCvRD6wkYxF1I3K9ukz7tDnUBUUQa wX21E2fLVl+KQH195fM6q/BS0GrUHMMeeWViOBejM1t8Vmfu92fc/dkQ0LK5TyjZX1PW 5kNrHpRCA3zfQDAaqKRlhoaRmsz+h/s2YIQIdZD6/BiWuzt391swg5ZDVTTxMJuIgy/j //K7PrOntiGcwqo4/QyO9Kyz3zbybacTMxEAw6OVlP1jtrXBqJGnUcP3tYnCodtWbfYI mVJRKKDBBVPD/LjB/SBy8HZnbnnfkPtKlDpPZ7F27LYFDQPawZiBP/5b+yfBPgdpyHmS 8bTA==
X-Gm-Message-State: ABuFfogii1keP8/dZJshsdEBDJ9ugm1vpQapBjkUa75B3HlEyY8DEjEX NNlg7tye6wty07VJ6mFDnOBdDr+Nq88U4RNcgzxuow==
X-Google-Smtp-Source: ACcGV61S1D4u/D73HYNr6O+uoqLypF89So/0EvrzloClh9SpgPodBRmKFXNk2bBwzQBYHdzojvwzONtnEn8L2RjYlXM=
X-Received: by 2002:a9d:5f82:: with SMTP id g2-v6mr6640333oti.126.1537803035389;  Mon, 24 Sep 2018 08:30:35 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 24 Sep 2018 15:30:34 +0000
From: Alvaro Retana 
In-Reply-To: <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net>
References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net>
X-Mailer: Airmail (506)
MIME-Version: 1.0
Date: Mon, 24 Sep 2018 15:30:34 +0000
Message-ID: 
To: Luigi Iannone , "lisp@ietf.org list" 
Cc: lisp-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a8bf2505769fab28"
Archived-At: 
Subject: Re: [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113bis-01.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Sep 2018 15:30:49 -0000

--000000000000a8bf2505769fab28
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[Speaking as a WG participant.]

Hi!

I don=E2=80=99t object to the adoption.

The main change with respect to rfc8113, that doesn=E2=80=99t seem right to=
 me, is
that rfc8113 defined the LISP Packet Types registry, but this document only
adds to it.  In the weird world of Updating and Obsoleting RFCs, I think
this means that we=E2=80=99re left with no document being the originator of=
 the
registry.

Note that rfc6833bis, which requests that the references from the registry
point to it *and* to rfc8113, also doesn=E2=80=99t define the registry (whi=
ch is
the correct thing to do).

My 2c.

Alvaro.

On September 19, 2018 at 11:05:05 AM, Luigi Iannone (ggx@gigix.net) wrote:

Folks,

here is another piece of the work done in our WG that needs to be moved to
PS.

It is the updated version of RFC 8113, nothing changed just updated
coherently with the current status of the other documents.

Because this documents is really really short we will have just one week
adoption call followed be one week WG Last Call.

This email officially starts the one week call for adoption.

Please spend 10 minutes having a look at the document and send an email on
whether you agree or not to adopt it.

Thanks

Ciao

Luigi


Begin forwarded message:

*From:* internet-drafts@ietf.org
*Subject:* *I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt*
*Date:* 19 September 2018 at 16:49:31 CEST
*To:* 
*Reply-To:* internet-drafts@ietf.org


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


       Title           : Locator/ID Separation Protocol (LISP): Shared
Extension Message & IANA Registry for Packet Type Allocations
       Authors         : Mohamed Boucadair
                         Christian Jacquenet
Filename        : draft-boucadair-lisp-rfc8113bis-01.txt
Pages           : 5
Date            : 2018-09-19

Abstract:
  This document specifies a Locator/ID Separation Protocol (LISP)
  shared message type for defining future extensions and conducting
  experiments without consuming a LISP packet type codepoint for each
  extension.

  This document obsoletes RFC 8113.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01
https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc8113bis-01


Please note that it may take a couple of minutes from the time of submissio=
n
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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

--000000000000a8bf2505769fab28
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

[Speaking as a WG participant.]

Hi!

I don=E2=80=99t object to the adoption.

The main change with respect to rfc8=
113, that doesn=E2=80=99t seem right to me, is that rfc8113 defined the LIS=
P Packet Types registry, but this document only adds to it.=C2=A0 In the we=
ird world of Updating and Obsoleting RFCs, I think this means that we=E2=80=
=99re left with no document being the originator of the registry.

Note that rfc6833bis, which re=
quests that the references from the registry point to it *and* to rfc8113, =
also doesn=E2=80=99t define the registry (which is the correct thing to do)=
.

<=
div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:=
13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">My 2c.

Alvaro.

On September 19, 2018 at 11:05:05 AM, Luigi Iannone (ggx@gigix.net) wrote:

Folks,

here is another piece of the work done in our WG that needs to be moved to PS.

It is the updated version of RFC 8113, nothing changed just updated coherently with the current status of the other documents.

Because this documents is really really short we will have just one week adoption call followed be one week WG Last Call.

This email officially starts the one week call for adoption.

Please spend 10 minutes having a look at the document and send an email on whether you agree or not to adopt it.

Thanks

Ciao

Luigi


Begin forwarded message:

Fr= om: internet-drafts@ietf.org
Su= bject: I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt
Da= te: 19 September 2018 at 16:49:31 CEST
To= : <i-d-announce@ietf.org>
Re= ply-To: internet-drafts@ietf.org


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


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Mohamed Boucadair
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Christian Jacquenet
Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: draft-boucadair-lisp-rfc8113bis-01.txt
Pages =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 5
Date =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2018-09-19

Abstract:
=C2=A0=C2=A0This document specifies a Locator/ID Separation Protocol (LISP)
=C2=A0=C2=A0shared message type for defining future extensions and conducting
=C2=A0=C2=A0experiments without consuming a LISP packet type codepoint for each
=C2=A0=C2=A0extension.

=C2=A0=C2=A0This document obsoletes RFC 8113.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113= bis/

There are also htmlized versions available at:
= https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01
https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc811= 3bis-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc8113bis= -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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.= ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html=
or ftp://ftp.ietf.org= /ietf/1shadow-sites.txt

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf= .org/mailman/listinfo/lisp
--000000000000a8bf2505769fab28-- From nobody Mon Sep 24 08:33:41 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA91130DD2; Mon, 24 Sep 2018 08:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.738 X-Spam-Level: X-Spam-Status: No, score=-0.738 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Pd7e_Lg9FlcL; Mon, 24 Sep 2018 08:33:31 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 97EF41252B7; Mon, 24 Sep 2018 08:33:31 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id m23-v6so2678934otf.0; Mon, 24 Sep 2018 08:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=qf61zTMvV9eeoWLrAPhW7w3kvxAyXqzmXUdAAMyre5g=; b=hA4Roc9YTZzjn7ney/hukoAqWtfO41k/lS9/MFigzpyBFWwHUsl/HqIJ9MDpLyb7E4 SsXK/sQavw6khlVQUnsKXCoCutNhZTDuiW8//4FVulTjaBw2q4xWLF2ZUFF0tx1R6Bgl Xa/kbUrwkA7mx5TPFYQDqQdHvf+NmbDp1H3JGCJel+9CxZEDbDZl8aiO05hxzWkljKbq SHpkIRhn2Ld5ladPBHsj+BU3lf5F9TDMI315G38yJ+Rav4gE7p+2Bv4R2XhWQuRoQbO+ gOB5BZdz3MDybMa72cVAtyGrumFv08tq8V6yE83f+MzEk2/lYTHkX7tZCI9JJnfrVIT+ d6VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=qf61zTMvV9eeoWLrAPhW7w3kvxAyXqzmXUdAAMyre5g=; b=LViDxVrRenqpoDK2FVtqATYp56160dQEbxwynEJS/MwgDLmppiygGngq6y/ZZv9yZ9 t2zOGSerO/WZlbfvZ3F6Kk+6hCdnIHSr2W80h3SfHdKDbyeE77hIPIH6Gl/VccsvUpHZ dYZ5IOoyyVDniwrAPGQ8wwbuXDbI70iZ9Nypvbqp2rGnvOLXcKYTvIjNE9ok4kYMO7gd b55M16QrNDD+NETiGYN0NDPz87JYLy3JEoxQMWpLnWG4s84NTg3JHXLJ4lhsrBOtDhlu WjU4N86EfcLrvs9xuk9lJ0Qo+G3ZNicAKnnJDfTwdCBWXfPALV0f8XbkjiF3yzjv/Fga /mcA== X-Gm-Message-State: APzg51BuPFcP9my+FE0n5yIrjKDVsHqaLW/vxOzk1DI47E3TKTAQPUCM ZuY66ZXyTNqIGm/1qvP5zrCFkU+YkRfxbNRbltQ= X-Google-Smtp-Source: ACcGV60wpWMPzBCy0cjg9jLl+1qomWo6FX7OZdrvUS0hjSFHtN88Rqb+/yXsyK8Ek6Yq8RmPIwRKSGqGoyFFTpIKkuw= X-Received: by 2002:a9d:ac5:: with SMTP id 63-v6mr7431611otq.16.1537803210809; Mon, 24 Sep 2018 08:33:30 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 24 Sep 2018 15:33:30 +0000 From: Alvaro Retana In-Reply-To: References: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> X-Mailer: Airmail (506) MIME-Version: 1.0 Date: Mon, 24 Sep 2018 15:33:30 +0000 Message-ID: To: Dino Farinacci Cc: draft-ietf-lisp-rfc6833bis@ietf.org, lisp-chairs@ietf.org, The IESG , lisp@ietf.org, Luigi Iannone Content-Type: multipart/alternative; boundary="0000000000001d67e805769fb605" Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 24 Sep 2018 15:33:34 -0000 --0000000000001d67e805769fb605 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On September 11, 2018 at 12:23:04 PM, Dino Farinacci (farinacci@gmail.com) wrote: Hi! I=E2=80=99m back to this document=E2=80=A6after the Defer... ... > (3) Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting rfc6830, I > think that, because of how the contents of that RFC were distributed, thi= s > document should also be tagged as Obsoleting rfc6830. Done. The text is there, but the tag in the header is missing ("Obsoletes: 6833 (if approved)=E2=80=9D). > (4) The LISP Packet Types registry was set up in rfc8113. This document asks > that IANA "refers to this document as well as [RFC8113] as references" (=C2=A711.2), > and it seems to try to change the registration (or the text is incomplete) in > (=C2=A75.1): "Values in the "Not Assigned" range can be assigned accordin= g to > procedures in [RFC8126]." Which procedure? s/Not Assigned/Unassigned (=C2= =A76 in > rfc8126) The early values are already registered with IANA. This document is asking to register the new ones which include type 15. And the values *within* type 15 are documented in RFC8113. The only place where I see type 15 referenced is in =C2=A75.1. If that sec= tion is "asking to register the new ones which include type 15=E2=80=9D, then th= ese are instructions to IANA. Regardless, a pointer from =C2=A711.2 to =C2=A75.1 won=E2=80=99t hurt the d= ocument. > (5) Because of the point above, this draft should (at least) Update rfc8113 > (see also below). Don=E2=80=99t follow. This document asks that the LISP Packet Type registry point also to this registry. That is a change to the registry, which was defined in rfc8113 (which is the only current reference). Updating the registry this way should be signaled with an update to rfc8113 in this document. > (6) This document says that "Protocol designers experimenting with new message > formats SHOULD use the LISP Shared Extension Message Type". I think this > statement makes rfc8113 a Normative reference -- which results in a DownRef. > Suggestion: given that this document already updates the registry set up in > rfc8113, and recommends the use of the Shared Extension Message, it may be a > good idea to simply adopt the contents of that document here (grand total of 6 > pages) and declare it Obsolete. I=E2=80=99m yielding to the lisp-chairs and Deborah for this one. I see that there=E2=80=99s a WG adoption call for rfc8113bis. That=E2=80= =99s fine with me =E2=80=94 but I still think that the reference should be normative. Thanks! Alvaro. --0000000000001d67e805769fb605 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On September 11, 2018 at 12:23:04 PM, Dino Farina= cci (farinacci@gmail.com) wrote:=

Hi!

I=E2=80=99m back to this document=E2= =80=A6after the Defer...

...
> (3) Even though draft-ietf-lisp-rfc6830bis is tagged = as Obsoleting rfc6830, I=C2=A0=
> think that, because of how the contents of that RFC were distribut= ed, this=C2=A0
> documen= t should also be tagged as Obsoleting rfc6830.=C2=A0

Done.= =C2=A0

The text is there, bu= t the tag in the header is missing ("Obsoletes: 6833 (if approved)=E2= =80=9D).


> (4) The LISP Packet Types registry was set up in r= fc8113. This document asks=C2=A0
> that IANA "refers to this document as well as [RFC8113] as = references" (=C2=A711.2),=C2=A0<= /span>
> and it seems to try to change the registration (or the text = is incomplete) in=C2=A0
>= ; (=C2=A75.1): "Values in the "Not Assigned" range can be as= signed according to=C2=A0
&= gt; procedures in [RFC8126]." Which procedure? s/Not Assigned/Unassign= ed (=C2=A76 in=C2=A0
> r= fc8126)=C2=A0

The early= values are already registered with IANA. This document is asking to regist= er the new ones which include type 15. And the values *within* type 15 are = documented in RFC8113.=C2=A0

The only place where I see type 15 r= eferenced is in =C2=A75.1.=C2=A0 If that section is "asking to registe= r the new ones which include type 15=E2=80=9D, then these are instructions = to IANA.

Regardless, a pointer from =C2=A711.2 to =C2=A75.1 won=E2=80= =99t hurt the document.


> (5) Because of the point above, thi= s draft should (at least) Update rfc8113=C2=A0
> (see also below).=C2=A0

Don=E2=80=99t follow.=C2=A0

This docume= nt asks that the LISP Packet Type registry point also to this registry.=C2= =A0 That is a change to the registry, which was defined in rfc8113 (which i= s the only current reference).=C2=A0 Updating the registry this way should = be signaled with an update to rfc8113 in this document.


=
> (6)= This document says that "Protocol designers experimenting with new me= ssage=C2=A0
> formats SH= OULD use the LISP Shared Extension Message Type". I think this=C2=A0
> statement makes rfc8113= a Normative reference -- which results in a DownRef.=C2=A0
> Suggestion: given that this document = already updates the registry set up in=C2=A0
> rfc8113, and recommends the use of the Shared Extens= ion Message, it may be a=C2=A0=
> good idea to simply adopt the contents of that document here (gran= d total of 6=C2=A0
> pag= es) and declare it Obsolete.=C2=A0

I=E2=80=99m yielding to the lisp-chairs and Deborah for this on= e.=C2=A0

I see that there=E2=80=99s a WG adoption call for rfc811= 3bis.=C2=A0 That=E2=80=99s fine with me =E2=80=94 but I still think that th= e reference should be normative.

Thanks!

Alvaro.

--0000000000001d67e805769fb605-- From nobody Mon Sep 24 10:10:06 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB6C131347; Mon, 24 Sep 2018 10:09:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8nbW5u5nUpVx; Mon, 24 Sep 2018 10:09:58 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 0195513140A; Mon, 24 Sep 2018 10:09:41 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id b97-v6so9412844plb.0; Mon, 24 Sep 2018 10:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s9d/VP4h42e3b7eg+JOihd+M0MswymQQa5wx1fcOTXs=; b=e/6lqY9KrjNSLzH3fltljm+tlyU7lgD4d0Tta6BOIr8Ou+DHSXWw20haJ9kSwgU/uI UdAoebYCu/7hVqNLBjXAbhJ8Q8DuggRfHxK7yV2v6L43fm5yTNLn4dIj8Upu+6rHhktm /l2YCL01ULivMaY4jNVHIWk6fFu5urgPp6inl8+8VSpJcnDdOH3Fy7vc8dM8mLmqOmxc vKqzXNYCFsuuLNE5A0Q8ZsqAUAKAtfiFLLpph7SchdWgJZGq86WLn89H6X9O0bW6mjH9 de/ei8wkS5a+Pybmqm4uAaiXeyk7RFKjN1amFnJdPuLJKQYIHXHtbEmCRnbQvjcT+QRB Hc9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s9d/VP4h42e3b7eg+JOihd+M0MswymQQa5wx1fcOTXs=; b=KYkfzBEvHDP2Iwvf6Ys5wjLhE0aWY/7d/Yo2adxc/iiS/X5PHNX8TSULgCfW8funjD P7ZESmrcT5YkIRTtcajXLHLls7xP4ZLl/3netgUtuHk4rDgHD3XqEnjtNOlli81MAgAA hYSjAn02aAmMDO2mysf6xP8UVuHvRDVvwOzweLGjDkVHKHOUNkU6FRcnpbz79XlnClfx RlZFyIG4rSFV8OmnY3n3QiEU64w1IONinLpUG+dWxjTWdnKeU4div89jxM7MOS2j8dJ9 +4MpQxt+nm7WYb9E17nFAUAHSaV4V73vQpxtKC2oTflR5z1xcpMgKvsxLGlfP+NcmZfU GsbA== X-Gm-Message-State: ABuFfojrlAEzgmEgk6alcPCiLCZSkmeWhCZymiDUjZQ0v1BbefWAT9a7 imq4ra4OKmTMKkbVmwhyQkL8Yhji X-Google-Smtp-Source: ACcGV62fkD8N5xBFE+NjfBrcQeATm5+tU52U4LtHNmSVoy5CJsQu0AV1BLy7e7FBfwLW7bxqKh0urA== X-Received: by 2002:a17:902:20e3:: with SMTP id v32-v6mr11605439plg.36.1537808981482; Mon, 24 Sep 2018 10:09:41 -0700 (PDT) Received: from [10.31.79.57] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id x77-v6sm10940292pff.37.2018.09.24.10.09.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Sep 2018 10:09:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <87CD79A8-9A7E-40BA-8333-61E27235B852@gigix.net> Date: Mon, 24 Sep 2018 10:09:38 -0700 Cc: "lisp@ietf.org list" , Erik Nordmark , lisp-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <958169EB-86ED-4A56-8042-124FC37CE4A6@gmail.com> References: <153608761426.14137.783984991533026116@ietfa.amsl.com> <87CD79A8-9A7E-40BA-8333-61E27235B852@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 24 Sep 2018 17:10:05 -0000 > Authors are invited to submit a new version of the document named: = draft-ietf-lisp-ecdsa-auth-00.txt Done. Dino From nobody Mon Sep 24 10:34:21 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E933130E3F; Mon, 24 Sep 2018 10:34:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 G_GiCUvyEPdM; Mon, 24 Sep 2018 10:34:18 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 87BF5126CB6; Mon, 24 Sep 2018 10:34:11 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id a18-v6so2514636pfo.4; Mon, 24 Sep 2018 10:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nmfwWX6Yz/2PlRpyQ5UWO8HZspDx+p7dS4VGMkoOEbA=; b=OWLjaTxr/JTotLzle7+ZVKZFAegSrbwiMevAnn+v4zSPcqujN0f61j+HwTcwyx9Qd6 tXLlJujCZ0NfWfu4bFIisGnPz/ZVNPPK0wsZ4f4GdYVdwjBhYCTzjKybtfjA7uYyx3HJ 5tAbBmxfPPUoZ5oj68wkU6MXs47r901Yjde4IRV32BqABVRrtLvYBhsxXOucgw5vuSnr MSKJU5b+PMHjsvZRkhbGeM7r/iHNZ5SXr9N1isqBy6EleNN8ZbvOl387Mpmh8TIROKjj tTJ4pX0KIYNvB+Of9aHea7xsnPuIw3r5ohoqH6stjLuwMwCdd8Hx8SaKjBeQfJqvR1qC pG3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nmfwWX6Yz/2PlRpyQ5UWO8HZspDx+p7dS4VGMkoOEbA=; b=DcjwFc1dDLH2QO/KMx3c4IJq+myJAZvR885CKArbgxFf1o7Vh7Gh9xrnNa7eVwSVbm AHTV4kGHfFH8h9v4ACVL1IjZe2TjhO8VnR4yTOYTXkQbyHd8IMWDfBYlbcBY/duyE0e0 8yGJ1VWEg0eo3DZ9W1dv+qtmEq8iM3zZfQuKcRn0XrYrZEYKQawhddUAaZDKXmdsnW/t teo55KEuL/6ePT8kpU607W1+/hN1p1iz+iPUzZW2IFakfv1AXBjH0REM9uxXo7OBmn7O RIbkJoCsES35YrJx4NifoT6qecTSDhS2hqQ112DMHIezXBdbQcZCiY9O1RcxXeQxcT8Q tx+g== X-Gm-Message-State: ABuFfohnHSlbDokcBErU2TrltFTYoMn5QYvHrKCTh1r5lbHhWw/pmRy6 6eDQ1r8xksbyk3S2ms3Y0i2npRNX X-Google-Smtp-Source: ACcGV635xqshREQvPX/EwE6l0WJNcVfKNkuV/7QBRMxy5ICeJJc5M6dm1bWrWJ4L/jupiHGD8Ecj5w== X-Received: by 2002:a63:69c3:: with SMTP id e186-v6mr10323493pgc.431.1537810451029; Mon, 24 Sep 2018 10:34:11 -0700 (PDT) Received: from [10.31.79.57] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id g5-v6sm51259193pgn.73.2018.09.24.10.34.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Sep 2018 10:34:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <11FBAC13-2859-4778-84CA-B546EB669727@kuehlewind.net> Date: Mon, 24 Sep 2018 10:34:09 -0700 Cc: Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com> <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net> <0BE5C929-D2FA-4786-9F5E-0A93E7700880@gmail.com> <11FBAC13-2859-4778-84CA-B546EB669727@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 24 Sep 2018 17:34:20 -0000 Well, the implementations are out and working. And we said in the latest = updates to consider using RFC6040. So not sure we can do much more than = that. Dino > On Sep 24, 2018, at 5:52 AM, Mirja Kuehlewind (IETF) = wrote: >=20 > Because they don=E2=80=99t follow RFC6040 and therefore we do = something different in some corner cases. >=20 >=20 >=20 >> Am 22.09.2018 um 06:52 schrieb Dino Farinacci : >>=20 >>> However, I totally disagree with your comment on providing details = that are not implemented. If they are not implemented correctly, it = might even be more important to spell them out in this document, so = implementors have chance to update their (future) implementation to do = the correct thing. Having deployed implementations that are non = standard-conform always happens and in this case it is probably not = specifically problematic as it doesn=E2=80=99t impact interoperability. = However, it is important though that the spec is correct. >>=20 >> And why do you think they are implemented incorrectly?=20 >>=20 >> Dino >>=20 >=20 From nobody Mon Sep 24 10:39:05 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD663126CB6; Mon, 24 Sep 2018 10:39:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DgXbhWPnqj-u; Mon, 24 Sep 2018 10:39:00 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 7200F130E3F; Mon, 24 Sep 2018 10:39:00 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id m77-v6so623552pfi.8; Mon, 24 Sep 2018 10:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8inRn0+N9Ypyruzdb0uOzHi2nT5XIB3QLHeYWsRiS/8=; b=N+CIWEszVBv2Ol5cCn6KkGrcKPyh0j+MgRgEhrfvbhaZXfwNJq2ld7XPBZph8w12nD 0q9o/E7GU/Ey9BbYIbL65VwJeW0ywMscbYif29s7Zf+LfTDPMK2r8VMMTuhbdRjMrHG7 j2Reg6gxpZ/BYIbWGzmXeSIRHBkufHLgY15QGEotsp7m617g7StDuIIaVIuauXsPIALd b5lD4DE/opP10kdEz7lLtMGbdu/bpHfGRvpjUM8x8b4UyG0A2/EGfLyQVEToIsBqlHI6 lTuA7dwSxhpCgrMvas0/VxEl28JTHsIhSKBACEMsuq7tKAbkz/IoNurwqBQ44tkKJwuu NaHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8inRn0+N9Ypyruzdb0uOzHi2nT5XIB3QLHeYWsRiS/8=; b=bVJzBu1QbMUMzZe38+IfykWW7hj70/EYPK9M4GAB5ZkaICHjcD3vy5hdsyQphQ4us9 EAGlOjkEnlfAyClcqfk+3ggglfQI7JlcpHgfS1pyxP81hmIzQFYQR/J0xd+ykRfOqPBF RDnWk/ohVeQKzO9CEDY2IjJr9xfhPDKULYmXtb88Jsif0NuXH3dfsmZNhgDb/SiQHUhP FHV5z/2j5WptnnQW5yxooNaerpg4U4oDxaNm8mZYzDISpzWZkIrw4b7iUU2Xf+7QJZg0 GpZDEoQWEPP3YqAKXHNuTNUQtUXz5XU0VLdoIAbLaVgzjmnm8SLX4M8BcRrvXZR/pdwP oTIg== X-Gm-Message-State: ABuFfojTLFg/UyZ2yxhdToM3P02ExWqKzUJv9XO1BSvxhZ9Tlv8gFLLM 8OzHtLj+PRgQ/D1/7H37JBg= X-Google-Smtp-Source: ACcGV61D1eiKZcfgSFtnj3YrXDC0RyIU4C/pdqIJSQ6ogcaxgtCDFR9+6/TlJD+2C418HmbHeaRWbg== X-Received: by 2002:a63:4a5a:: with SMTP id j26-v6mr9820849pgl.168.1537810739825; Mon, 24 Sep 2018 10:38:59 -0700 (PDT) Received: from [10.31.79.57] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id v81-v6sm14016845pfj.25.2018.09.24.10.38.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Sep 2018 10:38:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Mon, 24 Sep 2018 10:38:57 -0700 Cc: draft-ietf-lisp-rfc6833bis@ietf.org, lisp-chairs@ietf.org, The IESG , lisp@ietf.org, Luigi Iannone Content-Transfer-Encoding: quoted-printable Message-Id: <881C546E-62A6-4C92-8AE7-CA166A554AD3@gmail.com> References: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> To: Alvaro Retana X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 24 Sep 2018 17:39:04 -0000 Alvaro, I don=E2=80=99t know what you want to be satisified with the = text. And rather than go 20 questions, with weeks of turn-around time, = can you offer text please? Dino > On Sep 24, 2018, at 8:33 AM, Alvaro Retana = wrote: >=20 > On September 11, 2018 at 12:23:04 PM, Dino Farinacci = (farinacci@gmail.com) wrote: >=20 > Hi! >=20 > I=E2=80=99m back to this document=E2=80=A6after the Defer... >=20 > ... >> > (3) Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting = rfc6830, I=20 >> > think that, because of how the contents of that RFC were = distributed, this=20 >> > document should also be tagged as Obsoleting rfc6830.=20 >>=20 >> Done.=20 > The text is there, but the tag in the header is missing ("Obsoletes: = 6833 (if approved)=E2=80=9D). >=20 >=20 >=20 >> > (4) The LISP Packet Types registry was set up in rfc8113. This = document asks=20 >> > that IANA "refers to this document as well as [RFC8113] as = references" (=C2=A711.2),=20 >> > and it seems to try to change the registration (or the text is = incomplete) in=20 >> > (=C2=A75.1): "Values in the "Not Assigned" range can be assigned = according to=20 >> > procedures in [RFC8126]." Which procedure? s/Not = Assigned/Unassigned (=C2=A76 in=20 >> > rfc8126)=20 >>=20 >> The early values are already registered with IANA. This document is = asking to register the new ones which include type 15. And the values = *within* type 15 are documented in RFC8113.=20 > The only place where I see type 15 referenced is in =C2=A75.1. If = that section is "asking to register the new ones which include type = 15=E2=80=9D, then these are instructions to IANA. >=20 > Regardless, a pointer from =C2=A711.2 to =C2=A75.1 won=E2=80=99t hurt = the document. >=20 >=20 >=20 >> > (5) Because of the point above, this draft should (at least) Update = rfc8113=20 >> > (see also below).=20 >>=20 >> Don=E2=80=99t follow.=20 > This document asks that the LISP Packet Type registry point also to = this registry. That is a change to the registry, which was defined in = rfc8113 (which is the only current reference). Updating the registry = this way should be signaled with an update to rfc8113 in this document. >=20 >=20 >=20 >> > (6) This document says that "Protocol designers experimenting with = new message=20 >> > formats SHOULD use the LISP Shared Extension Message Type". I think = this=20 >> > statement makes rfc8113 a Normative reference -- which results in a = DownRef.=20 >> > Suggestion: given that this document already updates the registry = set up in=20 >> > rfc8113, and recommends the use of the Shared Extension Message, it = may be a=20 >> > good idea to simply adopt the contents of that document here (grand = total of 6=20 >> > pages) and declare it Obsolete.=20 >>=20 >> I=E2=80=99m yielding to the lisp-chairs and Deborah for this one.=20 > I see that there=E2=80=99s a WG adoption call for rfc8113bis. = That=E2=80=99s fine with me =E2=80=94 but I still think that the = reference should be normative. >=20 > Thanks! >=20 > Alvaro. >=20 From nobody Tue Sep 25 02:17:05 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D542130F24; Tue, 25 Sep 2018 02:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 FziAKth8eZd4; Tue, 25 Sep 2018 02:17:02 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0AD13114A; Tue, 25 Sep 2018 02:17:01 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 42KFnl1Rvqz5wHB; Tue, 25 Sep 2018 11:16:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 42KFnk6p0ZzDq7d; Tue, 25 Sep 2018 11:16:58 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0415.000; Tue, 25 Sep 2018 11:16:58 +0200 From: To: Alvaro Retana , Luigi Iannone , "lisp@ietf.org list" CC: "lisp-chairs@ietf.org" Thread-Topic: [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113bis-01.txt Thread-Index: AQHUVBu1moTCOM5Es0a8FTro+WqDZqUAt5zA Date: Tue, 25 Sep 2018 09:16:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DFE6578@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DFE6578OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113bis-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 25 Sep 2018 09:17:04 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DFE6578OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQpUaGUgZHJhZnQgc2F5cyB0aGUgZm9sbG93aW5nOg0KDQogICBJQU5BIGlz IHJlcXVlc3RlZCB0byByZXBsYWNlIHRoZSByZWZlcmVuY2UgdG8gUkZDODExMzxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjODExMz4gd2l0aCB0aGUgUkZDDQogICBudW1iZXIgdG8gYmUg YXNzaWduZWQgdG8gdGhpcyBkb2N1bWVudC4NCg0KV2hpY2ggc2VlbXMgcmVhc29uYWJsZSB0byBr ZWVwIHRyYWNrIG9uIHRoZSBkb2N1bWVudCB0aGF0IGNyZWF0ZWQgdGhlIHJlZ2lzdHJ5IHdoaWxl IGJlaW5nIGFsaWduZWQgd2l0aCBvYnNvbGV0ZWQgUkZDcy4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRl IDogbGlzcCBbbWFpbHRvOmxpc3AtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBBbHZh cm8gUmV0YW5hDQpFbnZvecOpIDogbHVuZGkgMjQgc2VwdGVtYnJlIDIwMTggMTc6MzENCsOAIDog THVpZ2kgSWFubm9uZTsgbGlzcEBpZXRmLm9yZyBsaXN0DQpDYyA6IGxpc3AtY2hhaXJzQGlldGYu b3JnDQpPYmpldCA6IFJlOiBbbGlzcF0gQ2FsbCBmbyBhZG9wdGlvbiBvZiBkcmFmdC1ib3VjYWRh aXItbGlzcC1yZmM4MTEzYmlzLTAxLnR4dA0KDQpbU3BlYWtpbmcgYXMgYSBXRyBwYXJ0aWNpcGFu dC5dDQoNCkhpIQ0KDQpJIGRvbuKAmXQgb2JqZWN0IHRvIHRoZSBhZG9wdGlvbi4NCg0KVGhlIG1h aW4gY2hhbmdlIHdpdGggcmVzcGVjdCB0byByZmM4MTEzLCB0aGF0IGRvZXNu4oCZdCBzZWVtIHJp Z2h0IHRvIG1lLCBpcyB0aGF0IHJmYzgxMTMgZGVmaW5lZCB0aGUgTElTUCBQYWNrZXQgVHlwZXMg cmVnaXN0cnksIGJ1dCB0aGlzIGRvY3VtZW50IG9ubHkgYWRkcyB0byBpdC4gIEluIHRoZSB3ZWly ZCB3b3JsZCBvZiBVcGRhdGluZyBhbmQgT2Jzb2xldGluZyBSRkNzLCBJIHRoaW5rIHRoaXMgbWVh bnMgdGhhdCB3ZeKAmXJlIGxlZnQgd2l0aCBubyBkb2N1bWVudCBiZWluZyB0aGUgb3JpZ2luYXRv ciBvZiB0aGUgcmVnaXN0cnkuDQoNCk5vdGUgdGhhdCByZmM2ODMzYmlzLCB3aGljaCByZXF1ZXN0 cyB0aGF0IHRoZSByZWZlcmVuY2VzIGZyb20gdGhlIHJlZ2lzdHJ5IHBvaW50IHRvIGl0ICphbmQq IHRvIHJmYzgxMTMsIGFsc28gZG9lc27igJl0IGRlZmluZSB0aGUgcmVnaXN0cnkgKHdoaWNoIGlz IHRoZSBjb3JyZWN0IHRoaW5nIHRvIGRvKS4uDQoNCk15IDJjLg0KDQpBbHZhcm8uDQoNCg0KT24g U2VwdGVtYmVyIDE5LCAyMDE4IGF0IDExOjA1OjA1IEFNLCBMdWlnaSBJYW5ub25lIChnZ3hAZ2ln aXgubmV0PG1haWx0bzpnZ3hAZ2lnaXgubmV0Pikgd3JvdGU6DQpGb2xrcywNCg0KaGVyZSBpcyBh bm90aGVyIHBpZWNlIG9mIHRoZSB3b3JrIGRvbmUgaW4gb3VyIFdHIHRoYXQgbmVlZHMgdG8gYmUg bW92ZWQgdG8gUFMuDQoNCkl0IGlzIHRoZSB1cGRhdGVkIHZlcnNpb24gb2YgUkZDIDgxMTMsIG5v dGhpbmcgY2hhbmdlZCBqdXN0IHVwZGF0ZWQgY29oZXJlbnRseSB3aXRoIHRoZSBjdXJyZW50IHN0 YXR1cyBvZiB0aGUgb3RoZXIgZG9jdW1lbnRzLg0KDQpCZWNhdXNlIHRoaXMgZG9jdW1lbnRzIGlz IHJlYWxseSByZWFsbHkgc2hvcnQgd2Ugd2lsbCBoYXZlIGp1c3Qgb25lIHdlZWsgYWRvcHRpb24g Y2FsbCBmb2xsb3dlZCBiZSBvbmUgd2VlayBXRyBMYXN0IENhbGwuDQoNClRoaXMgZW1haWwgb2Zm aWNpYWxseSBzdGFydHMgdGhlIG9uZSB3ZWVrIGNhbGwgZm9yIGFkb3B0aW9uLg0KDQpQbGVhc2Ug c3BlbmQgMTAgbWludXRlcyBoYXZpbmcgYSBsb29rIGF0IHRoZSBkb2N1bWVudCBhbmQgc2VuZCBh biBlbWFpbCBvbiB3aGV0aGVyIHlvdSBhZ3JlZSBvciBub3QgdG8gYWRvcHQgaXQuDQoNClRoYW5r cw0KDQpDaWFvDQoNCkx1aWdpDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Pg0KU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLWxpc3AtcmZjODExM2Jpcy0w MS50eHQNCkRhdGU6IDE5IFNlcHRlbWJlciAyMDE4IGF0IDE2OjQ5OjMxIENFU1QNClRvOiA8aS1k LWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KUmVwbHkt VG86IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPg0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCg0KDQogICAgICAgVGl0bGUgICAgICAg ICAgIDogTG9jYXRvci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIChMSVNQKTogU2hhcmVkIEV4dGVu c2lvbiBNZXNzYWdlICYgSUFOQSBSZWdpc3RyeSBmb3IgUGFja2V0IFR5cGUgQWxsb2NhdGlvbnMN CiAgICAgICBBdXRob3JzICAgICAgICAgOiBNb2hhbWVkIEJvdWNhZGFpcg0KICAgICAgICAgICAg ICAgICAgICAgICAgIENocmlzdGlhbiBKYWNxdWVuZXQNCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWJvdWNhZGFpci1saXNwLXJmYzgxMTNiaXMtMDEudHh0DQpQYWdlcyAgICAgICAgICAgOiA1DQpE YXRlICAgICAgICAgICAgOiAyMDE4LTA5LTE5DQoNCkFic3RyYWN0Og0KICBUaGlzIGRvY3VtZW50 IHNwZWNpZmllcyBhIExvY2F0b3IvSUQgU2VwYXJhdGlvbiBQcm90b2NvbCAoTElTUCkNCiAgc2hh cmVkIG1lc3NhZ2UgdHlwZSBmb3IgZGVmaW5pbmcgZnV0dXJlIGV4dGVuc2lvbnMgYW5kIGNvbmR1 Y3RpbmcNCiAgZXhwZXJpbWVudHMgd2l0aG91dCBjb25zdW1pbmcgYSBMSVNQIHBhY2tldCB0eXBl IGNvZGVwb2ludCBmb3IgZWFjaA0KICBleHRlbnNpb24uDQoNCiAgVGhpcyBkb2N1bWVudCBvYnNv bGV0ZXMgUkZDIDgxMTMuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1i b3VjYWRhaXItbGlzcC1yZmM4MTEzYmlzLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJz aW9ucyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91 Y2FkYWlyLWxpc3AtcmZjODExM2Jpcy0wMQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1ib3VjYWRhaXItbGlzcC1yZmM4MTEzYmlzLTAxDQoNCkEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ib3VjYWRhaXItbGlzcC1yZmM4MTEzYmlzLTAxDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0K DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlz dA0KSS1ELUFubm91bmNlQGlldGYub3JnPG1haWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KSW50ZXJu ZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCm9y IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpsaXNwIG1haWxpbmcgbGlzdA0K bGlzcEBpZXRmLm9yZzxtYWlsdG86bGlzcEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYuLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2xpc3A8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9saXNwPg0K --_000_787AE7BB302AE849A7480A190F8B93302DFE6578OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6dGF4PSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvdGF4b25vbXkvc29hcC8iIHhtbG5zOnRucz0iaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvcmVjb3Jkc3JlcG9zaXRvcnkvIiB4bWxu czpzcHN1cD0iaHR0cDovL21pY3Jvc29mdC5jb20vd2Vic2VydmljZXMvU2hhcmVQb2ludFBvcnRh bFNlcnZlci9Vc2VyUHJvZmlsZVNlcnZpY2UiIHhtbG5zOm1tbD0iaHR0cDovL3d3dy53My5vcmcv MTk5OC9NYXRoL01hdGhNTCIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ csOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw LmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1l OmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1z dHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpi cmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgQWx2YXJvLA0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+VGhlIGRyYWZ0IHNheXMgdGhlIGZvbGxvd2luZzo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IElBTkEgaXMgcmVx dWVzdGVkIHRvIHJlcGxhY2UgdGhlIHJlZmVyZW5jZSB0bw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODExMyI+PHNwYW4gbGFuZz0iRU4t VVMiPlJGQzgxMTM8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiB3aXRo IHRoZSBSRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBudW1iZXIgdG8gYmUgYXNzaWduZWQgdG8g dGhpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+V2hpY2ggc2VlbXMgcmVhc29uYWJsZSB0byBrZWVwIHRyYWNrIG9uIHRoZSBkb2N1 bWVudCB0aGF0IGNyZWF0ZWQgdGhlIHJlZ2lzdHJ5IHdoaWxlIGJlaW5nIGFsaWduZWQgd2l0aCBv YnNvbGV0ZWQgUkZDcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBsaXNwIFttYWlsdG86bGlzcC1ib3VuY2VzQGll dGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gQWx2YXJvIFJldGFuYTxicj4NCjxiPkVudm95 w6kmbmJzcDs6PC9iPiBsdW5kaSAyNCBzZXB0ZW1icmUgMjAxOCAxNzozMTxicj4NCjxiPsOAJm5i c3A7OjwvYj4gTHVpZ2kgSWFubm9uZTsgbGlzcEBpZXRmLm9yZyBsaXN0PGJyPg0KPGI+Q2MmbmJz cDs6PC9iPiBsaXNwLWNoYWlyc0BpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6 IFtsaXNwXSBDYWxsIGZvIGFkb3B0aW9uIG9mIGRyYWZ0LWJvdWNhZGFpci1saXNwLXJmYzgxMTNi aXMtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9t Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+W1NwZWFraW5nIGFzIGEgV0cgcGFydGljaXBhbnQuXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBkb27igJl0IG9i amVjdCB0byB0aGUgYWRvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBtYWluIGNoYW5nZSB3aXRoIHJlc3BlY3QgdG8g cmZjODExMywgdGhhdCBkb2VzbuKAmXQgc2VlbSByaWdodCB0byBtZSwgaXMgdGhhdCByZmM4MTEz IGRlZmluZWQgdGhlIExJU1AgUGFja2V0IFR5cGVzIHJlZ2lzdHJ5LCBidXQgdGhpcyBkb2N1bWVu dCBvbmx5IGFkZHMgdG8gaXQuJm5ic3A7IEluIHRoZQ0KIHdlaXJkIHdvcmxkIG9mIFVwZGF0aW5n IGFuZCBPYnNvbGV0aW5nIFJGQ3MsIEkgdGhpbmsgdGhpcyBtZWFucyB0aGF0IHdl4oCZcmUgbGVm dCB3aXRoIG5vIGRvY3VtZW50IGJlaW5nIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSByZWdpc3RyeS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9t Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Tm90ZSB0aGF0IHJmYzY4MzNiaXMsIHdoaWNoIHJlcXVlc3RzIHRoYXQgdGhlIHJlZmVyZW5j ZXMgZnJvbSB0aGUgcmVnaXN0cnkgcG9pbnQgdG8gaXQgKmFuZCogdG8gcmZjODExMywgYWxzbyBk b2VzbuKAmXQgZGVmaW5lIHRoZSByZWdpc3RyeSAod2hpY2ggaXMgdGhlIGNvcnJlY3QgdGhpbmcg dG8NCiBkbykuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJi bG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5NeSAyYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWx2YXJvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJhaXJtYWlsb24iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBTZXB0ZW1iZXIgMTksIDIwMTggYXQgMTE6MDU6 MDUgQU0sIEx1aWdpIElhbm5vbmUgKDxhIGhyZWY9Im1haWx0bzpnZ3hAZ2lnaXgubmV0Ij5nZ3hA Z2lnaXgubmV0PC9hPikgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G b2xrcywNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPmhlcmUgaXMgYW5vdGhlciBwaWVjZSBvZiB0aGUgd29yayBkb25lIGlu IG91ciBXRyB0aGF0IG5lZWRzIHRvIGJlIG1vdmVkIHRvIFBTLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SXQg aXMgdGhlIHVwZGF0ZWQgdmVyc2lvbiBvZiBSRkMgODExMywgbm90aGluZyBjaGFuZ2VkIGp1c3Qg dXBkYXRlZCBjb2hlcmVudGx5IHdpdGggdGhlIGN1cnJlbnQgc3RhdHVzIG9mIHRoZSBvdGhlciBk b2N1bWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CZWNhdXNlIHRoaXMgZG9jdW1lbnRzIGlzIHJlYWxs eSByZWFsbHkgc2hvcnQgd2Ugd2lsbCBoYXZlIGp1c3Qgb25lIHdlZWsgYWRvcHRpb24gY2FsbCBm b2xsb3dlZCBiZSBvbmUgd2VlayBXRyBMYXN0IENhbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGlzIGVt YWlsIG9mZmljaWFsbHkgc3RhcnRzIHRoZSBvbmUgd2VlayBjYWxsIGZvciBhZG9wdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlBsZWFzZSBzcGVuZCAxMCBtaW51dGVzIGhhdmluZyBhIGxvb2sgYXQgdGhl IGRvY3VtZW50IGFuZCBzZW5kIGFuIGVtYWlsIG9uIHdoZXRoZXIgeW91IGFncmVlIG9yIG5vdCB0 byBhZG9wdCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2lhbzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+THVpZ2k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0Ojwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGI+SS1EIEFjdGlvbjogZHJhZnQtYm91Y2Fk YWlyLWxpc3AtcmZjODExM2Jpcy0wMS50eHQ8L2I+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkRhdGU6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IDE5IFNlcHRlbWJlciAyMDE4IGF0IDE2OjQ5OjMxIENFU1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+VG86PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+ICZsdDs8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIj5pLWQtYW5ub3Vu Y2VAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5S ZXBseS1Ubzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhy ZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KPGJyPg0K PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGl0bGUgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 OiBMb2NhdG9yL0lEIFNlcGFyYXRpb24gUHJvdG9jb2wgKExJU1ApOiBTaGFyZWQgRXh0ZW5zaW9u IE1lc3NhZ2UgJmFtcDsgSUFOQSBSZWdpc3RyeSBmb3IgUGFja2V0IFR5cGUgQWxsb2NhdGlvbnM8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBdXRob3JzICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogTW9oYW1lZCBC b3VjYWRhaXI8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDaHJpc3Rp YW4gSmFjcXVlbmV0PGJyPg0KRmlsZW5hbWUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7OiBkcmFmdC1ib3VjYWRhaXItbGlzcC1yZmM4MTEzYmlzLTAxLnR4dDxicj4N ClBhZ2VzICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzogNTxicj4NCkRhdGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiAyMDE4LTA5LTE5PGJyPg0KPGJyPg0K QWJzdHJhY3Q6PGJyPg0KJm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBMb2Nh dG9yL0lEIFNlcGFyYXRpb24gUHJvdG9jb2wgKExJU1ApPGJyPg0KJm5ic3A7Jm5ic3A7c2hhcmVk IG1lc3NhZ2UgdHlwZSBmb3IgZGVmaW5pbmcgZnV0dXJlIGV4dGVuc2lvbnMgYW5kIGNvbmR1Y3Rp bmc8YnI+DQombmJzcDsmbmJzcDtleHBlcmltZW50cyB3aXRob3V0IGNvbnN1bWluZyBhIExJU1Ag cGFja2V0IHR5cGUgY29kZXBvaW50IGZvciBlYWNoPGJyPg0KJm5ic3A7Jm5ic3A7ZXh0ZW5zaW9u Ljxicj4NCjxicj4NCiZuYnNwOyZuYnNwO1RoaXMgZG9jdW1lbnQgb2Jzb2xldGVzIFJGQyA4MTEz Ljxicj4NCjxicj4NCjxicj4NClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0 aGlzIGRyYWZ0IGlzOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWJvdWNhZGFpci1saXNwLXJmYzgxMTNiaXMvIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1ib3VjYWRhaXItbGlzcC1yZmM4MTEzYmlzLzwvYT48YnI+DQo8 YnI+DQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1saXNw LXJmYzgxMTNiaXMtMDEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRh aXItbGlzcC1yZmM4MTEzYmlzLTAxPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYm91Y2FkYWlyLWxpc3AtcmZjODExM2Jpcy0wMSI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ib3VjYWRhaXItbGlz cC1yZmM4MTEzYmlzLTAxPC9hPjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtYm91Y2FkYWlyLWxpc3AtcmZjODExM2Jpcy0wMSI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJvdWNhZGFpci1saXNwLXJmYzgxMTNi aXMtMDE8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJy Pg0KPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iPmZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSS1ELUFubm91bmNlIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmciPkktRC1B bm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pLWQtYW5ub3VuY2U8L2E+PGJyPg0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3Jp ZXM6IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwiPmh0dHA6Ly93d3cu aWV0Zi5vcmcvc2hhZG93Lmh0bWw8L2E+PGJyPg0Kb3IgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYu b3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFk b3ctc2l0ZXMudHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPg0KbGlzcCBtYWls aW5nIGxpc3QgPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmxpc3BAaWV0Zi5vcmciPmxpc3BAaWV0Zi5v cmc8L2E+IDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbGlzcCI+aHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcDwvYT4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93302DFE6578OPEXCLILMA3corp_-- From nobody Tue Sep 25 02:22:48 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C9613114A; Tue, 25 Sep 2018 02:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 4yy3uVFP6dg7; Tue, 25 Sep 2018 02:22:37 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2368013125B; Tue, 25 Sep 2018 02:22:37 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 42KFwC5JFCz1y6T; Tue, 25 Sep 2018 11:22:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 42KFwC4QwzzDq7l; Tue, 25 Sep 2018 11:22:35 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0415.000; Tue, 25 Sep 2018 11:22:35 +0200 From: To: Dino Farinacci , Alvaro Retana CC: "lisp-chairs@ietf.org" , The IESG , "draft-ietf-lisp-rfc6833bis@ietf.org" , "lisp@ietf.org" Thread-Topic: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) Thread-Index: AQHUVC2DlTrX+vSS8kaXfn/Jv3V2WqUAuanQ Date: Tue, 25 Sep 2018 09:22:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DFE658F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> <881C546E-62A6-4C92-8AE7-CA166A554AD3@gmail.com> In-Reply-To: <881C546E-62A6-4C92-8AE7-CA166A554AD3@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 25 Sep 2018 09:22:39 -0000 SGkgRGlubywgDQoNCkkgdGhpbmsgdGhhdCBBbHZhcm8gaGFzIGEgdmFsaWQgcG9pbnQgYWJvdXQg cmZjODExM2JpcyB0byBiZSBjaXRlZCBhcyBub3JtYXRpdmUuIA0KDQpUaGlzIGlzIGVhc3kgdG8g Zml4LCBJTU8uIFRoYW5rcy4gIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdv cmlnaW5lLS0tLS0NCj4gRGXCoDogbGlzcCBbbWFpbHRvOmxpc3AtYm91bmNlc0BpZXRmLm9yZ10g RGUgbGEgcGFydCBkZSBEaW5vIEZhcmluYWNjaQ0KPiBFbnZvecOpwqA6IGx1bmRpIDI0IHNlcHRl bWJyZSAyMDE4IDE5OjM5DQo+IMOAwqA6IEFsdmFybyBSZXRhbmENCj4gQ2PCoDogbGlzcC1jaGFp cnNAaWV0Zi5vcmc7IFRoZSBJRVNHOyBkcmFmdC1pZXRmLWxpc3AtcmZjNjgzM2Jpc0BpZXRmLm9y ZzsNCj4gbGlzcEBpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW2xpc3BdIEFsdmFybyBSZXRhbmEn cyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1saXNwLQ0KPiByZmM2ODMzYmlzLTEzOiAod2l0 aCBDT01NRU5UKQ0KPiANCj4gQWx2YXJvLCBJIGRvbuKAmXQga25vdyB3aGF0IHlvdSB3YW50IHRv IGJlIHNhdGlzaWZpZWQgd2l0aCB0aGUgdGV4dC4gQW5kIHJhdGhlcg0KPiB0aGFuIGdvIDIwIHF1 ZXN0aW9ucywgd2l0aCB3ZWVrcyBvZiB0dXJuLWFyb3VuZCB0aW1lLCBjYW4geW91IG9mZmVyIHRl eHQNCj4gcGxlYXNlPw0KPiANCj4gRGlubw0KPiANCj4gPiBPbiBTZXAgMjQsIDIwMTgsIGF0IDg6 MzMgQU0sIEFsdmFybyBSZXRhbmEgPGFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+ DQo+ID4gT24gU2VwdGVtYmVyIDExLCAyMDE4IGF0IDEyOjIzOjA0IFBNLCBEaW5vIEZhcmluYWNj aSAoZmFyaW5hY2NpQGdtYWlsLmNvbSkNCj4gd3JvdGU6DQo+ID4NCj4gPiBIaSENCj4gPg0KPiA+ IEnigJltIGJhY2sgdG8gdGhpcyBkb2N1bWVudOKApmFmdGVyIHRoZSBEZWZlci4uLg0KPiA+DQo+ ID4gLi4uDQo+ID4+ID4gKDMpIEV2ZW4gdGhvdWdoIGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMwYmlz IGlzIHRhZ2dlZCBhcyBPYnNvbGV0aW5nDQo+IHJmYzY4MzAsIEkNCj4gPj4gPiB0aGluayB0aGF0 LCBiZWNhdXNlIG9mIGhvdyB0aGUgY29udGVudHMgb2YgdGhhdCBSRkMgd2VyZSBkaXN0cmlidXRl ZCwNCj4gdGhpcw0KPiA+PiA+IGRvY3VtZW50IHNob3VsZCBhbHNvIGJlIHRhZ2dlZCBhcyBPYnNv bGV0aW5nIHJmYzY4MzAuDQo+ID4+DQo+ID4+IERvbmUuDQo+ID4gVGhlIHRleHQgaXMgdGhlcmUs IGJ1dCB0aGUgdGFnIGluIHRoZSBoZWFkZXIgaXMgbWlzc2luZyAoIk9ic29sZXRlczogNjgzMw0K PiAoaWYgYXBwcm92ZWQp4oCdKS4NCj4gPg0KPiA+DQo+ID4NCj4gPj4gPiAoNCkgVGhlIExJU1Ag UGFja2V0IFR5cGVzIHJlZ2lzdHJ5IHdhcyBzZXQgdXAgaW4gcmZjODExMy4gVGhpcyBkb2N1bWVu dA0KPiBhc2tzDQo+ID4+ID4gdGhhdCBJQU5BICJyZWZlcnMgdG8gdGhpcyBkb2N1bWVudCBhcyB3 ZWxsIGFzIFtSRkM4MTEzXSBhcyByZWZlcmVuY2VzIg0KPiAowqcxMS4yKSwNCj4gPj4gPiBhbmQg aXQgc2VlbXMgdG8gdHJ5IHRvIGNoYW5nZSB0aGUgcmVnaXN0cmF0aW9uIChvciB0aGUgdGV4dCBp cw0KPiBpbmNvbXBsZXRlKSBpbg0KPiA+PiA+ICjCpzUuMSk6ICJWYWx1ZXMgaW4gdGhlICJOb3Qg QXNzaWduZWQiIHJhbmdlIGNhbiBiZSBhc3NpZ25lZCBhY2NvcmRpbmcgdG8NCj4gPj4gPiBwcm9j ZWR1cmVzIGluIFtSRkM4MTI2XS4iIFdoaWNoIHByb2NlZHVyZT8gcy9Ob3QgQXNzaWduZWQvVW5h c3NpZ25lZCAowqc2DQo+IGluDQo+ID4+ID4gcmZjODEyNikNCj4gPj4NCj4gPj4gVGhlIGVhcmx5 IHZhbHVlcyBhcmUgYWxyZWFkeSByZWdpc3RlcmVkIHdpdGggSUFOQS4gVGhpcyBkb2N1bWVudCBp cyBhc2tpbmcNCj4gdG8gcmVnaXN0ZXIgdGhlIG5ldyBvbmVzIHdoaWNoIGluY2x1ZGUgdHlwZSAx NS4gQW5kIHRoZSB2YWx1ZXMgKndpdGhpbiogdHlwZQ0KPiAxNSBhcmUgZG9jdW1lbnRlZCBpbiBS RkM4MTEzLg0KPiA+IFRoZSBvbmx5IHBsYWNlIHdoZXJlIEkgc2VlIHR5cGUgMTUgcmVmZXJlbmNl ZCBpcyBpbiDCpzUuMS4gIElmIHRoYXQgc2VjdGlvbg0KPiBpcyAiYXNraW5nIHRvIHJlZ2lzdGVy IHRoZSBuZXcgb25lcyB3aGljaCBpbmNsdWRlIHR5cGUgMTXigJ0sIHRoZW4gdGhlc2UgYXJlDQo+ IGluc3RydWN0aW9ucyB0byBJQU5BLg0KPiA+DQo+ID4gUmVnYXJkbGVzcywgYSBwb2ludGVyIGZy b20gwqcxMS4yIHRvIMKnNS4xIHdvbuKAmXQgaHVydCB0aGUgZG9jdW1lbnQuDQo+ID4NCj4gPg0K PiA+DQo+ID4+ID4gKDUpIEJlY2F1c2Ugb2YgdGhlIHBvaW50IGFib3ZlLCB0aGlzIGRyYWZ0IHNo b3VsZCAoYXQgbGVhc3QpIFVwZGF0ZQ0KPiByZmM4MTEzDQo+ID4+ID4gKHNlZSBhbHNvIGJlbG93 KS4NCj4gPj4NCj4gPj4gRG9u4oCZdCBmb2xsb3cuDQo+ID4gVGhpcyBkb2N1bWVudCBhc2tzIHRo YXQgdGhlIExJU1AgUGFja2V0IFR5cGUgcmVnaXN0cnkgcG9pbnQgYWxzbyB0byB0aGlzDQo+IHJl Z2lzdHJ5LiAgVGhhdCBpcyBhIGNoYW5nZSB0byB0aGUgcmVnaXN0cnksIHdoaWNoIHdhcyBkZWZp bmVkIGluIHJmYzgxMTMNCj4gKHdoaWNoIGlzIHRoZSBvbmx5IGN1cnJlbnQgcmVmZXJlbmNlKS4g IFVwZGF0aW5nIHRoZSByZWdpc3RyeSB0aGlzIHdheSBzaG91bGQNCj4gYmUgc2lnbmFsZWQgd2l0 aCBhbiB1cGRhdGUgdG8gcmZjODExMyBpbiB0aGlzIGRvY3VtZW50Lg0KPiA+DQo+ID4NCj4gPg0K PiA+PiA+ICg2KSBUaGlzIGRvY3VtZW50IHNheXMgdGhhdCAiUHJvdG9jb2wgZGVzaWduZXJzIGV4 cGVyaW1lbnRpbmcgd2l0aCBuZXcNCj4gbWVzc2FnZQ0KPiA+PiA+IGZvcm1hdHMgU0hPVUxEIHVz ZSB0aGUgTElTUCBTaGFyZWQgRXh0ZW5zaW9uIE1lc3NhZ2UgVHlwZSIuIEkgdGhpbmsgdGhpcw0K PiA+PiA+IHN0YXRlbWVudCBtYWtlcyByZmM4MTEzIGEgTm9ybWF0aXZlIHJlZmVyZW5jZSAtLSB3 aGljaCByZXN1bHRzIGluIGENCj4gRG93blJlZi4NCj4gPj4gPiBTdWdnZXN0aW9uOiBnaXZlbiB0 aGF0IHRoaXMgZG9jdW1lbnQgYWxyZWFkeSB1cGRhdGVzIHRoZSByZWdpc3RyeSBzZXQgdXANCj4g aW4NCj4gPj4gPiByZmM4MTEzLCBhbmQgcmVjb21tZW5kcyB0aGUgdXNlIG9mIHRoZSBTaGFyZWQg RXh0ZW5zaW9uIE1lc3NhZ2UsIGl0IG1heQ0KPiBiZSBhDQo+ID4+ID4gZ29vZCBpZGVhIHRvIHNp bXBseSBhZG9wdCB0aGUgY29udGVudHMgb2YgdGhhdCBkb2N1bWVudCBoZXJlIChncmFuZA0KPiB0 b3RhbCBvZiA2DQo+ID4+ID4gcGFnZXMpIGFuZCBkZWNsYXJlIGl0IE9ic29sZXRlLg0KPiA+Pg0K PiA+PiBJ4oCZbSB5aWVsZGluZyB0byB0aGUgbGlzcC1jaGFpcnMgYW5kIERlYm9yYWggZm9yIHRo aXMgb25lLg0KPiA+IEkgc2VlIHRoYXQgdGhlcmXigJlzIGEgV0cgYWRvcHRpb24gY2FsbCBmb3Ig cmZjODExM2Jpcy4gIFRoYXTigJlzIGZpbmUgd2l0aCBtZQ0KPiDigJQgYnV0IEkgc3RpbGwgdGhp bmsgdGhhdCB0aGUgcmVmZXJlbmNlIHNob3VsZCBiZSBub3JtYXRpdmUuDQo+ID4NCj4gPiBUaGFu a3MhDQo+ID4NCj4gPiBBbHZhcm8uDQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IGxpc3AgbWFpbGluZyBsaXN0DQo+IGxpc3BAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQo= From nobody Tue Sep 25 02:26:29 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B64131283; Tue, 25 Sep 2018 02:26:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Trammell To: Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153786758036.30012.5926379631854398353@ietfa.amsl.com> Date: Tue, 25 Sep 2018 02:26:20 -0700 Archived-At: Subject: [lisp] Tsvart telechat review of draft-ietf-lisp-rfc6830bis-19 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 25 Sep 2018 09:26:21 -0000 Reviewer: Brian Trammell Review result: Ready with Nits Thanks for the revisions. Following up on my previous tsvart review, there is one remaining nit from previous transport reviews: - Section 5.3, the list "When doing ITR/PITR encapsulation", third item needs a citation fix: OLD: The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168]. NEW: The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC6040]. Thanks, cheers, Brian From nobody Tue Sep 25 09:03:16 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030F913130A; Tue, 25 Sep 2018 09:03:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bLbT8BnFHQ7N; Tue, 25 Sep 2018 09:03:13 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 3A5141312F4; Tue, 25 Sep 2018 09:03:13 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id s5-v6so3770210pfj.7; Tue, 25 Sep 2018 09:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/wUNTjmjNTXBnsKpOf5Nc7T7ZG/ncMWxRQUwcsX+6X4=; b=PmEvW1RQosxaHehL4bBkUQNj9EcaPNUGlU+W2FWhk95fIZRCLhrJeVoWirGVFZaw8j /NHhTlynjeQ8946EVi9kq9tXgBAEWzoc8rDqmz7LSV4EvkApeDziQirBAWa49r447MQP FiQqSdKw8zFNbSG/koXsJrDXCbyzZiwPYb7E9cH+v/Ieri8FugzlygguzTXYvUTb6wnH yblE9xcPQd8G14Zdc/MY7xIDp0/UCHLoCEL8JnxZuASye2WhzPQChvStnkTYTIs7n085 FCbTKPmEXqF2Yy19IBd1dK1JLsrFloSE33UlO1F1Ds0RP4N5R/2hGPrWt1L3oO8qW8/K Xa5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/wUNTjmjNTXBnsKpOf5Nc7T7ZG/ncMWxRQUwcsX+6X4=; b=BNPhsAfo4dxFqaB2puRutXeMJKvP1FTbKVIUCPpkgnp9KoXW6NGgGPyb0HftdSepRW 7vjjgcVQ33ZiEIVPLq40R16g7zPA6A5WkXB3UO/QAuf89miGW7tsePO1lF5CfFRNMAew 8CICnnPrLswavouMN+VATLKZH41jnGDyqe0MEStYlSIupY1WXnE+4rXSSNpc09ePenry 7B9WV4H4MMqRBU9lIx6Xu6U1D7qhIU+Dt59+BUGoYYbyZoh+QQ84I+w46FgH+j59O9ke DOG9yDMSmAQGRX9/3HVJKKx0XS0VwxOYTgumtH31dm2Wt6d3DawcJ/X373KdrJlGOTqo jIiQ== X-Gm-Message-State: ABuFfogsAOJVbchqhx3S5stnPQySgDyDbBZ3wlyY6WYTgnVxmn4NabYT mZX77s9pGSMGrJb27mSctNE= X-Google-Smtp-Source: ACcGV61+sQSVk0Bwrx7o4dtFgOsAtHwWoPH2IwmgqhHKs37aPFGpIChShAm7W2pOed3saa8lIVnRVg== X-Received: by 2002:a63:e60c:: with SMTP id g12-v6mr1731830pgh.308.1537891392727; Tue, 25 Sep 2018 09:03:12 -0700 (PDT) Received: from [10.31.79.57] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id z19-v6sm3646093pgi.33.2018.09.25.09.03.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Sep 2018 09:03:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DFE658F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 25 Sep 2018 09:03:10 -0700 Cc: Alvaro Retana , "lisp-chairs@ietf.org" , The IESG , "draft-ietf-lisp-rfc6833bis@ietf.org" , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3553C470-8D15-4876-89FA-23A13830D27D@gmail.com> References: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> <881C546E-62A6-4C92-8AE7-CA166A554AD3@gmail.com> <787AE7BB302AE849A7480A190F8B93302DFE658F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 25 Sep 2018 16:03:15 -0000 That is not the part I had a problem with. Consider it added. Dino > On Sep 25, 2018, at 2:22 AM, = wrote: >=20 > Hi Dino,=20 >=20 > I think that Alvaro has a valid point about rfc8113bis to be cited as = normative.=20 >=20 > This is easy to fix, IMO. Thanks. =20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : lisp [mailto:lisp-bounces@ietf.org] De la part de Dino Farinacci >> Envoy=C3=A9 : lundi 24 septembre 2018 19:39 >> =C3=80 : Alvaro Retana >> Cc : lisp-chairs@ietf.org; The IESG; = draft-ietf-lisp-rfc6833bis@ietf.org; >> lisp@ietf.org >> Objet : Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp- >> rfc6833bis-13: (with COMMENT) >>=20 >> Alvaro, I don=E2=80=99t know what you want to be satisified with the = text. And rather >> than go 20 questions, with weeks of turn-around time, can you offer = text >> please? >>=20 >> Dino >>=20 >>> On Sep 24, 2018, at 8:33 AM, Alvaro Retana = wrote: >>>=20 >>> On September 11, 2018 at 12:23:04 PM, Dino Farinacci = (farinacci@gmail.com) >> wrote: >>>=20 >>> Hi! >>>=20 >>> I=E2=80=99m back to this document=E2=80=A6after the Defer... >>>=20 >>> ... >>>>> (3) Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting >> rfc6830, I >>>>> think that, because of how the contents of that RFC were = distributed, >> this >>>>> document should also be tagged as Obsoleting rfc6830. >>>>=20 >>>> Done. >>> The text is there, but the tag in the header is missing ("Obsoletes: = 6833 >> (if approved)=E2=80=9D). >>>=20 >>>=20 >>>=20 >>>>> (4) The LISP Packet Types registry was set up in rfc8113. This = document >> asks >>>>> that IANA "refers to this document as well as [RFC8113] as = references" >> (=C2=A711.2), >>>>> and it seems to try to change the registration (or the text is >> incomplete) in >>>>> (=C2=A75.1): "Values in the "Not Assigned" range can be assigned = according to >>>>> procedures in [RFC8126]." Which procedure? s/Not = Assigned/Unassigned (=C2=A76 >> in >>>>> rfc8126) >>>>=20 >>>> The early values are already registered with IANA. This document is = asking >> to register the new ones which include type 15. And the values = *within* type >> 15 are documented in RFC8113. >>> The only place where I see type 15 referenced is in =C2=A75.1. If = that section >> is "asking to register the new ones which include type 15=E2=80=9D, = then these are >> instructions to IANA. >>>=20 >>> Regardless, a pointer from =C2=A711.2 to =C2=A75.1 won=E2=80=99t = hurt the document. >>>=20 >>>=20 >>>=20 >>>>> (5) Because of the point above, this draft should (at least) = Update >> rfc8113 >>>>> (see also below). >>>>=20 >>>> Don=E2=80=99t follow. >>> This document asks that the LISP Packet Type registry point also to = this >> registry. That is a change to the registry, which was defined in = rfc8113 >> (which is the only current reference). Updating the registry this = way should >> be signaled with an update to rfc8113 in this document. >>>=20 >>>=20 >>>=20 >>>>> (6) This document says that "Protocol designers experimenting with = new >> message >>>>> formats SHOULD use the LISP Shared Extension Message Type". I = think this >>>>> statement makes rfc8113 a Normative reference -- which results in = a >> DownRef. >>>>> Suggestion: given that this document already updates the registry = set up >> in >>>>> rfc8113, and recommends the use of the Shared Extension Message, = it may >> be a >>>>> good idea to simply adopt the contents of that document here = (grand >> total of 6 >>>>> pages) and declare it Obsolete. >>>>=20 >>>> I=E2=80=99m yielding to the lisp-chairs and Deborah for this one. >>> I see that there=E2=80=99s a WG adoption call for rfc8113bis. = That=E2=80=99s fine with me >> =E2=80=94 but I still think that the reference should be normative. >>>=20 >>> Thanks! >>>=20 >>> Alvaro. >>>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Sep 25 09:50:07 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D806130E22; Tue, 25 Sep 2018 09:50:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-lisp-gpe@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153789420463.4906.8450972711039633067.idtracker@ietfa.amsl.com> Date: Tue, 25 Sep 2018 09:50:04 -0700 Archived-At: Subject: [lisp] Alexey Melnikov's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 25 Sep 2018 16:50:05 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-lisp-gpe-06: No Objection 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 3.1.1. Payload Specific Transport Interactions for Ethernet Encapsulated Payloads When a LISP-GPE router performs Ethernet encapsulation, the inner header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped to, or used to determine the LISP Instance IDentifier (IID) field. 3.1.2. Payload Specific Transport Interactions for NSH Encapsulated Payloads When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN values MAY be mapped as specified for the Next Protocol encapsulated by NSH (namely IPv4, IPv6 and Ethernet). Not being a specialist in this technology it is not clear to me whether "MAY be mapped" above (in 2 places) provides enough details to implement. Are there any extra references that you should insert above? From nobody Tue Sep 25 10:08:43 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F76C124D68; Tue, 25 Sep 2018 10:08:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 o6v9em9Fil7r; Tue, 25 Sep 2018 10:08:40 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 E3C3A12426A; Tue, 25 Sep 2018 10:08:39 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id y4-v6so12011015pgp.9; Tue, 25 Sep 2018 10:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J2dy3tU0K91JntPqBsnC8w1/nt1enfcPMFSY4yheQ0k=; b=SnthT9nzrOF5rfMQNLKOkvXX0sB+NKti9ughaYf5yLvpQQEq4ER8sFkydEQPZPd4Cl nihuN7eYERs7Vyvy1mj2+fGF8nTCrrYGdPar6Ns46m8xLhBf/PMXyK8ZUxfY89RvNtDI YlhdoaSpPsTYZgK4311+qClizzycfDLy8ZqvRQIi29jewMCyEDjhwkbD+aLpx4H/dJ3W lGf3qZKGW2+05xT+YtbGtGosoRQEJER0FZ+rK2mPJQbCc83hLujf0/bOzllvstbghCOL cYeI/r3ROZ8jAnuLHjea5Q6egjQ+03D5XrnNDIxWSOnT92Dj3CRgKUiFZmLef6xQMdm8 Ysog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J2dy3tU0K91JntPqBsnC8w1/nt1enfcPMFSY4yheQ0k=; b=iY2+UBfknsTrIVxlUz3OCqnNSQxCNg2w2k5pa7INdGhQW3p8DdEUzrvhb8GWInXbPC DulImWSaqg6+AcuyMIzUjwIuvcKCc4pqmCyhAr4C6GOKL0OmSQXrOH5w9EJ3AgdwtPiF L+am6pSv69MF/jx1/jzxy5zki3ALfpN4ISYPr/D1e2nuNQwsxk2p6KW0VWnRFggE6BFt 2QPsF+MPu/h4Y4D54sZj0eNHPCFrARVLJtCh1bx1ss9I4JhJLmdIq5WhMzywBbtyI54m XqUw4NpTtGmBXADfj2afMJ7KqsLrYbZwY+jy8RK22nwDSZh+afH5y4SbwJlbBJmsd9+i RkZg== X-Gm-Message-State: ABuFfojirX0ZoO0d3+z3VyNATiER0LCwxDOi+6mwEgrSbIdOvrrfxyv/ s9bJcu/cRQ6O5gb+hdzZPzKw7mBW X-Google-Smtp-Source: ACcGV62IKqy0OwKrtKH6cMKI17H75OA4tbtC1/jftVUm0bMh9BuWcJMGtyUmhBls2IMcOSuC/yPjow== X-Received: by 2002:a63:c046:: with SMTP id z6-v6mr1955010pgi.114.1537895319406; Tue, 25 Sep 2018 10:08:39 -0700 (PDT) Received: from [10.228.203.131] (72-172-185-190.bayarea.net. [72.172.185.190]) by smtp.gmail.com with ESMTPSA id w2-v6sm3383984pgb.61.2018.09.25.10.08.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Sep 2018 10:08:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153786758036.30012.5926379631854398353@ietfa.amsl.com> Date: Tue, 25 Sep 2018 10:08:37 -0700 Cc: tsv-art@ietf.org, draft-ietf-lisp-rfc6830bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0B81D5C1-6D51-407A-91D5-E793E59E873D@gmail.com> References: <153786758036.30012.5926379631854398353@ietfa.amsl.com> To: Brian Trammell X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Tsvart telechat review of draft-ietf-lisp-rfc6830bis-19 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 25 Sep 2018 17:08:41 -0000 Thanks Brian. Consider it changed in the -20. Dino > On Sep 25, 2018, at 2:26 AM, Brian Trammell wrote: >=20 > Reviewer: Brian Trammell > Review result: Ready with Nits >=20 > Thanks for the revisions. Following up on my previous tsvart review, = there is > one remaining nit from previous transport reviews: >=20 > - Section 5.3, the list "When doing ITR/PITR encapsulation", third = item needs a > citation fix: >=20 > OLD: >=20 > The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion [RFC3168]. >=20 > NEW: >=20 > The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in > order to avoid discarding indications of congestion [RFC6040]. >=20 > Thanks, cheers, >=20 > Brian >=20 >=20 From nobody Tue Sep 25 11:14:29 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 541721286E3; Tue, 25 Sep 2018 11:14:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-lisp-gpe@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153789926133.5101.18151906676525764346.idtracker@ietfa.amsl.com> Date: Tue, 25 Sep 2018 11:14:21 -0700 Archived-At: Subject: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 25 Sep 2018 18:14:21 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-lisp-gpe-06: No Objection 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have some non-blocking comments (and nits): (1) §1: "LISP-GPE MAY also be used to extend the LISP Data-Plane header..." I think that MAY is out of place because there's nothing normative about the statement. (2) §3: "If the P-bit is clear (0) the LISP header conforms to the definition in [I-D.ietf-lisp-rfc6830bis]." I find this statement a little confusing because even with the bit set, the header still conforms to rfc6830bis, except for the Nonce/Map-Version field. IOW, it sounds as if the bit makes the header non-conforming. (3) §3: For clarity, it would be nice to add a figure showing the header with the P and V bits set. (4) §3.1: "...the specification of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with..." s/SHOULD/should In this case the "SHOULD" is not normative. (5) For IP packets, two encapsulation mechanisms exist, the base one defined in rfc6830bis and the generic one defined in this document. When encapsulating towards a GPE-capable router, which mechanisms should be used? Should one have preference over the other? I'm thinking it probably doesn't matter (since the receiving router can understand both) -- I'm trying to figure out whether there are operational considerations or guidance that are worth mentioning. From nobody Tue Sep 25 13:43:48 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8682C124C04; Tue, 25 Sep 2018 13:43:47 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 uGX-Y_Y7VmwH; Tue, 25 Sep 2018 13:43:44 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B822130DD1; Tue, 25 Sep 2018 13:43:42 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w8PK5J4P003504; Tue, 25 Sep 2018 16:10:14 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 2mqu2vmbyj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Sep 2018 16:10:13 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8PKAA6X017916; Tue, 25 Sep 2018 16:10:12 -0400 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8PKA5hC017633; Tue, 25 Sep 2018 16:10:05 -0400 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id BD1824039458; Tue, 25 Sep 2018 20:10:05 +0000 (GMT) Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (unknown [130.9.129.152]) by zlp27128.vci.att.com (Service) with ESMTPS id A3DE14039462; Tue, 25 Sep 2018 20:10:05 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.5]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0415.000; Tue, 25 Sep 2018 16:10:05 -0400 From: "BRUNGARD, DEBORAH A" To: Dino Farinacci , "mohamed.boucadair@orange.com" CC: "lisp-chairs@ietf.org" , "lisp@ietf.org" , The IESG , "draft-ietf-lisp-rfc6833bis@ietf.org" , Alvaro Retana Thread-Topic: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) Thread-Index: AQHUSevCC1GljGcClk+KyR9NqbkPY6T/5xoAgAAjDYCAAQelAIAAb+0A///Ka3A= Date: Tue, 25 Sep 2018 20:10:05 +0000 Message-ID: References: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> <881C546E-62A6-4C92-8AE7-CA166A554AD3@gmail.com> <787AE7BB302AE849A7480A190F8B93302DFE658F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3553C470-8D15-4876-89FA-23A13830D27D@gmail.com> In-Reply-To: <3553C470-8D15-4876-89FA-23A13830D27D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.110] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-25_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809250197 Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 25 Sep 2018 20:43:48 -0000 QXMgQWx2YXJvIHN1Z2dlc3RlZCwgd2UgY291bGQgaGF2ZSBpbmNvcnBvcmF0ZWQgYWxsIG9mIFJG QzgxMTMgaGVyZSwgYW5kIG9ic29sZXRlIGl0LiBCdXQgaXQgYWxzbyBpcyBvayBhcyBhIHN0YW5k YWxvbmUuIFRoZSBncm91cCB3YW50ZWQgdG8gY29udGludWUgd2l0aCBpdCBhcyBhIHN0YW5kYWxv bmUuIEkgdGhpbmsgdGhvdWdoIHdlIG5lZWQgdG8gYmUgY2xlYXIgb24gdGhlIHJlbGF0aW9uc2hp cHMuIEkgdGhpbmsgRGlubyBpcyByaWdodCwgUkZDODExMyBpcyBvbmx5IChhbmQgc2hvdWxkIGJl IG9ubHkpIGluZm9ybWF0aXZlIGhlcmUuIFRoZXJlIGFyZSBzb21lIGludGVyLXJlbGF0aW9uc2hp cHMgd2hpY2ggd2Ugc2hvdWxkIGNsYXJpZnkgaW4gdGhpcyBkb2N1bWVudCBhbmQgODExM2Jpcy4g QWxzbyBuZWVkIHRvIGNsYXJpZnkgYSBiaXQgbW9yZSB3aGF0IGlzIHRvIGJlIGRvbmUgaW4gdGhl IElBTkEgc2VjdGlvbiAtIEknbSBzdXJlIElBTkEgd2lsbCBkbyBvayAtIGJ1dCBpdCB3aWxsIG1h a2UgaXQgY2xlYXJlciBmb3Igb3RoZXJzLg0KDQooVGhhbmtzIEFsdmFybyEhISkNCg0KU2VjdGlv biA1LjENCj09PT09PT09PQ0KT0xEDQpGb3IgY29tcGxldGVuZXNzLCB0aGlzIGRvY3VtZW50IHJl ZmVyZW5jZXMgdGhlIExJU1AgU2hhcmVkIEV4dGVuc2lvbiBNZXNzYWdlIGFzc2lnbmVkIGJ5IFtS RkM4MTEzXS4NCk5FVw0KRm9yIGNvbXBsZXRlbmVzcywgdGhlIHN1bW1hcnkgYmVsb3cgaW5jbHVk ZXMgdGhlIExJU1AgU2hhcmVkIEV4dGVuc2lvbiBNZXNzYWdlIGFzc2lnbmVkIGJ5IFtSRkM4MTEz XS4NCk9MRA0KVmFsdWVzIGluIHRoZSAiTm90IEFzc2lnbmVkIiByYW5nZSBjYW4gYmUgYXNzaWdu ZWQgYWNjb3JkaW5nIHRvIHByb2NlZHVyZXMgaW4gW1JGQzgxMjZdLiAgRG9jdW1lbnRzIHRoYXQg cmVxdWVzdCBmb3IgYSBuZXcgTElTUCBwYWNrZXQgdHlwZSBtYXkgaW5kaWNhdGUgYSBwcmVmZXJy ZWQgdmFsdWUuDQpORVcNClZhbHVlcyBpbiB0aGUgIk5vdCBBc3NpZ25lZCIgcmFuZ2UgY2FuIGJl IGFzc2lnbmVkIGFjY29yZGluZyB0byBwcm9jZWR1cmVzIGluIFtSRkM4MTEzXS4NCihEZWJvcmFo OiA4MTEzIHNldCB1cCB0aGUgZ3VpZGVsaW5lcyBmb3IgdGhlIHVuYXNzaWduZWQsIHRoZSByZWFk ZXIgc2hvdWxkIHJlZmVyIHRvIGl0LiBUaGlzIHdpbGwgYW5zd2VyIEFsdmFybydzIHF1ZXN0aW9u IG9uIHRoZSBwcm9jZWR1cmVzLiBIaW50IGZvciBBbHZhcm86IHVuYXNzaWduZWQgaXMgZG9uZSB2 aWEgc3RhbmRhcmRzIGFjdGlvbi4pDQpPTEQNClByb3RvY29sIGRlc2lnbmVycyBleHBlcmltZW50 aW5nIHdpdGggbmV3IG1lc3NhZ2UgZm9ybWF0cyBTSE9VTEQgdXNlIHRoZSBMSVNQIFNoYXJlZCBF eHRlbnNpb24gTWVzc2FnZSBUeXBlIGFuZCByZXF1ZXN0IGEgW1JGQzgxMTNdIHN1Yi10eXBlIGFz c2lnbm1lbnQuDQpORVcNClByb3RvY29sIGRlc2lnbmVycyBleHBlcmltZW50aW5nIHdpdGggbmV3 IG1lc3NhZ2UgZm9ybWF0cyBhcmUgcmVjb21tZW5kZWQgdG8gdXNlIHRoZSBMSVNQIFNoYXJlZCBF eHRlbnNpb24gTWVzc2FnZSBUeXBlIFtSRkM4MTEzXS4NCihEZWJvcmFoOiBJIHRoaW5rIHRoaXMg c2VudGVuY2UgY291bGQgYmUgZGVsZXRlZCwgYnV0IGlmIHdhbnQgdG8ga2VlcCwgSSB0aGluayBp dCBzaG91bGQgbm90IGJlICJub3JtYXRpdmUiKQ0KDQpMSVNQIFBhY2tldCBUeXBlIENvZGVzDQo9 PT09PT09PT09PT09PT09PT09DQoqIEZvciBhdXRob3JzIG9mIFJGQzgxMTNiaXM6IG5lZWQgdG8g YWRkIHRvIDgxMTNiaXMgInVwZGF0ZXMgNjgzM2JpcyINClN1Z2dlc3Q6DQpPTEQNCkl0IGlzIGJl aW5nIHJlcXVlc3RlZCB0aGF0IHRoZSBJQU5BIGJlIGF1dGhvcml0YXRpdmUgZm9yIExJU1AgUGFj a2V0IFR5cGUgZGVmaW5pdGlvbnMgYW5kIHRoYXQgaXQgcmVmZXJzIHRvIHRoaXMgZG9jdW1lbnQg YXMgd2VsbCBhcyBbUkZDODExM10gYXMgcmVmZXJlbmNlcy4NCk5ldw0KSXQgaXMgYmVpbmcgcmVx dWVzdGVkIHRoYXQgdGhlIElBTkEgYmUgYXV0aG9yaXRhdGl2ZSBmb3IgTElTUCBQYWNrZXQgVHlw ZSBkZWZpbml0aW9ucyBhbmQgaXQgaXMgcmVxdWVzdGVkIHRvIHJlcGxhY2UgdGhlIFtSRkM2ODMw XSByZWdpc3RyeSBtZXNzYWdlIHJlZmVyZW5jZXMgd2l0aCB0aGUgUkZDIG51bWJlciBhc3NpZ25l ZCB0byB0aGlzIGRvY3VtZW50Lg0KDQpPTEQNCm1lc3NhZ2UgdHlwZSA1LCB3YXMgYWRkZWQgdG8g dGhpcyBkb2N1bWVudCBORVcgbWVzc2FnZSB0eXBlIDUsDQpORVcNCm1lc3NhZ2UgdHlwZSA1LCB3 YXMgYWRkZWQgYnkgdGhpcyBkb2N1bWVudCBORVcgbWVzc2FnZSB0eXBlIDUsDQoNCkxJU1AgQUNU IGFuZCBGbGFnIEZpZWxkcw0KPT09PT09PT09PT09PT09PT09PT0NCk9MRA0KRm91ciB2YWx1ZXMg aGF2ZSBhbHJlYWR5IGJlZW4gYWxsb2NhdGVkIGJ5IFtSRkM2ODMwXS4gIA0KTkVXDQpGb3VyIHZh bHVlcyBoYXZlIGFscmVhZHkgYmVlbiBhbGxvY2F0ZWQgYnkgW1JGQzY4MzBdLCBJQU5BIGlzIHJl cXVlc3RlZCB0byByZXBsYWNlIHRoZSBbUkZDNjgzMF0gcmVmZXJlbmNlIGZvciB0aGlzIHJlZ2lz dHJ5IHdpdGggdGhlIFJGQyBudW1iZXIgYXNzaWduZWQgdG8gdGhpcyBkb2N1bWVudCBhbmQgdGhl IFtSRkM2ODMwXSBBY3Rpb24gdmFsdWVzIHJlZmVyZW5jZXMgd2l0aCB0aGUgUkZDIG51bWJlciBh c3NpZ25lZCB0byB0aGlzIGRvY3VtZW50Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaWVzZyA8aWVzZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRGlubyBGYXJp bmFjY2kNClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNSwgMjAxOCAxMjowMyBQTQ0KVG86IG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCkNjOiBsaXNwLWNoYWlyc0BpZXRmLm9yZzsgbGlz cEBpZXRmLm9yZzsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWxpc3AtcmZj NjgzM2Jpc0BpZXRmLm9yZzsgQWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4N ClN1YmplY3Q6IFJlOiBbbGlzcF0gQWx2YXJvIFJldGFuYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFm dC1pZXRmLWxpc3AtcmZjNjgzM2Jpcy0xMzogKHdpdGggQ09NTUVOVCkNCg0KVGhhdCBpcyBub3Qg dGhlIHBhcnQgSSBoYWQgYSBwcm9ibGVtIHdpdGguIENvbnNpZGVyIGl0IGFkZGVkLg0KDQpEaW5v DQoNCj4gT24gU2VwIDI1LCAyMDE4LCBhdCAyOjIyIEFNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiANCj4gSGkg RGlubywNCj4gDQo+IEkgdGhpbmsgdGhhdCBBbHZhcm8gaGFzIGEgdmFsaWQgcG9pbnQgYWJvdXQg cmZjODExM2JpcyB0byBiZSBjaXRlZCBhcyBub3JtYXRpdmUuIA0KPiANCj4gVGhpcyBpcyBlYXN5 IHRvIGZpeCwgSU1PLiBUaGFua3MuICANCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0KPj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+PiBEZSA6IGxpc3AgW21haWx0bzpsaXNwLWJvdW5j ZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgRGlubyBGYXJpbmFjY2kgDQo+PiBFbnZvecOpIDog bHVuZGkgMjQgc2VwdGVtYnJlIDIwMTggMTk6Mzkgw4AgOiBBbHZhcm8gUmV0YW5hIENjIDogDQo+ PiBsaXNwLWNoYWlyc0BpZXRmLm9yZzsgVGhlIElFU0c7IGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMz YmlzQGlldGYub3JnOw0KPj4gbGlzcEBpZXRmLm9yZw0KPj4gT2JqZXQgOiBSZTogW2xpc3BdIEFs dmFybyBSZXRhbmEncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1saXNwLQ0KPj4gcmZjNjgz M2Jpcy0xMzogKHdpdGggQ09NTUVOVCkNCj4+IA0KPj4gQWx2YXJvLCBJIGRvbuKAmXQga25vdyB3 aGF0IHlvdSB3YW50IHRvIGJlIHNhdGlzaWZpZWQgd2l0aCB0aGUgdGV4dC4gDQo+PiBBbmQgcmF0 aGVyIHRoYW4gZ28gMjAgcXVlc3Rpb25zLCB3aXRoIHdlZWtzIG9mIHR1cm4tYXJvdW5kIHRpbWUs IGNhbiANCj4+IHlvdSBvZmZlciB0ZXh0IHBsZWFzZT8NCj4+IA0KPj4gRGlubw0KPj4gDQo+Pj4g T24gU2VwIDI0LCAyMDE4LCBhdCA4OjMzIEFNLCBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hLmlldGZA Z21haWwuY29tPiB3cm90ZToNCj4+PiANCj4+PiBPbiBTZXB0ZW1iZXIgMTEsIDIwMTggYXQgMTI6 MjM6MDQgUE0sIERpbm8gRmFyaW5hY2NpIA0KPj4+IChmYXJpbmFjY2lAZ21haWwuY29tKQ0KPj4g d3JvdGU6DQo+Pj4gDQo+Pj4gSGkhDQo+Pj4gDQo+Pj4gSeKAmW0gYmFjayB0byB0aGlzIGRvY3Vt ZW504oCmYWZ0ZXIgdGhlIERlZmVyLi4uDQo+Pj4gDQo+Pj4gLi4uDQo+Pj4+PiAoMykgRXZlbiB0 aG91Z2ggZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBiaXMgaXMgdGFnZ2VkIGFzIE9ic29sZXRpbmcN Cj4+IHJmYzY4MzAsIEkNCj4+Pj4+IHRoaW5rIHRoYXQsIGJlY2F1c2Ugb2YgaG93IHRoZSBjb250 ZW50cyBvZiB0aGF0IFJGQyB3ZXJlIA0KPj4+Pj4gZGlzdHJpYnV0ZWQsDQo+PiB0aGlzDQo+Pj4+ PiBkb2N1bWVudCBzaG91bGQgYWxzbyBiZSB0YWdnZWQgYXMgT2Jzb2xldGluZyByZmM2ODMwLg0K Pj4+PiANCj4+Pj4gRG9uZS4NCj4+PiBUaGUgdGV4dCBpcyB0aGVyZSwgYnV0IHRoZSB0YWcgaW4g dGhlIGhlYWRlciBpcyBtaXNzaW5nICgiT2Jzb2xldGVzOiANCj4+PiA2ODMzDQo+PiAoaWYgYXBw cm92ZWQp4oCdKS4NCj4+PiANCj4+PiANCj4+PiANCj4+Pj4+ICg0KSBUaGUgTElTUCBQYWNrZXQg VHlwZXMgcmVnaXN0cnkgd2FzIHNldCB1cCBpbiByZmM4MTEzLiBUaGlzIA0KPj4+Pj4gZG9jdW1l bnQNCj4+IGFza3MNCj4+Pj4+IHRoYXQgSUFOQSAicmVmZXJzIHRvIHRoaXMgZG9jdW1lbnQgYXMg d2VsbCBhcyBbUkZDODExM10gYXMgcmVmZXJlbmNlcyINCj4+ICjCpzExLjIpLA0KPj4+Pj4gYW5k IGl0IHNlZW1zIHRvIHRyeSB0byBjaGFuZ2UgdGhlIHJlZ2lzdHJhdGlvbiAob3IgdGhlIHRleHQg aXMNCj4+IGluY29tcGxldGUpIGluDQo+Pj4+PiAowqc1LjEpOiAiVmFsdWVzIGluIHRoZSAiTm90 IEFzc2lnbmVkIiByYW5nZSBjYW4gYmUgYXNzaWduZWQgDQo+Pj4+PiBhY2NvcmRpbmcgdG8gcHJv Y2VkdXJlcyBpbiBbUkZDODEyNl0uIiBXaGljaCBwcm9jZWR1cmU/IHMvTm90IA0KPj4+Pj4gQXNz aWduZWQvVW5hc3NpZ25lZCAowqc2DQo+PiBpbg0KPj4+Pj4gcmZjODEyNikNCj4+Pj4gDQo+Pj4+ IFRoZSBlYXJseSB2YWx1ZXMgYXJlIGFscmVhZHkgcmVnaXN0ZXJlZCB3aXRoIElBTkEuIFRoaXMg ZG9jdW1lbnQgaXMgDQo+Pj4+IGFza2luZw0KPj4gdG8gcmVnaXN0ZXIgdGhlIG5ldyBvbmVzIHdo aWNoIGluY2x1ZGUgdHlwZSAxNS4gQW5kIHRoZSB2YWx1ZXMgDQo+PiAqd2l0aGluKiB0eXBlDQo+ PiAxNSBhcmUgZG9jdW1lbnRlZCBpbiBSRkM4MTEzLg0KPj4+IFRoZSBvbmx5IHBsYWNlIHdoZXJl IEkgc2VlIHR5cGUgMTUgcmVmZXJlbmNlZCBpcyBpbiDCpzUuMS4gIElmIHRoYXQgDQo+Pj4gc2Vj dGlvbg0KPj4gaXMgImFza2luZyB0byByZWdpc3RlciB0aGUgbmV3IG9uZXMgd2hpY2ggaW5jbHVk ZSB0eXBlIDE14oCdLCB0aGVuIA0KPj4gdGhlc2UgYXJlIGluc3RydWN0aW9ucyB0byBJQU5BLg0K Pj4+IA0KPj4+IFJlZ2FyZGxlc3MsIGEgcG9pbnRlciBmcm9tIMKnMTEuMiB0byDCpzUuMSB3b27i gJl0IGh1cnQgdGhlIGRvY3VtZW50Lg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+Pj4gKDUpIEJlY2F1 c2Ugb2YgdGhlIHBvaW50IGFib3ZlLCB0aGlzIGRyYWZ0IHNob3VsZCAoYXQgbGVhc3QpIA0KPj4+ Pj4gVXBkYXRlDQo+PiByZmM4MTEzDQo+Pj4+PiAoc2VlIGFsc28gYmVsb3cpLg0KPj4+PiANCj4+ Pj4gRG9u4oCZdCBmb2xsb3cuDQo+Pj4gVGhpcyBkb2N1bWVudCBhc2tzIHRoYXQgdGhlIExJU1Ag UGFja2V0IFR5cGUgcmVnaXN0cnkgcG9pbnQgYWxzbyB0byANCj4+PiB0aGlzDQo+PiByZWdpc3Ry eS4gIFRoYXQgaXMgYSBjaGFuZ2UgdG8gdGhlIHJlZ2lzdHJ5LCB3aGljaCB3YXMgZGVmaW5lZCBp biANCj4+IHJmYzgxMTMgKHdoaWNoIGlzIHRoZSBvbmx5IGN1cnJlbnQgcmVmZXJlbmNlKS4gIFVw ZGF0aW5nIHRoZSByZWdpc3RyeSANCj4+IHRoaXMgd2F5IHNob3VsZCBiZSBzaWduYWxlZCB3aXRo IGFuIHVwZGF0ZSB0byByZmM4MTEzIGluIHRoaXMgZG9jdW1lbnQuDQo+Pj4gDQo+Pj4gDQo+Pj4g DQo+Pj4+PiAoNikgVGhpcyBkb2N1bWVudCBzYXlzIHRoYXQgIlByb3RvY29sIGRlc2lnbmVycyBl eHBlcmltZW50aW5nIHdpdGggDQo+Pj4+PiBuZXcNCj4+IG1lc3NhZ2UNCj4+Pj4+IGZvcm1hdHMg U0hPVUxEIHVzZSB0aGUgTElTUCBTaGFyZWQgRXh0ZW5zaW9uIE1lc3NhZ2UgVHlwZSIuIEkgDQo+ Pj4+PiB0aGluayB0aGlzIHN0YXRlbWVudCBtYWtlcyByZmM4MTEzIGEgTm9ybWF0aXZlIHJlZmVy ZW5jZSAtLSB3aGljaCANCj4+Pj4+IHJlc3VsdHMgaW4gYQ0KPj4gRG93blJlZi4NCj4+Pj4+IFN1 Z2dlc3Rpb246IGdpdmVuIHRoYXQgdGhpcyBkb2N1bWVudCBhbHJlYWR5IHVwZGF0ZXMgdGhlIHJl Z2lzdHJ5IA0KPj4+Pj4gc2V0IHVwDQo+PiBpbg0KPj4+Pj4gcmZjODExMywgYW5kIHJlY29tbWVu ZHMgdGhlIHVzZSBvZiB0aGUgU2hhcmVkIEV4dGVuc2lvbiBNZXNzYWdlLCANCj4+Pj4+IGl0IG1h eQ0KPj4gYmUgYQ0KPj4+Pj4gZ29vZCBpZGVhIHRvIHNpbXBseSBhZG9wdCB0aGUgY29udGVudHMg b2YgdGhhdCBkb2N1bWVudCBoZXJlIA0KPj4+Pj4gKGdyYW5kDQo+PiB0b3RhbCBvZiA2DQo+Pj4+ PiBwYWdlcykgYW5kIGRlY2xhcmUgaXQgT2Jzb2xldGUuDQo+Pj4+IA0KPj4+PiBJ4oCZbSB5aWVs ZGluZyB0byB0aGUgbGlzcC1jaGFpcnMgYW5kIERlYm9yYWggZm9yIHRoaXMgb25lLg0KPj4+IEkg c2VlIHRoYXQgdGhlcmXigJlzIGEgV0cgYWRvcHRpb24gY2FsbCBmb3IgcmZjODExM2Jpcy4gIFRo YXTigJlzIGZpbmUgDQo+Pj4gd2l0aCBtZQ0KPj4g4oCUIGJ1dCBJIHN0aWxsIHRoaW5rIHRoYXQg dGhlIHJlZmVyZW5jZSBzaG91bGQgYmUgbm9ybWF0aXZlLg0KPj4+IA0KPj4+IFRoYW5rcyENCj4+ PiANCj4+PiBBbHZhcm8uDQo+Pj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiBsaXNwIG1haWxpbmcgbGlzdA0KPj4gbGlzcEBpZXRm Lm9yZw0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpDQo+PiBsbWFuX2xpc3RpbmZvX2xpc3AmZD1Ed0lGYVEmYz1M RllaLW85X0hVTWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTcNCj4+IGpZbHhYRDh3Jm09b0lk MnNOemRXQUo5N3RMYnVaVUt0aGRuRHlsWjNJbWkyTjd6WWNNZGtiYyZzPTVoNzZCUXc4SUFKVg0K Pj4gTU4yM3VqZ2dnQ0Z3UlhsZEtUd2tSVFdweHJILV9NayZlPQ0KDQo= From nobody Tue Sep 25 13:44:14 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B254E130E14; Tue, 25 Sep 2018 13:43:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cFtubL2XUliq; Tue, 25 Sep 2018 13:43:46 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 C965E130DD3; Tue, 25 Sep 2018 13:43:42 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id z14-v6so9947221qtn.2; Tue, 25 Sep 2018 13:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R123IKOrq5gtfzKlgBsPBRkO3uPUCZ0UpqWrv+ZKm4w=; b=aykbB+JrU+eEou0BM/kj0f8WmFtBt/hgdgfdLbIinLWpngS0+ShQdw8CrYZPqSRudm hDelqxIUhFRkOrGR7xNDP9o0+phbSkxAL+gqpdFW9oMV0bOnCUxNVe5YnyDojfHx7QGU TeA6Tapnsi4ak17xPJVeKRn+JSpFZZL9/nEfLKNsL9ABf7JBUmq+ilmBi3KvRBLjn8N0 HQ1YTA/GqGQ2kwFhAOaTkwYgWIfiTLmgA2G5vl4bpB2LlfxquB9XPGCDK8IDexKkUrwF bkWmsn1AfNblaK1N0D13Px99MpSzTuMFrxnAXxY+vvj6BDoVLLz5D91LriUzkFE/jElJ AIHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R123IKOrq5gtfzKlgBsPBRkO3uPUCZ0UpqWrv+ZKm4w=; b=rR0fwx1o1dGTBLZm5hpWfxETH5s+vzHNjCKGzcN+PMvw3Zdt0//43Ndf96+8siOCr9 RnYxVputUL8Tkr7GdgGf6MhpliBFNV5PMHMzrgkLyjmotp1ntorAI40TRzELM5ZXijDt lBzVXGOysOp3DPDFxDhzBCtYFekNec7Ts4uTh2/S3VTxUrDXF4SL7us18e7zo1QUUVIe WHKOYY/+cbBCRRpFj5lwdKGbidqD2GuiLvWGWsk7V+aue37QdKX0amhNce4P/H7KQ2sg SZLutrqK4WEVRwaK3xzbswa3UKw1PsbnWeYeefnkNZ2dqjROZSVczyYALmvbjVhMdu5L HyOQ== X-Gm-Message-State: ABuFfojEcSPDASCFQ/Y4XdBruk7uqiQXHOArz2q5tM3QBomsCKGpCpcZ BJANgPBpVUrQpGjPyOYUMN4= X-Google-Smtp-Source: ACcGV63r/LEnH8COmCDg8jqW7AA1/dQor95TLjtLA6eEJqmhcYNhyOAwwMr1heWGUXe1KY+fD1xlrw== X-Received: by 2002:aed:3848:: with SMTP id j66-v6mr2173257qte.218.1537908221903; Tue, 25 Sep 2018 13:43:41 -0700 (PDT) Received: from [100.96.40.161] ([205.157.120.4]) by smtp.gmail.com with ESMTPSA id r73-v6sm1788318qke.78.2018.09.25.13.43.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Sep 2018 13:43:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 25 Sep 2018 13:41:37 -0700 Cc: "mohamed.boucadair@orange.com" , "lisp-chairs@ietf.org" , "lisp@ietf.org" , The IESG , "draft-ietf-lisp-rfc6833bis@ietf.org" , Alvaro Retana Content-Transfer-Encoding: quoted-printable Message-Id: <74996139-0B0A-48B3-BD70-D3392C900A6A@gmail.com> References: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com> <881C546E-62A6-4C92-8AE7-CA166A554AD3@gmail.com> <787AE7BB302AE849A7480A190F8B93302DFE658F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3553C470-8D15-4876-89FA-23A13830D27D@gmail.com> To: "BRUNGARD, DEBORAH A" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 25 Sep 2018 20:43:58 -0000 I=E2=80=99ll add the suggested text. Queued up for = draft-ietf-lisp-rfc6833bis-16. Thanks, Dino > On Sep 25, 2018, at 1:10 PM, BRUNGARD, DEBORAH A = wrote: >=20 > As Alvaro suggested, we could have incorporated all of RFC8113 here, = and obsolete it. But it also is ok as a standalone. The group wanted to = continue with it as a standalone. I think though we need to be clear on = the relationships. I think Dino is right, RFC8113 is only (and should be = only) informative here. There are some inter-relationships which we = should clarify in this document and 8113bis. Also need to clarify a bit = more what is to be done in the IANA section - I'm sure IANA will do ok - = but it will make it clearer for others. >=20 > (Thanks Alvaro!!!) >=20 > Section 5.1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > OLD > For completeness, this document references the LISP Shared Extension = Message assigned by [RFC8113]. > NEW > For completeness, the summary below includes the LISP Shared Extension = Message assigned by [RFC8113]. > OLD > Values in the "Not Assigned" range can be assigned according to = procedures in [RFC8126]. Documents that request for a new LISP packet = type may indicate a preferred value. > NEW > Values in the "Not Assigned" range can be assigned according to = procedures in [RFC8113]. > (Deborah: 8113 set up the guidelines for the unassigned, the reader = should refer to it. This will answer Alvaro's question on the = procedures. Hint for Alvaro: unassigned is done via standards action.) > OLD > Protocol designers experimenting with new message formats SHOULD use = the LISP Shared Extension Message Type and request a [RFC8113] sub-type = assignment. > NEW > Protocol designers experimenting with new message formats are = recommended to use the LISP Shared Extension Message Type [RFC8113]. > (Deborah: I think this sentence could be deleted, but if want to keep, = I think it should not be "normative") >=20 > LISP Packet Type Codes > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * For authors of RFC8113bis: need to add to 8113bis "updates 6833bis" > Suggest: > OLD > It is being requested that the IANA be authoritative for LISP Packet = Type definitions and that it refers to this document as well as = [RFC8113] as references. > New > It is being requested that the IANA be authoritative for LISP Packet = Type definitions and it is requested to replace the [RFC6830] registry = message references with the RFC number assigned to this document. >=20 > OLD > message type 5, was added to this document NEW message type 5, > NEW > message type 5, was added by this document NEW message type 5, >=20 > LISP ACT and Flag Fields > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > OLD > Four values have already been allocated by [RFC6830]. =20 > NEW > Four values have already been allocated by [RFC6830], IANA is = requested to replace the [RFC6830] reference for this registry with the = RFC number assigned to this document and the [RFC6830] Action values = references with the RFC number assigned to this document. >=20 > -----Original Message----- > From: iesg On Behalf Of Dino Farinacci > Sent: Tuesday, September 25, 2018 12:03 PM > To: mohamed.boucadair@orange.com > Cc: lisp-chairs@ietf.org; lisp@ietf.org; The IESG ; = draft-ietf-lisp-rfc6833bis@ietf.org; Alvaro Retana = > Subject: Re: [lisp] Alvaro Retana's No Objection on = draft-ietf-lisp-rfc6833bis-13: (with COMMENT) >=20 > That is not the part I had a problem with. Consider it added. >=20 > Dino >=20 >> On Sep 25, 2018, at 2:22 AM, = wrote: >>=20 >> Hi Dino, >>=20 >> I think that Alvaro has a valid point about rfc8113bis to be cited as = normative.=20 >>=20 >> This is easy to fix, IMO. Thanks. =20 >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : lisp [mailto:lisp-bounces@ietf.org] De la part de Dino = Farinacci=20 >>> Envoy=C3=A9 : lundi 24 septembre 2018 19:39 =C3=80 : Alvaro Retana = Cc :=20 >>> lisp-chairs@ietf.org; The IESG; draft-ietf-lisp-rfc6833bis@ietf.org; >>> lisp@ietf.org >>> Objet : Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp- >>> rfc6833bis-13: (with COMMENT) >>>=20 >>> Alvaro, I don=E2=80=99t know what you want to be satisified with the = text.=20 >>> And rather than go 20 questions, with weeks of turn-around time, can=20= >>> you offer text please? >>>=20 >>> Dino >>>=20 >>>> On Sep 24, 2018, at 8:33 AM, Alvaro Retana = wrote: >>>>=20 >>>> On September 11, 2018 at 12:23:04 PM, Dino Farinacci=20 >>>> (farinacci@gmail.com) >>> wrote: >>>>=20 >>>> Hi! >>>>=20 >>>> I=E2=80=99m back to this document=E2=80=A6after the Defer... >>>>=20 >>>> ... >>>>>> (3) Even though draft-ietf-lisp-rfc6830bis is tagged as = Obsoleting >>> rfc6830, I >>>>>> think that, because of how the contents of that RFC were=20 >>>>>> distributed, >>> this >>>>>> document should also be tagged as Obsoleting rfc6830. >>>>>=20 >>>>> Done. >>>> The text is there, but the tag in the header is missing = ("Obsoletes:=20 >>>> 6833 >>> (if approved)=E2=80=9D). >>>>=20 >>>>=20 >>>>=20 >>>>>> (4) The LISP Packet Types registry was set up in rfc8113. This=20 >>>>>> document >>> asks >>>>>> that IANA "refers to this document as well as [RFC8113] as = references" >>> (=C2=A711.2), >>>>>> and it seems to try to change the registration (or the text is >>> incomplete) in >>>>>> (=C2=A75.1): "Values in the "Not Assigned" range can be assigned=20= >>>>>> according to procedures in [RFC8126]." Which procedure? s/Not=20 >>>>>> Assigned/Unassigned (=C2=A76 >>> in >>>>>> rfc8126) >>>>>=20 >>>>> The early values are already registered with IANA. This document = is=20 >>>>> asking >>> to register the new ones which include type 15. And the values=20 >>> *within* type >>> 15 are documented in RFC8113. >>>> The only place where I see type 15 referenced is in =C2=A75.1. If = that=20 >>>> section >>> is "asking to register the new ones which include type 15=E2=80=9D, = then=20 >>> these are instructions to IANA. >>>>=20 >>>> Regardless, a pointer from =C2=A711.2 to =C2=A75.1 won=E2=80=99t = hurt the document. >>>>=20 >>>>=20 >>>>=20 >>>>>> (5) Because of the point above, this draft should (at least)=20 >>>>>> Update >>> rfc8113 >>>>>> (see also below). >>>>>=20 >>>>> Don=E2=80=99t follow. >>>> This document asks that the LISP Packet Type registry point also to=20= >>>> this >>> registry. That is a change to the registry, which was defined in=20 >>> rfc8113 (which is the only current reference). Updating the = registry=20 >>> this way should be signaled with an update to rfc8113 in this = document. >>>>=20 >>>>=20 >>>>=20 >>>>>> (6) This document says that "Protocol designers experimenting = with=20 >>>>>> new >>> message >>>>>> formats SHOULD use the LISP Shared Extension Message Type". I=20 >>>>>> think this statement makes rfc8113 a Normative reference -- which=20= >>>>>> results in a >>> DownRef. >>>>>> Suggestion: given that this document already updates the registry=20= >>>>>> set up >>> in >>>>>> rfc8113, and recommends the use of the Shared Extension Message,=20= >>>>>> it may >>> be a >>>>>> good idea to simply adopt the contents of that document here=20 >>>>>> (grand >>> total of 6 >>>>>> pages) and declare it Obsolete. >>>>>=20 >>>>> I=E2=80=99m yielding to the lisp-chairs and Deborah for this one. >>>> I see that there=E2=80=99s a WG adoption call for rfc8113bis. = That=E2=80=99s fine=20 >>>> with me >>> =E2=80=94 but I still think that the reference should be normative. >>>>=20 >>>> Thanks! >>>>=20 >>>> Alvaro. >>>>=20 >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai >>> = lman_listinfo_lisp&d=3DDwIFaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi9dM= 7 >>> = jYlxXD8w&m=3DoId2sNzdWAJ97tLbuZUKthdnDylZ3Imi2N7zYcMdkbc&s=3D5h76BQw8IAJV >>> MN23ujgggCFwRXldKTwkRTWpxrH-_Mk&e=3D >=20 From nobody Wed Sep 26 08:28:16 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF453130EBA for ; Wed, 26 Sep 2018 08:28:13 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 kol7xUX7xpz0 for ; Wed, 26 Sep 2018 08:28:11 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 55E0D130EAB for ; Wed, 26 Sep 2018 08:28:08 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id s14-v6so27457550wrw.6 for ; Wed, 26 Sep 2018 08:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0Tir1IqSKT+is+D7reVC+umW6U7F5LVuQikn/nSX3XE=; b=I/KZ2fo83jKJ5wY/rinh1l3eWH6abd9OKE9WpXUSjZChybWunuhP4o/ptgiTLtVu5E 7fJTQNPhd9yafZ0Mcj4zgQEjjwqYACs5QyO2AZPDpalqvEBfANT9JAypeBcNmAVyeB2+ L6flHpToSX/eHNJMFbzSLh1jRVP6nnlbuhC8ceGmDlQTyTUXNqO9/Bf1w/a9lG1X2+St cA+ca7Ca0HO7vsB5u4YEqyNiYuYaR3/cUVNdYwRBdPo+4SYDawaDFbqdOyGOGeiInWxn t6Fz/crQLFrnz/XM7sf2PcSNFb68vAe99wkMsxp1keJaNPs2g8ErsbMifQJE4GOoK1vL 7mSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0Tir1IqSKT+is+D7reVC+umW6U7F5LVuQikn/nSX3XE=; b=bzjNqr5TOUWVPWFPyzN6u4PWhAmqfZZEk6lSfjnrFSdG8ODti5Drh9F5JDTQ7IrvFp niXezKhQ2PErMlvUs7u5A2NpHhBxn9hLRxX9a7DA/ljJ0XIyXkzhDRsaYKGFk7OaTV1f /guSLyzOE9vsZob77jwABHqTvVsEKlk9utRcOQisHeznpauy/YbEQZgkYZHVP3OZS52u 3Y52++9faUxQEo8L6AJ1/Z/al+5JqY5hMXwV0IM/MsQ/iZZZRaiC0heFReczl6714RzV aRZdaz2OsC3t8niq6jMLIozqEtBSrJ9k0nhkFT3A4OI9Rs0+ie+sDKqJUKwCGXLx1hu8 I5IQ== X-Gm-Message-State: ABuFfohOkxXukvxNOMM05IRup+HaZypMHw2ytyFPn0fMNm6z8Z/IQwVc F3+LhQ/07qxnOLU4Ph+9il6Uog== X-Google-Smtp-Source: ACcGV63fESfRQq8TQX/ZWrZatPnUWYqihdsKt2WrDgfHWckYJwW8b33Kg4+jIaZoeEYC1Lb0NWG7Iw== X-Received: by 2002:adf:9af5:: with SMTP id a108-v6mr5684169wrc.125.1537975682366; Wed, 26 Sep 2018 08:28:02 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:b0a0:f6a9:d60b:b029? ([2001:660:330f:a4:b0a0:f6a9:d60b:b029]) by smtp.gmail.com with ESMTPSA id a17-v6sm1171240wme.40.2018.09.26.08.28.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Sep 2018 08:28:00 -0700 (PDT) From: Luigi Iannone Message-Id: <2FEB555F-16A5-4875-93ED-D14BFEEF503A@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_EFBF6645-2486-4EF5-8324-9DB4C1EFD319" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Wed, 26 Sep 2018 17:27:59 +0200 In-Reply-To: Cc: "Mirja Kuehlewind (IETF)" , lisp-chairs@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-rfc6830bis@ietf.org, The IESG To: Dino Farinacci References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com> <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net> <0BE5C929-D2FA-4786-9F5E-0A93E7700880@gmail.com> <11FBAC13-2859-4778-84CA-B546EB669727@kuehlewind.net> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 26 Sep 2018 15:28:14 -0000 --Apple-Mail=_EFBF6645-2486-4EF5-8324-9DB4C1EFD319 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mirja, trying to follow up on this issue. The ECN text for encapsulation is currently: The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168 = ]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. Can we keep it as it is (updating the reference to 6040)? The text for decapsulation is: CURRENT: The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC6040 = ]. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. Implementations exist that copy the 'ECN' field from the outer header to the inner header even though [RFC6040 ] does not recommend = this behavior. It is RECOMMENDED that implementations change to support the behavior in [RFC6040 = ]. Which I suggest we shrink to: NEW: The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC6040 = ].=20 Note that implementations exist that copy the 'ECN' field from the outer header to the inner header even though [RFC6040 ] does not recommend = such behavior. It is RECOMMENDED that implementations change, so to support the specifications in = [RFC6040 ]. The text above clearly states that implementations should be conform to = 6040.=20 Is it what you were looking for? Or am I missing something? Ciao L. =20 > On 24 Sep 2018, at 19:34, Dino Farinacci wrote: >=20 > Well, the implementations are out and working. And we said in the = latest updates to consider using RFC6040. So not sure we can do much = more than that. >=20 > Dino >=20 >> On Sep 24, 2018, at 5:52 AM, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Because they don=E2=80=99t follow RFC6040 and therefore we do = something different in some corner cases. >>=20 >>=20 >>=20 >>> Am 22.09.2018 um 06:52 schrieb Dino Farinacci : >>>=20 >>>> However, I totally disagree with your comment on providing details = that are not implemented. If they are not implemented correctly, it = might even be more important to spell them out in this document, so = implementors have chance to update their (future) implementation to do = the correct thing. Having deployed implementations that are non = standard-conform always happens and in this case it is probably not = specifically problematic as it doesn=E2=80=99t impact interoperability. = However, it is important though that the spec is correct. >>>=20 >>> And why do you think they are implemented incorrectly?=20 >>>=20 >>> Dino >>>=20 >>=20 >=20 --Apple-Mail=_EFBF6645-2486-4EF5-8324-9DB4C1EFD319 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mirja,

trying to = follow up on this issue.

The ECN text for encapsulation is currently:

      The 'Explicit Congestion =
Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion [RFC3168].
      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
      header to the outer header.  Re-encapsulation MUST copy the =
2-bit
      'ECN' field from the stripped outer header to the new outer

      =
header.

Can we = keep it as it is (updating the reference to 6040)?

The text for = decapsulation is:

CURRENT:
      The 'Explicit Congestion =
Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion [RFC6040].  If
      the 'ECN' field contains a congestion indication codepoint (the
      value is '11', the Congestion Experienced (CE) codepoint), then
      ETR decapsulation MUST copy the 2-bit 'ECN' field from the
      stripped outer header to the surviving inner header that is used
      to forward the packet beyond the ETR.  These requirements preserve
      CE indications when a packet that uses ECN traverses a LISP tunnel
      and becomes marked with a CE indication due to congestion between
      the tunnel endpoints.  Implementations exist that copy the 'ECN'
      field from the outer header to the inner header even though
      [RFC6040] does not recommend this behavior.  It is =
RECOMMENDED
      that implementations change to support the behavior in [RFC6040].

Which I = suggest we shrink to:

NEW:

      The 'Explicit Congestion Notification' (ECN) field (bits 6 =
and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion [RFC6040]. 
      Note that implementations =
exist that copy the 'ECN'
      field from the outer header to the inner header even though
      [RFC6040] does not recommend such behavior.  It is =
RECOMMENDED
      that implementations change, so to support the specifications in =
[RFC6040].


The text above clearly states that = implementations should be conform to 6040. 

Is it what you were looking = for?

Or am I = missing something?

Ciao

L.

 




On 24 Sep 2018, at 19:34, Dino Farinacci = <farinacci@gmail.com> wrote:

Well, = the implementations are out and working. And we said in the latest = updates to consider using RFC6040. So not sure we can do much more than = that.

Dino

On Sep 24, 2018, at 5:52 = AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:

Because they don=E2=80=99t follow RFC6040 and therefore we do = something different in some corner cases.


Am = 22.09.2018 um 06:52 schrieb Dino Farinacci <farinacci@gmail.com>:

However, I totally = disagree with your comment on providing details that are not = implemented. If they are not implemented correctly, it might even be = more important to spell them out in this document, so implementors have = chance to update their (future) implementation to do the correct thing. = Having deployed implementations that are non standard-conform always = happens and in this case it is probably not specifically problematic as = it doesn=E2=80=99t impact interoperability. However, it is important = though that the spec is correct.

And why do you think they are implemented incorrectly?

Dino




= --Apple-Mail=_EFBF6645-2486-4EF5-8324-9DB4C1EFD319-- From nobody Wed Sep 26 09:21:09 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8215130E19; Wed, 26 Sep 2018 09:21:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153797886791.21566.17486476119741623514@ietfa.amsl.com> Date: Wed, 26 Sep 2018 09:21:07 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-20.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 26 Sep 2018 16:21:08 -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 WG of the IETF. Title : The Locator/ID Separation Protocol (LISP) Authors : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Albert Cabellos Filename : draft-ietf-lisp-rfc6830bis-20.txt Pages : 45 Date : 2018-09-26 Abstract: This document describes the Data-Plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. This document obsoletes RFC 6830. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-20 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 26 09:24:27 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E515E130E19; Wed, 26 Sep 2018 09:24:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153797906591.21521.17052892782743287357@ietfa.amsl.com> Date: Wed, 26 Sep 2018 09:24:25 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-16.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 26 Sep 2018 16:24:26 -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 WG of the IETF. Title : Locator/ID Separation Protocol (LISP) Control-Plane Authors : Vince Fuller Dino Farinacci Albert Cabellos Filename : draft-ietf-lisp-rfc6833bis-16.txt Pages : 52 Date : 2018-09-26 Abstract: This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases. By using this Control-Plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems, which facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP Control-Plane infrastructure, connect directly to LISP-capable Internet end sites, and comprising the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. This document obsoletes RFC 6830 and 6833. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-16 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-16 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 Wed Sep 26 20:44:31 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF499130DDE; Wed, 26 Sep 2018 20:44:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com> Date: Wed, 26 Sep 2018 20:44:24 -0700 Archived-At: Subject: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 03:44:25 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lisp-rfc6830bis-20: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have grave concerns about the suitability of LISP as a whole, in its present form, for advancement to the Standards-Track. While some of my concerns are not specific to this document, as the core protocol (data-plane) spec, it seems an appropriate place to attach them to. I am told, out of band, that the intended deployment model is no longer to cover the entire Internet (c.f. the MISSREF-state draft-ietf-lisp-introduction's "with LISP, the dge of the Internet and the core can be logically separated and interconnected by LISP-capable routers", etc.), and that full Internet-scale operation is no longer a goal. However, since that does not seem to be reflected in the current batch of documents up for IESG review, I am forced to ballot on them "as-is", namely as targetting global Internet deployment. The requirements placed on the mapping system are so stringent so as to be arguably unachievable at Internet-scale, though that arguably has more of an interaction with the control-plane than the data-plane. It's still in scope here, though, as part of the overall description of the protocol flow. There are an almost innumerable number of downgrade attacks possible, and the control-plane and data-plane security mechanisms are not normative dependencies of the current corpus of documents, and as such are not up for consideration as mitigating the security concerns with the core documents. Section 3 defines the EID-to-RLOC Datbaase: EID-to-RLOC Database: The EID-to-RLOC Database is a global distributed database that contains all known EID-Prefix-to-RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID-Prefixes "behind" the router. These map to one of the router's own globally visible IP addresses. Note that there MAY be transient conditions when the EID-Prefix for the site and Locator-Set for each EID-Prefix may not be the same on all ETRs. This has no negative implications, since a partial set of Locators can be used. No compelling architecture for a trustworthy global distributed database has been presented that I've seen so far, and LISP relies heavily on the mapping system's database for its functionality. I am concerned that so many requirements are placed on the mapping system so as to be in effect unimplementable, in which case it would seem that the architecture as a whole (that is, for a global Internet-scale system) is not fit for purpose. Section 4.1's Step (6) only mentions parsing "to check for format validity". I think it is appropriate to mention (and refer to) source authentication checks as well, since bad Map-Reply data can allow all sorts of attacks to occur. There are some fairly subtle ordering requirements between the order of entries in Map-Reply messages and the Locator-Status-Bits in data-plane traffic (so that the semantic meaning of the status bits are meaningful), which is only given a minimal treatment in the control-plane document. The need for synchronization in interpreting these bits should be mentioned more prominently in the data-plane document as well. The usage of the Instance ID does not seem to be adequately covered; from what I've been able to pick up so far it seems that both source and destination participants must agree on the meaning of an Instance ID, and the source and destination EIDs must be in the same Instance. This does not seem like it is compatible with Internet scale, especially if there are only 24 usable bits of Instance ID. There seems to be a lot of intra-site synchronization requirements, notably with respect to Map-Version consistency, the contents and ordering of locator sets for EIDs in the site, etc.; the actual hard requirements for synchronization within a site should be clearly called out, ideally in a single location. The security considerations attempt to defer substantially to the threat-analysis in RFC 7835, which does not really seem like a complete threat analysis and does not provide analysis as to what requirements are placed on the boundaries between the different components of LISP (data plane, control plane, mapping system, various extensions, etc.). The secdir reviewer had some good thoughts in this space. The security considerations throughout the LISP documents place a heavy focus on the risk of over-claiming for routing EID-prefixes. This is a real concern, to be clear, but it should not overshadow the risk of an attacker who is able to move traffic around at will, strip security protections, cause denial of service, alter data-plane payloads, etc. Similarly, this document's security considerations call out denial of service as a risk from Map-Cache insertion/spoofing, but the risks from an attacker being able to read and modify the traffic, perhaps even without detection, seems a much greater threat to me. I am not convinced that this protocol meets the current IETF requirements for the security properties of Standards-Track Protocols without at least LISP-SEC as a mandatory-to-implement component, and possibly additional or stronger requirements. (I did not do a full analysis of the system in the presence of those security mechanisms, since that is not what is being presented for review.) Having an EID that is associated to user-correlatable devices has severe privacy considerations, but I could not find this mentioned anywhere in all of the LISP documents I've read so far. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I apologize for the somewhat scattered nature of these comments; there are a lot of them and I was focusing my time more on trying to understand the broader system, and the intended security posture, so they did not get as much clean-up as I would have liked. (Most of my review was performed on the -18, though I have tried to update to the -20 as relevant.) The instance ID provides for organizational correlation, another privacy exposure. Is there anything different between an "EID-to-RLOC Map-Request" and just a "Map-Request"? (Same question for "Map-Reply", too.) There's a lot of stuff that seems to work best if there is symmetric bidirectional traffic, with inline signalling of map version and reachability changes, though clearly everything is designed to also work with asymmetric connectivity or unidirectional traffic. It would be nice to have a high-level summary in or near the introduction about what kinds of behavior/performance differences are expected for bidirectional vs. unidirectional traffic. Section 2 That's not the 8174 boilerplate; it's more than just adding a cite to the 2119 boilerplate. Section 3 nit: "An address family that pertains to the Data-Plane." is a sentence fragment. Ingress Tunnel Router (ITR): An ITR is a router that resides in a [...] mapping lookup in the destination address field. Note that this destination RLOC MAY be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the This doesn't seem like a 2119 MAY is necessary, but rather a statement of fact that may not be known to the encapsulating ITR. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating host's supplied EID). I'm confused here, perhaps in multiple ways. Are there now *two* LISP headers on the packet? Is the "outer RLOC the ISP ITR uses" the source RLOC or the destination RLOC? Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-Prefix is advertised or stored with no RLOCs. That is, the Locator-Set for the EID-to-RLOC entry is empty or has an encoded Locator count of 0. Is "empty" a distinct representation from "locator count of zero"? Perhaps something of an aside, but the check described for Route-Returnability is a somewhat weak check, and in some cases could still be spoofed. (I don't expect this to surprise anyone, of course, but perhaps some more qualifiers could be added to the text.) Section 4 An additional LISP header MAY be prepended to packets by a TE-ITR when re-routing of the path for a packet is desired. A potential use-case for this would be an ISP router that needs to perform Traffic Engineering for packets flowing through its network. In such a situation, termed "Recursive Tunneling", an ISP transit acts as an additional ITR, and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along an intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). "the RLOC it uses for the new prepnded header", again, this is as the destination RLOC (vs. source RLOC)? Section 4.1 o Map-Replies are sent on the underlying routing system topology using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. Just to check my understanding: is the "underlying routing system topology" the same as the "underlay"? Is step (3) just describing more of what step (2) says is "not described in this example"? Section 5.3 The word "nonce" is normally used for something used exactly once. E.g., with some AEAD algorithms, if the same "nonce" input is used for different encryptions, the entire security of the system is compromised. It would be better to refer to this field with a different term, given that "the same nonce can be used for a period of time when encapsulating to the same ETR". "Uniquifier" or "random value" might be reasonable choices. Why is there no discussion of the Map-Version or Instance-ID fields in this section? When doing ETR/PETR decapsulation: o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site. Er, what is "this check" that is also performed for initial encapsulation? How are there multiple TTL values to compare? o The inner-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header DSCP field ('Traffic Class' field, in the case of IPv6) to the inner-header. nit: the first "inner-header" seems like an editing remnant? Section 7.1 How is this stateless if it invovles knowledge about the routers between the ITR and all possible ETRs (i.e., a set that could change over time)? Section 8 This 32-bit vs 24-bit thing is pretty hokey for a standards-track specification (yes, I know that LISP-DDT is not standards track at the moment). Section 9 Alternatively, RLOC information MAY be gleaned from received tunneled What is this an alternative to? The list of four options above? packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner-header IP source address) of the received encapsulated packet. The source EID is some random end system, right? So this relys on some magic in the ETR to detect that there's a Map-Request and reply directly instead of passing it on to the EID that won't know what to do with it? Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and might benefit from an explicit section reference to the other document. Section 10 What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it is not marked as well-known at https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion is probably in order. Again, when we are talking about the internal structure of the Map-Reply, a detailed section refernce to 6833bis is useful. Modifying LSBs seems like a fine DoS attack vector for an on-path attacker. value of 1. Locator-Status-Bits are associated with a Locator-Set per EID-Prefix. Therefore, when a Locator becomes unreachable, the Locator-Status-Bit that corresponds to that Locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-Prefix Doesn't this imply a stateful relationship between the ordering of Map-Replys and data-plane traffic? Section 10.1 Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. Perhaps they could be given actual names so as to disambiguate which steps are performed with ITR vs. ETR role? The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may erroneously consider the Locator unreachable. An ITR SHOULD only set the E-bit in an encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- probe Map-Reply message. Why is this even optional? If it was mandatory to use, then there would not be a question. But at least clarify that the "this" that is conveyed is whether the peer supports the echo-nonce algorithm. (Also, subject to downgrade.) Section 13 When a Locator record is removed from a Locator-Set, ITRs that have the mapping cached will not use the removed Locator because the xTRs will set the Locator-Status-Bit to 0. So, even if the Locator is in the list, it will not be used. For new mapping requests, the xTRs can set the Locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding Locator-Status-Bit to 0. This forces ITRs with old or new mappings to avoid using the removed Locator. The behavior describe here seems like it would be better described as "when a Locator is taken out of service" than "removed from a Locator-Set", since if it is not in the set at all, it has no index, and no LSB or AFI to set. Should actually depopulating it like this be forbidden? I guess the Map Versioning is supposed to help with this, but we need to nail down the semantics more and/or give a clearer reference to it. Section 13.1 An ITR, when it encapsulates packets to ETRs, can convey its own Map- Version Number. This is known as the Source Map-Version Number. Replacing "its own Map-Version Number" with something like "the Map-Version numer for the LISP site of which it is a part". Writing this causes me to note that the semantics of the Map-Version are unclear, here -- what is it scoped to? An EID-Prefix? An RLOC? Oh, you say that in the next paragraph (EID-Prefix). A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server to assure that all ETRs for a site registering to it will be synchronized according to Map- Version Number. Huh? I must be confused how this works. (Also, wouldn't this be better in the control plane document which covers Map-Register?) Section 15 o When a tunnel-encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special Forwarding Information Base (FIB) entries for the EID-Prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that Control-Plane processing SHOULD be performed. I assume this is just my lack of background showing, but I'm confused how it makes sense to mark these for control-plane processing. Isn't the control plane much slower, and we're not putting all of the LISP data-plane traffic onto the slow path? Section 18 o Data-Plane gleaning for creating map-cache entries has been made optional. If any ITR implementations depend or assume the remote ETR is gleaning should not do so. nit: this is ungrammatical; "they should not" or "Any ITR implementations that depend on or assume that" would fix it. Section 19.1 Presumably IANA also updated the reference column to point to this document? From nobody Wed Sep 26 20:53:11 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B81130DDE; Wed, 26 Sep 2018 20:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 Vu97cWi3eJG3; Wed, 26 Sep 2018 20:53:05 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3EF124C04; Wed, 26 Sep 2018 20:53:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B438F446FB6; Wed, 26 Sep 2018 20:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1538020384; bh=yp5XEkHdjtgMaXB1wZtWIbCND3OjDtszRhSNTBfkark=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=W2blQhFluMu/unBoHHilAgJwceDFxTzGdYI3ZznjpMPvpsW4YNnRzwgj3Ctptf6Nh +aYPW0libhB/WHJAXq8f237lFVBPGnri6cmlPBY1g9Y7+PUDKwNA/SMJzW1xyexzR9 B67sRYcNYhw9BAc/da+itadbbp1vDMXaK+jfqft4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 9AA1B447095; Wed, 26 Sep 2018 20:53:03 -0700 (PDT) To: Benjamin Kaduk , The IESG Cc: draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org References: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <739fae18-85a5-26c2-85a6-7d7c830fcd32@joelhalpern.com> Date: Wed, 26 Sep 2018 23:53:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 03:53:09 -0000 Is there text we can add about the scoping that will change your discuss into a series of useful comments? If so, Some indication of how you would like that phrased would help us address these. If not, we seem to have a larger problem. Yours, Joel On 9/26/18 11:44 PM, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-lisp-rfc6830bis-20: 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 https://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: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have grave concerns about the suitability of LISP as a whole, in its > present form, for advancement to the Standards-Track. While some of my > concerns are not specific to this document, as the core protocol > (data-plane) spec, it seems an appropriate place to attach them to. > > I am told, out of band, that the intended deployment model is no longer to > cover the entire Internet (c.f. the MISSREF-state > draft-ietf-lisp-introduction's "with LISP, the dge of the Internet and the > core can be logically separated and interconnected by LISP-capable > routers", etc.), and that full Internet-scale operation is no longer a > goal. However, since that does not seem to be reflected in the current > batch of documents up for IESG review, I am forced to ballot on them > "as-is", namely as targetting global Internet deployment. The requirements > placed on the mapping system are so stringent so as to be arguably > unachievable at Internet-scale, though that arguably has more of an > interaction with the control-plane than the data-plane. It's still in > scope here, though, as part of the overall description of the protocol > flow. > > There are an almost innumerable number of downgrade attacks possible, and > the control-plane and data-plane security mechanisms are not normative > dependencies of the current corpus of documents, and as such are not up for > consideration as mitigating the security concerns with the core documents. > > Section 3 defines the EID-to-RLOC Datbaase: > > EID-to-RLOC Database: The EID-to-RLOC Database is a global > distributed database that contains all known EID-Prefix-to-RLOC > mappings. Each potential ETR typically contains a small piece of > the database: the EID-to-RLOC mappings for the EID-Prefixes > "behind" the router. These map to one of the router's own > globally visible IP addresses. Note that there MAY be transient > conditions when the EID-Prefix for the site and Locator-Set for > each EID-Prefix may not be the same on all ETRs. This has no > negative implications, since a partial set of Locators can be > used. > > No compelling architecture for a trustworthy global distributed database > has been presented that I've seen so far, and LISP relies heavily on the > mapping system's database for its functionality. I am concerned that so > many requirements are placed on the mapping system so as to be in effect > unimplementable, in which case it would seem that the architecture as a > whole (that is, for a global Internet-scale system) is not fit for purpose. > > Section 4.1's Step (6) only mentions parsing "to check for format > validity". I think it is appropriate to mention (and refer to) source > authentication checks as well, since bad Map-Reply data can allow all sorts > of attacks to occur. > > There are some fairly subtle ordering requirements between the order of > entries in Map-Reply messages and the Locator-Status-Bits in data-plane > traffic (so that the semantic meaning of the status bits are meaningful), > which is only given a minimal treatment in the control-plane document. The > need for synchronization in interpreting these bits should be mentioned > more prominently in the data-plane document as well. > > The usage of the Instance ID does not seem to be adequately covered; from > what I've been able to pick up so far it seems that both source and > destination participants must agree on the meaning of an Instance ID, and > the source and destination EIDs must be in the same Instance. This does > not seem like it is compatible with Internet scale, especially if there are > only 24 usable bits of Instance ID. > > There seems to be a lot of intra-site synchronization requirements, notably > with respect to Map-Version consistency, the contents and ordering of > locator sets for EIDs in the site, etc.; the actual hard requirements for > synchronization within a site should be clearly called out, ideally in a > single location. > > The security considerations attempt to defer substantially to the > threat-analysis in RFC 7835, which does not really seem like a complete > threat analysis and does not provide analysis as to what requirements are > placed on the boundaries between the different components of LISP (data > plane, control plane, mapping system, various extensions, etc.). The > secdir reviewer had some good thoughts in this space. > > The security considerations throughout the LISP documents place a heavy > focus on the risk of over-claiming for routing EID-prefixes. This is a > real concern, to be clear, but it should not overshadow the risk of an > attacker who is able to move traffic around at will, strip security > protections, cause denial of service, alter data-plane payloads, etc. > Similarly, this document's security considerations call out denial of > service as a risk from Map-Cache insertion/spoofing, but the risks from an > attacker being able to read and modify the traffic, perhaps even without > detection, seems a much greater threat to me. > > I am not convinced that this protocol meets the current IETF requirements > for the security properties of Standards-Track Protocols without at least > LISP-SEC as a mandatory-to-implement component, and possibly additional or > stronger requirements. (I did not do a full analysis of the system in the > presence of those security mechanisms, since that is not what is being > presented for review.) > > Having an EID that is associated to user-correlatable devices has severe > privacy considerations, but I could not find this mentioned anywhere in all > of the LISP documents I've read so far. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I apologize for the somewhat scattered nature of these comments; there are > a lot of them and I was focusing my time more on trying to understand the > broader system, and the intended security posture, so they did not get as > much clean-up as I would have liked. (Most of my review was performed on the > -18, though I have tried to update to the -20 as relevant.) > > > The instance ID provides for organizational correlation, another privacy > exposure. > > Is there anything different between an "EID-to-RLOC Map-Request" and just a > "Map-Request"? (Same question for "Map-Reply", too.) > > There's a lot of stuff that seems to work best if there is symmetric > bidirectional traffic, with inline signalling of map version and > reachability changes, though clearly everything is designed to also work > with asymmetric connectivity or unidirectional traffic. It would be nice > to have a high-level summary in or near the introduction about what kinds > of behavior/performance differences are expected for bidirectional vs. > unidirectional traffic. > > Section 2 > > That's not the 8174 boilerplate; it's more than just adding a cite to the > 2119 boilerplate. > > Section 3 > > nit: "An address family that pertains to the Data-Plane." is a sentence > fragment. > > Ingress Tunnel Router (ITR): An ITR is a router that resides in a > [...] > mapping lookup in the destination address field. Note that this > destination RLOC MAY be an intermediate, proxy device that has > better knowledge of the EID-to-RLOC mapping closer to the > > This doesn't seem like a 2119 MAY is necessary, but rather a statement of > fact that may not be known to the encapsulating ITR. > > Specifically, when a service provider prepends a LISP header for > Traffic Engineering purposes, the router that does this is also > regarded as an ITR. The outer RLOC the ISP ITR uses can be based > on the outer destination address (the originating ITR's supplied > RLOC) or the inner destination address (the originating host's > supplied EID). > > I'm confused here, perhaps in multiple ways. Are there now *two* LISP > headers on the packet? Is the "outer RLOC the ISP ITR uses" the source > RLOC or the destination RLOC? > > Negative Mapping Entry: A negative mapping entry, also known as a > negative cache entry, is an EID-to-RLOC entry where an EID-Prefix > is advertised or stored with no RLOCs. That is, the Locator-Set > for the EID-to-RLOC entry is empty or has an encoded Locator count > of 0. > > Is "empty" a distinct representation from "locator count of zero"? > > Perhaps something of an aside, but the check described for > Route-Returnability is a somewhat weak check, and in some cases could still > be spoofed. (I don't expect this to surprise anyone, of course, but > perhaps some more qualifiers could be added to the text.) > > Section 4 > > An additional LISP header MAY be prepended to packets by a TE-ITR > when re-routing of the path for a packet is desired. A potential > use-case for this would be an ISP router that needs to perform > Traffic Engineering for packets flowing through its network. In such > a situation, termed "Recursive Tunneling", an ISP transit acts as an > additional ITR, and the RLOC it uses for the new prepended header > would be either a TE-ETR within the ISP (along an intra-ISP traffic > engineered path) or a TE-ETR within another ISP (an inter-ISP traffic > engineered path, where an agreement to build such a path exists). > > "the RLOC it uses for the new prepnded header", again, this is as the > destination RLOC (vs. source RLOC)? > > Section 4.1 > > o Map-Replies are sent on the underlying routing system topology > using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. > > Just to check my understanding: is the "underlying routing system topology" > the same as the "underlay"? > > Is step (3) just describing more of what step (2) says is "not described in > this example"? > > Section 5.3 > > The word "nonce" is normally used for something used exactly once. > E.g., with some AEAD algorithms, if the same "nonce" input is used for > different encryptions, the entire security of the system is compromised. > It would be better to refer to this field with a different term, given > that "the same nonce can be used for a period of time when encapsulating to > the same ETR". "Uniquifier" or "random value" might be reasonable choices. > > Why is there no discussion of the Map-Version or Instance-ID fields > in this section? > > When doing ETR/PETR decapsulation: > > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > the case of IPv6) SHOULD be copied from the outer-header 'Time to > Live' field, when the Time to Live value of the outer header is > less than the Time to Live value of the inner header. Failing to > perform this check can cause the Time to Live of the inner header > to increment across encapsulation/decapsulation cycles. This > check is also performed when doing initial encapsulation, when a > packet comes to an ITR or PITR destined for a LISP site. > > Er, what is "this check" that is also performed for initial encapsulation? > How are there multiple TTL values to compare? > > o The inner-header 'Differentiated Services Code Point' (DSCP) field > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be > copied from the outer-header DSCP field ('Traffic Class' field, in > the case of IPv6) to the inner-header. > > nit: the first "inner-header" seems like an editing remnant? > > Section 7.1 > > How is this stateless if it invovles knowledge about the routers between > the ITR and all possible ETRs (i.e., a set that could change over time)? > > Section 8 > > This 32-bit vs 24-bit thing is pretty hokey for a standards-track > specification (yes, I know that LISP-DDT is not standards track at the > moment). > > Section 9 > > Alternatively, RLOC information MAY be gleaned from received tunneled > > What is this an alternative to? The list of four options above? > > packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache > entry, one learned from the source RLOC of a received encapsulated > packet, is only stored and used for a few seconds, pending > verification. Verification is performed by sending a Map-Request to > the source EID (the inner-header IP source address) of the received > encapsulated packet. > > The source EID is some random end system, right? So this relys on some > magic in the ETR to detect that there's a Map-Request and reply directly > instead of passing it on to the EID that won't know what to do with it? > > Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and > might benefit from an explicit section reference to the other document. > > Section 10 > > What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it > is not marked as well-known at > https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion is > probably in order. > > Again, when we are talking about the internal structure of the Map-Reply, a > detailed section refernce to 6833bis is useful. > > Modifying LSBs seems like a fine DoS attack vector for an on-path attacker. > > value of 1. Locator-Status-Bits are associated with a Locator-Set > per EID-Prefix. Therefore, when a Locator becomes unreachable, the > Locator-Status-Bit that corresponds to that Locator's position in the > list returned by the last Map-Reply will be set to zero for that > particular EID-Prefix > > Doesn't this imply a stateful relationship between the ordering of > Map-Replys and data-plane traffic? > > Section 10.1 > > Note that "ITR" and "ETR" are relative terms here. Both devices MUST > be implementing both ITR and ETR functionality for the echo nonce > mechanism to operate. > > Perhaps they could be given actual names so as to disambiguate which steps > are performed with ITR vs. ETR role? > > The echo-nonce algorithm is bilateral. That is, if one side sets the > E-bit and the other side is not enabled for echo-noncing, then the > echoing of the nonce does not occur and the requesting side may > erroneously consider the Locator unreachable. An ITR SHOULD only set > the E-bit in an encapsulated data packet when it knows the ETR is > enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- > probe Map-Reply message. > > Why is this even optional? If it was mandatory to use, then there would > not be a question. But at least clarify that the "this" that is conveyed > is whether the peer supports the echo-nonce algorithm. (Also, subject to > downgrade.) > > Section 13 > > When a Locator record is removed from a Locator-Set, ITRs that have > the mapping cached will not use the removed Locator because the xTRs > will set the Locator-Status-Bit to 0. So, even if the Locator is in > the list, it will not be used. For new mapping requests, the xTRs > can set the Locator AFI to 0 (indicating an unspecified address), as > well as setting the corresponding Locator-Status-Bit to 0. This > forces ITRs with old or new mappings to avoid using the removed > Locator. > > The behavior describe here seems like it would be better described as "when > a Locator is taken out of service" than "removed from a Locator-Set", since > if it is not in the set at all, it has no index, and no LSB or AFI to set. > Should actually depopulating it like this be forbidden? > > I guess the Map Versioning is supposed to help with this, but we need to > nail down the semantics more and/or give a clearer reference to it. > > Section 13.1 > > An ITR, when it encapsulates packets to ETRs, can convey its own Map- > Version Number. This is known as the Source Map-Version Number. > > Replacing "its own Map-Version Number" with something like "the Map-Version > numer for the LISP site of which it is a part". Writing this causes me to > note that the semantics of the Map-Version are unclear, here -- what is it > scoped to? An EID-Prefix? An RLOC? Oh, you say that in the next > paragraph (EID-Prefix). > > A Map-Version Number can be included in Map-Register messages as > well. This is a good way for the Map-Server to assure that all ETRs > for a site registering to it will be synchronized according to Map- > Version Number. > > Huh? I must be confused how this works. (Also, wouldn't this be better in > the control plane document which covers Map-Register?) > > Section 15 > > o When a tunnel-encapsulated packet is received by an ETR, the outer > destination address may not be the address of the router. This > makes it challenging for the control plane to get packets from the > hardware. This may be mitigated by creating special Forwarding > Information Base (FIB) entries for the EID-Prefixes of EIDs served > by the ETR (those for which the router provides an RLOC > translation). These FIB entries are marked with a flag indicating > that Control-Plane processing SHOULD be performed. > > I assume this is just my lack of background showing, but I'm confused how > it makes sense to mark these for control-plane processing. Isn't the > control plane much slower, and we're not putting all of the LISP data-plane > traffic onto the slow path? > > Section 18 > > o Data-Plane gleaning for creating map-cache entries has been made > optional. If any ITR implementations depend or assume the remote > ETR is gleaning should not do so. > > nit: this is ungrammatical; "they should not" or "Any ITR implementations > that depend on or assume that" would fix it. > > Section 19.1 > > Presumably IANA also updated the reference column to point to this > document? > > > From nobody Wed Sep 26 21:51:41 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53629130DC5; Wed, 26 Sep 2018 21:51:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153802389933.21595.7512100936069393959.idtracker@ietfa.amsl.com> Date: Wed, 26 Sep 2018 21:51:39 -0700 Archived-At: Subject: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 04:51:39 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lisp-rfc6833bis-16: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- See my ballot position on rfc6830bis for some more general notes. I did most of my review on the -15, though I attempted to note when the -16 has changed the text. I am concerned about the handling procedures for Map-Requests that are encapsulated with the 'S' bit present. In particular, the ITR is required to discard non-secure responses, which is necessary in order to avoid a downgrade attack (in the current architecture). However, it seems that ETRs are not required to enable security in their registrations, and Map-Servers are supposed to strip the security flag when forwarding Map-Requests to ETRs that do not register as supporting LISP-SEC, and the resulting Map-Reply messages would thus not be secured, and dropped by the initiating ITR. So support for LISP-SEC would need to be mandatory for all ETRs in order for any ITR to be able to enforce the downgrade-protection behavior, which is a pretty bad deployment story. Making LISP-SEC mandatory everywhere would, of course, avoid this issue. I do not understand the procedure for allocation of EIDs. In a global mapping database, there needs to be some authoritative procedure for determining what ETRs and/or Map-Servers are authoritative for a given subset of EID space. All I've seen so far to do this effectively boils down to manual configuration, whether explicitly on a Map-Server or just as a mapping of what keys are authorized to advertise which EIDs. A 64-bit (or in some cases 24-bit) nonce is used, apparently as a request/response correlator, but the actual (cryptographic?) properties required from the nonce in the protocol are not clearly covered. In some cryptographic contexts a 64-bit nonce may be too short; I do not believe that this is the case here, but without a clear picture of what the requirements are it's hard to say for sure. 24 bits, on the other hand, is quite small. The layout of the document is somewhat confusing, in a way that could arguably lead to noninteroperable implemnetations. For example, the section on the Map-Register message format includes descriptions of the fields in the records and locators therein, and the section on Map-Notify reuses that portion of the structure, incorporating the field descriptions by reference. But the Map-Register section does not indicate that its descriptions are to apply in both cases, leading to confusing text that talks about values being set or cases that are not possible for a Map-Register (i.e., the section nominally being described). It would be most clear to have a dedicated subsection for the portion of the structure(s) that is being reused, which would allow for the per-field descriptions to clearly indicate in which scope they are defined. But the more minimal change of just indicating that the primary definition will be "dual use" would probably suffice as well. The Map-Reply record/locator descriptions are reused similarly; I made a comment on section 5.4 that lists a specific instance, though I believe the phenomenon is more general. Similarly, there are many instances (some noted in my Comment) where a bidirectional interaction between two xTRs is described, yet the peers are identified as "ITR" and "ETR". This is very confusing when the entity named as "ITR" is described as performing ETR functionality, or vice versa; pedagogically, it would be much better to use non-role-based names for the entities while describing these exchanges. While I see that there is an entire document dedicated to Map-Versioning and thus we do not need to fully cover everything here, I think it is critically important to be clear that there are consistency requirements attached to map versions, as relating to the stability of membership of RLOCs in a given record, etc. (I cannot be very clear hear since I am not entirely confident of the details of the consistency requirements yet.) The Map-Register message format field descriptions includes: Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register messages if no Map-Notify message is expected to acknowledge it. Since the Map-Register message is authenticated, the 'Nonce' field is not currently used for any security function but may be in the future as part of an anti-replay solution. Having the map registrations subject to replay seems like a critical flaw that would allow an attacker to disrupt any sort of mobility situation, even in the presence of LISP-SEC. I cannot see how this protocol could be suitable for Proposed Standard status with such a susceptibility to replay. I think we need more details on the expected Map-Register/Map-Notify and Map-Notify/Map-Notify-Ack message flows. In what cases is the ack not needed, and why? I think we need greater clarity on the 'E' and 'M' bits in the ECM format; more in the Comment section. I am concerned that the extensibility mechanism for ECM encapsulation is insufficiently well specified. Is a registry needed? Will new message types need to Update: this document to indicate the extension? What attributes make a message (un)suitable for encapsulation? Section 8.1 says: o A Negative Map-Reply, with action code of "Natively-Forward", from a Map-Server that is authoritative for an EID-Prefix that matches the requested EID but that does not have an actively registered, more-specific ID-prefix. This document provides no mechanism to establish that a Map-Server is authoritative for a given EID-Prefix, so this entire case is non-actionable. Section 8.2 says: An ETR publishes its EID-Prefixes on a Map-Server by sending LISP Map-Register messages. A Map-Register message includes authentication data, so prior to sending a Map-Register message, the ETR and Map-Server SHOULD be configured with a shared secret or other relevant authentication information. This cannot be a SHOULD if things are to work properly; it has to be MUST. Section 8.2 also says: As developers and operators gain experience with the mapping system, additional, stronger security measures may be added to the registration process. This kind of language for forward-looking guidance indicates that the current security properties are not well-understood by the authors and is inconsistent with Proposed Standard status. Perhaps I am misunderstanding the desired behavior but when Section 8.4 says: To do this, it forwards the unencapsulated Map-Request, with the original ITR RLOC as the source, to the mapping database system. [...] doesn't this carry substantial risk of running afoul of BCP 38 filtering? I think the MUST and SHOULD requirements for implementing cryptographic primitives are generally swapped; the more-secure ones (e.g., HMAC-SHA-256-128) should be MUST, and the legacy algorithms needed for compatibility with existing deployments would be SHOULD. Section 9 currently states: [a]s noted in Section 8.2, a Map-Server SHOULD verify that all EID- Prefixes registered by an ETR match the configuration stored on the Map-Server. I think we need a MUST-level requirement for verifying authorization for a given EID-Prefix, with one way of satisfying the requirement being checking configuration, but allowing for other means as well. In the -15, Section 9 also stated: The currently defined authentication mechanism for Map-Register messages does not provide protection against "replay" attacks by a "man-in-the-middle". Additional work is needed in this area. I don't understand how this sort of statement can be present in a document targetting Proposed Standard status, in effect admitting that there are grave deficiencies in the security posture of the protocol. The -16 has gained some language indicating that LISP-SEC mitigates many attacks in this space, but that is hardly of much use when LISP-SEC is not a mandatory protocol feature. I'm disappointed that there is no Privacy Considerations section, though given that RFC 7835 seems to attempt to disclaim privacy considerations entirely, perhaps I should not be surprised. Tying devices to persistent Endpoint IDentifiers and using them in mobility situations inherently raises privacy concerns. These are not necessarily fatal to a protocol, but they do need to be discussed and the benefits weighed against the costs. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I apologize for the somewhat scattered nature of these comments; there are a lot of them and I was focusing my time more on trying to understand the broader system, and the intended security posture, so they did not get as much clean-up as I would have liked. Map-Reply will typically forward a packet that got a negative reply onto the public internet, adding extra latency to all flows through a LISP-enabled ITR; is that correct? Section 1 Note this document doesn't assume any particular database mapping infrastructure to illustrate certain aspects of Map-Server and Map- Resolver operation, the Mapping Service interface can (and likely will) be used by ITRs and ETRs to access other mapping database systems as the LISP infrastructure evolves. nit: This looks like a comma splice, though I'm not sure I'm parsing everything correctly. Section 2 Use the actual boilerplate from RFC 8174; don't just tack on a new reference to the existing (and without errata fix!) RFC 2119 boilerplate. Section 3 Should the Map-Register message's definition also mention that the Map-Server returns the registered RLOCs in normal Map-Replys? Section 4 A Map-Server is a device that publishes EID-Prefixes in a LISP mapping database on behalf of a set of ETRs. When it receives a Map Request (typically from an ITR), it consults the mapping database to find an ETR that can answer with the set of RLOCs for an EID-Prefix. My understanding from the intro document, etc., was that the ITR generally was not sending Map-Requests directly to Map-Servers, and that rather there was some triangle routing, with the Map-Request going from ITR to Map-Resolver to Map-Server, and the Map-Reply directly from Map-Server to ITR (so "typically one initiated by an ITR" or similar). It's also odd language (to me) to have the Map-Server "consult the mapping database" when the Map-Server comprises part of the mapping database and has local authoritative data. Section 5 Are we really just duplicating the IPv4+UDP and IPv6+UDP packet headers here? Section 5.1 Values in the "Not Assigned" range can be assigned according to procedures in [RFC8126]. Documents that request for a new LISP packet type may indicate a preferred value. 8126 has lots of procedures; generally we use a name to indicate which one is to be followed. Section 5.2 Using the same letter with different case for different flag bits sounds confusing. Lots of potential fun tampering with these flag bits, whether downgrade attacks on features or otherwise mucking around. Source EID address in Map-Request has privacy considerations. If the multiple ITR-RLOC Addresses is soleyl "to give the ETR the option of selecting the destination address from any address family" then there should be a restriction to one ITR address per AFI. (But it's not, so this text should be tweaked to avoid suggesting that it is.) When an EID mask-len smaller than the full length of the given address type is used, what are the values of the bits in the EID-Prefix field that are "masked away"? Leaving unspecified bits like this makes for an easy covert channel, especially so when the protocol messages are not covered by any integrity protection scheme and subject to on-path tampering. Section 5.3 A Map-Request is sent from an ITR when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration. For the initial case, the destination IP address used for the Map-Request is the data packet's destination address (i.e., the destination EID) that had a mapping cache lookup failure. For the latter two cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the Locator-Set of the Map-Cache entry. I seem to be confused by the "destination IP address" bits here. Are we really sending Map-Request UDPgrams from an ITR to the EID destination address that we failed to look up, hoping that some magic in the network will cause it to end up at an ETR or Map-Server that can reply? Or is this talking about how we set the EID-Prefix portion of the Map-Request? The latter two cases do seem to be using RLOCs in a way that I expect, which makes me think I'm confused. Where is the term "Map-Replier" defined? [...] If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- Request. It's unclear how the Map-Replier would detect this, as opposed to just blindly trying to interpret the start of the request records as an ITR-RLOC. An ITR that is configured with mapping database information (i.e., it is also an ETR) MAY optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does not have this mapping in the Map-Cache, it MAY originate a "verifying Map-Request", addressed to the map-requesting ITR and the ETR MAY add a Map-Cache entry. [...] This seems like a place where naming the xTRs not by role would help clarify the flows and the role in which each entity is acting, at each point. [...] If the ETR has a Map-Cache entry that matches the "piggybacked" EID and the RLOC is in the Locator-Set for the entry, then it MAY send the "verifying Map-Request" directly to the originating Map-Request source. If the RLOC is not in the Locator- Set, then the ETR MUST send the "verifying Map-Request" to the "piggybacked" EID. It's probably worth disambiguating that "the RLOC" is the cached RLOC for the EID in the "piggybacked" Map-Reply record. (Of course, there could be more than one cached RLOC for a given EID, so "the" is not really right anyway.) Similarly, "the Locator-Set" could become "the Locator-Set in the piggybacked Map-Reply record". Additionally, and this may just be my confusion, but is "send ... to the piggybacked EID" the right terminology? In my mental model at least, "perform a fresh mapping lookup for the EID in order to send a verifying Map-Request" would be better. Section 5.4 'S' bit, so clearing that bit and dropping the AD trailer allows an attacker to modify the contents. We would perhaps only saved by the bit in 6830bis where if you ask for a secure resolution you have to get one back, but that's not deployable. Nonce: This is a 24-bit value set in a Data-Probe [I-D.ietf-lisp-rfc6830bis] or a 64-bit value from the Map-Request is echoed in this 'Nonce' field of the Map-Reply. When a 24-bit value is supplied, it resides in the low-order 64 bits of the 'Nonce' field. Just a 6830bis reference isn't quite enough to describe this case, I think; don't you need to say that the other 40 bits are used by the mapping implementation? In the ACT field, is the "No-Action" value ever used for Negative Map-Replies? If so, I'm confused what the semantics are supposed to be. Differentiating between Drop/policy and Drop/authentication may open up a side channel for an attacker to learn about authentication or policy information. (But maybe not; this needs more analysis) A: The Authoritative bit, when sent, is always set to 1 by an ETR. What does "when sent" mean? The field is part of the structure; it's always sent. Or is this supposed to be "has value 1 if and only if the Map-Reply is sent by an ETR"? The EID-Prefix entry should probably reuse (or refer to) the text from the Map-Request field, covering length for other AFIs. Also, say what goes on for the bits that are "masked out". I feel like perhaps less could be said about the 'M' priority and weight fields, as what's currently there just leaves me confused about ETR vs. ITR vs. xTR and how this information flow is consumed. p: When this bit is set, an ETR informs the RLOC-Probing ITR that the locator address for which this bit is set is the one being RLOC- probed and may be different from the source address of the Map- Reply. An ITR that RLOC-probes a particular Locator MUST use this Locator for retrieving the data structure used to store the fact that the Locator is reachable. The p-bit is set for a single Locator in the same Locator-Set. If an implementation sets more Exactly one or at most one? than one p-bit erroneously, the receiver of the Map-Reply MUST select the first Locator. The p-bit MUST NOT be set for Locator- First overall or first that sets the p bit? Set records sent in Map-Request and Map-Register messages. Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- AFI' field) assigned to an ETR. Note that the destination RLOC address MAY be an anycast address. A source RLOC can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router) and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID. This is the section on the contents of the Map-Reply message. Why are we talking about source RLOCs? Oh, we're going to refer back to this from other sections for just the "EID-record" portion (a term which is not properly defined). It would be good to mention that up front at the start of this section or the list of fields in the EID-record. Section 5.5 A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID- Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32. Note filling out the /24 with more-specifics that exist in the mapping system. nit: This last sentence is a sentence fragment. Requiring numerical sort of the locators seems to make the "inserted in the middle" case very difficult to reason about, especially relating to synchronization with the data plane and LSBs in data-plane messages. [...] The source address of the Map-Reply is one of the local IP addresses chosen to allow Unicast Reverse Path Forwarding (uRPF) checks to succeed in the upstream service provider. nit: should there be a comma before "chosen"? Section 5.6 Huh, why did I think that Map-Register was always sent encapsulated? The key-ID description is a great example of how to best describe the security properties of a field; thanks! Authentication Data: This is the message digest used from the output "digest" is a term of art and is not appropriate here. Probably best to just say "This is the output of the MAC algorithm." of the MAC algorithm. The entire Map-Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404], and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. It's probably good to explictly clarify that "entire payload" means "from and including the LISP message type field through the end of the last record and its locators". Also, the MUST/RECOMMENDED status seems backwards. I guess referring back to Section 5.4 for the duplicated fields is probably okay, but I would suggest calling out the portions that are only applicable or uniquely handled for the Map-Register message. Section 5.7 [...] An implementation SHOULD retransmit up to 3 times at 3 second retransmission intervals, after which time the retransmission interval is exponentially backed-off for another 3 retransmission attempts. This is underdefined without specifying the exponent base for the exponential backoff. Why is it allowed to Map-Register without requesting a Map-Notify? Section 5.8 An Encapsulated Control Message (ECM) is used to encapsulate control packets sent between xTRs and the mapping database system. Please be explicit about whether all such messages are encapsulated or only some of them. S: This is the Security bit. When set to 1, the field following the 'Reserved' field will have the following Authentication Data format and follow the procedures from [I-D.ietf-lisp-sec]. Could there be some indication of "optional security fields" in the figure? It's a bit odd to have the 'D' bit in the encapsulation as opposed to directly in the Map-Request, though I guess it's a bit late to be changing that. E: This is the to-ETR bit. When set to 1, the Map-Server's intention is to forward the ECM to an authoritative ETR. I think this needs to say more about which message flows this bit is defined for. Presumably the ITR will never use it for sending an encapsulated Map-Request to a Map-Resolver, but there seem to be plenty of places where ECM wrapping is used. M: This is the to-MS bit. When set to 1, a Map-Request is being sent to a co-located Map-Resolver and Map-Server where the message can be processed directly by the Map-Server versus the Map-Resolver using the LISP-DDT procedures in [RFC8111]. How does the sender know that its configured Map-Resolver is also a Map-Server? It's unclear to me why this needs a bit in the message as opposed to just happening based on the attributes of the receiving Map-Server. LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages are allowed to be Control-Plane (ECM) encapsulated. In the future, PIM Join/Prune messages [RFC6831] might be allowed. Encapsulating other types of LISP control messages is for further study. When Map-Requests are sent for RLOC-Probing purposes (i.e., the probe-bit is set), they MUST NOT be sent inside Encapsulated Control Messages. This type of forward-looking language seems unusuabl for a PS document; I would expect to not see predictions on what might happen, but rather the specification of what procedure is used to allow new message types. Section 6.1 Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. [...] Nothing *prevents* ETRs from doing this tracking; they're just not required to do so. So it would be better to say something like "Since ETRs are not required to keep track of [...]". [...] In particular, an ETR will send an SMR to an ITR to which it has recently sent encapsulated data. This can only occur when both ITR and ETR functionality reside in the same router. Having just come from the section on the "encapsulated control message", perhaps the reader could use an extra hint that the "encapsulated data" is just "LISP-tunneled data-plane traffic". Also, is this intended to be a normative requirement (with the use of "will")? 1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each Locator in each Map-Cache entry the ETR caches. Map-Cache is an ITR function; this is probably another case where naming the routers would allow for a more clear description of the protocol exchanges. Also, this seems in disagreement with the previous text about sending data in the previous minute, since Map-Cache entries can persist for longer than a minute. 5. The ETRs at the site with the changed mapping record the fact that the site that sent the Map-Request has received the new mapping data in the Map-Cache entry for the remote site so the Locator-Status-Bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages. Perhaps a nit, but the "site with the changed mapping" doesn't make sense -- the map applies to the EID, and in principle the EID could have moved to a different site. So this could be "the site sending SMR messages" perhaps. Also, I think there needs to be greater clarity about which Locator-Status bits are being described. Finally, the cessation of sending SMR messages is presumably scoped to those targetted to the sender of the Map-Request in question and not a global property? For security reasons, an ITR MUST NOT process unsolicited Map- Replies. To avoid Map-Cache entry corruption by a third party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR-based Map-Request and the source is not in the Locator-Set for the stored Map-Cache entry, then the responding Map- Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is a more secure way to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. The only verification possible in this set of documents does not constitute a security mechanism worthy of the name. Also, allowing off-path attackers to induce requests to the mapping system seems like a DoS vector only partially mitgiated by rate limiting. Section 7 One could perhaps quibble as to whether (1) through (3) constitute "control-plane", vs. "out-of-band" given that this documents the LISP Control-Plane as specific UDP messages. Section 7.1 When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set according to the procedure described in [I-D.ietf-lisp-rfc6830bis]. Please provide a detailed section reference; 6830bis does not specifically cover source address selection for probes. [...] The greatest benefit of RLOC-Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific Locator is reachable or has become unreachable, thus providing a robust mechanism for switching to using another Locator from the cached Locator. nit: "greatest benefit ... handle many failure scenarios" is a strange wording to me. Presumably the failures are not failures of the probing, but rather network failures of some form? Section 8.1 o An immediate Negative Map-Reply (with action code of "Natively- Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if the Map-Resolver can determine that the requested EID does not exist. [...] This seems to be attempting to instill a normative requirement of setting the 15-minute TTL for this case; please use normative language to that effect. [...] If the requested EID matches a more-specific EID-Prefix that has been delegated by the Map-Server but for which no ETRs are currently registered, a 1-minute TTL is returned. If the requested EID matches a non-delegated part of the authoritative EID-Prefix, then it is not a LISP EID and a 15-minute TTL is returned. [...] (Same comment as above about normative language) A Map-Server's configuration SHOULD also include a list of the EID-Prefixes for which each ETR is authoritative. Upon receipt of a Map-Register from an ETR, a Map- Server accepts only EID-Prefixes that are configured for that ETR. I think there also needs to be some text about the ETR and associated Map-Server being part of a single administrative domain. Failure to implement such a check would leave the mapping system vulnerable to trivial EID-Prefix hijacking attacks. As developers As described here, this is essentially relying on local configuration for information about who is authoritative for what EID prefixes, which is prone to becoming stale and does not scale. Section 8.3 If there is no match, the Map- Server returns a Negative Map-Reply with action code "Natively- Forward" and a 15-minute TTL. [...] In light of my comments in section 8.2, perhaps we can consolidate the normative requirements to just one location and have a pointer from the other(s)? If the EID-prefix is either registered or not registered to the mapping system and there is a policy in the Map-Server to have the requestor drop packets for the matching EID-prefix, then a Drop/ Policy-Denied action is returned. [...] In a Map-Server state machine or flow chart, it seems like this policy application would come before even the above checks for negative responses. Should the document reflect that ordering as well? If the EID-prefix is registered or not registered and there is a authentication failure, then a Drop/ Authentication- failure action is returned. [...] I'm confused what kind of authentication failure is possible here -- there does not seem to be any end-to-end client authentication of mapping requests that I have seen in any LISP documents I've read so far. Section 9 To publish an authoritative EID-to-RLOC mapping with a Map-Server, an ETR includes authentication data that is a hash of the message using a pair-wise shared key. [...] "hash" is a term of art and is not appropriate here; please use "MAC". [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin authentication, integrity, anti-replay protection, and prevention of man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- Reply exchange. Work is ongoing on this and other proposals for resolving these open security issues. It only partially mitigates some of those, and for others relies on the mapping system to provide some properties that are not clearly achievable. It is unwise to claim that they are possible absent further clarity on what behavior mapping systems can currently provide. [edit: this text changed in the -16] Section 11.3 In addition, LISP has a number of flag fields and reserved fields, such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New bits for flags in these fields can be implemented after IETF review or IESG approval, but these need not be managed by IANA. How will a prospective implementor know that they have found all defined flags fields? Are documents allocating new ones supposed to Update: this one? Section 11.4 The IANA registry "LISP Canonical Address Format (LCAF) Types" is used for LCAF types, the registry for LCAF types use the Specification Required policy [RFC8126]. [...] nit: comma splice Section 11.5 I would suggest Expert Review rather than FCFS, for such a scarce codepoint space with only 256 total values. From nobody Wed Sep 26 22:28:09 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A37130DEE; Wed, 26 Sep 2018 22:28:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153802608641.21525.4981689568836441403.idtracker@ietfa.amsl.com> Date: Wed, 26 Sep 2018 22:28:06 -0700 Archived-At: Subject: [lisp] Suresh Krishnan's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 05:28:07 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-lisp-rfc6830bis-20: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 7.1. This should be an easy fix but I would like to see it fixed before publication. When talking about IPv6 packets being larger than L, the correct behavior should be to send an ICMPv6 message with Type 2 (Packet Too Big) instead of the Destination Unreachable (Type 1) message as specified in the text. The text *is correct* for IPv4 messages with the DF bit set where the Destination Unreachable (Type 3) is the right kind of message to send. From nobody Thu Sep 27 01:22:32 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5E6130E13 for ; Thu, 27 Sep 2018 01:22:30 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 EpcnnN6LjbKh for ; Thu, 27 Sep 2018 01:22:28 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 8801D130E47 for ; Thu, 27 Sep 2018 01:22:25 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id m16so1532649wrx.12 for ; Thu, 27 Sep 2018 01:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=y4b+LJg63KyIjZjT8sb8JPjP4Lr5dK0DB8R/WBy8PWY=; b=WEN3lImzN6uz+juoe/jX0mq6chjKDKgOtq3L9Nvs8yUs5J6i1pbbx/P9ZwKkeElaRQ LXl2ydpd/kDuNipBRRa2dAeBcPYm9IzdbjPWHeuphdKBFk+FLk5EKwbvxa3y1TsuwBM5 BSIVg8w9Pg1SjfmvsHzt/kHUU+YfI6bvaZhDClKJC07fIB+5RZZGD387gY44IWJlKQXN d/8dxuiISsw02zrrBSSltmtf9kEfXQavPd7txUPFHxBdGIbE1kgHagyktY5AKtpt4gyC PJyLtFHHMfd8vI+6DTzG3cQE7Z0jQiKhIqJFWzDNgtvW1SY8eriWZps7wM+6W0Xr2BQe 6aqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=y4b+LJg63KyIjZjT8sb8JPjP4Lr5dK0DB8R/WBy8PWY=; b=hP1L7DEBSnuDnuEUncf5izsqy3p5qhzdG5NpxKlI9i/qnpsSOSxlMcJAbQtSTU5YCC LNPPKuR0DeXahxIuf5nIIooG/MfoM802XK8RbwE73x01twqDY0xWFRkQ7Rapdxs189Sn MLRDeySWM58mY+CJN6SyFC7Rzz09QEp311VibjzLzBKmDybLRoD46eDv5jJQIgcHnQqp drJMVCK47CuztqLzGXr7bXHw/dLt+DXLNU5PfAC113yrdzNYelSUXSEuB5E5fs6okwYu OhY9QfY/OOAJnX5Ru4080pA5v6J8Uy4qcFENGGseWqpbmzjeQsIcYie6ssZ/L7NtdSM+ l87A== X-Gm-Message-State: ABuFfog3cwp39NoIhpPq0L4+shjhhF/dA1mLwU8rh8qHDaA1rY5N++dh q/AfIgm1ZbJVx20d+6rKHnJgeRF7wtc= X-Google-Smtp-Source: ACcGV61EYm0YO5rpnXuverAjsQ/z+ezQACdAJVvGuoQ7cs21F3KwGzuz7kBspXkEPg6n7we3+N+QvA== X-Received: by 2002:adf:8248:: with SMTP id 66-v6mr1966482wrb.140.1538036543379; Thu, 27 Sep 2018 01:22:23 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:4055:3d23:b247:681d? ([2001:660:330f:a4:4055:3d23:b247:681d]) by smtp.gmail.com with ESMTPSA id z13sm1244532wrw.19.2018.09.27.01.22.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 01:22:21 -0700 (PDT) From: Luigi Iannone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_894F1CBE-9402-45B0-BEBF-FE4C3E8946B8" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Thu, 27 Sep 2018 10:22:24 +0200 In-Reply-To: <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> Cc: lisp-chairs@ietf.org, "BRUNGARD, DEBORAH A" To: "lisp@ietf.org list" References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] Call fo adoption of draft-boucadair-lisp-rfc8113bis-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 08:22:31 -0000 --Apple-Mail=_894F1CBE-9402-45B0-BEBF-FE4C3E8946B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, one week is over and we received several email in support adoption of = this document. Because of such consensus the authors are invited to submit a document = named draft-ietf-lisp-rfc8113bis-00.txt. As soon as the new document is available we will start the WG Last Call, = as already said in my previous mail. Ciao L. > On 19 Sep 2018, at 17:04, Luigi Iannone wrote: >=20 > Folks, >=20 > here is another piece of the work done in our WG that needs to be = moved to PS. >=20 > It is the updated version of RFC 8113, nothing changed just updated = coherently with the current status of the other documents. >=20 > Because this documents is really really short we will have just one = week adoption call followed be one week WG Last Call. >=20 > This email officially starts the one week call for adoption. >=20 > Please spend 10 minutes having a look at the document and send an = email on whether you agree or not to adopt it. >=20 > Thanks >=20 > Ciao >=20 > Luigi >=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt >> Date: 19 September 2018 at 16:49:31 CEST >> To: > >> Reply-To: internet-drafts@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : Locator/ID Separation Protocol (LISP): = Shared Extension Message & IANA Registry for Packet Type Allocations >> Authors : Mohamed Boucadair >> Christian Jacquenet >> Filename : draft-boucadair-lisp-rfc8113bis-01.txt >> Pages : 5 >> Date : 2018-09-19 >>=20 >> Abstract: >> This document specifies a Locator/ID Separation Protocol (LISP) >> shared message type for defining future extensions and conducting >> experiments without consuming a LISP packet type codepoint for each >> extension. >>=20 >> This document obsoletes RFC 8113. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/ = >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01 >> = https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc8113bis-01 >>=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 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 --Apple-Mail=_894F1CBE-9402-45B0-BEBF-FE4C3E8946B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii All,

one = week is over and we received several email in support adoption of this = document.

Because of such consensus the authors are invited to submit a = document named draft-ietf-lisp-rfc8113bis-00.txt.
As soon as the new document is = available we will start the WG Last Call, as already said in my previous = mail.

Ciao

L.


On 19 = Sep 2018, at 17:04, Luigi Iannone <ggx@gigix.net> wrote:

Folks,

here is another piece of = the work done in our WG that needs to be moved to PS.

It is the updated = version of RFC 8113, nothing changed just updated coherently with the = current status of the other documents.

Because this documents is really really = short we will have just one week adoption call followed be one week WG = Last Call.

This = email officially starts the one week call for adoption.

Please spend 10 minutes = having a look at the document and send an email on whether you agree or = not to adopt it.

Thanks

Ciao

Luigi


Begin forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt
Date: 19 September 2018 at 16:49:31 CEST
To: <i-d-announce@ietf.org>
Reply-To: internet-drafts@ietf.org


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


=        Title =           : Locator/ID = Separation Protocol (LISP): Shared Extension Message & IANA Registry = for Packet Type Allocations
=        Authors =         : Mohamed Boucadair
=             &n= bsp;           &nbs= p;Christian Jacquenet
Filename =        : = draft-boucadair-lisp-rfc8113bis-01.txt
Pages =           : 5
= Date =            : = 2018-09-19

Abstract:
=   This document specifies a Locator/ID Separation Protocol = (LISP)
  shared message type for defining = future extensions and conducting
  experiments = without consuming a LISP packet type codepoint for each
=   extension.

  This = document obsoletes RFC 8113.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bi= s/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01<= /a>
https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8= 113bis-01

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc811= 3bis-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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


= --Apple-Mail=_894F1CBE-9402-45B0-BEBF-FE4C3E8946B8-- From nobody Thu Sep 27 01:23:43 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B1F130FBB; Thu, 27 Sep 2018 01:23:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153803662209.26285.475786319362224357.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 01:23:42 -0700 Archived-At: Subject: [lisp] The LISP WG has placed draft-boucadair-lisp-rfc8113bis in state "Adopted by a WG" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 08:23:42 -0000 The LISP WG has placed draft-boucadair-lisp-rfc8113bis in state Adopted by a WG (entered by Luigi Iannone) The document is available at https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/ From nobody Thu Sep 27 01:29:24 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C08D5130E13; Thu, 27 Sep 2018 01:29:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153803696272.26418.15651641592539791468@ietfa.amsl.com> Date: Thu, 27 Sep 2018 01:29:22 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-ecdsa-auth-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 08:29:23 -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 WG of the IETF. Title : LISP Control-Plane ECDSA Authentication and Authorization Authors : Dino Farinacci Erik Nordmark Filename : draft-ietf-lisp-ecdsa-auth-00.txt Pages : 17 Date : 2018-09-24 Abstract: This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-ecdsa-auth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-ecdsa-auth-00 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-ecdsa-auth-00 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 Sep 27 01:57:35 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4861A130E13; Thu, 27 Sep 2018 01:57:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153803864724.26438.15865940929773606926@ietfa.amsl.com> Date: Thu, 27 Sep 2018 01:57:27 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc8113bis-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 08:57:27 -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 WG of the IETF. Title : Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations Authors : Mohamed Boucadair Christian Jacquenet Filename : draft-ietf-lisp-rfc8113bis-00.txt Pages : 5 Date : 2018-09-27 Abstract: This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. This document obsoletes RFC 8113. This document updates I-D.ietf-lisp-rfc6833bis. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc8113bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc8113bis-00 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc8113bis-00 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 Sep 27 02:02:18 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E6E130E55 for ; Thu, 27 Sep 2018 02:02:16 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 Wxd1rt9QfB5y for ; Thu, 27 Sep 2018 02:02:13 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 DC62E130E27 for ; Thu, 27 Sep 2018 02:02:12 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id q8-v6so5148311wmq.4 for ; Thu, 27 Sep 2018 02:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WHXRepqG9bGs9af63q7Gy5rS/4Xk3mvXaG63uSSljoE=; b=K+c99o4BoUwyV0XNnPyaoU2WqiiysWpWoIjVdXPbduzeGinEMdbHcgiWeOO57iQ1mH vLRqryxIpcwO/SMTPsdCL7ASFfvVeOYITARijXl5UGEb3W6qlqWX6Jql6UL/SLKmXVwA G8z5ugc0RAgIadNkCRjL1f9wVFdDly7VejQ15RwEfTcU5OvjwfgMRsgP2yjLJzeGahNt 7qvccxCzLRikw7iPM0KEzA80+3kqALbPGCGGACR6Ew5tmAtGZV6infrww5TdPv+i3+1b Y5AaGuZxc/ymauEcRnXhknQW9P8JEato8fQDAZd24PDay9JBwpnEiHTSAyGQU0/fiYzH 2Png== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WHXRepqG9bGs9af63q7Gy5rS/4Xk3mvXaG63uSSljoE=; b=Woye4Nla8/AcrCZkPgXThIijH/Ss4ouzwXzwGLV5gkfMaFCxhwNaPAYfvLS34DctMJ wJlP+aXefEMCOdApO/RJCEfSX/ADwg6XG01J2A0El9J2Kawza8FICBfICuZ6REjEtfP2 /DE4XKUcjWAa3Xi1skQch7asE/Ts5UcUI2IbOwpbfjAuwKsmn0FN3gkV4Sc00SfMc+11 TBpG4muvW2ouwjp7Ma3YTBu+UH3p0S0/WKxiJTLXyIZfp2oCu5zrxEYjGRABSNYfSYES +1PMQtOIwpAQSHmQGdHsT629SqLoGrPG+oBN52FOtWCYtIcJkkKMBMxGZBRW717Ax/Js Ep/w== X-Gm-Message-State: ABuFfoi1sU0Mkc4JSCoAQbFiE0GJjurvgMKnGmkmjG08qaASMsGN/NX4 KRPJ3GP2JpJgGUw7pu+gAfyi00Omv6Q= X-Google-Smtp-Source: ACcGV61x89iY0TnDVU5EqobvK+BXJ4r9vOnp+SCDSYb3ogn5BvhE25AlqzV3QIySOs9S6Xsfs0BMuQ== X-Received: by 2002:a1c:5e08:: with SMTP id s8-v6mr7354926wmb.88.1538038930857; Thu, 27 Sep 2018 02:02:10 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:4055:3d23:b247:681d? ([2001:660:330f:a4:4055:3d23:b247:681d]) by smtp.gmail.com with ESMTPSA id g129-v6sm2311303wmf.42.2018.09.27.02.02.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 02:02:09 -0700 (PDT) From: Luigi Iannone Message-Id: <44201301-8E2D-4649-8483-5418A8CFC138@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_69CE01E5-FAA7-45F1-98D6-519713A65150" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Thu, 27 Sep 2018 11:02:12 +0200 In-Reply-To: Cc: lisp-chairs@ietf.org, "BRUNGARD, DEBORAH A" To: "lisp@ietf.org list" References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: [lisp] WGLC fo draft-ietf-lisp-rfc8113bis-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 09:02:16 -0000 --Apple-Mail=_69CE01E5-FAA7-45F1-98D6-519713A65150 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Well, Authors were pretty quick =E2=80=A6 This email open the one week WG Last Call for the document = draft-ietf-lisp-rfc8113bis-00.txt Please review this 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. Ciao L. > On 27 Sep 2018, at 10:22, Luigi Iannone wrote: >=20 > All, >=20 > one week is over and we received several email in support adoption of = this document. >=20 > Because of such consensus the authors are invited to submit a document = named draft-ietf-lisp-rfc8113bis-00.txt. >=20 > As soon as the new document is available we will start the WG Last = Call, as already said in my previous mail. >=20 > Ciao >=20 > L. >=20 >=20 >> On 19 Sep 2018, at 17:04, Luigi Iannone > wrote: >>=20 >> Folks, >>=20 >> here is another piece of the work done in our WG that needs to be = moved to PS. >>=20 >> It is the updated version of RFC 8113, nothing changed just updated = coherently with the current status of the other documents. >>=20 >> Because this documents is really really short we will have just one = week adoption call followed be one week WG Last Call. >>=20 >> This email officially starts the one week call for adoption. >>=20 >> Please spend 10 minutes having a look at the document and send an = email on whether you agree or not to adopt it. >>=20 >> Thanks >>=20 >> Ciao >>=20 >> Luigi >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> Subject: I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt >>> Date: 19 September 2018 at 16:49:31 CEST >>> To: > >>> Reply-To: internet-drafts@ietf.org >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>=20 >>>=20 >>> Title : Locator/ID Separation Protocol (LISP): = Shared Extension Message & IANA Registry for Packet Type Allocations >>> Authors : Mohamed Boucadair >>> Christian Jacquenet >>> Filename : draft-boucadair-lisp-rfc8113bis-01.txt >>> Pages : 5 >>> Date : 2018-09-19 >>>=20 >>> Abstract: >>> This document specifies a Locator/ID Separation Protocol (LISP) >>> shared message type for defining future extensions and conducting >>> experiments without consuming a LISP packet type codepoint for = each >>> extension. >>>=20 >>> This document obsoletes RFC 8113. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/ = >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01 = >>> = https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc8113bis-01= >>>=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 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >=20 --Apple-Mail=_69CE01E5-FAA7-45F1-98D6-519713A65150 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Well,

Authors were pretty quick =E2=80=A6

This email open the one week WG Last = Call for the document draft-ietf-lisp-rfc8113bis-00.txt

Please review this 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.

Ciao

L.

On 27 Sep 2018, at 10:22, Luigi = Iannone <ggx@gigix.net> wrote:

All,

one week is over and we received = several email in support adoption of this document.

Because of such = consensus the authors are invited to submit a document named = draft-ietf-lisp-rfc8113bis-00.txt.

As soon as the new document is = available we will start the WG Last Call, as already said in my previous = mail.

Ciao

L.


On 19 = Sep 2018, at 17:04, Luigi Iannone <ggx@gigix.net> wrote:

Folks,

here is another piece of = the work done in our WG that needs to be moved to PS.

It is the updated = version of RFC 8113, nothing changed just updated coherently with the = current status of the other documents.

Because this documents is really really = short we will have just one week adoption call followed be one week WG = Last Call.

This = email officially starts the one week call for adoption.

Please spend 10 minutes = having a look at the document and send an email on whether you agree or = not to adopt it.

Thanks

Ciao

Luigi


Begin forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt
Date: 19 September 2018 at 16:49:31 CEST
To: <i-d-announce@ietf.org>
Reply-To: internet-drafts@ietf.org


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


=        Title =           : Locator/ID = Separation Protocol (LISP): Shared Extension Message & IANA Registry = for Packet Type Allocations
=        Authors =         : Mohamed Boucadair
=             &n= bsp;           &nbs= p;Christian Jacquenet
Filename =        : = draft-boucadair-lisp-rfc8113bis-01.txt
Pages =           : 5
= Date =            : = 2018-09-19

Abstract:
=   This document specifies a Locator/ID Separation Protocol = (LISP)
  shared message type for defining = future extensions and conducting
  experiments = without consuming a LISP packet type codepoint for each
=   extension.

  This = document obsoletes RFC 8113.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bi= s/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01<= /a>
https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8= 113bis-01

A diff from the previous = version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc811= 3bis-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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt



= --Apple-Mail=_69CE01E5-FAA7-45F1-98D6-519713A65150-- From nobody Thu Sep 27 04:38:52 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 281FD130E64; Thu, 27 Sep 2018 04:38:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-lisp-gpe@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153804833115.26433.10640728868047419094.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 04:38:51 -0700 Archived-At: Subject: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-gpe-06: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 11:38:51 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lisp-gpe-06: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [Unlike for the 683xbis documents, this is a more mundane Discuss, with one process issue and one issue of clarity with respect to randomness requirements, that should be fairly easy to resolve.] I think that 8060 needs to be a normative reference; it seems to be needed to implement the Multiple Data-Planes LCAF type. Arguably 6040 also should be, though that seems less clear-cut to me. (8060 would be a new normative downref and require another IETF LC, IIUC.) Section 3 notes: The encoding of the Nonce field in LISP-GPE, compared with the one used in [I-D.ietf-lisp-rfc6830bis] for the LISP data plane encapsulation, reduces the length of the nonce from 24 to 16 bits. As per [I-D.ietf-lisp-rfc6830bis], Ingress Tunnel Routers (ITRs) are required to generate different nonces when sending to different Routing Locators (RLOCs), but the same nonce can be used for a period of time when encapsulating to the same Egress Tunnel Router (ETR). The use of 16 bits nonces still allows an ITR to determine to and from reachability for up to 64k RLOCs at the same time. That seems to be missing the point of the nonce -- it's not just for unique identification but also to prevent off-path attackers from guessing a valid value and spoofing a bogus map-reply! Using the entire 64k of nonce space means that such a spoofing attack can succeed pretty reliably (e.g., by over-claiming so that the response EID-prefix contains whatever the request was for). I think it's important to accurately describe what properties are required of indivdiual nonces and the combined set of active nonces, which this text seems to mischaracterize. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 LISP-GPE MAY also be used to extend the LISP Data-Plane header, that has allocated all by defining a Next Protocol "shim" header that nit: allocated all of what? Section 3 This is not exactly the responsibility of LISP-GPE merely because it allocates the last bit in this bitmap, but it seems like it would be quite useful to have a table of which combinations of values are valid vs. nonsensical, given the somewhat complicated interaction between some of these flag bits. Similarly, the encoding of the Source and Dest Map-Version fields, compared with [I-D.ietf-lisp-rfc6830bis], is reduced from 12 to 8 bits. This still allows to associate 256 different versions to each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping to inform commmunicating ITRs and ETRs about modifications of the mapping. Are we limited to 256 versions total, or is there some sort of larger version space that we truncate to send (a la a wraparound process)? I understand that map-versioning is primarily in a separate document but it seems important for this document to describe to what extent it is limiting functionality. Section 3.1 To ensure that protocols that are encapsulated in LISP-GPE will work well from a transport interaction perspective, the specification of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion Notification (ECN) bits whenever they apply to the new encapsulated payload. This MUST is duplicated in the next three paragraphs; I would suggest leaving this introduction as non-normative, with something like "needs to contain an analysis of how LISP-GPE will deal with [...]" Also, nit: "the outer UDP Checksum" Section 4 When encapsulating IP packets to a non LISP-GPE capable router the P-bit MUST be set to 0. [...] A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the P-bit set to 1) to a non-LISP-GPE capable router. I'm failing to see how these two sentences are not redundant. Section 5.1 Just to be clear, the intent is that if there is some non-IETF protocol that we want to encapsulate, we write a two-page Standards-Track RFC that says "this GPE codepoint means to do what this non-IETF document says"? Section 6 However, the use of common anti-spoofing mechanisms such as uRPF prevents this form of attack. I think "mitigates" is probably better than "prevents" in this case. LISP-GPE, as many encapsulations that use optional extensions, is subject to on-path adversaries that by manipulating the g-Bit and the packet itself can remove part of the payload. Typical integrity protection mechanisms (such as IPsec) SHOULD be used in combination with LISP-GPE by those protocol extensions that want to protect from on-path attackers. The g-Bit is present in the Map-Reply message, which can in the general case be sent via triangle-routing, in which case the establishment and selection of IPsec security associations is somewhat nontrivial and probably does not quality as "typical", based on my limited experience. I think a more general scheme for providing integrity protection for mapping messages is needed as a mandatory mechanism, but that's a topic for the control-plane document so I will not belabor it here. From nobody Thu Sep 27 05:16:14 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C71128CE4; Thu, 27 Sep 2018 05:16:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 05:16:00 -0700 Archived-At: Subject: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 12:16:01 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-lisp-rfc6833bis-16: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This DISCUSS is somewhat arbitratrily on 6833bis, but many of the same issues apply to 6830bis. I concur with Ben's DISCUSS. I do not believe that these documents have adequate security to advance to Proposed Standard. I thought it might be helpful for me to lay out my starting assumptions and threat model and what I think the appropriate standard is here. That gives us an opportunity to discuss them prior to getting into the specific security issues I raise below. SYSTEM ARCHITECTURE Per offline discussion, I understand that despite some of the introductory material, LISP is not currently intended to be Internet scale but rather to run in what seem to be fairly tightly controlled environments. Thus, I am assuming the following facts about the system: - The Mapping Service itself is secure and trusted. For the purposed of this discussion, I'm modelling all the entities in the services as one trusted element. - The ETRs have a preconfigured relationship with the Mapping Service, which includes some sort of shared key and an ACL on the Mapping Service which tells it which EIDs anm ETR can advertise. How this gets established is out of scope of this discussion. Note that neither of these assumptions would be reasonable in an Internet scale system, but I'm assuming that the text about that in these documents will be removed. Because it's not in the document set before us, nor is it a normative reference, I am disregarding LISP-SEC and only analyzing the system as specified in these documents. THREAT MODEL I'm assuming the usual RFC 3552 threat model, I.e., - All non-Map Server elements in the system (specifically, endpoints and the xTRs are potentially malicious). - Aside from the links between the Map Server elements, the network is controlled by the attacker. Against this background, my expectation is that the attacker should not be able to affect traffic in any fashion significantly more effective than tampering with the data plane. For instance, it's clearly the case that an on-path attacker between two xTRs can drop all the packets or forward them to some third xTR, but it should not be able to send a small number of packets which would then affect the routing of a large number of packets. I do not expect that the data plane should have better security than native (non-IPsec) traffic. Given the nature of LISP and the existence of a mapping system, it seems like it's kind of a missed opportunity to deploy a credentials system that would support IPsec-style data plane security, but given that this isn't a generally safe assumption for IP traffic, and therefore you need to provide some sort of transport or application security anyway, I don't think it's the right standard to hold LISP to. ATTACKS LISP appears to be vulnerable to a number of routing attacks that I claim above it should not be subject to. For example: 1. An on-path attacker can forge Map Replys to the ITR, thus redirecting traffic. 2. An ETR can perform an "overclaiming" attack in which it claims to be responsible for EIDs which it is not actually responsible for. 3. An off-path attacker can temporarily reroute traffic by exploiting the "gleaning" feature to cache poison an ITR. In addition, the "echo noncing" feature does not appear to have a sufficiently strong nonce to protect against forgery, and thus turning this into a long-term attack 4. An attacker may be able to perform a number of cache invalidation and contamination attacks by exploiting the Map-Version and Locator-Status bits. This may lead to DoS. 5. An attacker who was at time T responsible for an EID block can probably prolong its ability to respond for that block even after it is no longer responsible. 6. A number of the components appear to be subject to various replay attacks. I note that many of these attacks are documented in the Security Considerations for these documents. Also, I doubt this list is exhaustive. As noted above, I have spent no time on the data plane protocol. DEFENSES When looking at attacks, it's important to determine whether there are plausible defenses. For most of these, I believe that the answer is "yes", at varying levels of cost. As noted above, LISP-SEC appears to be intended to address a number of these issues, so it's possible that requiring LISP-SEC would go a fair ways towards addressing these issues. A cursory look at LISP-SEC turns up some somewhat concerning design choices, so I would have to examine it more closely to give a real opinion. I do not believe that LISP-SEC will address the attacks that do not involve the Mapping Server. For instance, the gleaning contamination/nonce attacks (3) would not appear to be fixed by LISP-SEC. However, it's probably possible to fix them by lengthening the nonce. With that said, I tend to think that the overall authentication architecture here would benefit from a rethink. At a high level, the source of most of these problems is the "non-transferability" of the mapping information from the Map Server. If the Map Server instead had an asymmetric key pair which it used to sign mappings, then almost all of these attacks would not work. Specifically: - The map server could send signed Map Replys so forgery wouldn't work - Map Replys from ETRs would be signed, so you couldn't overclaim - Gleaning attacks would sort of work, but because the probe would elicit a Map Reply, you couldn't persist them - Map Versions could be tied to signed objects, so you couldn't do cache invalidation by version. You'd probably need some other approach for Locator Status bits. And so on. Detailed review below, with some duplication.... Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4115 IMPORTANT S 5.2. > s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is > sending a Map-Request in response to a received SMR-based Map- > Request. > > m: This is the LISP mobile-node m-bit. This bit is set by xTRs that > operate as a mobile node as defined in [I-D.ietf-lisp-mn]. This would appear to create a normative reference to this document. To avoid that, you need to specify how I behave if I receive it but I don't implement lisp-mn. S 5.2. > m: This is the LISP mobile-node m-bit. This bit is set by xTRs that > operate as a mobile node as defined in [I-D.ietf-lisp-mn]. > > I: This is the xTR-ID bit. When this bit is set, what is appended to > the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage > procedures in [I-D.ietf-lisp-pubsub] for details. here too you seem to be creating a normative reference. S 5.5. > is being mapped from a multicast destination EID. > > 5.5. EID-to-RLOC UDP Map-Reply Message > > A Map-Reply returns an EID-Prefix with a prefix length that is less > than or equal to the EID being requested. The EID being requested is How do I behave if I receive an EID-Prefix that is less than any of my mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16 and someone asks me for 10.0.0.0/8? Also, when you talk about prefix length, I assume you mean the length fo the mask? S 5.6. > Authentication Data: This is the message digest used from the output > of the MAC algorithm. The entire Map-Register payload is > authenticated with this field preset to 0. After the MAC is > computed, it is placed in this field. Implementations of this > specification MUST include support for HMAC-SHA-1-96 [RFC2404], > and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. What prevents replay attacks here? I'm guessing it's the Map-Version- Number, but as I understand it, I can set this to 0. S 6.1. > receives an SMR-based Map-Request and the source is not in the > Locator-Set for the stored Map-Cache entry, then the responding Map- > Request MUST be sent with an EID destination to the mapping database > system. Since the mapping database system is a more secure way to > reach an authoritative ETR, it will deliver the Map-Request to the > authoritative source of the mapping data. If I'm understanding this correctly, this allows an ETR to prevent an ITR from learning that it is no longer the appropriate ETR for a prefix. The way this attack works is that before the topology shift, I send SMRs, thus causing Map-Requests, which, because my entry is cached, refresh the cache on the ITR past the topology shift. I can keep doing this indefinitely. Am I missing something S 8.2. > authentication data, so prior to sending a Map-Register message, the > ETR and Map-Server SHOULD be configured with a shared secret or other > relevant authentication information. A Map-Server's configuration > SHOULD also include a list of the EID-Prefixes for which each ETR is > authoritative. Upon receipt of a Map-Register from an ETR, a Map- > Server accepts only EID-Prefixes that are configured for that ETR. How does it know? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 5. > \ | UDP Length | UDP Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | LISP Message | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What do these two diagrams correspond to? v4 and v6? This needs explanation. S 5.2. > Type: 1 (Map-Request) > > A: This is an authoritative bit, which is set to 0 for UDP-based Map- > Requests sent by an ITR. It is set to 1 when an ITR wants the > destination site to return the Map-Reply rather than the mapping > database system. I don't understand this sentence, as literally it would say that you should not return "the mapping database system" but that doesn't make any sense. S 5.2. > P: This is the probe-bit, which indicates that a Map-Request SHOULD > be treated as a Locator reachability probe. The receiver SHOULD > respond with a Map-Reply with the probe-bit set, indicating that > the Map-Reply is a Locator reachability probe reply, with the > nonce copied from the Map-Request. See RLOC-Probing Section 7.1 > for more details. How am I supposed to handle this if I am a Map Server. S 5.2. > receipt. > > L: This is the local-xtr bit. It is used by an xTR in a LISP site to > tell other xTRs in the same site that it is part of the RLOC-set > for the LISP site. The L-bit is set to 1 when the RLOC is the > sender's IP address. Is the xTR supposed to filter this on exiting the site. S 5.2. > > Nonce: This is an 8-octet random value created by the sender of the > Map-Request. This nonce will be returned in the Map-Reply. The > security of the LISP mapping protocol critically depends on the > strength of the nonce in the Map-Request message. The nonce > SHOULD be generated by a properly seeded pseudo-random (or strong This seems like it needs to be a MUST. S 5.3. > originating Map-Request source. If the RLOC is not in the Locator- > Set, then the ETR MUST send the "verifying Map-Request" to the > "piggybacked" EID. Doing this forces the "verifying Map-Request" to > go through the mapping database system to reach the authoritative > source of information about that EID, guarding against RLOC-spoofing > in the "piggybacked" mapping data. This text here doesn't seem compatible with either of the two cases listed in "EID-prefix" above. S 5.4. > > Nonce: This is a 24-bit value set in a Data-Probe > [I-D.ietf-lisp-rfc6830bis] or a 64-bit value from the Map-Request > is echoed in this 'Nonce' field of the Map-Reply. When a 24-bit > value is supplied, it resides in the low-order 64 bits of the > 'Nonce' field. Nit: a 64-bit quantity doesn't really have low-order bits if it's not numeric. Do you mean "rightmost"? Also, what are the other bits. S 5.4. > 'Nonce' field. > > Record TTL: This is the time in minutes the recipient of the Map- > Reply will store the mapping. If the TTL is 0, the entry MUST be > removed from the cache immediately. If the value is 0xffffffff, > the recipient can decide locally how long to store the mapping. Am I supposed to merge this with previous mappings? REmove them? S 8.3. > of the mapping database protocols. > > 8.3. Map-Server Processing > > Once a Map-Server has EID-Prefixes registered by its client ETRs, it > can accept and process Map-Requests for them. This section is confusing because the introduction says that this function is only performed by Map-Resolvers: ' "The LISP Mapping Service defines two new types of LISP-speaking devices: the Map-Resolver, which accepts Map-Requests from an Ingress Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a mapping database; and the Map-Server, which learns authoritative EID- to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes them in a database." From nobody Thu Sep 27 05:18:02 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FE7130DCC; Thu, 27 Sep 2018 05:18:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 05:18:00 -0700 Archived-At: Subject: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 12:18:01 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-lisp-rfc6830bis-20: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3126 See my DISCUSS on 6833bis for overall issues. This is just detailed issues on 6830bis as I went through it. DETAIL S 4.1. > RLOC (outer-header source IP address) in a received LISP packet. > Such a cache entry is termed a "glean mapping" and only contains > a single RLOC for the EID in question. More complete information > about additional RLOCs SHOULD be verified by sending a LISP Map- > Request for that EID. Both the ITR and the ETR MAY also > influence the decision the other makes in selecting an RLOC. This seems like it introduces an immediate overclaiming problem. S 10. > When an ETR decapsulates a packet, it will check for any change in > the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the > ETR, if acting also as an ITR, will refrain from encapsulating > packets to an RLOC that is indicated as down. It will only resume > using that RLOC if the corresponding Locator-Status-Bit returns to a > value of 1. Locator-Status-Bits are associated with a Locator-Set This seems to enable a pretty obvious denial of service attack in which you send a message with all LSBs set to 0. S 10. > list returned by the last Map-Reply will be set to zero for that > particular EID-Prefix. Refer to Section 16 for security related > issues regarding Locator-Status-Bits. > > When an ETR decapsulates a packet, it knows that it is reachable from > the encapsulating ITR because that is how the packet arrived. In It doesn't even know this. It just knows that that's been claimed by someone who can generate traffic to it. S 10.1. > NOT use the lack of return traffic as an indication that the ETR is > unreachable. Instead, it MUST use an alternate mechanism to > determine reachability. > > 10.1. Echo Nonce Algorithm > This mechanism seems sufficient to verify unreachability but is not a secure test of reachability because the nonce is way too short. S 16. > Map-Versioning is a Data-Plane mechanism used to signal a peering xTR > that a local EID-to-RLOC mapping has been updated, so that the > peering xTR uses LISP Control-Plane signaling message to retrieve a > fresh mapping. This can be used by an attacker to forge the map- > versioning field of a LISP encapsulated header and force an excessive > amount of signaling between xTRs that may overload them. Can't I also set a super-high version number, thus gagging updates? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 5.3. > header. > > When doing ETR/PETR decapsulation: > > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > the case of IPv6) SHOULD be copied from the outer-header 'Time to This should probably be a MUST because there are other protocols that assume that TTLs get decremented. S 7.1. > destination site. The two fragments are reassembled at the > destination host into the single IP datagram that was originated by > the source host. Note that reassembly can happen at the ETR if the > encapsulated packet was fragmented at or after the ITR. > > This behavior MAY be performed by the ITR only when the source host Nit: I think you want to say MUST be, assuming you mean that you can perform it only if.... S 7.2. > 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet > with the DF bit set to 1, exceeds what the core network can > deliver, one of the intermediate routers on the path will send an > ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/ > Fragmentation-Needed to the ITR, respectively. The ITR will > parse the ICMP message to determine which Locator is affected by What if you are in an environment where ICMP is blocked? S 9. > outside of the subset list if it determines that the subset list > is unreachable (unless RLOCs are set to a Priority of 255). Some > sharing of control exists: the server-side determines the > destination RLOC list and load distribution while the client-side > has the option of using alternatives to this list if RLOCs in the > list are unreachable. How would you obtain alternative RLOCs? S 10. > also acting as an ITR and has traffic to return to the original > ITR site, it can use this status information to help select an > RLOC. > > 2. When an ETR receives an encapsulated packet from an ITR, the > source RLOC from the outer header of the packet is likely up. What does "is likely up" mean? From nobody Thu Sep 27 05:23:04 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 435C3130DFF; Thu, 27 Sep 2018 05:22:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153805097526.26380.13580308305182872824.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 05:22:55 -0700 Archived-At: Subject: [lisp] Alexey Melnikov's No Objection on draft-ietf-lisp-rfc6830bis-20: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 12:22:56 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-lisp-rfc6830bis-20: No Objection 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share many of the security related concerns raised by Benjamin. The document is otherwise readable. I have one specific question: 12. Routing Locator Hashing When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is stored in the Map-Cache of a requesting ITR, the Locator-Set for the EID-Prefix MAY contain different Priority and Weight values for each locator address. When more than one best Priority Locator exists, the ITR can decide how to load-share traffic against the corresponding Locators. The following hash algorithm MAY be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping: 1. Either a source and destination address hash or the traditional 5-tuple hash can be used. The traditional 5-tuple hash includes the source and destination addresses; source and destination TCP, UDP, or Stream Control Transmission Protocol (SCTP) port numbers; and the IP protocol number field or IPv6 next-protocol fields of a packet that a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash. Ok, maybe this is just me, but you don't actually define how to hash these things, you are only talking about what needs to be covered by the hash. I appreciate that picking a specific hashing algorithm is probably not relevant for interoperability, but I feel adding a specific algorithm (as an example or via a pointer) would improve the document. From nobody Thu Sep 27 06:14:00 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEB7130E85; Thu, 27 Sep 2018 06:13:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153805403943.26537.10169153194287970368.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 06:13:59 -0700 Archived-At: Subject: [lisp] Alissa Cooper's No Objection on draft-ietf-lisp-rfc6830bis-20: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 13:13:59 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-lisp-rfc6830bis-20: No Objection 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I unfortunately ran out of time to do more than a cursory review of the LISP documents on this week's telechat. My apologies. I find the SEC ADs' DISCUSS positions concerning, though, and support the resolution of their security concerns. Section 15 of RFC 6830 lists a number of open issues and areas for future work. It seems like at least some of these are not addressed in this round of document updates. I would have expected some more explicit discussion of how the bis document addresses those areas, or why it does not need to. I'm curious why there are several authors listed with an affiliation (Cisco) who no longer have that affiliation AFAIK. From nobody Thu Sep 27 06:17:36 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 196D2130E86; Thu, 27 Sep 2018 06:17:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153805424909.26271.13091674207718282821.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 06:17:29 -0700 Archived-At: Subject: [lisp] Alissa Cooper's No Objection on draft-ietf-lisp-rfc6833bis-16: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 13:17:29 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-lisp-rfc6833bis-16: No Objection 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As with 6830bis, I unfortunately ran out of time to do more than a cursory review of the LISP documents on this week's telechat. Here too I find the SEC ADs' DISCUSS positions concerning and support the resolution of their security concerns. I'm curious why there are several authors listed with an affiliation (Cisco) who no longer have that affiliation AFAIK. From nobody Thu Sep 27 06:18:23 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6D1130E99; Thu, 27 Sep 2018 06:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=NCOD99At; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=puTd6S8V 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 EMnc6jUPudgQ; Thu, 27 Sep 2018 06:18:20 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B73130E98; Thu, 27 Sep 2018 06:18:20 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DE63921FF0; Thu, 27 Sep 2018 09:18:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 27 Sep 2018 09:18:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=D8S9W4HXBypTm134XRrfz3WHhV5OQ Uxu+JKHUhkU4IE=; b=NCOD99Atu4k+JfEERiENzkJvPGwx5dSmTZd4E6RnX622z OM4XZik5sHYRRaT0BH3Jf+e75ZtZJwxdkM8EnMCWlY9SVaxgSD8sfXNROp14GBxj K1hvl01cKSFZJebDnRQNtbg4WZQlbUAdU+xv7vl98LC3DlofYMvzKF79YsaEeb1a iZ8ETLnZA5c2P8PKy90gS+YjwkjGQ0qvgjBuFLVta/VQKZxdPY7RjK+IABMtr138 2EB8QI/W9NVHYWNvZ1RzAUXAphzAEqGaqc5Ld4vuSFrkB+CQf+bDHgUF6fxot43o nNmBS1n9FvtqRsQ2Yi5D07AEdoPWNsEKMkfv6l/Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=D8S9W4 HXBypTm134XRrfz3WHhV5OQUxu+JKHUhkU4IE=; b=puTd6S8ViZQoZw7n5I/5Cl Ch9vRtxI+w1QMc4DKaT34qx6MKvWu/PjDNR1rwV0Qu9YbwXJ5IBkzXSFudi6o95h yNqz0rTKYxKTaNWH1H1DJKyR+7e/QUOwq3jyeGeJ8paJrC94Qu527vaIhHk+IJsm HTyvQp+C28c5k+8RRN2pKk3LxS7q5F5ODhJ9LpPzZ/13rUsWkTNS3k1ScnkYzCRq OmdN+RWGw0Z6uzqh0dL6252dgPbNLtBv/zZ9PBb1BDi2HVuthVHT6RSiZyexJOn1 hoAY0P1BhfVptyg/A6dJwEop5n56oCNIurzUHljF8121qHW+5d4qy1TZm/W7eiSg == X-ME-Proxy: X-ME-Sender: Received: from [10.71.5.33] (unknown [8.25.222.2]) by mail.messagingengine.com (Postfix) with ESMTPA id 1DA4CE405E; Thu, 27 Sep 2018 09:18:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: Date: Thu, 27 Sep 2018 06:18:32 -0700 Cc: General Area Review Team , draft-ietf-lisp-rfc6833bis.all@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <583DBDB5-88B0-42FD-B9C3-0E460FCDA14B@cooperw.in> References: <153739126898.21452.4751492511227758945@ietfa.amsl.com> To: Dino Farinacci , Pete Resnick X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] [Gen-art] Genart telechat review of draft-ietf-lisp-rfc6833bis-15 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 13:18:22 -0000 Pete, thanks for your reviews. Dino, thanks for your responses. I have = entered a No Objection ballot. Alissa > On Sep 19, 2018, at 2:16 PM, Dino Farinacci = wrote: >=20 > Thanks again Pete for all your effort.=20 >=20 > Dino >=20 >> On Sep 19, 2018, at 2:07 PM, Pete Resnick = wrote: >>=20 >> Reviewer: Pete Resnick >> Review result: Ready >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please wait for direction from your >> document shepherd or AD before posting a new version of the draft. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-lisp-rfc6833bis-15 >> Reviewer: Pete Resnick >> Review Date: 2018-09-19 >> IETF LC End Date: 2018-08-31 >> IESG Telechat date: 2018-09-27 >>=20 >> Summary: Ready >>=20 >> Major issues: None. >>=20 >> Minor issues: None. >>=20 >> Nits/editorial comments: None. Thanks for all of the cleanup based on = my previous review. >>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Sep 27 06:27:38 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCBE130E90; Thu, 27 Sep 2018 06:27:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153805484850.26528.17792859473676071054.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 06:27:28 -0700 Archived-At: Subject: [lisp] Alexey Melnikov's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 13:27:29 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-lisp-rfc6833bis-16: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a list of smaller points that should be relatively easy to address. The two main ones: I believe [I-D.ietf-lisp-sec] needs to be a Normative Reference for this document. This will address some of the issues raised by Benjamin, but will also make description of various security bits meaningful. Similarly, in Section 5.6: I: This is the xTR-ID bit. When this bit is set, what is appended to the Map-Register is a 128-bit xTR router-ID and then a 64-bit site-ID. See LISP NAT-Traversal procedures in [I-D.ermagan-lisp-nat-traversal] for details. This description makes [I-D.ermagan-lisp-nat-traversal] a normative reference. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Abstract By using this Control-Plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems, which facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP Control-Plane infrastructure, connect directly to LISP-capable Internet end sites, and comprising the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. The last sentence: I've reread it several times and still not sure what it says. I suggest rewording, possibly breaking up into shorter sentences. In Section 5.1 the acronym SMR is used before it is defined (It is defined on the next page). In 5.2: A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. It is set to 1 when an ITR wants the destination site to return the Map-Reply rather than the mapping database system. This sentence seems to be missing a word at the end, because you don't return "the mapping database system". In Section 5.6: T: This is the use-TTL for timeout bit. When set to 1, the xTR wants the Map-Server to time out registrations based on the value in the "Record TTL" field of this message. And what happens when it is 0? 11.4. LISP Address Type Codes Therefore, there is no longer a need for the "LISP Address Type Codes" registry requested by [RFC6830]. This document requests to remove it. IANA registries are not supposed to be removed, they typically declared closed when not needed. Can you elaborate of whether this registry was ever used? From nobody Thu Sep 27 06:28:02 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D306E130E86; Thu, 27 Sep 2018 06:27:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-lisp-gpe@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153805487385.26290.14227373548139794294.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 06:27:53 -0700 Archived-At: Subject: [lisp] Alissa Cooper's Discuss on draft-ietf-lisp-gpe-06: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 13:27:54 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-lisp-gpe-06: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- In the thread with the Gen-ART reviewer, the rationale that was given for advancing this document now even though rfc6834bis is nascent was: "We do not expect big changes in any bis document, since they are just the PS version of deployed technology." This seems somewhat less likely given the feedback received on the LISP documents on the telechat this week, so I'd like to discuss whether it really makes sense to advance this one now given its normative dependencies on 6834bis and 6830bis. From nobody Thu Sep 27 06:28:37 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A1F130E9E; Thu, 27 Sep 2018 06:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=qXS6n3di; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ruVCc2Qh 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 E8ZFIsEz_YkY; Thu, 27 Sep 2018 06:28:29 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C4B130E90; Thu, 27 Sep 2018 06:28:29 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2299121B88; Thu, 27 Sep 2018 09:28:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 27 Sep 2018 09:28:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=QKUeWeRtfRO+iiaxiaFiOWhFM+TzTOqy2T5AFOq6JMY=; b=qXS6n3di KGv/WNQz/VFoDKDg7H5BRUjrdRDIZtZjM5DUBiMhSwq6Zvqrep/XX9AuqHfaWZpp Dl0avloM7ZBdQBpyfGKbZKcdB+VopHPHLU1PoQlJek4g6EelMM9DUikIsjd+nWSq pjfVfaipwGQVXj5mz7X29aBaNIBkfNfx6dxA8EcLakn223jV923Sl3BNn1Uj+gI6 f6jpZ7wsEVn/v5w1SISAagl8NG3e7gSCQA019uyNG6W211mBdbQKURiA7rWkpVwF EJ1y3bEzwC7xK3RwJvGlSdKfhfTa6bVZBKx2NJrrNOavJZtAthZ2qvd7XpEGVBvt jMC2VuskIuJ+Sg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=QKUeWeRtfRO+iiaxiaFiOWhFM+TzT Oqy2T5AFOq6JMY=; b=ruVCc2QhxzHILn6+I7PYXzjWCQl0GiQs1uvps7XBKlbht 7khQIVzoFfN3IxRvuMTEJ6s8TSvaWCNUog8Wyf638fwiWNuSfXDLa3H2MmiPTOXX meCwkvKgrsiO2yguUOCM11HYf3RW3cIHiwLMTlhAU0sbfmXqPkVLwYWerI9s9wu1 pRZe/tHITzZ3t6uvo4Kj4lDrm3GAfdWcoqtZ4LpcvHeJH6kO1b18mRQXl+TQZvfP z/ymQfiCUWPt3XRe2aZwmn0ys8knXvgz4CssZWDMmK7LUsuVdZZiTaCiYJ3ixStp iOCPzp8U/Iv50L+nLko3nYPY1hJ5nkxZL5RAdNU4g== X-ME-Proxy: X-ME-Sender: Received: from [10.71.5.33] (unknown [8.25.222.2]) by mail.messagingengine.com (Postfix) with ESMTPA id 03F1CE47C2; Thu, 27 Sep 2018 09:28:25 -0400 (EDT) From: Alissa Cooper Message-Id: <59D29F5A-3773-4E96-9369-3D7E624BBEBF@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_C49CA32D-F645-4972-A13C-454B7DB480E2" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 27 Sep 2018 06:28:39 -0700 In-Reply-To: <03c0a914-4d3d-e83e-204c-e9ae30bdf2f4@gmail.com> Cc: Luigi Iannone , General Area Review Team , draft-ietf-lisp-gpe.all@ietf.org, lisp@ietf.org To: Stewart Bryant References: <153510829645.23054.14135893273393348518@ietfa.amsl.com> <0FB6579C-8C87-4BB0-91ED-B53881F54CC2@gigix.net> <03c0a914-4d3d-e83e-204c-e9ae30bdf2f4@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] [Gen-art] Genart last call review of draft-ietf-lisp-gpe-05 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 13:28:33 -0000 --Apple-Mail=_C49CA32D-F645-4972-A13C-454B7DB480E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stewart, thanks for your review. I have entered a DISCUSS ballot on this = point. Alissa > On Aug 27, 2018, at 2:55 AM, Stewart Bryant = wrote: >=20 > Clearly I think it makes better sense to sequence the drafts in = dependency order so that everything lines up. >=20 > However, ultimately that is a decision to be made by the Chair and = responsible AD. >=20 > Stewart >=20 > On 27/08/2018 08:48, Luigi Iannone wrote: >> Hi Steward, >>=20 >> see inline=E2=80=A6. >>=20 >> On 24 Aug 2018, at 12:58, Stewart Bryant > wrote: >>>=20 >>> Reviewer: Stewart Bryant >>> Review result: Ready >>>=20 >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>>=20 >>> For more information, please see the FAQ at >>>=20 >>> >. >>>=20 >>> Document: draft-ietf-lisp-gpe-06 >>> Reviewer: Stewart Bryant >>> Review Date: 2018-08-24 >>> IETF LC End Date: 2018-09-06 >>> IESG Telechat date: Not scheduled for a telechat >>>=20 >>> Summary: >>>=20 >>> This is a well written draft, and I assume that everyone in the WG = is happy >>> that the reduction in size of the Nonce/Map-Version field will not = be a problem >>> in operational networks. >>>=20 >>> However, I do have a question of why this is being published now on = the >>> Standards Track with a normative reference to = draft-ietf-lisp-6834bis. >>> draft-ietf-lisp-6834bis is only a few weeks old. It will take its = time to get >>> through the IETF process and of course technically may change. If=20 >>> draft-ietf-lisp-gpe is approved by the IESG it will simply sit on = the RFC >>> Editor's queue until draft-ietf-lisp-6834bis gets through the = system, and even >>> then if there is a change to draft-ietf-lisp-6834bis, then = draft-ietf-lisp-gpe >>> may need to be pulled all the way back to the WG depending on the = nature of the >>> change. >>>=20 >>> Maybe the plan is that ietf-lisp-rfc6830bis will only take a short = while to >>> finish because I see that other bis drafts will also stall on it. If = not I >>> would have thought that a better approach would be to make this = experimental >>> and point to RFC6834. Then, when RFC6834bis is published to make = this draft a >>> PS pointing to it. >>=20 >> These are we small documents. I am not sure this would really be = necessary.=20 >> We do not expect big changes in any bis document, since they are just = the PS version of deployed technology.=20 >> So the risk to have the gee document come back to the WG to do any = change is quite inexistent. >>=20 >>>=20 >>> Whatever the conclusion this matter will need to be clearly written = up in the >>> Shepherd's report. >>=20 >> I am the shepherd of the document and I duly pointed out this fact in = my writeup, check point 14 of: = https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/shepherdwriteup/ = >>=20 >> Ciao >>=20 >> L. >>=20 >>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >>> Major issues: No technical issues, but see summary. >>>=20 >>> Minor issues: None >>>=20 >>> Nits/editorial comments: None >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_C49CA32D-F645-4972-A13C-454B7DB480E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Stewart, thanks for your review. I have entered a DISCUSS = ballot on this point.

Alissa

On Aug 27, 2018, at 2:55 AM, = Stewart Bryant <stewart.bryant@gmail.com> wrote:

=20 =20

Clearly I think it makes better sense to sequence the drafts = in dependency order so that everything lines up.

However, ultimately that is a decision to be made by the = Chair and responsible AD.

Stewart


On 27/08/2018 08:48, Luigi Iannone wrote:
Hi Steward,

see inline=E2=80=A6.

On 24 Aug 2018, at 12:58, Stewart Bryant <stewart.bryant@gmail.com> wrote:

Reviewer: Stewart Bryant
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
=
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq= >.

Document: draft-ietf-lisp-gpe-06
Reviewer: Stewart Bryant
Review Date: 2018-08-24
IETF LC End Date: 2018-09-06
IESG Telechat date: Not scheduled for a telechat

Summary:

This is a well written draft, and I assume that everyone in the WG is happy
that the reduction in size of the Nonce/Map-Version field will not be a problem
in operational networks.

However, I do have a question of why this is being published now on the
Standards Track with a normative reference to draft-ietf-lisp-6834bis.
draft-ietf-lisp-6834bis is only a few weeks old. It will take its time to get
through the IETF process and of course technically may change. If
draft-ietf-lisp-gpe is approved by the IESG  it = will simply sit on the RFC
Editor's queue until draft-ietf-lisp-6834bis gets through the system, and even
then if there is a change to draft-ietf-lisp-6834bis, then draft-ietf-lisp-gpe
may need to be pulled all the way back to the WG depending on the nature of the
change.

Maybe the plan is that ietf-lisp-rfc6830bis will only take a short while to
finish because I see that other bis drafts will also stall on it. If not I
would have thought that a better approach would be to make this experimental
and point to RFC6834. Then, when RFC6834bis is published to make this draft a
PS pointing to it.

These are we small documents. I am not sure = this would really be necessary. 
We do not expect big changes in any bis = document, since they are just the PS version of deployed = technology. 
So the risk to have the gee document come back = to the WG to do any change is quite inexistent.


Whatever the conclusion this matter will need to be clearly written up in the
Shepherd's report.

I am the shepherd of the document and I duly = pointed out this fact in my writeup, check point 14 of:  https://datatracker.ietf.org/doc/draft-ietf-lisp-= gpe/shepherdwriteup/

Ciao

L.







Major issues: No technical issues, but see summary.

Minor issues: None

Nits/editorial comments: None




_______________________________________________
Gen-art = mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_C49CA32D-F645-4972-A13C-454B7DB480E2-- From nobody Thu Sep 27 06:52:07 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE47129BBF; Thu, 27 Sep 2018 06:51:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-lisp-gpe@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153805631869.26309.11407581519814751945.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 06:51:58 -0700 Archived-At: Subject: [lisp] Suresh Krishnan's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 13:51:59 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-lisp-gpe-06: No Objection 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This draft needs to update RFC6830 since it takes the last reserved bit away from there. As a side question, since 6830 is being bised right now should this flag be acknowledged in the bis draft? I am also interested to see the resolution to Mirja's DISCUSS point about the PCP and VID mappings. From nobody Thu Sep 27 06:52:20 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD76129BBF; Thu, 27 Sep 2018 06:51:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-lisp-gpe@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153805631975.26348.11653127475924404630.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 06:51:59 -0700 Archived-At: Subject: [lisp] Suresh Krishnan's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 13:52:00 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-lisp-gpe-06: No Objection 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This draft needs to update RFC6830 since it takes the last reserved bit away from there. As a side question, since 6830 is being bised right now should this flag be acknowledged in the bis draft? I am also interested to see the resolution to Mirja's DISCUSS point about the PCP and VID mappings. From nobody Thu Sep 27 06:58:24 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A52130E23; Thu, 27 Sep 2018 06:58:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Deborah Brungard To: "The IESG" Cc: draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153805669438.26412.17934535067328199888.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 06:58:14 -0700 Archived-At: Subject: [lisp] Deborah Brungard's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 13:58:15 -0000 Deborah Brungard has entered the following ballot position for draft-ietf-lisp-rfc6833bis-16: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- IANA has requested a Temporary Discuss related to issue with port assignments. From nobody Thu Sep 27 09:51:49 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6495130EBC; Thu, 27 Sep 2018 09:51: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9WTXDuKDluwf; Thu, 27 Sep 2018 09:51:46 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 1618C130E4B; Thu, 27 Sep 2018 09:51:46 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id d19-v6so2402072pgv.1; Thu, 27 Sep 2018 09:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o3CkfvX2QEx2lSM7V/x/pTBA9yV4U6QxasKy2DEpyGM=; b=t0JpseeJkAs02ZGvycq24df1GTaEZWEzt+5+sNbDZh1rEP9xBadS/JnuK8ISX27p+d 4pqmb1p0UCiDkD6gGhw7fllJL05X/4PI15eg7uIzv0XtPKOQAcD39L/P6Z/G0hOkTnZn TL1myaFKyfn+1Jl2xmMdvqkwam7snfenH7LZenK4dI6h00qIfGs4ZB6DjU3OfJ0mps5L NqwpWad/m3mEjEc77a3BfH5otand21gHWopotyMkjwCy1fQ8JmFpr3KeZKGw4gKK/E7n PAkEp2ef561JZwT15FKPjj2ycQDsHA/0o9RG8+HKcD3gN3syhqDB3eAbBmUIUNj8IQ+U pj4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o3CkfvX2QEx2lSM7V/x/pTBA9yV4U6QxasKy2DEpyGM=; b=hHKgE4wxFwPFF1ju3xFvyy+m7YI+1wQrQPqsxE90CHOh0lePooDHNFhHlW+jtAmfNI mn85LIroNE3/LeDLirbtyhEkGOHlcuWgnyfqeQosEamMAeF3kwx1rFhxWLAdeZU+Whr6 whre4PiurFpb273bicTQ4imnPEaRHUoFqxrJUEB5PZZZmcUB+LXDbS611I8n/11XOqFm VywJcehRZIUSF0rNfXK9sfX7Kh1SogSCNVV0Yt+ZoFxAiIILc7vT/pvVpDxB8isxia7f E7SdGlfnWn2R5QQehLXHGuJrea9wtB4I074zO60Bxhq96ACpng6Hhv+iayMysGabXouy wr2g== X-Gm-Message-State: ABuFfohwazzaWF8pIsUPT1LPmDK50DwcdJSf7jQ/ML7ZiaWmzo37Bdnt v1j6Cc5YJ4hU7zDzlw6B46SPWHMf X-Google-Smtp-Source: ACcGV62xq8X5oJA6f4CHXp4UVYOdQjkT8Z685aSd3xaXk30Lnwf6HQY+p3yybojJyfGLykNPapuusA== X-Received: by 2002:a17:902:b496:: with SMTP id y22-v6mr11854572plr.314.1538067105584; Thu, 27 Sep 2018 09:51:45 -0700 (PDT) Received: from [10.31.79.57] (adsl-108-209-217-65.dsl.pltn13.sbcglobal.net. [108.209.217.65]) by smtp.gmail.com with ESMTPSA id d18-v6sm7447347pfk.163.2018.09.27.09.51.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 09:51:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153805403943.26537.10169153194287970368.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 09:51:43 -0700 Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <51B68197-1D1B-4B17-95D6-8EDE53C881DC@gmail.com> References: <153805403943.26537.10169153194287970368.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alissa Cooper's No Objection on draft-ietf-lisp-rfc6830bis-20: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 16:51:48 -0000 > I'm curious why there are several authors listed with an affiliation = (Cisco) > who no longer have that affiliation AFAIK. The authors decided to do this since much of the foundational work was = done while the authors were at cisco. We thought the right thing to do = was to give cisco credit. Dino From nobody Thu Sep 27 09:54:00 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C896130EC7; Thu, 27 Sep 2018 09:53:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Jj298AUvhhMT; Thu, 27 Sep 2018 09:53:57 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 56C56130EBD; Thu, 27 Sep 2018 09:53:57 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id b7-v6so2336603pfo.3; Thu, 27 Sep 2018 09:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MIwBcYjXxjZE5ZonKalwhTPlDZIofP/uVUSg6jirP4U=; b=VjLs4r8JWjzbtwcPZiLJElSU8y5HR1y1D/x7OJv9n1mSu7ukK6hZmgTOP8swtqhOJL W4QSZ23q1ykmR51hcLvEoWQ8UMekzzJAhYN9WsjU/Fg5KLYRvOt056cVoFyOoL000cS/ ri2S71ZCbSgJtPgFq9wkTJmjcCe6flenJzvtIjSlSoDiCSvedBYder7gj4vZlcz8YLF3 NRBwxRv2FRyUlS8VMK33TY35J9vATA7z03nMG2hfWm+mUohF1pfnXdG3HBXcgpcY4gX2 DWS+/N8DwS+X+RqohxGdA3LGgRb6IUmiPQfB3x72wVdgFQZCXG3wCaSN6MsKuUR5XCzC 3iOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MIwBcYjXxjZE5ZonKalwhTPlDZIofP/uVUSg6jirP4U=; b=mttq2gxeFSX5g7fQsv09K1ljraqVHnwhEoQ9WexVomAWA4DKbRyCDIZTpTEB6LkIWU OKn/HXnVcfuAxDhMryboox1R8YBqB+NucxkOwqP5OXh/DfXcLAvxyygRBqKjAivhARrF tXAkqqVci3nTBqH60HMHLRzycbcUq3Ad+E3l4WqROzRNLZrFJo74p0na7ZIrncIQA93/ 3M2kw1N91UsEAWH6Tv4+2zr8ilR0wcz7z78UimadBAYO7Yh/gXJ9dWmBc9nvsnrQoV3Y hCHe0N7dxmQOGPU+It1RZm+yJ4j6IMr5waj6C5BOcvz8fq2uUPlngu6KbFNcpUOn681E XH7Q== X-Gm-Message-State: ABuFfoiekaMXuQE0ahT8PI4pVSGG1HARJ5yDbaRDmi+eKNAO3EIT/wpK MsjrnaqPvl6ylrrUhXBlzjI= X-Google-Smtp-Source: ACcGV630XyqhgIA4yUlvDSFG4kyXKlHRdWNvUYo9pEvqrh8syYvwQkDdjlcu/58o4w6OoellcUTn7A== X-Received: by 2002:a17:902:e088:: with SMTP id cb8-v6mr11933890plb.189.1538067236893; Thu, 27 Sep 2018 09:53:56 -0700 (PDT) Received: from [10.31.79.57] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id s23-v6sm3473078pgg.67.2018.09.27.09.53.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 09:53:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153805631869.26309.11407581519814751945.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 09:53:55 -0700 Cc: The IESG , lisp-chairs@ietf.org, draft-ietf-lisp-gpe@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1C8878A4-4130-4920-85D3-1F98250C94C5@gmail.com> References: <153805631869.26309.11407581519814751945.idtracker@ietfa.amsl.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Suresh Krishnan's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 16:53:59 -0000 > COMMENT: > ---------------------------------------------------------------------- >=20 > This draft needs to update RFC6830 since it takes the last reserved = bit away > from there. As a side question, since 6830 is being bised right now = should this > flag be acknowledged in the bis draft? The working group decided to not have 6830bis refer to LISP-GPE. Dino From nobody Thu Sep 27 09:56:22 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671C5130EC7; Thu, 27 Sep 2018 09:56:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CFeA7M_t7zFP; Thu, 27 Sep 2018 09:56:10 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 2F6F4130EBC; Thu, 27 Sep 2018 09:56:10 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id l9-v6so2313199pff.9; Thu, 27 Sep 2018 09:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o2F4KqXl3jPZvBGiJYwOT6Nn0TGJvBIA3utmj+EZt/s=; b=I0vxptowVdCSFCBy+grN0rJ81xZLQGEck7F5VlGZlAh+4i72nW6SSkNZqXXYT9GnKz Xun7ir90v7DGUT5gxiiS6wQQ62oHopB1qQ9xogaZ/uqnzKo1GSjc+KHB5xmv9ks0c8tC ZrRohMYin49B9wwBYV+vhqBOmAgo6sFqGwGGOk5EArMOkkyh/HKvv7oP1MteASnVzKAq cCm0e3YNuAOHLP0/7hR2cIT6B1WLkPbihxt6CpT3fags6eysGr+G1Rmwqj/0zWhCJrsb OktdYPW2LsAy3F98hENsdvXZUw3cK425UrZ732ciefdYlkQdHN8CvsM72NL7rOR+SHOp T4hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o2F4KqXl3jPZvBGiJYwOT6Nn0TGJvBIA3utmj+EZt/s=; b=OF9gWM7mRArUEX3LaM47mXhEwMSwQR0gMtwZbbD/E2HgUOtfyxRwRHHzU44CYKolcf 5xLsGJYUvVD/eZrB6wemaGIKXID/zwB0afJ2mEW1KJN0M3i+f85VeK0jihexwxD1GcIc PtOUnL1NJl9rt1d/CGONSe3Q9BSnq+5TMUf2jkQnDobJKzH8CrStoW//KGOmZxFOvCdX g/eDhH0qjlUGDctThCrrRdUn37L8DZZiXkha+gUCgxhu6QoibUm6sGHKzYu3TF6uyotE WlL8Lm1E5ScO/aJgvlTjNIUP+DaoMlfWbRvWf5BgFr0w9GfzPlkmw+J3JOrFDSah2yRd NNEA== X-Gm-Message-State: ABuFfoi4NEiX6vEvR1EV/gC4dy37Nh33EqXAmjbv8wA/YVN8kTg8k14/ Xkjjzgl/9Bqn7qikeKf2L6eINP+E X-Google-Smtp-Source: ACcGV60I0BCulmpRnrP2kiIZsWls+79qZRR7KdSAj/mzABAkB/GAeJBB/HNY/tB60THmDnButMKoEg== X-Received: by 2002:a62:8a4f:: with SMTP id y76-v6mr7132016pfd.142.1538067369799; Thu, 27 Sep 2018 09:56:09 -0700 (PDT) Received: from [10.31.79.57] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id h88-v6sm8897279pfa.184.2018.09.27.09.56.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 09:56:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153805669438.26412.17934535067328199888.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 09:56:08 -0700 Cc: The IESG , lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-rfc6833bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A3B3549-E149-4AAB-8000-EED15970BF0F@gmail.com> References: <153805669438.26412.17934535067328199888.idtracker@ietfa.amsl.com> To: Deborah Brungard X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Deborah Brungard's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 16:56:12 -0000 "---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > IANA has requested a Temporary Discuss related to issue with port = assignments. I don=E2=80=99t know what this could be about. I had gone back and forth = with IANA. The port assignments are very straight forward. They are: lisp-control tcp/udp 4342 lisp-data tcp/udp 4341 And there should be no reference to lisp-cons anywhere. LISP-CONS is = historical and deprecated. Dino= From nobody Thu Sep 27 09:59:36 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A41A130ED7; Thu, 27 Sep 2018 09:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.com 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 O7qxHhlJnC76; Thu, 27 Sep 2018 09:59:26 -0700 (PDT) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660123.outbound.protection.outlook.com [40.107.66.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544A3130EC7; Thu, 27 Sep 2018 09:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oG9xmCIhpdVojBf4c15DDwxS/hds7l52lfMM36yE3ZQ=; b=N6gTD/shG7Ot+33GI1GlZKTLw2ZI/roAyFnXUL6ZpXZwb9Xxqujb/wPAT5UBXZCjPIZce2nKGHI5s+uv0O2uN2tHkVVUtfSfGvedBLdrS6uQJNoBJu85Tt6PjnN8y0KcrWsBU7O+tlgQiWNiSnZ3a+cCIvLRiYE6BlyFnyy3Cto= Received: from YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM (10.169.141.148) by YQBPR01MB0083.CANPRD01.PROD.OUTLOOK.COM (10.169.141.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1164.25; Thu, 27 Sep 2018 16:59:24 +0000 Received: from YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM ([fe80::8dbd:5e3f:40e5:d4e1]) by YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM ([fe80::8dbd:5e3f:40e5:d4e1%4]) with mapi id 15.20.1164.024; Thu, 27 Sep 2018 16:59:24 +0000 From: Suresh Krishnan To: Dino Farinacci CC: The IESG , "lisp-chairs@ietf.org" , "draft-ietf-lisp-gpe@ietf.org" , "lisp@ietf.org" Thread-Topic: [lisp] Suresh Krishnan's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) Thread-Index: AQHUVoKvwELTvYkCG0GqDdfjktS2Y6UEWduA Date: Thu, 27 Sep 2018 16:59:24 +0000 Message-ID: References: <153805631869.26309.11407581519814751945.idtracker@ietfa.amsl.com> <1C8878A4-4130-4920-85D3-1F98250C94C5@gmail.com> In-Reply-To: <1C8878A4-4130-4920-85D3-1F98250C94C5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [45.19.110.76] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQBPR01MB0083; 6:3ugbYZpJX4xvLtzQLBJREns+SZN0iKWjiH3zf8s4GryngOTudeXo3TE1I9F6zV4g3h+BXAUgk9PclLtnfIavIw0cP52HMagWcjKVuyb8QCus36VfU8qEE9g119nkNyTSRS2MNCb2FtNbf5MmwL4ZcKI7U0Zw0HKRQuLAPhwdM9dM619PJAo1N9oDqiDODeYRmzlj+oUZAl2qFWVJyTnkEqP2Ll+mqoD/aAM54qvoX/gQXTM8uvuvxXLpCwPba/JmWx9f+z6LdIBxNW2JiwSSIkx1gevvoeuNyrYVSNJamt7ed1e+dmPiOHdGPHmLwq5rOvQHszjXxY7hnQZc/bdLNm8MhzJPQSh0hMu7YkG+2MQKS/SP9kN6zPvhvRIg9+Xav69XfVXEl0e5JPS7mKrxaRUaTqQMkj04baGi6lsbiiOGhmnWztXI5rryXvvvAJV3tT7xXwHPF8nWtgnHQ7TmhA==; 5:2ie/yQyie6o3USV7yylxTQR3yNtPy2RFa4qtYsPZQkqM0Og1F5PrLpefeQqHoxbHF209R0OTgVbWBp5lv/xX78Bk/G6hJjoLy8q4L86PgzZ2PyqOIjGKnR0ZAnz0XIgeORpQVpRKrGWSIdvs/MB1GWwC65psvXpXAWLKLKzRghM=; 7:f0nHYr8Hu/oZawLJMrt5kQopzvhGa/Gizo8hFjvn8Al4oJniS+SpXbEBc/qj2W9HjnCcJovF0jpqSt9moznm71EennIJZGtsOuIPqUXlxPUUn95/R/smUXMQq5pKypp7B5A8OsoYQkKGI0AWeUOISmFUCRRcDvjAq6hoHC534eglOYYNprUDsSkOJjHRb0br3PaULcZB/RFD9AW+CfBGGp+9K0yrmeZxpfUgZG8f5LC8o4ST0akS66RNUWb4mNo7 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4dfbc080-bef1-4d16-581f-08d6249a93c1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989299)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:YQBPR01MB0083; x-ms-traffictypediagnostic: YQBPR01MB0083: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(52105095)(93006095)(93001095)(3002001)(149066)(150057)(6041310)(2016111802025)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6043046)(201708071742011)(7699051); SRVR:YQBPR01MB0083; BCL:0; PCL:0; RULEID:; SRVR:YQBPR01MB0083; x-forefront-prvs: 0808323E97 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(39840400004)(346002)(396003)(366004)(199004)(189003)(316002)(11346002)(97736004)(6486002)(508600001)(54906003)(25786009)(305945005)(5250100002)(66066001)(81166006)(81156014)(6436002)(3846002)(82746002)(8676002)(2616005)(99286004)(72206003)(1411001)(446003)(4326008)(8936002)(6506007)(53546011)(2900100001)(256004)(86362001)(14444005)(2906002)(486006)(476003)(36756003)(14454004)(229853002)(5660300001)(6512007)(6116002)(106356001)(71200400001)(71190400001)(102836004)(105586002)(83716004)(80792005)(53936002)(6916009)(39060400002)(6246003)(7736002)(26005)(68736007)(76176011)(34290500001)(186003)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:YQBPR01MB0083; H:YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ZDgMb3CcH7cxBdtgGEvWKVZ1oGb6sy+ppGnxLntDOIwluo1m6JHx6jSArALJeVYOn8RHrUapLN6FwqVrbKWv1Dwexh037Ebeksj/z8WymDW+R3ix/icmV+FT5lGBtT3C/rvWLXvDFNi8prgGoMcXJG9pYTmrET8XcMZFTO5AukTzcrGrEk4zkto5d4pllAWIIzglZ/9wNMJoNZ772ooKmUsI+5zdsgP4/iRKqQbsGX8dT35c6MWfo32uwcOLrX0GSkdZflNZZH718xLKd2dO9VcEhssjafhoG7HkhRCq7mkYcDCy9aT3oAACFiUsuoiV75icLHy3731YWBrYe89GoKKGIO9b/iQwOI6K+5KArL4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4dfbc080-bef1-4d16-581f-08d6249a93c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2018 16:59:24.0895 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR01MB0083 Archived-At: Subject: Re: [lisp] Suresh Krishnan's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 16:59:28 -0000 Hi Dino, > On Sep 27, 2018, at 12:53 PM, Dino Farinacci wrote: >=20 >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> This draft needs to update RFC6830 since it takes the last reserved bit = away >> from there. As a side question, since 6830 is being bised right now shou= ld this >> flag be acknowledged in the bis draft? >=20 > The working group decided to not have 6830bis refer to LISP-GPE. Makes sense. Luigi was on the call today and clarified this. I am perfectly= happy with this updating only RFC6830. Thanks Suresh From nobody Thu Sep 27 10:04:53 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4A4130ECB; Thu, 27 Sep 2018 10:04:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Lz7kXQbdGF-5; Thu, 27 Sep 2018 10:04:49 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 0B19C130EC7; Thu, 27 Sep 2018 10:04:49 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id b7-v6so2356536pfo.3; Thu, 27 Sep 2018 10:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1zNpxMkAPT5ArUw8gwP/3K+38oKZ+0DcdJGOa+qzupY=; b=QypsZZ7Z6hw1B0A1buKibLgO1EC8B94McBrbTavAsTjwV2hkpWxPnr9MnfQ3hC19zc VxC4yEKB8kaAH2jA44DdZclYrRiE0CcyXs0kpaHgo+pcdWLAjAIwSyO11Yfz44NGdEWp jgPj0vTCu3dAnxWe5R+CiEDaIHJcfc7JEDQlL+NwhNMYCSqGyhwumgRgJBRV8fIJktLX NaQRaIng/voqWNdJr2maReeRGZFkcQReSlZs7Ck+Y1WZQEIjNOX8+RSX4m0kPQ9P/jGd iwwtEjzpinY1YbUJnPWcDnxTOuXIYbpk9AIYQKuG24nAB2kmQWFauw3M5+EVAEIvST4Q 4JOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1zNpxMkAPT5ArUw8gwP/3K+38oKZ+0DcdJGOa+qzupY=; b=dgMns+yGWQs6bc3iA0A3jRNKjFO55qFGkv8xC7vHYmiylexEV80Vbyc/miYMzEDr65 XnRjszg/ueYmltI6kcPRhob1+IZt0U6syBWZ6aqzosVTEv9ThvqmKL/FU6To9vNvKs50 +nsFHzcvMYyAP4iCxx5/yLlx4ZVO4zkj8b84U4N2D8dJXPJFWO2YCsG3B0xab/INLhF7 YkKVz6Flglim5W48u25N4D8YWeRwN3egzxiqmkanqsNDI1BokB4YOOQ531IMmE3MfxvU 46oBbCis4X++vDrD0hEdJbQZ9BFgr1GffjZTeEaSC0bgKEMVZ/WcgbnLYB9squQ0NboK sy+g== X-Gm-Message-State: ABuFfojYAw5Hf/OlBhmKYjTrYO6OcpEHPfR8avspMfy962b4Cuqj98HC a78j/EPehl+QBYOVgTpolC8= X-Google-Smtp-Source: ACcGV62oe8KD4vgVeYfmNupa4AKkbBhTlto7QDtr+EJkXBJ/v5nwFzhqYUFt46vO5dTRLfWVxdCjmA== X-Received: by 2002:a17:902:f209:: with SMTP id gn9mr11968714plb.173.1538067888505; Thu, 27 Sep 2018 10:04:48 -0700 (PDT) Received: from [10.31.79.57] (adsl-108-209-217-65.dsl.pltn13.sbcglobal.net. [108.209.217.65]) by smtp.gmail.com with ESMTPSA id v8-v6sm3727107pfl.6.2018.09.27.10.04.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 10:04:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Thu, 27 Sep 2018 10:04:46 -0700 Cc: The IESG , "lisp-chairs@ietf.org" , "draft-ietf-lisp-gpe@ietf.org" , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9868FB0E-4FA3-43B5-AF07-359E18635606@gmail.com> References: <153805631869.26309.11407581519814751945.idtracker@ietfa.amsl.com> <1C8878A4-4130-4920-85D3-1F98250C94C5@gmail.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Suresh Krishnan's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 17:04:51 -0000 The working group decided to not document that bit since LISP-GPE was = further behind in the standards process. That could be different now but = others can comment. Dino > On Sep 27, 2018, at 9:59 AM, Suresh Krishnan = wrote: >=20 > Hi Dino, >=20 >> On Sep 27, 2018, at 12:53 PM, Dino Farinacci = wrote: >>=20 >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> This draft needs to update RFC6830 since it takes the last reserved = bit away >>> from there. As a side question, since 6830 is being bised right now = should this >>> flag be acknowledged in the bis draft? >>=20 >> The working group decided to not have 6830bis refer to LISP-GPE. >=20 > Makes sense. Luigi was on the call today and clarified this. I am = perfectly happy with this updating only RFC6830. >=20 > Thanks > Suresh >=20 From nobody Thu Sep 27 10:27:29 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2FD130EE8; Thu, 27 Sep 2018 10:27:26 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 76dTK455dmvJ; Thu, 27 Sep 2018 10:27:25 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 4002F130EEE; Thu, 27 Sep 2018 10:27:25 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id 85-v6so2448725pge.6; Thu, 27 Sep 2018 10:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PwPeSNM0cjCt7Vle+WXfNA3aIiMMUrm5EprD/YW3ed0=; b=k20NEIaChHCo+q25GtXdVkSyVeJhkZyma9dWyei7A/hsPyGxrcRssHAOj38XSy863t 03pZjEeyh9bMCSr8I0jKzLDeMUOVgFVqI3OO9j9GWgd+2VNkhmDGfMLD5t/XSbOiCE1k sWXuJ817+9WFur38heowHVODaY2bz8dEReRh7ne0nAazfTx/mWx582BFCcEIai1l7s4f Wxvkpc9vvDfUOnnOzxmwNM6zPE3soyPq+ham2eJnuH1NWmkNze4B0x7bAkl3Y4KVV6wm 6GiN7oFlsuG9rgomyG/raH6/Km+mJz39uU0GFSb8ABq6GhoCUgQt3Lwpu489P343gWA9 xNNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PwPeSNM0cjCt7Vle+WXfNA3aIiMMUrm5EprD/YW3ed0=; b=Ao5Hm+4+egGdhcXyiW5ykO1A5/KtUJs4qofoBroSySB2Q/uVS3BQDsMBEyOX7CR+Di otINwVcpoLeWKUicIdygYtdLbWS1bTnJrPPJTO3A1mkOvt/0dQiVtdlZdeE+5S6lJazy BgBgtdB5xBGBa5zGINCALwtmIb3uHJi9yeK96UKKfxFZuXuc+CQTcCttDFd0Q3EM1zH5 XYa/iDrmd2rIyRx1oK+7W7syES5hcwpcuug9bExADuFnIXyIkkIhHCPuqgW0+mPgvKwf J5j44s/nh5B5CuYHK4mVXfvw8+GvPFL7KBsb0APpdpEZiTgZihU/WnJ7Ra8v2pN0Rlkc B+9Q== X-Gm-Message-State: ABuFfojaw5Juvvm2cVinWtnK1Xnp+sr+LPxPX43vVFF2kuMGnVtlFA0a fEC5ZDkN+Pd/5pJ7ERUKJjQ= X-Google-Smtp-Source: ACcGV63PkZgQgxIr9AJYP9FOzKaJ5x08fLBZuJHA1MvQEXDB6k6t7A3sfYsOz/vchMXmTMpcHluybQ== X-Received: by 2002:a62:4799:: with SMTP id p25-v6mr12598253pfi.197.1538069244734; Thu, 27 Sep 2018 10:27:24 -0700 (PDT) Received: from [10.31.79.57] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id g21-v6sm5955171pfe.41.2018.09.27.10.27.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 10:27:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153802608641.21525.4981689568836441403.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 10:27:22 -0700 Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7FD9C027-C60B-4552-A1CF-B98D490CDC53@gmail.com> References: <153802608641.21525.4981689568836441403.idtracker@ietfa.amsl.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Suresh Krishnan's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 17:27:27 -0000 > This should be an easy fix but I would like to see it fixed before = publication. > When talking about IPv6 packets being larger than L, the correct = behavior > should be to send an ICMPv6 message with Type 2 (Packet Too Big) = instead of the > Destination Unreachable (Type 1) message as specified in the text. The = text *is > correct* for IPv4 messages with the DF bit set where the Destination > Unreachable (Type 3) is the right kind of message to send. Consider this fixed in -21. We had this comment before and missed this = one occurence. I will make it the same language to be consistent with = section 7.2. Thanks. Dino From nobody Thu Sep 27 10:31:16 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EBD130F04; Thu, 27 Sep 2018 10:31:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9h1hEWlJzElj; Thu, 27 Sep 2018 10:31:13 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 2C995130FA5; Thu, 27 Sep 2018 10:31:13 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id d19-v6so2475605pgv.1; Thu, 27 Sep 2018 10:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SA3V7TKVm95jMQQzvmdxleVrFwdfZoghnlseXp8EhSM=; b=j3ybr41Td2wT7CdHO1fUBadYcKi65jJJYsdET22xmWfhTBKlkBI6Oz2ZrPWpMozDPG dnq2pq0hsxbTzR0xCKAVJHDjJujGXzu3FkOEsJGVTV4rhYsegHR9UkACuc1QDWR1T8Pk sOdZIsJBeA9UANXwvqhdU+ejkrgzCGPl+XcOAjiNI59K8oLXtW++lm3tpsFrPbIRVAea USS2CDKKHVA6II7f9vOydRJ749dVr0qFlltHgeWpmN8b3heKJcSuajgxRXo1jNVfqWaK r934U1lTsCFfMUE4MzXX/HHCMp7LsWQDIZkuXYlhW//ENZrH7JUflaMCfugyx5lort4L OCbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SA3V7TKVm95jMQQzvmdxleVrFwdfZoghnlseXp8EhSM=; b=e7S9f2Ic/n9ag0zvMDlbH7mfACaPwEaRniOw8WWSzefjIuypGgrs0RKxa2EgkM8rPT A6+lQR2uiJ8gUShaIR9GRQLQ7beiR91QYXIlC06LfuCKIgPvgNgXHQkTIr8tRZFUwzWl 1IKAxbwh0dmhfWdw6CxQXHIG9E+x7s4uXYeELDKstnOPyDu+bXiJWsaIA3edUTBKG4PX B77ta9nyT9+xbeOsY9/4CQ7qnReIhlz8a9Ekck4+mr2uxUWWizPQeCPUxjS42i5Xe5Xn tzOzF2wLkiPvMZIRFPxYil9nHCDeokr6AMWicE0kFJ3oq0jVdjk1KX4zazS0pZGM7pJO M4GQ== X-Gm-Message-State: ABuFfoidpmP1BtaNaLrzKphZu9mCLnMxQ5dEjK87I6vm5DdeWym3i+Cf QCeW9IP6MdhzZUKd3Y8Nkyg= X-Google-Smtp-Source: ACcGV61/gdhte91rxYdOwDZAfmuPMh8MydCkQdJmOi2PhfJZ1QgdbFhoo8kS1CwEnQGaYjcss4xXDA== X-Received: by 2002:a62:4494:: with SMTP id m20-v6mr12672973pfi.205.1538069472783; Thu, 27 Sep 2018 10:31:12 -0700 (PDT) Received: from [10.31.79.57] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id l79-v6sm4616333pfi.172.2018.09.27.10.31.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 10:31:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153805097526.26380.13580308305182872824.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 10:31:11 -0700 Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153805097526.26380.13580308305182872824.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alexey Melnikov's No Objection on draft-ietf-lisp-rfc6830bis-20: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 17:31:15 -0000 > Ok, maybe this is just me, but you don't actually define how to hash = these > things, you are only talking about what needs to be covered by the = hash. I > appreciate that picking a specific hashing algorithm is probably not = relevant > for interoperability, but I feel adding a specific algorithm (as an = example or > via a pointer) would improve the document. We decided to leave this to the implementation and is a local matter ot = the encapsulator. Most implementations use a =E2=80=9Cfolded XOR=E2=80=9D.= Which means XOR the set of 32-bit fields from the 5-tuple hash, then = XOR the 2 16-bit quantities, then XOR the 2 bytes. Mod the number of = best priority RLOCs, to give you an index to choose one. Dino From nobody Thu Sep 27 13:08:45 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02A0128D68; Thu, 27 Sep 2018 13:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.com 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 OaY0Esfx28Lu; Thu, 27 Sep 2018 13:08:35 -0700 (PDT) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670095.outbound.protection.outlook.com [40.107.67.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2374127333; Thu, 27 Sep 2018 13:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZZw9G1tpzKCBo2IiuVBNbSEaBOYxYFo6cb+SS/adlpk=; b=b9CoUU+4tuaob8xH7JSyXnKN4UZzf/o2B2Zxppf0HPJqNCUlUtR4OzdcSwZJigaD/UOejVqQ3WSuGx3f80jEm+HfMLpocgsAvGz+YpZKQ2iwrePn4OIra2gvRKgzeh2OSSMeV/C8sJQfDNwTHCBQoWvELRJ26I1xYElUPHo0Ahw= Received: from YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM (10.169.141.148) by YQBPR01MB0035.CANPRD01.PROD.OUTLOOK.COM (10.169.140.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1164.22; Thu, 27 Sep 2018 20:08:32 +0000 Received: from YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM ([fe80::8dbd:5e3f:40e5:d4e1]) by YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM ([fe80::8dbd:5e3f:40e5:d4e1%4]) with mapi id 15.20.1164.024; Thu, 27 Sep 2018 20:08:32 +0000 From: Suresh Krishnan To: Dino Farinacci CC: Luigi Iannone , "lisp-chairs@ietf.org" , "lisp@ietf.org" , The IESG , "draft-ietf-lisp-rfc6830bis@ietf.org" Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS) Thread-Index: AQHUVodcrt/Len8EHke6SI6hdj1mQaUEjqsA Date: Thu, 27 Sep 2018 20:08:32 +0000 Message-ID: <730DA5AE-2183-49F6-86B1-74D8D03BF402@kaloom.com> References: <153802608641.21525.4981689568836441403.idtracker@ietfa.amsl.com> <7FD9C027-C60B-4552-A1CF-B98D490CDC53@gmail.com> In-Reply-To: <7FD9C027-C60B-4552-A1CF-B98D490CDC53@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [45.19.110.76] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQBPR01MB0035; 6:/NmOycXptrH6+HDmkGoalTYwk8a+xDPZKRR7HL4SO2XoYI4FKvsSb8pQCv17CXHOjQcxxOZ+V9QbkGsEOThUH+kYru7U+M3aiQ5FcywF86Enc+cLGMRntv0T1fkIcr+BJDITSSJTeOxK75dT8ca9sov1bVVhU62Mop+gb+m2XlvPiVyf8KRTiXy93nK1dNUGsjIJ3tGS4yD7VIxHSq5ufsgh+E/W3DewqkbWi9fAOttLbSY0ytslZtDPd+j5eMtg/t/hb8U1UwWVBgW3fmPj/+PXDAA9+92O8Ph5+S293VHRQq2sjBe7EjXHeLP0yibCZSD3AWl5w/YBYgVRhFogLsrX6uvZeeKQRqT3xZUfyfYQ//i1mDvKkQVIDjKr1uzLPShCWNwKfzaCioYjuO+jAloyXJIUlqXqlixvIAwAM2mcbpV/WmgQKxSyheRIdqUAuwaWflGQAa9LtJ06rij1eg==; 5:kuAz0CUtNCJVe8YW8mFeqOUpKkKUn7rYsJGXoSjPnAjFsk7+JBJHqnGDTZFecFOQkxQz6RvPNW8c70aMttxCiAylBTQM+hPiHewWiJXHKHR1g4zCPDvOc+gCm3ErihkJzk2f0lmNvmJeTre3qeQWfhI9iqwReST7kQj+1a7AI68=; 7:f7yvhbM2wj5lHQwFKk917NSvlWbWRVeKZEr6s8Zamum/LAiMogXRy6x74C78n0wlYp5leXiWdOiKCjuc9etsxwUlgtCzuAnPfIwH/oSEFg6+ikOxDTyPBKHKnzQJK1hn97fev8VzA2UpSLtx4EtsK4PsnoMU8iZD+7eTlvp3tACNmLR2eyS940MexMkScPOaxeTwJz7FVuzebeO6gf7ClnHFFe++HoEqTRrJb0ZnAgdDKnKdIWD0TiAOJ8MJdEI9 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3646df55-2b3f-4c8e-df7c-08d624b4fff4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989299)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:YQBPR01MB0035; x-ms-traffictypediagnostic: YQBPR01MB0035: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(2016111802025)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(6043046)(201708071742011)(7699051); SRVR:YQBPR01MB0035; BCL:0; PCL:0; RULEID:; SRVR:YQBPR01MB0035; x-forefront-prvs: 0808323E97 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(346002)(376002)(39840400004)(199004)(189003)(229853002)(68736007)(53936002)(25786009)(6486002)(7736002)(54906003)(305945005)(486006)(106356001)(71190400001)(34290500001)(71200400001)(316002)(6512007)(82746002)(86362001)(256004)(4326008)(6246003)(83716004)(1411001)(3846002)(6116002)(2906002)(33656002)(14454004)(6506007)(39060400002)(81166006)(5660300001)(2900100001)(8676002)(26005)(186003)(97736004)(66066001)(102836004)(76176011)(5250100002)(6916009)(105586002)(53546011)(8936002)(36756003)(80792005)(81156014)(508600001)(476003)(446003)(6436002)(72206003)(99286004)(11346002)(2616005); DIR:OUT; SFP:1102; SCL:1; SRVR:YQBPR01MB0035; H:YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: FkgnVJKc6/sT0YHrjGeQlGtHWbUABraG1WsUgC2kdOrZwuSBXg1dZR8naKJ4qdf0xXJ7mHnfREkiJQhWGlXL0zmggkx/wcBgkUdGBYuA0iWV6jM+a4oysA5DjrK82Tk+pdrZrSC1pIuFgeOQgsjOptKy1uqDtRP6p1mTRkk0WsWRyJG/o43Q0poZKB0m3obkjNcO27Ti7BdgQpO/QRLRIJFp5k9SYgNwPLTbpzybkXk06tXw0RSJh7JQ6E7qkCkmOvtEwUiR7LNR1zgSpTHwwRvvGjRSQOrFcVwXsL/kSi5e9wZx1ltS6PTpfpzOO+pa5mIwWTu+uSR34lILcM52xjLdKjRNxuZsnxXDjOY9m8k= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3646df55-2b3f-4c8e-df7c-08d624b4fff4 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2018 20:08:32.5830 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR01MB0035 Archived-At: Subject: Re: [lisp] Suresh Krishnan's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 20:08:37 -0000 > On Sep 27, 2018, at 1:27 PM, Dino Farinacci wrote: >=20 >> This should be an easy fix but I would like to see it fixed before publi= cation. >> When talking about IPv6 packets being larger than L, the correct behavio= r >> should be to send an ICMPv6 message with Type 2 (Packet Too Big) instead= of the >> Destination Unreachable (Type 1) message as specified in the text. The t= ext *is >> correct* for IPv4 messages with the DF bit set where the Destination >> Unreachable (Type 3) is the right kind of message to send. >=20 > Consider this fixed in -21. We had this comment before and missed this on= e occurence. I will make it the same language to be consistent with section= 7.2. Thanks. Awesome Dino. Will clear as soon as -21 hits. Regards Suresh From nobody Thu Sep 27 14:06:21 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F415130DEA; Thu, 27 Sep 2018 14:06:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DUo1A8QDn6Eo; Thu, 27 Sep 2018 14:06:16 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 AC98F12DD85; Thu, 27 Sep 2018 14:06:16 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id i4-v6so2210423pgq.9; Thu, 27 Sep 2018 14:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cMjGyS0B2bUeorBTvmMbB6lVu0xVc/OyxQ8moK1uw4M=; b=ow43sBWxgJkkAQswcsa+RIiFAOUkZdf8VSfhydgW0b9yXmBHYZlPz1uERreWA1w6LR FDHCHMMI26lhdepPBq81JyG3otSfxdsYm5tjwITVT5mmm9mU7bEvR0wGjT9cCmrEEUhv OJCz7j+qeB55QcJJeecRmgoDT7yLytP7pkG1QXcKOg8ClsMyWZ90sp9t69U+Wj9BunuA odKNIpJDU6rMeiKI0ejrAAN51qp6Qotoby0rdOmU9n0dSkxYKJ1yd+2olaJDkbdlcRVH P6y+ALbwT94/X0gtXxAW/OqC+A2b84qkSWz7BosWNgZRGe0g2//5U0wILyQfRT7YLSu2 AZUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cMjGyS0B2bUeorBTvmMbB6lVu0xVc/OyxQ8moK1uw4M=; b=StSCcSBCHwV0NESzY35qD9X7CjBFKqSA1eFFmDKjAgzJxDcVXEyYfv2zq4EQWakwmU JoX/EmWnMxFsi90hL5B0KHjMR0hfMYsDghGwgFtUnQ6gk8IXiUSbtJ1q6tk+Xy38S9el qrM+aD+PBiwHCQ7e+pVx1tuhJZbnIx3Vhyjq+/HSVcVbzKKo/7BecN3NIElIfpMEi6k3 QdccXUMuEYrN54XZArXS2uVQOShLAuwAgdELkqPOZv+cKutbEbwaOBOYv4xqTncVC0Lb L1QrTHAV3d/TeIRFj9Ud3A1yCIdYb8ENvQzjPn0GZoO3LJLxAGsdjjfFJW48Axq7EuLa yh6g== X-Gm-Message-State: ABuFfoh7hOEydEVd02LPzn5dGp2APLHpuMnDgRqYsuomGZdwXcMQqoJk pHogymkkVwcFXqU0+1YsPzk= X-Google-Smtp-Source: ACcGV61qL8RaijwuPn8dJmGtpg8QuboHZPnmNtTXq1W0JH5i9d1AGnfATg+rcvESBZpky2bzlF/mgw== X-Received: by 2002:a17:902:3081:: with SMTP id v1-v6mr13064657plb.58.1538082376041; Thu, 27 Sep 2018 14:06:16 -0700 (PDT) Received: from [172.31.99.184] (96-86-164-193-static.hfc.comcastbusiness.net. [96.86.164.193]) by smtp.gmail.com with ESMTPSA id f184-v6sm7677546pfc.88.2018.09.27.14.06.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 14:06:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 14:06:13 -0700 Cc: The IESG , lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 21:06:19 -0000 Fixing the simple issues first. Clipping out the rest of the text. > Is there anything different between an "EID-to-RLOC Map-Request" and = just a > "Map-Request"? (Same question for "Map-Reply", too.) No. But Map-Requests are used for lookups in the mapping system as well = as for probing RLOCs for reachability. > Section 3 >=20 > nit: "An address family that pertains to the Data-Plane." is a = sentence > fragment. Fixed. >=20 > Ingress Tunnel Router (ITR): An ITR is a router that resides in a > [...] > mapping lookup in the destination address field. Note that this > destination RLOC MAY be an intermediate, proxy device that has > better knowledge of the EID-to-RLOC mapping closer to the >=20 > This doesn't seem like a 2119 MAY is necessary, but rather a statement = of > fact that may not be known to the encapsulating ITR. Agree. Fixed. >=20 > Specifically, when a service provider prepends a LISP header for > Traffic Engineering purposes, the router that does this is also > regarded as an ITR. The outer RLOC the ISP ITR uses can be based > on the outer destination address (the originating ITR's supplied > RLOC) or the inner destination address (the originating host's > supplied EID). >=20 > I'm confused here, perhaps in multiple ways. Are there now *two* LISP > headers on the packet? Is the "outer RLOC the ISP ITR uses" the = source > RLOC or the destination RLOC? No, just one. When referring to =E2=80=9Cinner=E2=80=9D and =E2=80=9Couter= =E2=80=9D, we mean IP headers. >=20 > Negative Mapping Entry: A negative mapping entry, also known as a > negative cache entry, is an EID-to-RLOC entry where an EID-Prefix > is advertised or stored with no RLOCs. That is, the Locator-Set > for the EID-to-RLOC entry is empty or has an encoded Locator = count > of 0. >=20 > Is "empty" a distinct representation from "locator count of zero=E2=80=9D= ? Yes. Added text to make that more clear. > Section 4 >=20 > An additional LISP header MAY be prepended to packets by a TE-ITR > when re-routing of the path for a packet is desired. A potential > use-case for this would be an ISP router that needs to perform > Traffic Engineering for packets flowing through its network. In = such > a situation, termed "Recursive Tunneling", an ISP transit acts as an > additional ITR, and the RLOC it uses for the new prepended header > would be either a TE-ETR within the ISP (along an intra-ISP traffic > engineered path) or a TE-ETR within another ISP (an inter-ISP = traffic > engineered path, where an agreement to build such a path exists). >=20 > "the RLOC it uses for the new prepnded header", again, this is as the > destination RLOC (vs. source RLOC)? Fixed. > Section 4.1 >=20 > o Map-Replies are sent on the underlying routing system topology > using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. >=20 > Just to check my understanding: is the "underlying routing system = topology" > the same as the "underlay=E2=80=9D? Yes. > Is step (3) just describing more of what step (2) says is "not = described in > this example=E2=80=9D? I lost your reference. Is it to the previous bulleted set or the one = starting with =E2=80=9CClient host1 =E2=80=A6=E2=80=9D? >=20 > When doing ETR/PETR decapsulation: >=20 > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > the case of IPv6) SHOULD be copied from the outer-header 'Time to > Live' field, when the Time to Live value of the outer header is > less than the Time to Live value of the inner header. Failing to > perform this check can cause the Time to Live of the inner header > to increment across encapsulation/decapsulation cycles. This > check is also performed when doing initial encapsulation, when a > packet comes to an ITR or PITR destined for a LISP site. >=20 > Er, what is "this check" that is also performed for initial = encapsulation? > How are there multiple TTL values to compare? =E2=80=9CThis check=E2=80=9D is outer-header-TTL is < the = inner-header-TTL. > o The inner-header 'Differentiated Services Code Point' (DSCP) = field > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be > copied from the outer-header DSCP field ('Traffic Class' field, = in > the case of IPv6) to the inner-header. >=20 > nit: the first "inner-header" seems like an editing remnant? Fixed. This text has changed so many times, it=E2=80=99s not a surprise = it became confusing. >=20 > Section 7.1 >=20 > How is this stateless if it invovles knowledge about the routers = between > the ITR and all possible ETRs (i.e., a set that could change over = time)? The ITR does not keep state about underlay routers between it and the = ETR. > Section 8 >=20 > This 32-bit vs 24-bit thing is pretty hokey for a standards-track > specification (yes, I know that LISP-DDT is not standards track at the > moment). It is actually useful to allow more instance-IDs but not waste extra = bits in the encapsulation header. > Section 9 >=20 > Alternatively, RLOC information MAY be gleaned from received = tunneled >=20 > What is this an alternative to? The list of four options above? Doing a mapping system lookup to get an RLOC-set. > packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache > entry, one learned from the source RLOC of a received encapsulated > packet, is only stored and used for a few seconds, pending > verification. Verification is performed by sending a Map-Request to > the source EID (the inner-header IP source address) of the received > encapsulated packet. >=20 > The source EID is some random end system, right? So this relys on = some > magic in the ETR to detect that there's a Map-Request and reply = directly > instead of passing it on to the EID that won't know what to do with = it? Not following your description. > Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and > might benefit from an explicit section reference to the other = document. Done. >=20 > Section 10 >=20 > What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it > is not marked as well-known at > https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion = is > probably in order. It is defined in the xTR definition. > Section 10.1 >=20 > Note that "ITR" and "ETR" are relative terms here. Both devices = MUST > be implementing both ITR and ETR functionality for the echo nonce > mechanism to operate. >=20 > Perhaps they could be given actual names so as to disambiguate which = steps > are performed with ITR vs. ETR role? They are. An ITR is an encapsulator. An ETR is a decapsulator. This is = defined in the definition section. When the functions are co-located, = they refer to an xTR, also in the definition section. >=20 > The echo-nonce algorithm is bilateral. That is, if one side sets = the > E-bit and the other side is not enabled for echo-noncing, then the > echoing of the nonce does not occur and the requesting side may > erroneously consider the Locator unreachable. An ITR SHOULD only = set > the E-bit in an encapsulated data packet when it knows the ETR is > enabled for echo-noncing. This is conveyed by the E-bit in the = RLOC- > probe Map-Reply message. >=20 > Why is this even optional? If it was mandatory to use, then there = would > not be a question. But at least clarify that the "this" that is = conveyed > is whether the peer supports the echo-nonce algorithm. (Also, subject = to > downgrade.) Because it has cost implications in a hardware implementation. > Section 18 >=20 > o Data-Plane gleaning for creating map-cache entries has been made > optional. If any ITR implementations depend or assume the remote > ETR is gleaning should not do so. >=20 > nit: this is ungrammatical; "they should not" or "Any ITR = implementations > that depend on or assume that" would fix it. Fixed. Thanks. > Section 19.1 >=20 > Presumably IANA also updated the reference column to point to this > document? Yes, from my perspective. Thanks, Dino From nobody Thu Sep 27 14:13:01 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867DA131050; Thu, 27 Sep 2018 14:12:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dfC0F6CF1ehQ; Thu, 27 Sep 2018 14:12:43 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 C8C3D130E09; Thu, 27 Sep 2018 14:12:43 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id a23-v6so2729298pfi.12; Thu, 27 Sep 2018 14:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WRqmSUihWFIvqJYqvVgmzdgjIP1CqpRQka098+Qufic=; b=fSJ9YtBvZ8taCLBnaShpvThfln6t8Mn1LrKTDeFoc0lbYWd4AwI9gam9kgYoENZfyK Jin8mMncddETg/FPpAIv5vq6SrEAugCAEdDxdUfCjzhjycnAzIzvbeAJaBwHYKq42eGs M0t6YJk8eNOWcfxJ1JpSw/9lB/0Hnes747VhOcYvRhkFmuC+Jrz7VRyngmWWARdi63PQ dGVMulGAFKIStH+SpuwUneUl2J/ZBtDUGwBcQBplHlYwEjyA4E6SsfW8BmO2IGebvARu d9GHsBLSsQnH+9347pMhyRWt4/KMsaa45GSZ1EtXo6IdkSZZCIRZ3cG5TONfG+gvO61q KoLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WRqmSUihWFIvqJYqvVgmzdgjIP1CqpRQka098+Qufic=; b=PnXuLAIytQVQQFjh6uOadIGT+ejQplQ81B2SAGL4RI2W+N/Wk7IU11XSzONz8+nUuM vNxv1UKgUWFvNPQ3Opml/vfdyXc51yFlwJn6qITsJ8bp7SJmozcWdcnjkCy+NrPA0hOH JW5+DuQkz9zRwQ+Cd1kMZoziIuHb1Wog3kA7jAIQzp6XmVQ64Uu46l4QsjuAT2AKtHAj KCTbNhZ3cDstuBrcxpvcaGgv3uLUHG4MnOHkVaaBTn6hm/+3PudnlacJhk7tVqSVOrT2 sALMbELohUSed+aJMJJ5ODHGLjSAjWwvHxcswNCyBetbcS76eJIJHIG8sVqBHPIgXh+4 N12g== X-Gm-Message-State: ABuFfoiP+Fu/UWu5PhD1Fq/xvs6AKLSNyQgae5nzrwyhMUCwI6fIstlq WDCkMXD/aa4P4Z7flPw5qJI= X-Google-Smtp-Source: ACcGV61p5KM5VTyuTMWQUJpvi5aG52ch/Kq/9WuEN6ngb3ZmfKj2S+o/yJQ0B8DqJ1+kHwooukJV2A== X-Received: by 2002:a65:5188:: with SMTP id h8-v6mr11896235pgq.288.1538082763295; Thu, 27 Sep 2018 14:12:43 -0700 (PDT) Received: from [172.31.99.184] (96-86-164-193-static.hfc.comcastbusiness.net. [96.86.164.193]) by smtp.gmail.com with ESMTPSA id x24-v6sm5327428pfh.67.2018.09.27.14.12.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 14:12:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 14:12:41 -0700 Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 21:12:49 -0000 Doing the same as I did with Ben=E2=80=99s email. Fixing the simple = stuff first. The simple changes (editorial) will be submitted in -21. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > S 5.3. >> header. >>=20 >> When doing ETR/PETR decapsulation: >>=20 >> o The inner-header 'Time to Live' field (or 'Hop Limit' field, = in >> the case of IPv6) SHOULD be copied from the outer-header 'Time = to >=20 > This should probably be a MUST because there are other protocols that > assume that TTLs get decremented. Agree, changed. It was SHOULD a long time ago because some hardware = couldn=E2=80=99t support this. Technology has moved on. > S 7.1. >> destination site. The two fragments are reassembled at the >> destination host into the single IP datagram that was originated = by >> the source host. Note that reassembly can happen at the ETR if = the >> encapsulated packet was fragmented at or after the ITR. >>=20 >> This behavior MAY be performed by the ITR only when the source = host >=20 > Nit: I think you want to say MUST be, assuming you mean that you can > perform it only if=E2=80=A6. Agree. Same issue as my last comment. >=20 > S 7.2. >> 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated = packet >> with the DF bit set to 1, exceeds what the core network can >> deliver, one of the intermediate routers on the path will = send an >> ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/ >> Fragmentation-Needed to the ITR, respectively. The ITR will >> parse the ICMP message to determine which Locator is affected = by >=20 > What if you are in an environment where ICMP is blocked? You lose. There are mechanisms (un-documented) for the control-plane to = detect this on its own.=20 >=20 > S 9. >> outside of the subset list if it determines that the subset = list >> is unreachable (unless RLOCs are set to a Priority of 255). = Some >> sharing of control exists: the server-side determines the >> destination RLOC list and load distribution while the = client-side >> has the option of using alternatives to this list if RLOCs in = the >> list are unreachable. >=20 > How would you obtain alternative RLOCs? You can use a PETR that is configurable. But we didn=E2=80=99t want to = document interworking mechanisms here. > S 10. >> also acting as an ITR and has traffic to return to the = original >> ITR site, it can use this status information to help select = an >> RLOC. >>=20 >> 2. When an ETR receives an encapsulated packet from an ITR, the >> source RLOC from the outer header of the packet is likely up. >=20 > What does "is likely up" mean? Changed to =E2=80=9Creachable=E2=80=9D. Thanks. Thanks, Dino From nobody Thu Sep 27 14:17:48 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41229130DEA; Thu, 27 Sep 2018 14:17:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153808306724.26331.5266697259550058182@ietfa.amsl.com> Date: Thu, 27 Sep 2018 14:17:47 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-21.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Sep 2018 21:17:47 -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 WG of the IETF. Title : The Locator/ID Separation Protocol (LISP) Authors : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Albert Cabellos Filename : draft-ietf-lisp-rfc6830bis-21.txt Pages : 45 Date : 2018-09-27 Abstract: This document describes the Data-Plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. This document obsoletes RFC 6830. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-21 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-21 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 Sep 27 14:19:03 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4AF131060 for ; Thu, 27 Sep 2018 14:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jlFUYgfxBEqJ for ; Thu, 27 Sep 2018 14:18:47 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 39AA11310DA for ; Thu, 27 Sep 2018 14:18:47 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id k19-v6so2778723pfi.1 for ; Thu, 27 Sep 2018 14:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=fRZsV6q5NvR0+baXW+70SAybPOfm9/vsa2vNZp5nDZ4=; b=Wr3VEgC/bpRUbJSncSW7RbCRYnUEvwlLaEUw3fV41FQagRix++EMPD/GIWjVbsBQxZ oYQ2fCk+xBvLd5hPrMe5/hCaYzA0SPpGifRCom6UHBv8SRC5jSTbDTzVyq7b2PVVhHFD KT4ke4TO24o0WwT45yyRXAXy8HuSMDY3Kz3umwqtGwu5OdMotCpVZWGfeok4NDl/6Jzo 62JvNn7cMhhnqJ9WAbhS+gcSAbEItfnZZCwGAYsyYI7ic1vHmRiVgsSUwTqIhy9zED9O ZbI2C2x9PeAQ1tlAj9ClU4/9ApWfEQ8+ublsKB3LeMjjQMR/Zz415sBbov7/nzGTBrbm n6EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=fRZsV6q5NvR0+baXW+70SAybPOfm9/vsa2vNZp5nDZ4=; b=Eq1lm+3X3SOMrsP/CIjJFxf+JUWi2r8TlD6178k1fcOCxv6WFIXzIyFkmurwtrwfek mQbkaeKyW7oSq+/ZDuOYnfegICrlbCaJkDh0xD3AJ+GOGzBANF0AtYdwCvHHdPi0aBaj 4ubFd0ZtG3L0wOIujacMMl6UbasSZpbkjkzxt6p92S2qIXMuGNm77U1IpoW+8MnK6F00 DIyRN4H5ungnyNyzZt9PA0rBEDQwDTB16EDCAjI43OX22cZevEcNwxUjtc34vjin40yI 1DG12vMj5bAoL0T4KD7YQzM994Y78SBddflNjvkiYwTV6WWfC2ehTPdZFqe1C+a+NDuG wexg== X-Gm-Message-State: ABuFfoigFtCj7dR+wrqh7wBxn86/y5qdV6LLUCvK/4Q83K5R5AYmLLBh 7Tcp0xvWy8BZBYUwttTqUD47M1RM X-Google-Smtp-Source: ACcGV60nXtWNbmnVV5bFRgkb3VNSKuIjs/ld+uyv+rpVYlLac5FIKC1gkiYI9p8uAZflBc6ueKxJaQ== X-Received: by 2002:a63:b4b:: with SMTP id a11-v6mr2733798pgl.97.1538083126528; Thu, 27 Sep 2018 14:18:46 -0700 (PDT) Received: from [172.31.99.184] (96-86-164-193-static.hfc.comcastbusiness.net. [96.86.164.193]) by smtp.gmail.com with ESMTPSA id f6-v6sm4082386pgf.52.2018.09.27.14.18.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 14:18:45 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/alternative; boundary="Apple-Mail=_3424C36A-ABAE-4980-BD4F-559123194E5A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: References: <153808306724.26331.5266697259550058182@ietfa.amsl.com> To: "lisp@ietf.org list" Date: Thu, 27 Sep 2018 14:18:44 -0700 X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-rfc6830bis-21.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 21:19:01 -0000 --Apple-Mail=_3424C36A-ABAE-4980-BD4F-559123194E5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Reflects editorial comments from today=E2=80=99s Telechat. Dino > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-21.txt > Date: September 27, 2018 at 2:17:47 PM PDT > To: > Cc: lisp@ietf.org > Reply-To: lisp@ietf.org >=20 >=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 WG of = the IETF. >=20 > Title : The Locator/ID Separation Protocol (LISP) > Authors : Dino Farinacci > Vince Fuller > Dave Meyer > Darrel Lewis > Albert Cabellos > Filename : draft-ietf-lisp-rfc6830bis-21.txt > Pages : 45 > Date : 2018-09-27 >=20 > Abstract: > This document describes the Data-Plane protocol for the Locator/ID > Separation Protocol (LISP). LISP defines two namespaces, End-point > Identifiers (EIDs) that identify end-hosts and Routing Locators > (RLOCs) that identify network attachment points. With this, LISP > effectively separates control from data, and allows routers to = create > overlay networks. LISP-capable routers exchange encapsulated = packets > according to EID-to-RLOC mappings stored in a local Map-Cache. >=20 > LISP requires no change to either host protocol stacks or to = underlay > routers and offers Traffic Engineering, multihoming and mobility, > among other features. >=20 > This document obsoletes RFC 6830. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-21 > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-21 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-rfc6830bis-21 >=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 --Apple-Mail=_3424C36A-ABAE-4980-BD4F-559123194E5A Content-Type: multipart/mixed; boundary="Apple-Mail=_CF031218-2624-4E86-AB19-1205EB0524B1" --Apple-Mail=_CF031218-2624-4E86-AB19-1205EB0524B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Reflects editorial comments from today=E2=80=99s = Telechat.

Dino

= --Apple-Mail=_CF031218-2624-4E86-AB19-1205EB0524B1 Content-Disposition: attachment; filename=rfcdiff-6830bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6830bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6830bis-20.txt - = draft-ietf-lisp-rfc6830bis-21.txt=20 =20 =20 =20 =20 =20 =20 = =
< draft-ietf-lisp-rfc6830bis-20.txt  =  draft-ietf-lisp-rfc6830bis-21.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = V. Fuller Internet-Draft = V. Fuller
Obsoletes: 6830 = (if approved) D. Meyer = Obsoletes: 6830 (if approved) = D. Meyer
Intended status: = Standards Track D. Lewis = Intended status: Standards Track = D. Lewis
Expires: March = 30, 2019 = Cisco Systems Expires: March 31, 2019 Cisco = Systems
= A. Cabellos (Ed.) = A. Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= September 26, 2018 = September 27, 2018
=
= The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol = (LISP)
= draft-ietf-lisp-rfc6830bis-20 = = draft-ietf-lisp-rfc6830bis-21
=
Abstract = Abstract
=
This document = describes the Data-Plane protocol for the Locator/ID This document describes the Data-Plane protocol for = the Locator/ID
Separation = Protocol (LISP). LISP defines two namespaces, End-point = Separation Protocol (LISP). LISP defines = two namespaces, End-point
Identifiers = (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and = Routing Locators
(RLOCs) that = identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. = With this, LISP
effectively = separates control from data, and allows routers to create = effectively separates control from data, and = allows routers to create
overlay = networks. LISP-capable routers exchange encapsulated packets = overlay networks. LISP-capable routers = exchange encapsulated packets
according to = EID-to-RLOC mappings stored in a local Map-Cache. according to EID-to-RLOC mappings stored in a local = Map-Cache.
=
skipping to = change at = page 1, line 46 =C2=B6 = skipping to change at page 1, line 46 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on March 30, = 2019. This Internet-Draft will = expire on March 31, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 3, line 7 =C2=B6 = skipping to change at page 3, line 7 =C2=B6
17. Network = Management Considerations . . . . . . . . . . . . . . 33 = 17. Network Management Considerations . . . = . . . . . . . . . . . 33
18. Changes = since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 = 18. Changes since RFC 6830 . . . . . . . . = . . . . . . . . . . . 33
19. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 33 = 19. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 33
19.1. LISP = UDP Port Numbers . . . . . . . . . . . . . . . . . 34 = 19.1. LISP UDP Port Numbers . . . . . . = . . . . . . . . . . . 34
20. References = . . . . . . . . . . . . . . . . . . . . . . . . . 34 20. References . . . . . . . . . . . . . . . . . . . = . . . . . . 34
20.1. = Normative References . . . . . . . . . . . . . . . . . . 34 = 20.1. Normative References . . . . . . . = . . . . . . . . . . . 34
20.2. = Informative References . . . . . . . . . . . . . . . . . 35 = 20.2. Informative References . . . . . . = . . . . . . . . . . . 35
=
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 39 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 39 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 39
B.1. = Changes to draft-ietf-lisp-rfc6830bis-20 = . . . . . . . . 40 B.1. = Changes to draft-ietf-lisp-rfc6830bis-21 = . . . . . . . . 40
B.2. = Changes to draft-ietf-lisp-rfc6830bis-19 = . . . . . . . . 40 B.2. = Changes to draft-ietf-lisp-rfc6830bis-20 = . . . . . . . . 40
B.3. = Changes to draft-ietf-lisp-rfc6830bis-18 = . . . . . . . . 40 B.3. = Changes to draft-ietf-lisp-rfc6830bis-19 = . . . . . . . . 40
B.4. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 40 B.4. = Changes to draft-ietf-lisp-rfc6830bis-18 = . . . . . . . . 40
B.5. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 40 B.5. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 40
B.6. = Changes to draft-ietf-lisp-rfc6830bis-15 = . . . . . . . . 40 B.6. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 40
B.7. = Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 41 = B.7. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . = 40
B.8. Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 41 B.8. Changes to = draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 41
B.9. Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 41 B.9. Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 41
B.10. Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 41 B.10. Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 41
B.11. Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 41 B.11. Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 41
B.12. Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 42 B.12. Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 41
B.13. Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 42 B.13. Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 42
B.14. Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 42 B.14. Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 42
B.15. Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 42
B.16. Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 43 B.16. Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 42
B.17. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 43 B.17. Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 43
B.18. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 43 B.18. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 43
B.19. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 43 B.19. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 43
B.20. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 43 B.20. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 43
B.21. Changes to draft-ietf-lisp-rfc6830bis-00 = . . . . . . . . 44 B.21. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 43
= B.22. = Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 44
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 44
=
1. = Introduction 1. Introduction
=
This document = describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier = Separation Protocol
(LISP). LISP = is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built = around the
fundamental = idea of separating the topological location of a network = fundamental idea of separating the = topological location of a network
attachment = point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. = As a result
LISP creates = two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers = (EIDs), that are
used to = identify end-hosts (e.g., nodes or Virtual Machines) and = used to identify end-hosts (e.g., nodes or = Virtual Machines) and
=
skipping to = change at = page 4, line 34 =C2=B6 = skipping to change at page 4, line 36 =C2=B6
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
"SHOULD", = "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = "SHOULD", "SHOULD NOT", "RECOMMENDED", = "MAY", and "OPTIONAL" in this
document are = to be interpreted as described in [RFC2119] and document are to be interpreted as described in = [RFC2119] and
= [RFC8174]. [RFC8174].
=
3. Definition of = Terms 3. Definition of Terms
=
Address Family = Identifier (AFI): AFI is a term used to describe an Address Family Identifier (AFI): AFI is a term used = to describe an
address = encoding in a packet. An address family that pertains to = address encoding in a packet. An address = family that pertains to
the Data-Plane. See [AFN] and [RFC3232] for = details. An AFI addresses found in Data-Plane headers. See = [AFN] and [RFC3232]
value of = 0 used in this specification indicates an unspecified for details. An AFI value of 0 used in this = specification
encoded = address where the length of the address is 0 octets indicates an unspecified encoded address where = the length of the
following = the 16-bit AFI value of 0. = address is 0 octets following the 16-bit AFI value of 0.
=
Anycast = Address: Anycast Address is a term used in this document to = Anycast Address: Anycast Address is a term = used in this document to
refer to = the same IPv4 or IPv6 address configured and used on refer to the same IPv4 or IPv6 address configured = and used on
multiple = systems at the same time. An EID or RLOC can be an multiple systems at the same time. An EID or RLOC = can be an
anycast = address in each of their own address spaces. anycast address in each of their own address = spaces.
=
Client-side: = Client-side is a term used in this document to indicate = Client-side: Client-side is a term used in = this document to indicate
a = connection initiation attempt by an end-system represented by = an a connection initiation = attempt by an end-system represented by an
= EID. EID.
=
=
skipping to = change at = page 6, line 37 =C2=B6 = skipping to change at page 6, line 40 =C2=B6
to an = LEID. to an LEID.
=
Ingress Tunnel = Router (ITR): An ITR is a router that resides in a Ingress Tunnel Router (ITR): An ITR is a router = that resides in a
LISP site. = Packets sent by sources inside of the LISP site to LISP site. Packets sent by sources inside of the = LISP site to
= destinations outside of the site are candidates for = encapsulation destinations = outside of the site are candidates for encapsulation
by the ITR. = The ITR treats the IP destination address as an EID by the ITR. The ITR treats the IP destination = address as an EID
and = performs an EID-to-RLOC mapping lookup. The router then = and performs an EID-to-RLOC mapping = lookup. The router then
prepends an = "outer" IP header with one of its routable RLOCs (in prepends an "outer" IP header with one of its = routable RLOCs (in
the RLOC = space) in the source address field and the result of the = the RLOC space) in the source address = field and the result of the
mapping = lookup in the destination address field. Note that this = mapping lookup in the destination address = field. Note that this
= destination RLOC MAY be an intermediate, = proxy device that has = destination RLOC may be an intermediate, = proxy device that has
better = knowledge of the EID-to-RLOC mapping closer to the better knowledge of the EID-to-RLOC mapping closer = to the
destination = EID. In general, an ITR receives IP packets from site destination EID. In general, an ITR receives IP = packets from site
end-systems = on one side and sends LISP-encapsulated IP packets end-systems on one side and sends = LISP-encapsulated IP packets
toward the = Internet on the other side. = toward the Internet on the other side.
=
= Specifically, when a service provider prepends a LISP header = for Specifically, when a service = provider prepends a LISP header for
Traffic = Engineering purposes, the router that does this is also = Traffic Engineering purposes, the router = that does this is also
regarded as = an ITR. The outer RLOC the ISP ITR uses can be based regarded as an ITR. The outer RLOC the ISP ITR = uses can be based
on the = outer destination address (the originating ITR's supplied = on the outer destination address (the = originating ITR's supplied
RLOC) or = the inner destination address (the originating host's RLOC) or the inner destination address (the = originating host's
=
skipping to = change at = page 7, line 26 =C2=B6 = skipping to change at page 7, line 29 =C2=B6
= Locator-Status-Bits (LSBs): Locator-Status-Bits are present in = the Locator-Status-Bits (LSBs): = Locator-Status-Bits are present in the
LISP = header. They are used by ITRs to inform ETRs about the up/ = LISP header. They are used by ITRs to = inform ETRs about the up/
down status = of all ETRs at the local site. These bits are used as down status of all ETRs at the local site. These = bits are used as
a hint to = convey up/down router status and not path reachability a hint to convey up/down router status and not = path reachability
status. = The LSBs can be verified by use of one of the Locator status. The LSBs can be verified by use of one of = the Locator
= reachability algorithms described in Section 10. reachability algorithms described in Section = 10.
=
Negative = Mapping Entry: A negative mapping entry, also known as a = Negative Mapping Entry: A negative mapping = entry, also known as a
negative = cache entry, is an EID-to-RLOC entry where an EID-Prefix = negative cache entry, is an EID-to-RLOC = entry where an EID-Prefix
is = advertised or stored with no RLOCs. That is, the Locator-Set = is advertised or stored with no RLOCs. = That is, the Locator-Set
for the = EID-to-RLOC entry is empty or has an = encoded Locator count for the = EID-to-RLOC entry is empty, one with an = encoded Locator
of 0. = This type of entry could be used to describe a prefix from = count of 0. This type of entry could be = used to describe a prefix
a = non-LISP site, which is explicitly not in the mapping database. = from a non-LISP site, which is = explicitly not in the mapping
There are = a set of well-defined actions that are encoded in a database. There are a set of well-defined = actions that are
Negative = Map-Reply. encoded in a = Negative Map-Reply.
=
Proxy-ETR = (PETR): A PETR is defined and described in [RFC6832]. A = Proxy-ETR (PETR): A PETR is defined and = described in [RFC6832]. A
PETR acts = like an ETR but does so on behalf of LISP sites that PETR acts like an ETR but does so on behalf of = LISP sites that
send = packets to destinations at non-LISP sites. send packets to destinations at non-LISP = sites.
=
Proxy-ITR = (PITR): A PITR is defined and described in [RFC6832]. A = Proxy-ITR (PITR): A PITR is defined and = described in [RFC6832]. A
PITR acts = like an ITR but does so on behalf of non-LISP sites that = PITR acts like an ITR but does so on = behalf of non-LISP sites that
send = packets to destinations at LISP sites. = send packets to destinations at LISP sites.
=
Recursive = Tunneling: Recursive Tunneling occurs when a packet has = Recursive Tunneling: Recursive Tunneling = occurs when a packet has
=
skipping to = change at = page 10, line 18 =C2=B6 = skipping to change at page 10, line = 21 =C2=B6
= encapsulated for inter-site communication. encapsulated for inter-site communication.
=
o EIDs MAY = also be structured (subnetted) in a manner suitable for = o EIDs MAY also be structured (subnetted) = in a manner suitable for
local = routing within an Autonomous System (AS). local routing within an Autonomous System = (AS).
=
An additional = LISP header MAY be prepended to packets by a TE-ITR An additional LISP header MAY be prepended to packets = by a TE-ITR
when = re-routing of the path for a packet is desired. A potential = when re-routing of the path for a packet is = desired. A potential
use-case for = this would be an ISP router that needs to perform use-case for this would be an ISP router that needs = to perform
Traffic = Engineering for packets flowing through its network. In such = Traffic Engineering for packets flowing = through its network. In such
a situation, = termed "Recursive Tunneling", an ISP transit acts as an = a situation, termed "Recursive Tunneling", = an ISP transit acts as an
additional = ITR, and the RLOC it uses for the new prepended header additional ITR, and the destination RLOC it uses for the new
would be = either a TE-ETR within the ISP (along an intra-ISP traffic = prepended header would be either a TE-ETR = within the ISP (along an
engineered = path) or a TE-ETR within another ISP (an inter-ISP traffic = intra-ISP traffic engineered path) or a = TE-ETR within another ISP (an
engineered = path, where an agreement to build such a path exists). inter-ISP traffic engineered path, where an = agreement to build such a
= path exists).
=
In order to = avoid excessive packet overhead as well as possible In order to avoid excessive packet overhead as well = as possible
encapsulation = loops, this document recommends that a maximum of two encapsulation loops, this document recommends that a = maximum of two
LISP headers = can be prepended to a packet. For initial LISP LISP headers can be prepended to a packet. For = initial LISP
deployments, = it is assumed that two headers is sufficient, where the = deployments, it is assumed that two headers = is sufficient, where the
first = prepended header is used at a site for Location/Identity = first prepended header is used at a site for = Location/Identity
separation and = the second prepended header is used inside a service separation and the second prepended header is used = inside a service
provider for = Traffic Engineering purposes. = provider for Traffic Engineering purposes.
=
Tunnel Routers = can be placed fairly flexibly in a multi-AS topology. Tunnel Routers can be placed fairly flexibly in a = multi-AS topology.
=
skipping to = change at = page 19, line 10 =C2=B6 = skipping to change at page 19, line = 10 =C2=B6
of the IPv6 = 'Traffic Class' field) requires special treatment in of the IPv6 'Traffic Class' field) requires = special treatment in
order to = avoid discarding indications of congestion [RFC6040]. order to avoid discarding indications of = congestion [RFC6040].
ITR = encapsulation MUST copy the 2-bit 'ECN' field from the inner = ITR encapsulation MUST copy the 2-bit = 'ECN' field from the inner
header to = the outer header. Re-encapsulation MUST copy the 2-bit = header to the outer header. = Re-encapsulation MUST copy the 2-bit
'ECN' field = from the stripped outer header to the new outer 'ECN' field from the stripped outer header to the = new outer
= header. header.
=
When doing = ETR/PETR decapsulation: When doing = ETR/PETR decapsulation:
=
o The = inner-header 'Time to Live' field (or 'Hop Limit' field, in = o The inner-header 'Time to Live' field (or = 'Hop Limit' field, in
the case = of IPv6) SHOULD be copied from the = outer-header 'Time to the case = of IPv6) MUST be copied from the = outer-header 'Time to
Live' = field, when the Time to Live value of the outer header is = Live' field, when the Time to Live value = of the outer header is
less than = the Time to Live value of the inner header. Failing to = less than the Time to Live value of the = inner header. Failing to
perform = this check can cause the Time to Live of the inner header = perform this check can cause the Time to = Live of the inner header
to = increment across encapsulation/decapsulation cycles. This = to increment across = encapsulation/decapsulation cycles. This
check is = also performed when doing initial encapsulation, when a = check is also performed when doing = initial encapsulation, when a
packet = comes to an ITR or PITR destined for a LISP site. packet comes to an ITR or PITR destined for a LISP = site.
=
o The inner-header 'Differentiated Services Code = Point' (DSCP) field o The outer-header 'Differentiated Services Code = Point' (DSCP) field
(or the = 'Traffic Class' field, in the case of IPv6) SHOULD be (or the 'Traffic Class' field, in the case of = IPv6) SHOULD be
copied from = the outer-header DSCP field ('Traffic Class' field, in copied from the outer-header DSCP field ('Traffic = Class' field, in
the case of = IPv6) to the inner-header. the = case of IPv6) to the inner-header.
=
o The = 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 = o The 'Explicit Congestion Notification' = (ECN) field (bits 6 and 7
of the IPv6 = 'Traffic Class' field) requires special treatment in of the IPv6 'Traffic Class' field) requires = special treatment in
order to = avoid discarding indications of congestion [RFC6040]. If = order to avoid discarding indications of = congestion [RFC6040]. If
the 'ECN' = field contains a congestion indication codepoint (the the 'ECN' field contains a congestion indication = codepoint (the
value is = '11', the Congestion Experienced (CE) codepoint), then value is '11', the Congestion Experienced (CE) = codepoint), then
ETR = decapsulation MUST copy the 2-bit 'ECN' field from the ETR decapsulation MUST copy the 2-bit 'ECN' field = from the
=
skipping to = change at = page 21, line 45 =C2=B6 = skipping to change at page 21, line = 45 =C2=B6
MTU between = the ITR and its correspondent ETR. = MTU between the ITR and its correspondent ETR.
=
When an ETR = receives encapsulated fragments, it treats them as two When an ETR receives encapsulated fragments, it = treats them as two
individually = encapsulated packets. It strips the LISP headers and individually encapsulated packets. It strips the = LISP headers and
then forwards = each fragment to the destination host of the then forwards each fragment to the destination host = of the
destination = site. The two fragments are reassembled at the destination site. The two fragments are reassembled = at the
destination = host into the single IP datagram that was originated by = destination host into the single IP datagram = that was originated by
the source = host. Note that reassembly can happen at the ETR if the = the source host. Note that reassembly can = happen at the ETR if the
encapsulated = packet was fragmented at or after the ITR. encapsulated packet was fragmented at or after the = ITR.
=
This = behavior MAY be performed by the ITR only = when the source host This behavior = MUST be performed by the ITR only when the = source host
originates a = packet with the 'DF' field of the IP header set to 0. originates a packet with the 'DF' field of the IP = header set to 0.
When the 'DF' = field of the IP header is set to 1, or the packet is an = When the 'DF' field of the IP header is set = to 1, or the packet is an
IPv6 packet = originated by the source host, the ITR will drop the IPv6 packet originated by the source host, the ITR = will drop the
packet when = the size is greater than L and send an ICMP Unreachable/ = packet when the size is greater than L and send an ICMPv4 ICMP
Fragmentation-Needed message to the source = with a value of S, where S Unreachable/Fragmentation-Needed or ICMPv6 "Packet Too = Big" message
is (L - = H). to the source with a value of = S, where S is (L - H).
=
When the = outer-header encapsulation uses an IPv4 header, an When the outer-header encapsulation uses an IPv4 = header, an
implementation = SHOULD set the DF bit to 1 so ETR fragment reassembly implementation SHOULD set the DF bit to 1 so ETR = fragment reassembly
can be = avoided. An implementation MAY set the DF bit in such headers = can be avoided. An implementation MAY set = the DF bit in such headers
to 0 if it has = good reason to believe there are unresolvable path MTU to 0 if it has good reason to believe there are = unresolvable path MTU
issues between = the sending ITR and the receiving ETR. = issues between the sending ITR and the receiving ETR.
=
This = specification RECOMMENDS that L be defined as 1500. This specification RECOMMENDS that L be defined as = 1500.
=
7.2. A Stateful = Solution to MTU Handling 7.2. A = Stateful Solution to MTU Handling
=
skipping = to change at page 24, line = 51 =C2=B6 = skipping to change at page 24, line = 51 =C2=B6
encapsulated = packet. A reply to this "verifying Map-Request" is used = encapsulated packet. A reply to this = "verifying Map-Request" is used
to fully = populate the Map-Cache entry for the "gleaned" EID and is = to fully populate the Map-Cache entry for = the "gleaned" EID and is
stored and = used for the time indicated from the 'TTL' field of a stored and used for the time indicated from the 'TTL' = field of a
received = Map-Reply. When a verified Map-Cache entry is stored, data = received Map-Reply. When a verified = Map-Cache entry is stored, data
gleaning no = longer occurs for subsequent packets that have a source = gleaning no longer occurs for subsequent = packets that have a source
EID that = matches the EID-Prefix of the verified entry. This EID that matches the EID-Prefix of the verified = entry. This
"gleaning" = mechanism is OPTIONAL, refer to Section 16 for security = "gleaning" mechanism is OPTIONAL, refer to = Section 16 for security
issues = regarding this mechanism. issues = regarding this mechanism.
=
RLOCs that = appear in EID-to-RLOC Map-Reply messages are assumed to be = RLOCs that appear in EID-to-RLOC Map-Reply = messages are assumed to be
reachable = when the R-bit for the Locator record is set to 1. When = reachable when the R-bit [I-D.ietf-lisp-rfc6833bis] for the = Locator
the R-bit is = set to 0, an ITR or PITR MUST NOT encapsulate to the record is set to 1. When the R-bit is set to 0, an = ITR or PITR MUST
RLOC. = Neither the information contained in a Map-Reply nor that = NOT encapsulate to the RLOC. Neither the = information contained in a
stored in = the mapping database system provides reachability Map-Reply nor that stored in the mapping database = system provides
information = for RLOCs. Note that reachability is not part of the reachability information for RLOCs. Note that = reachability is not
mapping = system and is determined using one or more of the Routing = part of the mapping system and is = determined using one or more of the
Locator = reachability algorithms described in the next section. Routing Locator reachability algorithms described in = the next
= section.
=
10. Routing = Locator Reachability 10. Routing = Locator Reachability
=
Several = Data-Plane mechanisms for determining RLOC reachability are = Several Data-Plane mechanisms for = determining RLOC reachability are
currently = defined. Please note that additional Control-Plane based = currently defined. Please note that = additional Control-Plane based
reachability = mechanisms are defined in [I-D.ietf-lisp-rfc6833bis]. reachability mechanisms are defined in = [I-D.ietf-lisp-rfc6833bis].
=
1. An ETR MAY = examine the Locator-Status-Bits in the LISP header of 1. An ETR MAY examine the Locator-Status-Bits in the = LISP header of
an = encapsulated data packet received from an ITR. If the ETR is = an encapsulated data packet received = from an ITR. If the ETR is
also = acting as an ITR and has traffic to return to the original = also acting as an ITR and has traffic to = return to the original
ITR site, = it can use this status information to help select an ITR site, it can use this status information to = help select an
= RLOC. RLOC.
=
2. When an = ETR receives an encapsulated packet from an ITR, the 2. When an ETR receives an encapsulated packet from = an ITR, the
source = RLOC from the outer header of the packet is likely up. = source RLOC from the outer header of the packet is likely to be
= = reachable.
=
3. An ITR/ETR = pair can use the 'Echo-Noncing' Locator reachability 3. An ITR/ETR pair can use the 'Echo-Noncing' = Locator reachability
algorithms = described in this section. = algorithms described in this section.
=
When = determining Locator up/down reachability by examining the = When determining Locator up/down = reachability by examining the
= Locator-Status-Bits from the LISP-encapsulated data packet, an = ETR Locator-Status-Bits from the = LISP-encapsulated data packet, an ETR
will receive = up-to-date status from an encapsulating ITR about will receive up-to-date status from an encapsulating = ITR about
reachability = for all ETRs at the site. CE-based ITRs at the source reachability for all ETRs at the site. CE-based ITRs = at the source
site can = determine reachability relative to each other using the site = site can determine reachability relative to = each other using the site
IGP as = follows: IGP as follows:
=
skipping = to change at page 33, line = 36 =C2=B6 = skipping to change at page 33, line = 36 =C2=B6
than 2 LISP = headers, an implementation can support more. However, than 2 LISP headers, an implementation can support = more. However,
it is = RECOMMENDED that a maximum of two LISP headers can be it is RECOMMENDED that a maximum of two LISP = headers can be
prepended = to a packet. prepended to a = packet.
=
o The 3 = reserved flag bits in the LISP header have been allocated = o The 3 reserved flag bits in the LISP = header have been allocated
for = [RFC8061]. The low-order 2 bits of the 3-bit field (now named = for [RFC8061]. The low-order 2 bits of = the 3-bit field (now named
the KK = bits) are used as a key identifier. The 1 remaining bit is = the KK bits) are used as a key = identifier. The 1 remaining bit is
still = documented as reserved. still = documented as reserved.
=
o Data-Plane = gleaning for creating map-cache entries has been made o Data-Plane gleaning for creating map-cache entries = has been made
optional. = If any ITR implementations depend or = assume the remote optional. = Any ITR implementations that depend on or = assume the
ETR is = gleaning should not do so. This does not create any remote ETR is gleaning should not do so. This = does not create any
= interoperability problems since the control-plane map-cache = interoperability problems since the = control-plane map-cache
population = procedures are unilateral and are the typical method population procedures are unilateral and are the = typical method
for = map-cache population. for = map-cache population.
=
o The bulk of = the changes to this document which reduces its length o The bulk of the changes to this document which = reduces its length
are due to = moving the LISP control-plane messaging and procedures are due to moving the LISP control-plane messaging = and procedures
to = [I-D.ietf-lisp-rfc6833bis]. to = [I-D.ietf-lisp-rfc6833bis].
=
19. IANA = Considerations 19. IANA = Considerations
=
=
skipping = to change at page 34, line = 25 =C2=B6 = skipping to change at page 34, line = 25 =C2=B6
20.1. Normative = References 20.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6833bis] = [I-D.ietf-lisp-rfc6833bis]
= Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. = Cabellos-Aparicio,
= "Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) = Control-Plane",
= draft-ietf-lisp-rfc6833bis-15 (work in = progress), = draft-ietf-lisp-rfc6833bis-16 (work in = progress),
= September 2018. = September 2018.
=
[RFC0768] = Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD = 6, RFC 768,
DOI = 10.17487/RFC0768, August 1980, = DOI 10.17487/RFC0768, August 1980,
= <https://www.rfc-editor.org/info/rfc768>. = <https://www.rfc-editor.org/info/rfc768>.
=
[RFC0791] = Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, = RFC 791,
DOI = 10.17487/RFC0791, September 1981, = DOI 10.17487/RFC0791, September 1981,
= <https://www.rfc-editor.org/info/rfc791>. = <https://www.rfc-editor.org/info/rfc791>.
=
=
skipping = to change at page 40, line = 5 =C2=B6 = skipping to change at page 40, line = 5 =C2=B6
The LISP = working group would like to give a special thanks to Jari = The LISP working group would like to give a = special thanks to Jari
Arkko, the = Internet Area AD at the time that the set of LISP Arkko, the Internet Area AD at the time that the set = of LISP
documents were = being prepared for IESG last call, and for his documents were being prepared for IESG last call, and = for his
meticulous = reviews and detailed commentaries on the 7 working group = meticulous reviews and detailed commentaries = on the 7 working group
last call = documents progressing toward standards-track RFCs. last call documents progressing toward = standards-track RFCs.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6830bis-20 B.1. = Changes to draft-ietf-lisp-rfc6830bis-21
=
= o Late-September = 2018.
=
= o Changes to = reflect comments from Sep 27th Telechat.
=
= B.2. Changes to = draft-ietf-lisp-rfc6830bis-20
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o Fix old = reference to RFC3168, changed to RFC6040. o Fix old reference to RFC3168, changed to = RFC6040.
=
B.2. Changes to = draft-ietf-lisp-rfc6830bis-19 B.3. Changes to = draft-ietf-lisp-rfc6830bis-19
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o More = editorial changes. o More = editorial changes.
=
B.3. Changes to = draft-ietf-lisp-rfc6830bis-18 B.4. Changes to = draft-ietf-lisp-rfc6830bis-18
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Secdir review (Mirja). o Changes to reflect comments from Secdir review = (Mirja).
=
B.4. Changes to = draft-ietf-lisp-rfc6830bis-17 B.5. Changes to = draft-ietf-lisp-rfc6830bis-17
=
o Posted = September 2018. o Posted September = 2018.
=
o Indicate in = the "Changes since RFC 6830" section why the document o Indicate in the "Changes since RFC 6830" section = why the document
has been = shortened in length. has been = shortened in length.
=
o Make = reference to RFC 8085 about UDP congestion control. o Make reference to RFC 8085 about UDP congestion = control.
=
o More = editorial changes from multiple IESG reviews. o More editorial changes from multiple IESG = reviews.
=
B.5. Changes to = draft-ietf-lisp-rfc6830bis-16 B.6. Changes to = draft-ietf-lisp-rfc6830bis-16
=
o Posted late = August 2018. o Posted late August = 2018.
=
o Distinguish = the message type names between ICMP for IPv4 and ICMP o Distinguish the message type names between ICMP = for IPv4 and ICMP
for IPv6 = for handling MTU issues. for = IPv6 for handling MTU issues.
=
B.6. Changes to = draft-ietf-lisp-rfc6830bis-15 B.7. Changes to = draft-ietf-lisp-rfc6830bis-15
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6830" so implementers are o Added section "Changes since RFC 6830" so = implementers are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.7. Changes to = draft-ietf-lisp-rfc6830bis-14 B.8. Changes to = draft-ietf-lisp-rfc6830bis-14
=
o Posted July = 2018 IETF week. o Posted July 2018 = IETF week.
=
o Put = obsolete of RFC 6830 in Intro section in addition to abstract. = o Put obsolete of RFC 6830 in Intro section = in addition to abstract.
=
B.8. Changes to = draft-ietf-lisp-rfc6830bis-13 B.9. Changes to = draft-ietf-lisp-rfc6830bis-13
=
o Posted = March IETF Week 2018. o Posted = March IETF Week 2018.
=
o Clarified = that a new nonce is required per RLOC. = o Clarified that a new nonce is required per RLOC.
=
o Removed = 'Clock Sweep' section. This text must be placed in a new = o Removed 'Clock Sweep' section. This text = must be placed in a new
OAM = document. OAM document.
=
o Some = references changed from normative to informative o Some references changed from normative to = informative
=
B.9. Changes to = draft-ietf-lisp-rfc6830bis-12 B.10. Changes to = draft-ietf-lisp-rfc6830bis-12
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status. o Fixed Luigi editorial comments to ready draft for = RFC status.
=
B.10. Changes to = draft-ietf-lisp-rfc6830bis-11 B.11. Changes to = draft-ietf-lisp-rfc6830bis-11
=
o Posted = March 2018. o Posted March = 2018.
=
o Removed = sections 16, 17 and 18 (Mobility, Deployment and o Removed sections 16, 17 and 18 (Mobility, = Deployment and
Traceroute = considerations). This text must be placed in a new OAM = Traceroute considerations). This text = must be placed in a new OAM
= document. document.
=
B.11. Changes to = draft-ietf-lisp-rfc6830bis-10 B.12. Changes to = draft-ietf-lisp-rfc6830bis-10
=
o Posted = March 2018. o Posted March = 2018.
=
o Updated = section 'Router Locator Selection' stating that the Data- = o Updated section 'Router Locator = Selection' stating that the Data-
Plane MUST = follow what's stored in the Map-Cache (priorities and Plane MUST follow what's stored in the Map-Cache = (priorities and
= weights). weights).
=
o Section = 'Routing Locator Reachability': Removed bullet point 2 o Section 'Routing Locator Reachability': Removed = bullet point 2
(ICMP = Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port = (ICMP Network/Host Unreachable),3 (hints = from BGP),4 (ICMP Port
= Unreachable),5 (receive a Map-Reply as a response) and RLOC = Unreachable),5 (receive a Map-Reply as a = response) and RLOC
= probing probing
=
o Removed = 'Solicit-Map Request'. o Removed = 'Solicit-Map Request'.
=
B.12. Changes to = draft-ietf-lisp-rfc6830bis-09 B.13. Changes to = draft-ietf-lisp-rfc6830bis-09
=
o Posted = January 2018. o Posted January = 2018.
=
o Add more = details in section 5.3 about DSCP processing during o Add more details in section 5.3 about DSCP = processing during
= encapsulation and decapsulation. = encapsulation and decapsulation.
=
o Added = clarity to definitions in the Definition of Terms section = o Added clarity to definitions in the = Definition of Terms section
from = various commenters. from various = commenters.
=
o Removed PA = and PI definitions from Definition of Terms section. o Removed PA and PI definitions from Definition of = Terms section.
=
o More = editorial changes. o More = editorial changes.
=
o Removed = 4342 from IANA section and move to RFC6833 IANA section. = o Removed 4342 from IANA section and move = to RFC6833 IANA section.
=
B.13. Changes to = draft-ietf-lisp-rfc6830bis-08 B.14. Changes to = draft-ietf-lisp-rfc6830bis-08
=
o Posted = January 2018. o Posted January = 2018.
=
o Remove = references to research work for any protocol mechanisms. = o Remove references to research work for = any protocol mechanisms.
=
o Document = scanned to make sure it is RFC 2119 compliant. o Document scanned to make sure it is RFC 2119 = compliant.
=
o Made = changes to reflect comments from document WG shepherd Luigi = o Made changes to reflect comments from = document WG shepherd Luigi
= Iannone. Iannone.
=
o Ran IDNITs = on the document. o Ran IDNITs on = the document.
=
B.14. Changes to = draft-ietf-lisp-rfc6830bis-07 B.15. Changes to = draft-ietf-lisp-rfc6830bis-07
=
o Posted = November 2017. o Posted November = 2017.
=
o Rephrase = how Instance-IDs are used and don't refer to [RFC1918] o Rephrase how Instance-IDs are used and don't refer = to [RFC1918]
= addresses. addresses.
=
B.15. Changes to = draft-ietf-lisp-rfc6830bis-06 B.16. Changes to = draft-ietf-lisp-rfc6830bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Put RTR = definition before it is used. o = Put RTR definition before it is used.
=
o Rename = references that are now working group drafts. o Rename references that are now working group = drafts.
=
o Remove = "EIDs MUST NOT be used as used by a host to refer to other = o Remove "EIDs MUST NOT be used as used by = a host to refer to other
hosts. = Note that EID blocks MAY LISP RLOCs". = hosts. Note that EID blocks MAY LISP RLOCs".
=
=
skipping = to change at page 43, line = 15 =C2=B6 = skipping to change at page 43, line = 15 =C2=B6
o ETRs may, = rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send = Map-Replies.
=
o Recommend, = rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation = headers to 2.
=
o Reference = VPN draft when introducing Instance-ID. = o Reference VPN draft when introducing Instance-ID.
=
o Indicate = that SMRs can be sent when ITR/ETR are in the same node. = o Indicate that SMRs can be sent when = ITR/ETR are in the same node.
=
o Clarify = when private addresses can be used. = o Clarify when private addresses can be used.
=
B.16. Changes to = draft-ietf-lisp-rfc6830bis-05 B.17. Changes to = draft-ietf-lisp-rfc6830bis-05
=
o Posted = August 2017. o Posted August = 2017.
=
o Make it = clear that a Re-encapsulating Tunnel Router is an RTR. o Make it clear that a Re-encapsulating Tunnel = Router is an RTR.
=
B.17. Changes to = draft-ietf-lisp-rfc6830bis-04 B.18. Changes to = draft-ietf-lisp-rfc6830bis-04
=
o Posted July = 2017. o Posted July 2017.
=
o Changed = reference of IPv6 RFC2460 to RFC8200. = o Changed reference of IPv6 RFC2460 to RFC8200.
=
o Indicate = that the applicability statement for UDP zero checksums = o Indicate that the applicability statement = for UDP zero checksums
over IPv6 = adheres to RFC6936. over IPv6 = adheres to RFC6936.
=
B.18. Changes to = draft-ietf-lisp-rfc6830bis-03 B.19. Changes to = draft-ietf-lisp-rfc6830bis-03
=
o Posted May = 2017. o Posted May 2017.
=
o Move the = control-plane related codepoints in the IANA o Move the control-plane related codepoints in the = IANA
= Considerations section to RFC6833bis. = Considerations section to RFC6833bis.
=
B.19. Changes to = draft-ietf-lisp-rfc6830bis-02 B.20. Changes to = draft-ietf-lisp-rfc6830bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Reflect = some editorial comments from Damien Sausez. o Reflect some editorial comments from Damien = Sausez.
=
B.20. Changes to = draft-ietf-lisp-rfc6830bis-01 B.21. Changes to = draft-ietf-lisp-rfc6830bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Change = references from RFC6833 to RFC6833bis. = o Change references from RFC6833 to RFC6833bis.
=
o Clarified = LCAF text in the IANA section. o = Clarified LCAF text in the IANA section.
=
o Remove = references to "experimental". o = Remove references to "experimental".
=
B.21. Changes to = draft-ietf-lisp-rfc6830bis-00 B.22. Changes to = draft-ietf-lisp-rfc6830bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6830-00 = individual submission. No other changes made. -rfc6830-00 individual submission. No other = changes made.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
Cisco = Systems Cisco Systems
 End of changes. 38 change blocks. 
77 lines changed or = deleted 87 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_CF031218-2624-4E86-AB19-1205EB0524B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = [lisp] I-D = Action: draft-ietf-lisp-rfc6830bis-21.txt
Date: = September 27, 2018 at 2:17:47 = PM PDT
To: = <i-d-announce@ietf.org>
Cc: lisp@ietf.org
Reply-To: = lisp@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Locator/ID = Separation Protocol WG of the IETF.

=        Title =           : The = Locator/ID Separation Protocol (LISP)
=        Authors =         : Dino Farinacci
=             &n= bsp;           &nbs= p;Vince Fuller
=             &n= bsp;           &nbs= p;Dave Meyer
=             &n= bsp;           &nbs= p;Darrel Lewis
=             &n= bsp;           &nbs= p;Albert Cabellos
Filename =        : = draft-ietf-lisp-rfc6830bis-21.txt
Pages =           : 45
= Date =            : = 2018-09-27

Abstract:
=   This document describes the Data-Plane protocol for the = Locator/ID
  Separation Protocol (LISP). =  LISP defines two namespaces, End-point
=   Identifiers (EIDs) that identify end-hosts and Routing = Locators
  (RLOCs) that identify network = attachment points.  With this, LISP
=   effectively separates control from data, and allows routers = to create
  overlay networks. =  LISP-capable routers exchange encapsulated packets
=   according to EID-to-RLOC mappings stored in a local = Map-Cache.

  LISP requires no = change to either host protocol stacks or to underlay
=   routers and offers Traffic Engineering, multihoming and = mobility,
  among other features.

  This document obsoletes RFC = 6830.


The IETF datatracker = status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-21
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bi= s-21

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-rfc6830bis-= 21


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/

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

= --Apple-Mail=_CF031218-2624-4E86-AB19-1205EB0524B1-- --Apple-Mail=_3424C36A-ABAE-4980-BD4F-559123194E5A-- From nobody Thu Sep 27 14:31:11 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA141130DEA; Thu, 27 Sep 2018 14:31:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ixdx4kwi_iJW; Thu, 27 Sep 2018 14:31:00 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 F01B3127332; Thu, 27 Sep 2018 14:30:59 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id a23-v6so2757652pfi.12; Thu, 27 Sep 2018 14:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ul0mkXXAJnpZqAcWL+Il2MFTQ7/pM47rlDLMi+MxYp0=; b=g7bs1X1MqKDBHEfUbi6eoVcElP8khJyovjBFIUkcqvkF3S578qNdmzvGSvw3z4AxJM 7itB7RUYn0O9i4lJGDFqlFOFEPkN4uS8p0rpNCKw1PqCToPsT2a6qfwIiBFJRKV6D1Gt 6vrkKvGyGjwZNzAqc8isa3kEkwjmFBpISro6FsuU7jXZu++irXD2G1qHhEEhKSjHKC5P 3Bejb98SWes0C94jng5wiJjxAGE83f12iUpIfC5bYIGGh466cqOjgydxraBwiJY5VHIG RBM3NouWtHLBcpZC5X26bOgNWVPzCwKb9JG0e7OtxUXM4PPOhu/Mbl0KBrpUuWpmLtZj wW5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ul0mkXXAJnpZqAcWL+Il2MFTQ7/pM47rlDLMi+MxYp0=; b=FKoOqMb1JLf6aCxmoZnmX7xkWZUU1aNtPFkoE6JkfNN9lCqSAnwLi8OaGpBeWWz0t4 zzBbsbp1alESu/Z2Db1P1zxPEZEhD/p3TH4LX8yPFI6LnDW9Gi4XvtT24ZZSotI2VT6M GgOo6b4j5G+fvuhRSdHAEwnjgJFb8RGHFnrcmGd9bQQS+2j9Qm/Hc50+t9M7t/QxhkdJ P5EIDiRK8ps6ibrxGw2l5Dubd1mAvfIk3dmVB7jeeHrcD/Tw7tuqFiAb7T+/9SquL+yK KiyzrUWhnVdsCYgM6oyMYWW5WrvIEFNWyF0VxRdtou/Nx2OBlWk5/aTnnuQ3vgMA48QO hT5g== X-Gm-Message-State: ABuFfohvAVpD4L7Fn44MVLK7xOri6pTCTXdlVnzTe2pTQoSg2BgmDavV hNm8oMlZ7ic1+DecdRzfQqs= X-Google-Smtp-Source: ACcGV638g3+fP9S/RZtUefuflkhOJfdtV0pCC3Wnrz12YNqV62Y87ABHq62ilXKew7SAvlsfzuLudw== X-Received: by 2002:a63:a441:: with SMTP id c1-v6mr12184592pgp.182.1538083859513; Thu, 27 Sep 2018 14:30:59 -0700 (PDT) Received: from [172.31.99.184] (96-86-164-193-static.hfc.comcastbusiness.net. [96.86.164.193]) by smtp.gmail.com with ESMTPSA id k1-v6sm4404688pfi.62.2018.09.27.14.30.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 14:30:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153805484850.26528.17792859473676071054.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2018 14:30:56 -0700 Cc: The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153805484850.26528.17792859473676071054.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alexey Melnikov's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 21:31:02 -0000 I fixed all the comments you had in the COMMENT section. Dino > On Sep 27, 2018, at 6:27 AM, Alexey Melnikov = wrote: >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-lisp-rfc6833bis-16: 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 = https://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: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I have a list of smaller points that should be relatively easy to = address. The > two main ones: >=20 > I believe [I-D.ietf-lisp-sec] needs to be a Normative Reference for = this > document. This will address some of the issues raised by Benjamin, but = will > also make description of various security bits meaningful. >=20 > Similarly, in Section 5.6: >=20 > I: This is the xTR-ID bit. When this bit is set, what is appended = to > the Map-Register is a 128-bit xTR router-ID and then a 64-bit > site-ID. See LISP NAT-Traversal procedures in > [I-D.ermagan-lisp-nat-traversal] for details. >=20 > This description makes [I-D.ermagan-lisp-nat-traversal] a normative = reference. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Abstract >=20 > By using this Control-Plane service interface and communicating with > Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) = and > Egress Tunnel Routers (ETRs) are not dependent on the details of > mapping database systems, which facilitates modularity with = different > database designs. Since these devices implement the "edge" of the > LISP Control-Plane infrastructure, connect directly to LISP-capable > Internet end sites, and comprising the bulk of LISP-speaking = devices, > reducing their implementation and operational complexity should also > reduce the overall cost and effort of deploying LISP. >=20 > The last sentence: I've reread it several times and still not sure = what it says. > I suggest rewording, possibly breaking up into shorter sentences. >=20 > In Section 5.1 the acronym SMR is used before it is defined (It is = defined on > the next page). >=20 > In 5.2: >=20 > A: This is an authoritative bit, which is set to 0 for UDP-based = Map- > Requests sent by an ITR. It is set to 1 when an ITR wants the > destination site to return the Map-Reply rather than the mapping > database system. >=20 > This sentence seems to be missing a word at the end, because you don't = return > "the mapping database system". >=20 > In Section 5.6: >=20 > T: This is the use-TTL for timeout bit. When set to 1, the xTR = wants > the Map-Server to time out registrations based on the value in = the > "Record TTL" field of this message. >=20 > And what happens when it is 0? >=20 > 11.4. LISP Address Type Codes >=20 > Therefore, there is no longer a need for the "LISP Address Type > Codes" registry requested by [RFC6830]. This document requests to > remove it. >=20 > IANA registries are not supposed to be removed, they typically = declared closed > when not needed. Can you elaborate of whether this registry was ever = used? >=20 >=20 From nobody Fri Sep 28 00:07:33 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDA4130DF1 for ; Fri, 28 Sep 2018 00:07:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 LyE2RahkaIL2 for ; Fri, 28 Sep 2018 00:07:30 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 0B059130E36 for ; Fri, 28 Sep 2018 00:07:30 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id z14-v6so5123823wrs.10 for ; Fri, 28 Sep 2018 00:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X8IL0FjZcMjSHVYn+UUMDlAEgDlODShceFjK8dp08lA=; b=eNxVJPPQlgdIbDYsUaRVvpnmfv91w29QN4/Y481BNXrRne/a9hrYZGna5LuHRaTPqA JmvJHVkAlS6lH+Yl+peapUq91B38fyVrlVZlEXGx+oLk6ACYbah23VZsFJj5akShx9dv 6ACQQl7YxTMkp9PeGbnmYVsHg6eE312VacncTvNOHgdJW+MjYUd5GYFe13udNcsHgwO9 eW3PJy069PDoFfb+9o/Kfk27z+Q4EtMpZY1B4kensUzqYBf85DTY3O5l+GaaZ34+B8mr MkDDzUk9t6G83+d0XaTHrC4+PjWjyN3d8xDz7nPG+SrgZSai8RJsjAVI95QEjgsemVFH b1Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X8IL0FjZcMjSHVYn+UUMDlAEgDlODShceFjK8dp08lA=; b=GKb8ZyWGBPn/SLkoxmPSfG9i0WTNsnqV7PaXl0s2Sv56pEcSRK5Fw0E6gfJ0seUgLz xgEEaiXfL2I9YyRAs1XbFo3mOe1m4KXt/fvQpKpFwMxQKU/ckONWu4/qCr5OfoYy+TiE 7T4vFCFMSJUYtANy38fX9OJgjixgM+QEL8WbrISt8GggNmCrFcPebJRdW+IeWzOaQyiS Ph6d1WNo0XlvKFgLbFdbYLWSEkskS92zeJCeCae6OKkWse+sAkPTudL6R95SqfJ5VZmA +Mv4I7baEVtqZURUQq7+u/UpegkzH4B/JluAMzJcoIbHv2D3CeCN9mvKNHiPK5yd3wnr oGsQ== X-Gm-Message-State: ABuFfoheGoQDooaJWziNH1cHRlbWLAgvtrE9zEuKv9RmwJi+YGAw9SiJ PnTyjqTfv1NshfIoB4IpzU98hg== X-Google-Smtp-Source: ACcGV62TbkIfOWx7GfiqlrqTgXekbeaMtAIBlIdc7h58Owb5f2Xhtf+/fMWeyP4PNXvi4+EkzrpZ1Q== X-Received: by 2002:a5d:400d:: with SMTP id n13-v6mr10556928wrp.147.1538118448368; Fri, 28 Sep 2018 00:07:28 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:e0:148b:4fb5:8e21? ([2001:660:330f:a4:e0:148b:4fb5:8e21]) by smtp.gmail.com with ESMTPSA id e16-v6sm2948542wrw.17.2018.09.28.00.07.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 00:07:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Luigi Iannone In-Reply-To: <153805487385.26290.14227373548139794294.idtracker@ietfa.amsl.com> Date: Fri, 28 Sep 2018 09:07:25 +0200 Cc: The IESG , draft-ietf-lisp-gpe@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153805487385.26290.14227373548139794294.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] Alissa Cooper's Discuss on draft-ietf-lisp-gpe-06: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 07:07:32 -0000 Hi Alissa, > On 27 Sep 2018, at 15:27, Alissa Cooper wrote: >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > In the thread with the Gen-ART reviewer, the rationale that was given = for > advancing this document now even though rfc6834bis is nascent was: >=20 > "We do not expect big changes in any bis document, since they are just = the PS > version of deployed technology." >=20 That was my comment. I surely wasn=E2=80=99t expecting so many comments = on the bis documents. I agree, with your position.=20 Let=E2=80=99s solve the current comments on the document and then put it = on hold a bit, while solving the comments on the other documents. Ciao L. From nobody Fri Sep 28 00:10:38 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5C9130DFB for ; Fri, 28 Sep 2018 00:10:35 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 zoOmepOeJ8nl for ; Fri, 28 Sep 2018 00:10:34 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 B5F45130DF1 for ; Fri, 28 Sep 2018 00:10:33 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id s12-v6so1120326wmc.0 for ; Fri, 28 Sep 2018 00:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8PXVbeoPzz13myqb8p6Vh/uIeSc2l3jqSDvIOEDEHG4=; b=F9WIzR1pmLinDywvDpJG9ecGKa0EUqymKIMxci/GZVj6q7BMJ3mc7++8dPpRFAOcU0 ruoJE/ElZT+SzwdIEr27+Lv/jjMlHEPRrJwiHkVPdBeovJyTJKIMI7kUBY3yli8p5UHy bhcWcp45+TQCuqxwx5FcbAeKOo7kp9krQRdDKCX2drAbg90NHv5adbfzsDJeaNwxf8XE O2zVS4S685Px2aL1del5aqWqpL26EVi0+c+8RYKiYudseRL++UR4RqI/LTkXFKI/lTff Gy6P3IZmnPBZoPKZHQ4c1gBlK6Py4EFVnmUHzx+l0gBRaudUlBg3yv0v9HuYtTAILaRt qQnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8PXVbeoPzz13myqb8p6Vh/uIeSc2l3jqSDvIOEDEHG4=; b=OK52P1OdzT2bt8lq/g97amFpT70cYc3oXEoRYiLNL8JXMjQuAGeN8/+MvjMZcFRJOa tvzYFDBwSAsx+rtIoPTKmZ6QGJ5HgX/VJw5WKLnq7M6HluPOjo6+nHeRmKQBveRA2rHj WYK0mjtEAPZ5cGTLdtnW22UZ7xza9RQgPvb6eXegAOfj0tlh8dSm6VyJZX7Y7oecuKyn xn+HYr0jCDBWJYSu8PrYXdmHn6pH65iJZYM3dg7XOczQWlBArFiVA/5o2XHfRV6pYJNI v/IIRqLdhxSY9nJgw8Oj1iAfD9jOuTxMbzImqMJc8pfMOSBklUQJ3UXttGl18oGmRdAa 7KcQ== X-Gm-Message-State: ABuFfoiPn6cm/ZBSTioo8OYzdUrTRMtSU10W8vI6QSzHsmkwpXpDuAeQ aTp/GcHLtTSj1jE45kJuirjZeQ== X-Google-Smtp-Source: ACcGV62nPAPlGWB7raW8omVCcFsETxBrY3gDo3KOu3Zb9BXOM/dx7yHP1M1zCG0nsmt5PUm54cJgXg== X-Received: by 2002:a1c:dac9:: with SMTP id r192-v6mr690207wmg.141.1538118632049; Fri, 28 Sep 2018 00:10:32 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:e0:148b:4fb5:8e21? ([2001:660:330f:a4:e0:148b:4fb5:8e21]) by smtp.gmail.com with ESMTPSA id y4-v6sm5718775wrd.25.2018.09.28.00.10.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 00:10:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Luigi Iannone In-Reply-To: <1C8878A4-4130-4920-85D3-1F98250C94C5@gmail.com> Date: Fri, 28 Sep 2018 09:10:29 +0200 Cc: Suresh Krishnan , The IESG , lisp-chairs@ietf.org, draft-ietf-lisp-gpe@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2D8743E5-F416-4373-975C-4704F95D7B79@gigix.net> References: <153805631869.26309.11407581519814751945.idtracker@ietfa.amsl.com> <1C8878A4-4130-4920-85D3-1F98250C94C5@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] Suresh Krishnan's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 07:10:36 -0000 Hi, > On 27 Sep 2018, at 18:53, Dino Farinacci wrote: >=20 >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> This draft needs to update RFC6830 since it takes the last reserved = bit away >> from there. As a side question, since 6830 is being bised right now = should this >> flag be acknowledged in the bis draft? >=20 > The working group decided to not have 6830bis refer to LISP-GPE. As I said during the IESG Telechat, my take is that 6830bis should not = refer to GPE, that would be a circular dependency. Let=E2=80=99s leave 6830bis as it is, with the last bit reserved.=20 LISP-GPE will update 6830bis allocating the last bit. Looks to me as a standard IETF procedure. Ciao L. =20 >=20 > Dino >=20 From nobody Fri Sep 28 00:11:38 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452F5126DBF for ; Fri, 28 Sep 2018 00:11:33 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 2zmsKOkYA2uB for ; Fri, 28 Sep 2018 00:11:32 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 0BB6E130DFB for ; Fri, 28 Sep 2018 00:11:30 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id z4-v6so3785830wrb.1 for ; Fri, 28 Sep 2018 00:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=51XQnH3KqSB9Y+P2RvejGVF59Q2WOopvjNZnjQVX4Vo=; b=KSPDmZ/OZEMy/AhGZyVw5I4tAzD5mtigdM0X6jkI0LESOFysvDfhGT8fwUMC8FQ7n8 tC8BcjfihmnHNdGOd7U48S4qfxhqsi5vkzAGBtSo7WIJyj7HGvDjh29ZGp8ha3uZB/No PtGWAcJBSrtRMpiU9TXT6N5/trHHClA76kofWn3LD34W29UzpIW1+IL6ulNQgENARHlw dAnBjmxHRDPpKn+AjWuYmvHToA5DEXJLocIXzhrTdWP2jtcMfQ0g3n39NTC5PRIq7ZqT bwbHt9DT/jmE2Dd+eqzRmL/OYjLqY5K20xHBBjb8NrTQOly2Iw5OcZgXt6R+W+/+0tgi 06YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=51XQnH3KqSB9Y+P2RvejGVF59Q2WOopvjNZnjQVX4Vo=; b=s31uxZ/k0F/wFiSJKI0VCH0Epjum/H2aeRrBYwnQ0GLPcXDu2ug7Z1LV/6r/zJHaDH GDhOdSId830+qmPILrA9ysbS2cpPSsgN+/hOh93fI2eRN5upsXrVPJawu+cBTQNxrkD1 43owhV1JEda0PlbP48dxPki0xbhZ9el1YooB3PX8b+IZvPM9qalj5FxMwdeagWXvD3XL Rz2CbtfUEYIqV/LrQJiK0pfEcyJgY2CXBuiV/cTFGbZSEdl5E1K+B7J0E3yGWZ0+Frcn 9VzVogvzaTbUiktKl87CFRst/LjvKbVAwh2xX8OErJxMVG9X7aBL49W+bmtyrQrcMrOF K9DQ== X-Gm-Message-State: ABuFfogBXARkvU5Viw9nr5lJN5O3m2/1QKvBY+5GoeUIN473SFXL+kYj BHuqVHBO/cXaQyE7aQrOGPen1A== X-Google-Smtp-Source: ACcGV63kFmAB+uuJtWyyi8fkiCKTBJpHjkbX7QIJlJvi3loMEfmtEAjao5j6cbg58aLSWXk2FBLYHA== X-Received: by 2002:adf:8567:: with SMTP id 94-v6mr11718098wrh.223.1538118688377; Fri, 28 Sep 2018 00:11:28 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:e0:148b:4fb5:8e21? ([2001:660:330f:a4:e0:148b:4fb5:8e21]) by smtp.gmail.com with ESMTPSA id y4-v6sm5718775wrd.25.2018.09.28.00.11.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 00:11:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Luigi Iannone In-Reply-To: Date: Fri, 28 Sep 2018 09:11:25 +0200 Cc: Dino Farinacci , The IESG , "lisp-chairs@ietf.org" , "draft-ietf-lisp-gpe@ietf.org" , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <153805631869.26309.11407581519814751945.idtracker@ietfa.amsl.com> <1C8878A4-4130-4920-85D3-1F98250C94C5@gmail.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] Suresh Krishnan's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 07:11:33 -0000 > On 27 Sep 2018, at 18:59, Suresh Krishnan wrote: >=20 > Hi Dino, >=20 >> On Sep 27, 2018, at 12:53 PM, Dino Farinacci = wrote: >>=20 >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> This draft needs to update RFC6830 since it takes the last reserved = bit away >>> from there. As a side question, since 6830 is being bised right now = should this >>> flag be acknowledged in the bis draft? >>=20 >> The working group decided to not have 6830bis refer to LISP-GPE. >=20 > Makes sense. Luigi was on the call today and clarified this. I am = perfectly happy with this updating only RFC6830. I should read ALL my mail before replying ;-) We are in Sync. Ciao L. >=20 > Thanks > Suresh >=20 From nobody Fri Sep 28 00:32:24 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75253130F85 for ; Fri, 28 Sep 2018 00:32:17 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 hMtPaWn16Ho8 for ; Fri, 28 Sep 2018 00:32:15 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 9A8EC130F86 for ; Fri, 28 Sep 2018 00:32:12 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id s14-v6so5226207wrw.6 for ; Fri, 28 Sep 2018 00:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ndlqCMaK+7hqCmeMQ/dhgivHS8gxGkcG36ycZffiVB8=; b=iymOJ8UO6FRDrj87stqGx3ib9Uz2WCSkNc4JX2JdlBBmFD70QtAhKTq8s82qy6YWYj t6HaD1ATe3bltksit/FoDklsWBawB2wZEg6+v4B/g9/+t1/S/doVWVWwAorgCnf0HmUP Riw0sHaaE2O37EVTJbrQei0J9Vd7kjpDj0ZjTwX7QzQXLqDI4BeSg+tvY/VF2anCBoIk 0T30Y/XbeK+Xk5ZI1hxJuSEZrj/T9Jh/mLaegqqNp5hBo6wRTqZ8ob/YgaG9X6LQ+uqO H3ZlPHUuryWQRfNYMXFZf1AOOC0YQuKRcOoOEkH6hoKfQ+ZXIsUzRfZ2L08arveQF41f 41aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ndlqCMaK+7hqCmeMQ/dhgivHS8gxGkcG36ycZffiVB8=; b=X9qU5uq1NCKFxA1JNYZAr8yVugb747jJSEvStQeloVjMLNBfnN0w7uqWGiEUZrS9IQ eG19oBhf7/vj4/PMsZZLJ2cQkfxE6b34u+REdYIx0lPhNLcbM1mzSV68LCP4m9Ljp0AX pyM9Dazn6jW8z70PzZ1g5gyUmS3f7C7PEaSNqL0k2QdM3cK1+XKXBAE27P3WYLadMH+d me5sk2jfXVKXNJKqcFIbuUD9mP+Wx00N3KdaOx/ELJ2xZIzB/dKQUeGfmn8GDoxEGVUl EaZ2BH3pgQV8dJDvrK8fhEVFhLasxyzDIQBqSYVKCh7nxn+LRoz/77UtgHmlpbwbr6BH tDjQ== X-Gm-Message-State: ABuFfoh41vYoMGU2e8zPVAY722tWaQhEbmMsgkaBZ1Cip00yXtsGdyZ2 8Yv8iyLDO4JI8jnPXjVtQKl01A== X-Google-Smtp-Source: ACcGV6176jClWXnxeRVk+xlfCtxYaV3l9gPYLCOm5RezdwUavm+QZNt5fANxrf/pWeYRaAbPpbN1ww== X-Received: by 2002:a5d:6782:: with SMTP id v2-v6mr11452839wru.245.1538119930925; Fri, 28 Sep 2018 00:32:10 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:e0:148b:4fb5:8e21? ([2001:660:330f:a4:e0:148b:4fb5:8e21]) by smtp.gmail.com with ESMTPSA id w192-v6sm1385877wmf.33.2018.09.28.00.32.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 00:32:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Luigi Iannone In-Reply-To: Date: Fri, 28 Sep 2018 09:32:08 +0200 Cc: Alexey Melnikov , The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153805097526.26380.13580308305182872824.idtracker@ietfa.amsl.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] Alexey Melnikov's No Objection on draft-ietf-lisp-rfc6830bis-20: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 07:32:18 -0000 Hi Alexey, > On 27 Sep 2018, at 19:31, Dino Farinacci wrote: >=20 >> Ok, maybe this is just me, but you don't actually define how to hash = these >> things, you are only talking about what needs to be covered by the = hash. I >> appreciate that picking a specific hashing algorithm is probably not = relevant >> for interoperability, but I feel adding a specific algorithm (as an = example or >> via a pointer) would improve the document. >=20 > We decided to leave this to the implementation and is a local matter = ot the encapsulator. Most implementations use a =E2=80=9Cfolded XOR=E2=80=9D= . Which means XOR the set of 32-bit fields from the 5-tuple hash, then = XOR the 2 16-bit quantities, then XOR the 2 bytes. Mod the number of = best priority RLOCs, to give you an index to choose one. While you are right that what is in the document is just what can be = covered by the hash, =20 I agree with Dino on this point. I do not think that we need a specific algorithm even as an example.=20 The load-sharing is local to the ITR, it just need to use any algorithm = that does that. Would you prefer a clear statement? Something like: =E2=80=9CThe specific algorithm the ITR uses for load-sharing is out of = the scope of this document and does not prevent interoperability"=20 Ciao L. >=20 > Dino >=20 From nobody Fri Sep 28 01:03:16 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95974130E05; Fri, 28 Sep 2018 01:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 hYwLHcdP4_nn; Fri, 28 Sep 2018 01:03:11 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85838130DC9; Fri, 28 Sep 2018 01:03:11 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 42M4194MB8z5wcm; Fri, 28 Sep 2018 10:03:09 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 42M4192fwnzyQF; Fri, 28 Sep 2018 10:03:09 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0415.000; Fri, 28 Sep 2018 10:03:09 +0200 From: To: Luigi Iannone , "lisp@ietf.org list" CC: "lisp-chairs@ietf.org" Thread-Topic: [lisp] WGLC fo draft-ietf-lisp-rfc8113bis-00.txt Thread-Index: AQHUVkDPr4RiCi1B+Uqv481ReF3uGaUFVbpA Date: Fri, 28 Sep 2018 08:03:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DFE8347@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> <44201301-8E2D-4649-8483-5418A8CFC138@gigix.net> In-Reply-To: <44201301-8E2D-4649-8483-5418A8CFC138@gigix.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DFE8347OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] WGLC fo draft-ietf-lisp-rfc8113bis-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 08:03:15 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DFE8347OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpGV0lXLCBkcmFmdC1pZXRmLWxpc3AtcmZjODExM2Jpcy0wMCBpbmNsdWRlIGFu ICJ1cGRhdGVzIDY4MzNiaXMiIGFzIHBlciB0aGUgc3VnZ2VzdGlvbiBmcm9tIERlYm9yYWguDQoN CkNoZWVycywNCk1lZA0KDQpEZSA6IGxpc3AgW21haWx0bzpsaXNwLWJvdW5jZXNAaWV0Zi5vcmdd IERlIGxhIHBhcnQgZGUgTHVpZ2kgSWFubm9uZQ0KRW52b3nDqSA6IGpldWRpIDI3IHNlcHRlbWJy ZSAyMDE4IDExOjAyDQrDgCA6IGxpc3BAaWV0Zi5vcmcgbGlzdA0KQ2MgOiBsaXNwLWNoYWlyc0Bp ZXRmLm9yZw0KT2JqZXQgOiBbbGlzcF0gV0dMQyBmbyBkcmFmdC1pZXRmLWxpc3AtcmZjODExM2Jp cy0wMC50eHQNCg0KV2VsbCwNCg0KQXV0aG9ycyB3ZXJlIHByZXR0eSBxdWljayDigKYNCg0KVGhp cyBlbWFpbCBvcGVuIHRoZSBvbmUgd2VlayBXRyBMYXN0IENhbGwgZm9yIHRoZSBkb2N1bWVudCBk cmFmdC1pZXRmLWxpc3AtcmZjODExM2Jpcy0wMC50eHQNCg0KUGxlYXNlIHJldmlldyB0aGlzIFdH IGRvY3VtZW50IGFuZCBsZXQgdGhlIFdHIGtub3cgaWYgeW91IGFncmVlIHRoYXQgaXQgaXMgcmVh ZHkgZm9yIGhhbmRpbmcgdG8gdGhlIEFELg0KSWYgeW91IGhhdmUgb2JqZWN0aW9ucywgcGxlYXNl IHN0YXRlIHlvdXIgcmVhc29ucyB3aHksIGFuZCBleHBsYWluIHdoYXQgaXQgd291bGQgdGFrZSB0 byBhZGRyZXNzIHlvdXIgY29uY2VybnMuDQoNCkNpYW8NCg0KTC4NCg0KDQpPbiAyNyBTZXAgMjAx OCwgYXQgMTA6MjIsIEx1aWdpIElhbm5vbmUgPGdneEBnaWdpeC5uZXQ8bWFpbHRvOmdneEBnaWdp eC5uZXQ+PiB3cm90ZToNCg0KQWxsLA0KDQpvbmUgd2VlayBpcyBvdmVyIGFuZCB3ZSByZWNlaXZl ZCBzZXZlcmFsIGVtYWlsIGluIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudC4NCg0K QmVjYXVzZSBvZiBzdWNoIGNvbnNlbnN1cyB0aGUgYXV0aG9ycyBhcmUgaW52aXRlZCB0byBzdWJt aXQgYSBkb2N1bWVudCBuYW1lZCBkcmFmdC1pZXRmLWxpc3AtcmZjODExM2Jpcy0wMC50eHQuDQoN CkFzIHNvb24gYXMgdGhlIG5ldyBkb2N1bWVudCBpcyBhdmFpbGFibGUgd2Ugd2lsbCBzdGFydCB0 aGUgV0cgTGFzdCBDYWxsLCBhcyBhbHJlYWR5IHNhaWQgaW4gbXkgcHJldmlvdXMgbWFpbC4NCg0K Q2lhbw0KDQpMLg0KDQoNCg0KT24gMTkgU2VwIDIwMTgsIGF0IDE3OjA0LCBMdWlnaSBJYW5ub25l IDxnZ3hAZ2lnaXgubmV0PG1haWx0bzpnZ3hAZ2lnaXgubmV0Pj4gd3JvdGU6DQoNCkZvbGtzLA0K DQpoZXJlIGlzIGFub3RoZXIgcGllY2Ugb2YgdGhlIHdvcmsgZG9uZSBpbiBvdXIgV0cgdGhhdCBu ZWVkcyB0byBiZSBtb3ZlZCB0byBQUy4NCg0KSXQgaXMgdGhlIHVwZGF0ZWQgdmVyc2lvbiBvZiBS RkMgODExMywgbm90aGluZyBjaGFuZ2VkIGp1c3QgdXBkYXRlZCBjb2hlcmVudGx5IHdpdGggdGhl IGN1cnJlbnQgc3RhdHVzIG9mIHRoZSBvdGhlciBkb2N1bWVudHMuDQoNCkJlY2F1c2UgdGhpcyBk b2N1bWVudHMgaXMgcmVhbGx5IHJlYWxseSBzaG9ydCB3ZSB3aWxsIGhhdmUganVzdCBvbmUgd2Vl ayBhZG9wdGlvbiBjYWxsIGZvbGxvd2VkIGJlIG9uZSB3ZWVrIFdHIExhc3QgQ2FsbC4NCg0KVGhp cyBlbWFpbCBvZmZpY2lhbGx5IHN0YXJ0cyB0aGUgb25lIHdlZWsgY2FsbCBmb3IgYWRvcHRpb24u DQoNClBsZWFzZSBzcGVuZCAxMCBtaW51dGVzIGhhdmluZyBhIGxvb2sgYXQgdGhlIGRvY3VtZW50 IGFuZCBzZW5kIGFuIGVtYWlsIG9uIHdoZXRoZXIgeW91IGFncmVlIG9yIG5vdCB0byBhZG9wdCBp dC4NCg0KVGhhbmtzDQoNCkNpYW8NCg0KTHVpZ2kNCg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2Fn ZToNCg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItbGlzcC1y ZmM4MTEzYmlzLTAxLnR4dA0KRGF0ZTogMTkgU2VwdGVtYmVyIDIwMTggYXQgMTY6NDk6MzEgQ0VT VA0KVG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9y Zz4+DQpSZXBseS1UbzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KDQoNCiAgICAgICBU aXRsZSAgICAgICAgICAgOiBMb2NhdG9yL0lEIFNlcGFyYXRpb24gUHJvdG9jb2wgKExJU1ApOiBT aGFyZWQgRXh0ZW5zaW9uIE1lc3NhZ2UgJiBJQU5BIFJlZ2lzdHJ5IGZvciBQYWNrZXQgVHlwZSBB bGxvY2F0aW9ucw0KICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1vaGFtZWQgQm91Y2FkYWlyDQog ICAgICAgICAgICAgICAgICAgICAgICAgQ2hyaXN0aWFuIEphY3F1ZW5ldA0KICAgICAgICAgIEZp bGVuYW1lICAgICAgICA6IGRyYWZ0LWJvdWNhZGFpci1saXNwLXJmYzgxMTNiaXMtMDEudHh0DQog ICAgICAgICAgUGFnZXMgICAgICAgICAgIDogNQ0KICAgICAgICAgIERhdGUgICAgICAgICAgICA6 IDIwMTgtMDktMTkNCg0KQWJzdHJhY3Q6DQogIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgTG9j YXRvci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIChMSVNQKQ0KICBzaGFyZWQgbWVzc2FnZSB0eXBl IGZvciBkZWZpbmluZyBmdXR1cmUgZXh0ZW5zaW9ucyBhbmQgY29uZHVjdGluZw0KICBleHBlcmlt ZW50cyB3aXRob3V0IGNvbnN1bWluZyBhIExJU1AgcGFja2V0IHR5cGUgY29kZXBvaW50IGZvciBl YWNoDQogIGV4dGVuc2lvbi4NCg0KICBUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgODExMy4N Cg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNhZGFpci1saXNwLXJm YzgxMTNiaXMvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBh dDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItbGlzcC1yZmM4 MTEzYmlzLTAxDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWJv dWNhZGFpci1saXNwLXJmYzgxMTNiaXMtMDENCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWJvdWNhZGFpci1saXNwLXJmYzgxMTNiaXMtMDENCg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSS1ELUFu bm91bmNlIG1haWxpbmcgbGlzdA0KSS1ELUFubm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KSW50ZXJuZXQtRHJhZnQgZGly ZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCm9yIGZ0cDovL2Z0cC5p ZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQoNCg0KDQo= --_000_787AE7BB302AE849A7480A190F8B93302DFE8347OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6dGF4PSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvdGF4b25vbXkvc29hcC8iIHhtbG5zOnRucz0iaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvcmVjb3Jkc3JlcG9zaXRvcnkvIiB4bWxu czpzcHN1cD0iaHR0cDovL21pY3Jvc29mdC5jb20vd2Vic2VydmljZXMvU2hhcmVQb2ludFBvcnRh bFNlcnZlci9Vc2VyUHJvZmlsZVNlcnZpY2UiIHhtbG5zOm1tbD0iaHR0cDovL3d3dy53My5vcmcv MTk5OC9NYXRoL01hdGhNTCIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1z cGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWln aHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQg NzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlO2xp bmUtYnJlYWs6YWZ0ZXItd2hpdGUtc3BhY2UiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBhbGwsDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5GV0lXLCBkcmFmdC1pZXRmLWxpc3At cmZjODExM2Jpcy0wMCBpbmNsdWRlIGFuICZxdW90O3VwZGF0ZXMgNjgzM2JpcyZxdW90OyBhcyBw ZXIgdGhlIHN1Z2dlc3Rpb24gZnJvbSBEZWJvcmFoLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si Pk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUm bmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGxpc3AgW21haWx0 bzpsaXNwLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBMdWlnaSBJYW5u b25lPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IGpldWRpIDI3IHNlcHRlbWJyZSAyMDE4IDEx OjAyPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBsaXNwQGlldGYub3JnIGxpc3Q8YnI+DQo8Yj5DYyZu YnNwOzo8L2I+IGxpc3AtY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBb bGlzcF0gV0dMQyBmbyBkcmFmdC1pZXRmLWxpc3AtcmZjODExM2Jpcy0wMC50eHQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZWxsLDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXV0aG9ycyB3ZXJlIHByZXR0eSBxdWlj ayDigKY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhpcyBlbWFpbCBvcGVuIHRoZSBvbmUgd2VlayBXRyBMYXN0IENhbGwgZm9yIHRoZSBkb2N1 bWVudCZuYnNwO2RyYWZ0LWlldGYtbGlzcC1yZmM4MTEzYmlzLTAwLnR4dDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5QbGVhc2UgcmV2aWV3IHRoaXMgV0cgZG9jdW1l bnQgYW5kIGxldCB0aGUgV0cga25vdyBpZiB5b3UgYWdyZWUgdGhhdCBpdCBpcyByZWFkeSBmb3Ig aGFuZGluZyB0byB0aGUgQUQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dCI+SWYgeW91IGhhdmUgb2JqZWN0aW9ucywgcGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucyB3aHks IGFuZCBleHBsYWluIHdoYXQgaXQgd291bGQgdGFrZSB0byBhZGRyZXNzIHlvdXIgY29uY2VybnMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5DaWFvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiAyNyBTZXAgMjAxOCwgYXQgMTA6MjIsIEx1aWdpIElhbm5vbmUgJmx0OzxhIGhyZWY9 Im1haWx0bzpnZ3hAZ2lnaXgubmV0Ij5nZ3hAZ2lnaXgubmV0PC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwsPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vbmUgd2VlayBpcyBvdmVyIGFuZCB3 ZSByZWNlaXZlZCBzZXZlcmFsIGVtYWlsIGluIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkb2N1 bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QmVjYXVzZSBvZiBzdWNoIGNvbnNlbnN1cyB0aGUgYXV0aG9ycyBhcmUgaW52aXRlZCB0byBz dWJtaXQgYSBkb2N1bWVudCBuYW1lZCBkcmFmdC1pZXRmLWxpc3AtcmZjODExM2Jpcy0wMC50eHQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFz IHNvb24gYXMgdGhlIG5ldyBkb2N1bWVudCBpcyBhdmFpbGFibGUgd2Ugd2lsbCBzdGFydCB0aGUg V0cgTGFzdCBDYWxsLCBhcyBhbHJlYWR5IHNhaWQgaW4gbXkgcHJldmlvdXMgbWFpbC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2lhbzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTkgU2VwIDIwMTgs IGF0IDE3OjA0LCBMdWlnaSBJYW5ub25lICZsdDs8YSBocmVmPSJtYWlsdG86Z2d4QGdpZ2l4Lm5l dCI+Z2d4QGdpZ2l4Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9sa3MsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5oZXJlIGlzIGFub3RoZXIgcGllY2Ugb2YgdGhlIHdvcmsgZG9uZSBp biBvdXIgV0cgdGhhdCBuZWVkcyB0byBiZSBtb3ZlZCB0byBQUy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgdGhlIHVwZGF0ZWQgdmVy c2lvbiBvZiBSRkMgODExMywgbm90aGluZyBjaGFuZ2VkIGp1c3QgdXBkYXRlZCBjb2hlcmVudGx5 IHdpdGggdGhlIGN1cnJlbnQgc3RhdHVzIG9mIHRoZSBvdGhlciBkb2N1bWVudHMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlY2F1c2UgdGhp cyBkb2N1bWVudHMgaXMgcmVhbGx5IHJlYWxseSBzaG9ydCB3ZSB3aWxsIGhhdmUganVzdCBvbmUg d2VlayBhZG9wdGlvbiBjYWxsIGZvbGxvd2VkIGJlIG9uZSB3ZWVrIFdHIExhc3QgQ2FsbC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBl bWFpbCBvZmZpY2lhbGx5IHN0YXJ0cyB0aGUgb25lIHdlZWsgY2FsbCBmb3IgYWRvcHRpb24uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFz ZSBzcGVuZCAxMCBtaW51dGVzIGhhdmluZyBhIGxvb2sgYXQgdGhlIGRvY3VtZW50IGFuZCBzZW5k IGFuIGVtYWlsIG9uIHdoZXRoZXIgeW91IGFncmVlIG9yIG5vdCB0byBhZG9wdCBpdC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpYW88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+THVp Z2k8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3ViamVjdDogSS1EIEFjdGlvbjog ZHJhZnQtYm91Y2FkYWlyLWxpc3AtcmZjODExM2Jpcy0wMS50eHQ8L3NwYW4+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5EYXRlOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4xOSBTZXB0ZW1iZXIgMjAxOCBh dCAxNjo0OTozMSBDRVNUPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbzogPC9zcGFuPg0KPC9iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jmx0OzxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmktZC1h bm5vdW5jZUBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZXBseS1UbzoNCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9y aWVzLjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1RpdGxlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzogTG9jYXRvci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIChMSVNQKTog U2hhcmVkIEV4dGVuc2lvbiBNZXNzYWdlICZhbXA7IElBTkEgUmVnaXN0cnkgZm9yIFBhY2tldCBU eXBlIEFsbG9jYXRpb25zPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7QXV0aG9ycyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs6IE1vaGFtZWQgQm91Y2FkYWlyPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Q2hyaXN0aWFuIEphY3F1ZW5ldDxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWIt c3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj5GaWxlbmFtZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs6IGRyYWZ0LWJvdWNhZGFpci1saXNwLXJmYzgxMTNiaXMtMDEudHh0PGJyPg0KPHNwYW4g Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPlBhZ2VzICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogNTxicj4NCjxzcGFuIGNsYXNz PSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5EYXRlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjAxOC0wOS0xOTxicj4NCjxi cj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyZuYnNwO1RoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEg TG9jYXRvci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIChMSVNQKTxicj4NCiZuYnNwOyZuYnNwO3No YXJlZCBtZXNzYWdlIHR5cGUgZm9yIGRlZmluaW5nIGZ1dHVyZSBleHRlbnNpb25zIGFuZCBjb25k dWN0aW5nPGJyPg0KJm5ic3A7Jm5ic3A7ZXhwZXJpbWVudHMgd2l0aG91dCBjb25zdW1pbmcgYSBM SVNQIHBhY2tldCB0eXBlIGNvZGVwb2ludCBmb3IgZWFjaDxicj4NCiZuYnNwOyZuYnNwO2V4dGVu c2lvbi48YnI+DQo8YnI+DQombmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMg ODExMy48YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1ib3VjYWRhaXItbGlzcC1yZmM4MTEzYmlzLyI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm91Y2FkYWlyLWxpc3AtcmZjODExM2Jpcy88L2E+PGJy Pg0KPGJyPg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXIt bGlzcC1yZmM4MTEzYmlzLTAxIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91 Y2FkYWlyLWxpc3AtcmZjODExM2Jpcy0wMTwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWJvdWNhZGFpci1saXNwLXJmYzgxMTNiaXMt MDEiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYm91Y2FkYWly LWxpc3AtcmZjODExM2Jpcy0wMTwvYT48YnI+DQo8YnI+DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWJvdWNhZGFpci1saXNwLXJmYzgxMTNiaXMtMDE8YnI+DQo8YnI+DQo8 YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQo8YnI+DQpJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0K ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkktRC1Bbm5vdW5jZSBt YWlsaW5nIGxpc3Q8YnI+DQpJLUQtQW5ub3VuY2VAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTxicj4NCkludGVybmV0LURyYWZ0 IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sPGJyPg0Kb3IgZnRw Oi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93302DFE8347OPEXCLILMA3corp_-- From nobody Fri Sep 28 04:57:47 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BEA130E0C; Fri, 28 Sep 2018 04:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=tlnrH9zJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d9qHWlvj 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 lRo-XQEKY-VZ; Fri, 28 Sep 2018 04:57:38 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C68130DED; Fri, 28 Sep 2018 04:57:38 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 1442CCB9; Fri, 28 Sep 2018 07:57:36 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 28 Sep 2018 07:57:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=mNEGu3WHdHbwZ/0JExXQWn18fatRa pSYNgylDvYnO6U=; b=tlnrH9zJItvqc2rt8JVm/JQzU1NdPJ9T+LF8keRSH3oL0 6E35i895tLKX75YF7u3xD0kXtWeIDDW9PlMKNiM+nLXlqJKZ7JNPXRTvRNp8YbSG VZ4KgvlRKPrlJ4vE4njQXKlN11pOEMz/0wY7yNsHWVfI9oGdKZ2g6ttkBHuCLmLC iB98sJMKGkTQyT8RMympTYbmYnDOnDAUQ73Eh810enpcOWeFZ9/szcSfIP3PGPv0 Hj8KedZ5G23m6EYmLCY+6NiG5rdQer+jnAtBT3wdxvA6sn/T12B13iQdxvmcEwkU OAA5iGu2HZww0wZ1aQyVnOwpcG9zaoc660oouzuTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=mNEGu3 WHdHbwZ/0JExXQWn18fatRapSYNgylDvYnO6U=; b=d9qHWlvjtDBeOygxV1IQox 7c/Lo3NnfNqlmYVHLUse1Vco+xzlzQqzc9c9WeRTkWeywjxZVK7C4e763F7uNJfe 2K6hyGQTXqR223ZMIZf5HIzTdZwoKNU9GDvkjNGstN/ihAkHEtr8mox41EsXGqsG TMPfWb5uqQY5M5DhsO0i2ozaOhmJxh2q7LJwUSdEHjEUuKoFRqmx+W7sZnEEcOUN FbPkgD5ItmLP1XuG4RyB0LTR9jCXhMakzJt/zaAcplx3ncIGAxoibMGk3ANnCKhH ODCIsYoVBRW8qXz50w3Jh0Ec0tBebsCxCyoPM1P5wamxLk0eJeGOAZgQKqeT8RHQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 19AA19E0E0; Fri, 28 Sep 2018 07:57:35 -0400 (EDT) Message-Id: <1538135855.2490729.1523775896.464BBC73@webmail.messagingengine.com> From: Alexey Melnikov To: Luigi Iannone , Dino Farinacci Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-27407983 References: <153805097526.26380.13580308305182872824.idtracker@ietfa.amsl.com> Date: Fri, 28 Sep 2018 12:57:35 +0100 In-Reply-To: Archived-At: Subject: Re: [lisp] Alexey Melnikov's No Objection on draft-ietf-lisp-rfc6830bis-20: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 11:57:40 -0000 On Fri, Sep 28, 2018, at 8:32 AM, Luigi Iannone wrote: > Hi Alexey, >=20 > > On 27 Sep 2018, at 19:31, Dino Farinacci wrote: > >=20 > >> Ok, maybe this is just me, but you don't actually define how to hash t= hese > >> things, you are only talking about what needs to be covered by the has= h. I > >> appreciate that picking a specific hashing algorithm is probably not r= elevant > >> for interoperability, but I feel adding a specific algorithm (as an ex= ample or > >> via a pointer) would improve the document. > >=20 > > We decided to leave this to the implementation and is a local matter ot= the encapsulator. Most implementations use a =E2=80=9Cfolded XOR=E2=80=9D.= Which means XOR the set of 32-bit fields from the 5-tuple hash, then XOR t= he 2 16-bit quantities, then XOR the 2 bytes. Mod the number of best priori= ty RLOCs, to give you an index to choose one. >=20 > While you are right that what is in the document is just what can be=20 > covered by the hash,=20=20 > I agree with Dino on this point. >=20 > I do not think that we need a specific algorithm even as an example.=20 > The load-sharing is local to the ITR, it just need to use any algorithm=20 > that does that. >=20 > Would you prefer a clear statement? Yes. > Something like: >=20 > =E2=80=9CThe specific algorithm the ITR uses for load-sharing is out of t= he=20 > scope of this document and does not prevent interoperability"=20 Sounds good to me. Thank you. > Ciao >=20 > L. >=20 >=20 > >=20 > > Dino > >=20 >=20 From nobody Fri Sep 28 07:03:07 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9840F1292F1; Fri, 28 Sep 2018 07:03:05 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.com 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 nXg_xUgHvXC3; Fri, 28 Sep 2018 07:03:02 -0700 (PDT) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670090.outbound.protection.outlook.com [40.107.67.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8FC128C65; Fri, 28 Sep 2018 07:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bniRCPwGDkZxw1gQywULvnkmI1XZFOLzo+6Q92PC6pc=; b=rwMDLvc5s1NW7XWon7hWpPXTtE+GYSjG5geDMJOLwu3094CK/pHAaUn5cL7V+mJpzme/KECXIPAHwUr933TGFyPRmTOf3Au0ieBxU+QXSdysQ4sWwPEezdUZbuKtR/KVWB76jLX/9axHsW2EtuPdbXdiJ2yHzFSkh5R31en6FIM= Received: from YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM (10.169.141.148) by YQBPR01MB0451.CANPRD01.PROD.OUTLOOK.COM (10.169.143.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.22; Fri, 28 Sep 2018 14:02:54 +0000 Received: from YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM ([fe80::8dbd:5e3f:40e5:d4e1]) by YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM ([fe80::8dbd:5e3f:40e5:d4e1%4]) with mapi id 15.20.1164.024; Fri, 28 Sep 2018 14:02:54 +0000 From: Suresh Krishnan To: Luigi Iannone CC: "lisp-chairs@ietf.org" , "draft-ietf-lisp-gpe@ietf.org" , The IESG , Dino Farinacci , "lisp@ietf.org" Thread-Topic: [lisp] Suresh Krishnan's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) Thread-Index: AQHUVoKvwELTvYkCG0GqDdfjktS2Y6UEWduAgADuDoCAAHL2AA== Date: Fri, 28 Sep 2018 14:02:53 +0000 Message-ID: <19A5E0C6-DC0C-4B8B-B045-3E2AE82CA15A@kaloom.com> References: <153805631869.26309.11407581519814751945.idtracker@ietfa.amsl.com> <1C8878A4-4130-4920-85D3-1F98250C94C5@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [45.19.110.76] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQBPR01MB0451; 6:C2QhaB1aKj7n4X/UnHdjMxkXY5gsjYLjTXDEATSR8cxAGscuFPU9VmZdNI6yNPcs+O3KjjmdQlJptQ1BLGc9PvoXGF+aWek7oZW2QdmgcNeslY9gj/Gy4W6Tp80cYubrEWg8M5Oo4WoqUr3D2O73oXzKuMLcoMfmm+v7p8mdvz7/spbmJN5uW9U8JdzhPqelaqPZx5R+m566VkxxQyb9ugxznGcf2m8kP0wzRQq1OczWDfNtMo6HzAvE2n/GOwPO0fv0yr+GPxVqFe9rQhOlXLA7OG0PUoeLvbGIY2JTMJbyNSMsZWfsynFTWYX3gtaUor4yhHn9HIMbTuKKnubpy/ndAfD4qNtY/0re+tUJWb6QP+RP933rg2pBl79CcOB1MK4Co1ATPs3ldDO0DrvRo5hUfV6H5XRWq0sznLnyS1vs3sUbkoZAZJwT1S+Yf6BIP6msVvhbYxb83f5r5NfzTg==; 5:yHmEnM1NFhl4rbDZIVP66qcrId6EzUCQQwg818aIEVHjdnnRowsC2dp1QYUlM4HwIESS++bGrxSNtRSqY3YndZFLy0Q6YUsiSB8mQo1naCLGkaqMYSynep+AxQU7BYy+SG9DI0IMRBCX0ugfNCZc8BtaKdd+fC6nxRXED8Ljrkg=; 7:ZI/UJOLt78ZOdmHWUTqDqCDZCFC+t5rkboTSP5zv9z7zFHTZZyjQ5h1dJX5AeA2b06g4/nJStYFTA1tTUVT5lIgq+U3X/qrhsb43gvTN5BHXvznV62HQjOboos+Se4mLC86BfJ78VsDqrslx8MFH+AccZcwo7Lnh7axzQoO/rBsrboLm2VHEwsbi6vKOF8U2KKvp68gaoaxznHToHZ0zUb2LGtARc7UjtkkoxxyxY84DS4xkNBldlB9o2y+aWEWL x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 93162327-a6da-4d9e-ac67-08d6254b1625 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989299)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:YQBPR01MB0451; x-ms-traffictypediagnostic: YQBPR01MB0451: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(2016111802025)(6043046)(201708071742011)(7699051); SRVR:YQBPR01MB0451; BCL:0; PCL:0; RULEID:; SRVR:YQBPR01MB0451; x-forefront-prvs: 0809C12563 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(396003)(39840400004)(366004)(199004)(189003)(25786009)(508600001)(486006)(76176011)(6246003)(93886005)(4326008)(39060400002)(86362001)(102836004)(7736002)(186003)(26005)(36756003)(446003)(53546011)(14454004)(6506007)(476003)(72206003)(11346002)(2616005)(105586002)(2900100001)(54906003)(34290500001)(316002)(106356001)(5250100002)(5660300001)(80792005)(97736004)(6116002)(3846002)(33656002)(68736007)(81166006)(81156014)(66066001)(99286004)(6916009)(229853002)(2906002)(53936002)(71190400001)(8936002)(6436002)(14444005)(71200400001)(6512007)(256004)(236005)(6486002)(82746002)(8676002)(54896002)(83716004); DIR:OUT; SFP:1102; SCL:1; SRVR:YQBPR01MB0451; H:YQBPR01MB0226.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: fWZywJLcb/MhA6r4jM51t5bZW+JihrBLQPRv/JCfBgHEHQD9GbboFFxggiq2swwkLZBLHo8bPresfPJGHvqw1r9oXPVg8YjcaC2jyji8rbcyxq4Lkts/xGQRto8eFJrLuGvAvmUxTGMzlPND4dyOwGC+Oz96xSTEqCvGtdrmhEQDqUzFUIAeU7XOSjPshgPyn2m28+8yU2kO9ueOca5zkJ3mFg9Ezp6WldCew8QMBn68nS0SCBK8JcGmSnLWesSv+6EFyX7S85sFCxcUTnnI2HBb8I3WNDFy2WlfoZ958ix+m+WiOt1Y5tT8+8GWKlomTuhpY2ThVu9n3YbtzPv9ifIg+eSTK7JDA6WUZPBdr84= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_19A5E0C6DC0C4B8BB0453E2AE82CA15Akaloomcom_" MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 93162327-a6da-4d9e-ac67-08d6254b1625 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2018 14:02:54.1033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR01MB0451 Archived-At: Subject: Re: [lisp] Suresh Krishnan's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 14:03:06 -0000 --_000_19A5E0C6DC0C4B8BB0453E2AE82CA15Akaloomcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sep 28, 2018, at 3:11 AM, Luigi Iannone > wrote: On 27 Sep 2018, at 18:59, Suresh Krishnan > wrote: Hi Dino, On Sep 27, 2018, at 12:53 PM, Dino Farinacci > wrote: COMMENT: ---------------------------------------------------------------------- This draft needs to update RFC6830 since it takes the last reserved bit awa= y from there. As a side question, since 6830 is being bised right now should = this flag be acknowledged in the bis draft? The working group decided to not have 6830bis refer to LISP-GPE. Makes sense. Luigi was on the call today and clarified this. I am perfectly= happy with this updating only RFC6830. I should read ALL my mail before replying ;-) We are in Sync. Haha. No worries Luigi. As long as the Updates: goes in there I am good :-) Thanks Suresh --_000_19A5E0C6DC0C4B8BB0453E2AE82CA15Akaloomcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <409DDBB101908E44894D213BFA2F8D6D@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable
On Sep 28, 2018, at 3:11 AM, Luigi Iannone <ggx@gigix.net> wrote:



On 27 Sep 2018, at 18:59, Suresh Krishnan <Suresh@kaloom.com> wrote:

Hi Dino,

On Sep 27, 2018, at 12:53 PM, Dino Far= inacci <farinacci@gmai= l.com> wrote:

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

This draft needs to update RFC6830 since it takes the last reserved bit awa= y
from there. As a side question, since 6830 is being bised right now should = this
flag be acknowledged in the bis draft?

The working group decided to not have 6830bis refer to LISP-GPE.

Makes sense. Luigi was on the call today and clarified this. I am perfectly= happy with this updating only RFC6830.

I should read ALL my mail before replying ;-)

We are in Sync.

Haha. No worries Luigi. As long as the Updates: goes in there I am goo= d :-)

Thanks
Suresh
--_000_19A5E0C6DC0C4B8BB0453E2AE82CA15Akaloomcom_-- From nobody Fri Sep 28 10:09:50 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CE9127148; Fri, 28 Sep 2018 10:09:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ECYwmRROghoj; Fri, 28 Sep 2018 10:09:39 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 BC0C012008A; Fri, 28 Sep 2018 10:09:39 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id d4-v6so4764631pfn.0; Fri, 28 Sep 2018 10:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ISrEs+bwM4moMc18+FLGUH4PLVjte3MR46F3YgQ+1yA=; b=uR3pSEoYoDMNTCV7wZljf1ejj3A9lSVWb9w7HDVCuFfLgontDRx5F5pTXpPsQX2TJD Bdi398orDbF2bcAcCGxUunb1+mm5MLIcodfnTHTOeZv5DNo69DTuf746ybkxpmQYTI1C Akam56e8hMpVFdiTasvIGuC7yK18xLIXuMOi40DndwL3pOv26YXcmr1l7W9caD/SzlVc Q1+Ca8b4avMfiq1Qj7dmcWWRb5K+DDLXGrQxa/Xj65MaYO3Jed7SrZv00mDnj9LOOEm6 +OjT7WTJSc+33wFnXPH22zHT8L4Y3jv415eokNdZiXBYjuTfhiab8BqP3+osFxNrOOmU qjSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ISrEs+bwM4moMc18+FLGUH4PLVjte3MR46F3YgQ+1yA=; b=WwqMt8EDVPCwZrnN3VTaZ00o3uDARGOTdcfKRrBQa+FD/kiyr2eLtPE4LLI013znDB Kxhvg5h1AH51r54KPzrS/XrnaxV2HkvC5xQXCwUh2/axyEBnFeHxW4sf0fkS/P9xipsR aFcs8ih8Cd+Jmx2qo8zzrAoC2dduoUQBibnC/kWI4zjsGOagpias45JrzcDIk07vKMsf s1iGCFxJ8K0zwTJ/3ekyboeeyczorZpKhanUvcoMpu84vw9gpJTUpUh9iP27aG7q0ml4 ZTKyiqibNuG4MxZy7luBilRFpQh2MG8cYfM9FD6s1bOVbni+/ZnIaK18tw+5ugyiaN2P T0aw== X-Gm-Message-State: ABuFfojpZSXGJhGjlp3d0DXZZKloy8pwE2l6tPFLcLGM/KLXXKx9couy zpJfJ0Ry/A3bEf6SGhyQYnY= X-Google-Smtp-Source: ACcGV63GIuhQAhVdQPePpIFrPaw5ZLsGiNLGmyQq8eJF9hA4LVWtqcC0sdS6uuhANL+57cXcTWIVCw== X-Received: by 2002:a63:5922:: with SMTP id n34-v6mr16044685pgb.134.1538154579292; Fri, 28 Sep 2018 10:09:39 -0700 (PDT) Received: from [10.31.79.57] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id v81-v6sm11321051pfj.25.2018.09.28.10.09.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 10:09:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <1538135855.2490729.1523775896.464BBC73@webmail.messagingengine.com> Date: Fri, 28 Sep 2018 10:09:37 -0700 Cc: Luigi Iannone , The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <927054DB-5157-48E6-82FB-C66DC3B32037@gmail.com> References: <153805097526.26380.13580308305182872824.idtracker@ietfa.amsl.com> <1538135855.2490729.1523775896.464BBC73@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Alexey Melnikov's No Objection on draft-ietf-lisp-rfc6830bis-20: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 17:09:42 -0000 Will add to -22. Thanks all. Dino > On Sep 28, 2018, at 4:57 AM, Alexey Melnikov = wrote: >=20 >> Something like: >>=20 >> =E2=80=9CThe specific algorithm the ITR uses for load-sharing is out = of the=20 >> scope of this document and does not prevent interoperability"=20 >=20 > Sounds good to me. Thank you. From nobody Fri Sep 28 13:35:56 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7863412F1A2; Fri, 28 Sep 2018 13:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.956 X-Spam-Level: X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 YdZrH6MySWVd; Fri, 28 Sep 2018 13:35:34 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE77127B92; Fri, 28 Sep 2018 13:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50097; q=dns/txt; s=iport; t=1538166934; x=1539376534; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Vy8d0/iKlSuEo3yG/PkFPm+s4NwmOWuGZQ+Go2Fg5Ow=; b=YJZQFr7CW2EF1BFKdxPdow9yRHl7YV3C0rAfemgqRnNshfk4ETfJvJQm hiQsn3AYEucpX5boDm61VeUw/H+d0n2RL96+SrgGuEC515qs9SqkHBD8j CeqnQ/iB2+7w7CfJ1Xw3PXiS76Ds5vwnjXnaTcENugBArQFIAIbPMQb0i Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAABZj65b/4sNJK0ZAUIbAQEBAQM?= =?us-ascii?q?BAQEHAwEBAYFSgV4FKmZ/IQeYOYFoJXiVXhSBZgsjhEkCg3shNRcBAwEBAgE?= =?us-ascii?q?BAm0cDIU4AQEBAQIBGgEsMg4CCw4EBiABBgcbKwMOBg0GAgEBgx0BgXkICAe?= =?us-ascii?q?HXJ4qH4MKgQIBBwc9hRUFinkXgUE/gRInDIIqNYMbAgMBgSoBCwcBGwqFUgK?= =?us-ascii?q?IKBgIBCyGAEaNXwmGQ4MLhlwGF4FHhFqCY4ZEjAaBeBeHDoFEATVkcTMaCBs?= =?us-ascii?q?VgycJFoIGF3sBAwSEK4MshV4fMAEXAQGKXg8XgicBAQ?= X-IronPort-AV: E=Sophos;i="5.54,316,1534809600"; d="scan'208,217";a="448533281" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2018 20:35:31 +0000 Received: from [10.32.173.55] ([10.32.173.55]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTP id w8SKZU88030903; Fri, 28 Sep 2018 20:35:30 GMT To: Luigi Iannone Cc: Magnus Westerlund , tsv-art@ietf.org, lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org, =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <153553422964.14784.628403975182959075@ietfa.amsl.com> <5dd519c0-6810-8596-37e9-377e38175a7d@ericsson.com> <8856bfce-8d2f-baae-d85c-fea09ba86f69@cisco.com> <29f21563-362e-e7cc-3e07-19ff14294eab@cisco.com> <368436FB-586D-4810-9A04-91CBD3C526D4@gigix.net> From: Fabio Maino Message-ID: <6f6e6640-6964-4b4e-a15e-f73f406cfdb0@cisco.com> Date: Fri, 28 Sep 2018 13:35:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <368436FB-586D-4810-9A04-91CBD3C526D4@gigix.net> Content-Type: multipart/alternative; boundary="------------22C74C5D87E349E9469F4094" Content-Language: en-US X-Outbound-SMTP-Client: 10.32.173.55, [10.32.173.55] X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 20:35:39 -0000 This is a multi-part message in MIME format. --------------22C74C5D87E349E9469F4094 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 9/21/18 2:04 AM, Luigi Iannone wrote: > Hi Fabio, > > just one comment on the following sentence (section 1) > > LISP-GPE MAY also be used to extend the LISP Data-Plane header, that > has allocated all by defining a Next Protocol "shim" header that > implements new data plane functions not supported in the LISP header. > > Something is missing in this sentence. > > May be: LISP-GPE MAY also be used to extend the LISP Data-Plane > header, **since > all of the reserved bits have been allocated, ** by defining a > Next Protocol "shim" header that > implements new data plane functions not supported in the LISP header. > Ciao Thanks for catching this Luigi. It will be addressed in -07. Fabio > > L. > > > >> On 21 Sep 2018, at 07:12, Fabio Maino > > wrote: >> >> I have incorporated the changes as discussed, so hopefully rev 6. can >> be used by reviewers before the telechat: >> https://www.ietf.org/id/draft-ietf-lisp-gpe-06.txt >> >> Here is the diff: goo.gl/tCKD4A >> >> >> I believe the following comments are still open. I'll work with the >> respective authors to address them in the next rev of the document. >> >> >> A. [Deborah/Magnus] it is being discussed on a separate private >> thread if the following should be added to the IANA section: >> "To ensure that protocols that are encapsulated in LISP-GPE will work >> well from a transport interaction perspective, the registration of a >> new encapsulated payload MUST contain an analysis of how LISP-GPE >> SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit >> Congestion Notification (ECN) bits whenever they apply to the new >> encapsulated payload. The analysis for the new encapsulated payload >> registered in this document is in section 3.1." >> >> >> B. [Magnus] draft-ietf-tsvwg-ecn-encap-guidelines has expired >> yesterday, and cannot be referenced. I'll add it back to section 3.1 >> as soon as the draft is refreshed. >> >> C. [Magnus/Mirja] in 3.1.1 Payload Specific Transport Interactions >> for Ethernet Encapsulated Payloads >> >> >>>The UDP Checksum considerations specified in section 5.3 of >> [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. >> Implementors are encouraged to consider the UDP checksum usage >> guidelines in section 3.4 of [RFC8085] when it is desirable to >> protect UDP, LISP and Ethernet headers against corruption. >> >> So this is not the necessary documentation of the analysis that >> IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. >> There needs to be an analysis here to verify that this protocol >> combination do work. You will actually have to discuss how the >> Ethernet encapsulation fulfills the requirements listed in Section 4 >> of RFC 6936. >> >> https://datatracker.ietf.org/doc/rfc7510/ is an example where such an >> analysis was included. I would also note the applicability >> limitations this has. >> >> Which actually brings up an additional issue for Ethernet >> encapsulation. For IP the assumption is that the IP traffic that is >> encapsulated is congestion controlled. This assumption is even less >> certain when having Ethernet. Thus, some consideration of that issue >> is likely needed. >> >> >>>When a LISP-GPE router performs Ethernet encapsulation, the inner >> 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be >> mapped from the encapsulated frame to the Type of Service field in >> the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' >> field as per guidelines provided by [RFC8325]. >> >> I don't know enough about IEEE and the various versions of Ethernet >> and WLAN here to be certain that 802.1Q PCP's can be mapped directly >> to the 802.11 User Priorities discussed in RFC8325. Please >> investigate if they are the same, and if they are the same >> priorities, then make a explicit statement that they are applicable. >> >> D. [Magnus] 3.1.2 Payload Specific Transport Interactions for NSH >> Encapsulated Payloads >> >> >>> The UDP Checksum considerations specified in section 5.3 of >> [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. >> Implementors are encouraged to consider the UDP checksum usage >> guidelines in section 3.4 of [RFC8085] when it is desirable to >> protect UDP, LISP, and NSH headers against corruption. >> >> Same as for Ethernet also the NSH header needs to have a documented >> analsysis of fulfillment of the requirements. >> >> >> Thanks, >> >> Fabio >> >> >> >> >> >> >> On 9/20/18 1:03 PM, Fabio Maino wrote: >>> Thanks Magnus, >>> I'll consolidate the changes we have agreed so far in the next rev >>> that I plan to publish later today. >>> >>> I'll then work on the comments on this email and will send you the >>> corresponding actions. >>> >>> Fabio >>> >>> On 9/20/18 2:39 AM, Magnus Westerlund wrote: >>>> >>>> Hi Fabio, >>>> >>>> Most of the below text is excellent. Some comments inline for >>>> needed clarifications and additions. >>>> >>>> On 9/18/2018 9:52 PM, Fabio Maino wrote: >>>>> Hi Magnus, >>>>> thanks for your comments. >>>>> >>>>> I think I see the points you are making. >>>>> >>>>> I'll add the section 3.1 below to specify the general transport >>>>> requirements for the registration of new LISP-GPE payloads, and I >>>>> will introduce two subsections to instantiate those requirements >>>>> for Ethernet and NSH (section 4.2 and 4.3 will be moved here). In >>>>> the "IANA Considerations" section I'll refer to this new section >>>>> 3.1 as a requirement for registration of new encapsulated payload. >>>>> >>>>> "3.1 Payload Specific Transport Interactions >>>>> >>>>> To ensure that protocols that are encapsulated in LISP-GPE will >>>>> work well from a transport interaction perspective, the >>>>> specification of a new encapsulated payload MUST contain an >>>>> analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP >>>>> mapping, and Explicit Congestion Notification (ECN) bits whenever >>>>> they apply to the new encapsulated payload. >>>>> >>>>> For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] >>>>> specifies how to handle UDP Checksums encouraging implementors to >>>>> consider UDP checksum usage guidelines in section 3.4 of [RFC8085] >>>>> when it is desirable to protect UDP and LISP headers against >>>>> corruption. Each new encapsulated payloads, when registered with >>>>> LISP-GPE, MUST be accompanied by a similar analysis. >>>>> >>>>> Encapsulated payloads may have a priority field that may or may >>>>> not be mapped to the DSCP field of the outer IP header (part of >>>>> Type of Service in IPv4 or Traffic Class in IPv6). Such new >>>>> encapsulated payloads, when registered with LISP-GPE, MUST be >>>>> accompanied by an analysis similar to the one performed in Section >>>>> 3.1.1 of this document for Ethernet payloads. >>>>> >>>>> Encapsulated payloads may have Explicit Congestion Notification >>>>> mechanisms that may or may not be mapped to the outer IP header >>>>> ECN field. Such new encapsulated payolads, when registered with >>>>> LISP-GPE, MUST be accompanied by a set of guidelines derived from >>>>> [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. >>>>> >>>>> The rest of this section specifies payload specific transport >>>>> interactions considerations for the two new LISP-GPE encapsulated >>>>> payloads specified in this document: Ethernet and NSH. >>>>> >>>>> 3.1.1 Payload Specific Transport Interactions for Ethernet >>>>> Encapsulated Payloads >>>>> >>>>> The UDP Checksum considerations specified in section 5.3 of >>>>> [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated >>>>> Payloads. Implementors are encouraged to consider the UDP checksum >>>>> usage guidelines in section 3.4 of [RFC8085] when it is desirable >>>>> to protect UDP, LISP and Ethernet headers against corruption. >>>> >>>> So this is not the necessary documentation of the analysis that >>>> IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to >>>> use. There needs to be an analysis here to verify that this >>>> protocol combination do work. You will actually have to discuss how >>>> the Ethernet encapsulation fulfills the requirements listed in >>>> Section 4 of RFC 6936. >>>> >>>> https://datatracker.ietf.org/doc/rfc7510/ is an example where such >>>> an analysis was included. I would also note the applicability >>>> limitations this has. >>>> >>>> Which actually brings up an additional issue for Ethernet >>>> encapsulation. For IP the assumption is that the IP traffic that is >>>> encapsulated is congestion controlled. This assumption is even less >>>> certain when having Ethernet. Thus, some consideration of that >>>> issue is likely needed. >>>> >>>> >>>>> >>>>> When a LISP-GPE router performs Ethernet encapsulation, the inner >>>>> 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be >>>>> mapped from the encapsulated frame to the Type of Service field in >>>>> the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' >>>>> field as per guidelines provided by [RFC8325]. >>>> >>>> I don't know enough about IEEE and the various versions of Ethernet >>>> and WLAN here to be certain that 802.1Q PCP's can be mapped >>>> directly to the 802.11 User Priorities discussed in RFC8325. Please >>>> investigate if they are the same, and if they are the same >>>> priorities, then make a explicit statement that they are applicable. >>>> >>>>> >>>>> When a LISP-GPE router performs Ethernet encapsulation, the inner >>>>> header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, >>>>> or used to determine the LISP Instance ID field. >>>>> >>>>> 3.1.2 Payload Specific Transport Interactions for NSH Encapsulated >>>>> Payloads >>>>> >>>>> The UDP Checksum considerations specified in section 5.3 of >>>>> [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. >>>>> Implementors are encouraged to consider the UDP checksum usage >>>>> guidelines in section 3.4 of [RFC8085] when it is desirable to >>>>> protect UDP, LISP, and NSH headers against corruption. >>>> >>>> Same as for Ethernet also the NSH header needs to have a documented >>>> analsysis of fulfillment of the requirements. >>>> >>>> >>>>> >>>>> When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN >>>>> values MAY be mapped as specified for the Next Protocol >>>>> encapsulated by NSH (namely IPv4, IPv6 and Ethernet)." >>>>> >>>>> >>>>> I will also add a paragraph to "Iana Considerations" that says: >>>>> >>>>> >>>>> "To ensure that protocols that are encapsulated in LISP-GPE will >>>>> work well from a transport interaction perspective, the >>>>> registration of a new encapsulated payload MUST contain an >>>>> analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP >>>>> mapping, and Explicit Congestion Notification (ECN) bits whenever >>>>> they apply to the new encapsulated payload. The analysis for the >>>>> new encapsulated payload registered in this document is in section >>>>> 3.1." >>>>> >>>>> Please, let me know if this address your comments. >>>>> >>>>> Thanks, >>>>> Fabio >>>>> >>>>> >>>>> >>>>> On 8/29/18 2:17 AM, Magnus Westerlund wrote: >>>>>> Reviewer: Magnus Westerlund >>>>>> Review result: Not Ready >>>>>> >>>>>> This document has been reviewed as part of the transport area directorate's >>>>>> ongoing effort to review key IETF documents. These comments were written >>>>>> primarily for the transport area directors, but are copied to the document's >>>>>> authors and WG for their information and to allow them to address any issues >>>>>> raised. >>>>>> >>>>>> When done at the time of IETF Last Call, the authors should consider this >>>>>> review together with any other last-call comments they receive. >>>>>> Please always CCtsv-art@ietf.org if you reply to or forward this review. >>>>>> >>>>>> Issue A. >>>>>> >>>>>> The reason I state Not Ready has to do with this documents failure to consider >>>>>> the use of zero checksum for IPv6 when tunneling other things than IP. The none >>>>>> GPE version is limited to tunnel IP for which the analysis for use of zero >>>>>> checksum has been done. Each of the new tunneled protocols that are specified >>>>>> in this document, i.e. ethernet and NHS, will need to perform the analysis if >>>>>> they are safe to use zero checksum or not, and if not disallow zero checksum >>>>>> for IPv6/UDP. The documetn also need a requirement in the registration >>>>>> requirements to perform this analysis and defined if zero checksum is >>>>>> acceptable or not. >>>>>> >>>>>> Citing Section 5.3 of draft-ietf-lisp-rfc6830bis >>>>>> >>>>>> UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero >>>>>> by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation >>>>>> [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is >>>>>> received by an ETR, the ETR MUST accept the packet for >>>>>> decapsulation. When an ITR transmits a non-zero value for the UDP >>>>>> checksum, it MUST send a correctly computed value in this field. >>>>>> When an ETR receives a packet with a non-zero UDP checksum, it MAY >>>>>> choose to verify the checksum value. If it chooses to perform >>>>>> such verification, and the verification fails, the packet MUST be >>>>>> silently dropped. If the ETR chooses not to perform the >>>>>> verification, or performs the verification successfully, the >>>>>> packet MUST be accepted for decapsulation. The handling of UDP >>>>>> zero checksums over IPv6 for all tunneling protocols, including >>>>>> LISP, is subject to the applicability statement in [RFC6936]. >>>>>> >>>>>> The issue is that when LISP encapsulate other protocols the impact of a >>>>>> missdelivered tunnel packet to the wrong ETR can have different impacts. As >>>>>> well as errors in the headers of the encapsulated packet that may be assumed to >>>>>> be protected by the encapsulating layer. Thus, individual analysis of each >>>>>> protocol that are tunneled are needed. >>>>>> >>>>>> B.) 4.2. Type of Service >>>>>> >>>>>> When a LISP-GPE router performs Ethernet encapsulation, the inner >>>>>> 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be >>>>>> mapped from the encapsulated frame to the Type of Service field in >>>>>> the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' >>>>>> field. >>>>>> >>>>>> Any recommendation about how to perform that mapping? Maybe parts of >>>>>> https://datatracker.ietf.org/doc/rfc8325/ are relevant in this context. >>>>>> >>>>>> C. General case of 4.2: >>>>>> >>>>>> I expect other protocols than Ethernet may have a priority field that may or >>>>>> may not be mapped to the DSCP field of the tunnel packet. >>>>>> >>>>>> I would expect that for new protocol registration in the LISP-GPE Next Protocol >>>>>> Registry should consider this. Thus, it would be good to note that such >>>>>> considerations are needed and part of what should be evaluated for new >>>>>> registrations. >>>>>> >>>>>> D. ECN handling >>>>>> >>>>>> Section 5.3 of draft-ietf-lisp-rfc6830bis states: >>>>>> >>>>>> o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 >>>>>> of the IPv6 'Traffic Class' field) requires special treatment in >>>>>> order to avoid discarding indications of congestion [RFC3168]. >>>>>> ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner >>>>>> header to the outer header. Re-encapsulation MUST copy the 2-bit >>>>>> 'ECN' field from the stripped outer header to the new outer >>>>>> header. >>>>>> >>>>>> The above rules may not be applicable for all transport protocols. Thus I think >>>>>> it is required that one do protocol specific considerations of ECN. TSVWG are >>>>>> working on recommendations for tunnels handling of ECN here, see: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ Thus, >>>>>> my expectation would be to ensure that the registered protocols have defined >>>>>> ECN handling, explicitly or by reference. Secondly that registration >>>>>> requirement states the need for this consideration. >>>>>> >>>>>> Summary: To ensure that future added protocols that are encapsulated will work >>>>>> well from a transport interaction perspective there need to be a requirement on >>>>>> new registration to consider and define how they use zero checksum, any DSCP >>>>>> mapping and ECN bits. In addition the current document needs to ensure these >>>>>> things are clearly specified for the encapsulated protocols in this document. >>>>>> >>>>>> >>>>> >>>> -- >>>> >>>> Magnus Westerlund >>>> >>>> ---------------------------------------------------------------------- >>>> Network Architecture & Protocols, Ericsson Research >>>> ---------------------------------------------------------------------- >>>> Ericsson AB | Phone +46 10 7148287 >>>> Torshamnsgatan 23 | Mobile +46 73 0949079 >>>> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com >>>> ---------------------------------------------------------------------- >>> >>> >> > --------------22C74C5D87E349E9469F4094 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 9/21/18 2:04 AM, Luigi Iannone wrote:
Hi Fabio,

just one comment on the following sentence (section 1)

LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
has allocated all by defining a Next Protocol "shim" header that
implements new data plane functions not supported in the LISP header.

Something is missing in this sentence.

May be: LISP-GPE MAY also be used to extend the LISP Data-Plane header, **since
all of the reserved bits have been allocated, ** by defining a Next Protocol "shim" header that
implements new data plane functions not supported in the LISP header.
Ciao

Thanks for catching this Luigi. It will be addressed in -07.

Fabio


L.



On 21 Sep 2018, at 07:12, Fabio Maino <fmaino@cisco.com> wrote:

I have incorporated the changes as discussed, so hopefully rev 6. can be used by reviewers before the telechat: https://www.ietf.org/id/draft-ietf-lisp-gpe-06.txt

Here is the diff: goo.gl/tCKD4A


I believe the following comments are still open. I'll work with the respective authors to address them in the next rev of the document.


A. [Deborah/Magnus] it is being discussed on a separate private thread if the following should be added to the IANA section:
"To ensure that protocols that are encapsulated in LISP-GPE will work well from a transport interaction perspective, the registration of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion Notification (ECN) bits whenever they apply to the new encapsulated payload. The analysis for the new encapsulated payload registered in this document is in section 3.1."


B. [Magnus] draft-ietf-tsvwg-ecn-encap-guidelines has expired yesterday, and cannot be referenced. I'll add it back to section 3.1 as soon as the draft is refreshed.

C. [Magnus/Mirja] in 3.1.1 Payload Specific Transport Interactions for Ethernet Encapsulated Payloads

>>>The UDP Checksum considerations specified in section 5.3 of [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. Implementors are encouraged to consider the UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP, LISP and Ethernet headers against corruption.

So this is not the necessary documentation of the analysis that IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. There needs to be an analysis here to verify that this protocol combination do work. You will actually have to discuss how the Ethernet encapsulation fulfills the requirements listed in Section 4 of RFC 6936.

https://datatracker.ietf.org/doc/rfc7510/ is an example where such an analysis was included. I would also note the applicability limitations this has.

Which actually brings up an additional issue for Ethernet encapsulation. For IP the assumption is that the IP traffic that is encapsulated is congestion controlled. This assumption is even less certain when having Ethernet. Thus, some consideration of that issue is likely needed.

>>>When a LISP-GPE router performs Ethernet encapsulation, the inner 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be mapped from the encapsulated frame to the Type of Service field in the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' field as per guidelines provided by [RFC8325].

I don't know enough about IEEE and the various versions of Ethernet and WLAN here to be certain that 802.1Q PCP's can be mapped directly to the 802.11 User Priorities discussed in RFC8325. Please investigate if they are the same, and if they are the same priorities, then make a explicit statement that they are applicable.

D. [Magnus] 3.1.2 Payload Specific Transport Interactions for NSH Encapsulated Payloads

>>> The UDP Checksum considerations specified in section 5.3 of [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. Implementors are encouraged to consider the UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP, LISP, and NSH headers against corruption.

Same as for Ethernet also the NSH header needs to have a documented analsysis of fulfillment of the requirements.


Thanks,

Fabio






On 9/20/18 1:03 PM, Fabio Maino wrote:
Thanks Magnus,
I'll consolidate the changes we have agreed so far in the next rev that I plan to publish later today.

I'll then work on the comments on this email and will send you the corresponding actions.

Fabio

On 9/20/18 2:39 AM, Magnus Westerlund wrote:

Hi Fabio,

Most of the below text is excellent. Some comments inline for needed clarifications and additions.

On 9/18/2018 9:52 PM, Fabio Maino wrote:
Hi Magnus,
thanks for your comments.

I think I see the points you are making.

I'll add the section 3.1 below to specify the general transport requirements for the registration of new LISP-GPE payloads, and I will introduce two subsections to instantiate those requirements for Ethernet and NSH (section 4.2 and 4.3 will be moved here). In the "IANA Considerations" section I'll refer to this new section 3.1 as a requirement for registration of new encapsulated payload.

"3.1 Payload Specific Transport Interactions

To ensure that protocols that are encapsulated in LISP-GPE will work well from a transport interaction perspective, the specification of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion Notification (ECN) bits whenever they apply to the new encapsulated payload.

For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] specifies how to handle UDP Checksums encouraging implementors to consider UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP and LISP headers against corruption. Each new encapsulated payloads, when registered with LISP-GPE, MUST be accompanied by a similar analysis.

Encapsulated payloads may have a priority field that may or may not be mapped to the DSCP field of the outer IP header (part of Type of Service in IPv4 or Traffic Class in IPv6). Such new encapsulated payloads, when registered with LISP-GPE, MUST be accompanied by an analysis similar to the one performed in Section 3.1.1 of this document for Ethernet payloads.

Encapsulated payloads may have Explicit Congestion Notification mechanisms that may or may not be mapped to the outer IP header ECN field. Such new encapsulated payolads, when registered with LISP-GPE, MUST be accompanied by a set of guidelines derived from [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].

The rest of this section specifies payload specific transport interactions considerations for the two new LISP-GPE encapsulated payloads specified in this document: Ethernet and NSH.

3.1.1 Payload Specific Transport Interactions for Ethernet Encapsulated Payloads

The UDP Checksum considerations specified in section 5.3 of [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. Implementors are encouraged to consider the UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP, LISP and Ethernet headers against corruption.

So this is not the necessary documentation of the analysis that IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. There needs to be an analysis here to verify that this protocol combination do work. You will actually have to discuss how the Ethernet encapsulation fulfills the requirements listed in Section 4 of RFC 6936.

https://datatracker.ietf.org/doc/rfc7510/ is an example where such an analysis was included. I would also note the applicability limitations this has.

Which actually brings up an additional issue for Ethernet encapsulation. For IP the assumption is that the IP traffic that is encapsulated is congestion controlled. This assumption is even less certain when having Ethernet. Thus, some consideration of that issue is likely needed.



When a LISP-GPE router performs Ethernet encapsulation, the inner 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be mapped from the encapsulated frame to the Type of Service field in the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' field as per guidelines provided by [RFC8325].

I don't know enough about IEEE and the various versions of Ethernet and WLAN here to be certain that 802.1Q PCP's can be mapped directly to the 802.11 User Priorities discussed in RFC8325. Please investigate if they are the same, and if they are the same priorities, then make a explicit statement that they are applicable.


When a LISP-GPE router performs Ethernet encapsulation, the inner header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or used to determine the LISP Instance ID field.

3.1.2 Payload Specific Transport Interactions for NSH Encapsulated Payloads

The UDP Checksum considerations specified in section 5.3 of [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. Implementors are encouraged to consider the UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP, LISP, and NSH headers against corruption.

Same as for Ethernet also the NSH header needs to have a documented analsysis of fulfillment of the requirements.



When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN values MAY be mapped as specified for the Next Protocol encapsulated by NSH (namely IPv4, IPv6 and Ethernet)."


I will also add a paragraph to "Iana Considerations" that says:


"To ensure that protocols that are encapsulated in LISP-GPE will work well from a transport interaction perspective, the registration of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion Notification (ECN) bits whenever they apply to the new encapsulated payload. The analysis for the new encapsulated payload registered in this document is in section 3.1."

Please, let me know if this address your comments.

Thanks,
Fabio



On 8/29/18 2:17 AM, Magnus Westerlund wrote:
Reviewer: Magnus Westerlund
Review result: Not Ready

This document has been reviewed as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG for their information and to allow them to address any issues
raised.

When done at the time of IETF Last Call, the authors should consider this
review together with any other last-call comments they receive.
Please always CC tsv-art@ietf.org if you reply to or forward this review.

Issue A.

The reason I state Not Ready has to do with this documents failure to consider
the use of zero checksum for IPv6 when tunneling other things than IP. The none
GPE version is limited to tunnel IP for which the analysis for use of zero
checksum has been done. Each of the new tunneled protocols that are specified
in this document, i.e. ethernet and NHS, will need to perform the analysis if
they are safe to use zero checksum or not, and if not disallow zero checksum
for IPv6/UDP. The documetn also need a requirement in the registration
requirements to perform this analysis and defined if zero checksum is
acceptable or not.

Citing Section 5.3 of draft-ietf-lisp-rfc6830bis

   UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as zero
      by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
      [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is
      received by an ETR, the ETR MUST accept the packet for
      decapsulation.  When an ITR transmits a non-zero value for the UDP
      checksum, it MUST send a correctly computed value in this field.
      When an ETR receives a packet with a non-zero UDP checksum, it MAY
      choose to verify the checksum value.  If it chooses to perform
      such verification, and the verification fails, the packet MUST be
      silently dropped.  If the ETR chooses not to perform the
      verification, or performs the verification successfully, the
      packet MUST be accepted for decapsulation.  The handling of UDP
      zero checksums over IPv6 for all tunneling protocols, including
      LISP, is subject to the applicability statement in [RFC6936].

The issue is that when LISP encapsulate other protocols the impact of a
missdelivered tunnel packet to the wrong ETR can have different impacts. As
well as errors in the headers of the encapsulated packet that may be assumed to
be protected by the encapsulating layer. Thus, individual analysis of each
protocol that are tunneled are needed.

B.) 4.2.  Type of Service

   When a LISP-GPE router performs Ethernet encapsulation, the inner
   802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be
   mapped from the encapsulated frame to the Type of Service field in
   the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'
   field.

Any recommendation about how to perform that mapping? Maybe parts of
https://datatracker.ietf.org/doc/rfc8325/ are relevant in this context.

C. General case of 4.2:

I expect other protocols than Ethernet may have a priority field that may or
may not be mapped to the DSCP field of the tunnel packet.

I would expect that for new protocol registration in the LISP-GPE Next Protocol
Registry should consider this. Thus, it would be good to note that such
considerations are needed and part of what should be evaluated for new
registrations.

D. ECN handling

Section 5.3 of draft-ietf-lisp-rfc6830bis states:

   o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion [RFC3168].
      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
      header to the outer header.  Re-encapsulation MUST copy the 2-bit
      'ECN' field from the stripped outer header to the new outer
      header.

The above rules may not be applicable for all transport protocols. Thus I think
it is required that one do protocol specific considerations of ECN. TSVWG are
working on recommendations for tunnels handling of  ECN here, see: 
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ Thus,
my expectation would be to ensure that the registered protocols have defined
ECN handling, explicitly or by reference. Secondly that registration
requirement states the need for this consideration.

Summary: To ensure that future added protocols that are encapsulated will work
well from a transport interaction perspective there need to be a requirement on
new registration to consider and define how they use zero checksum, any DSCP
mapping and ECN bits. In addition the current document needs to ensure these
things are clearly specified for the encapsulated protocols in this document.





-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------





--------------22C74C5D87E349E9469F4094-- From nobody Fri Sep 28 14:30:45 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0E012872C; Fri, 28 Sep 2018 14:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 m25cJajdR8ut; Fri, 28 Sep 2018 14:30:34 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13C7127148; Fri, 28 Sep 2018 14:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2724; q=dns/txt; s=iport; t=1538170234; x=1539379834; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=YNPLbhr9xCcISvL4lsv8gRpzaOiRHKEpBgzi1HKGqNk=; b=iCUJ4tG0UdpQzE9w3slbBoC/MR9LFCA91DgySTkojSe9BjvflcRasq36 xwBmxE1cytRH+aw/tm4EhulSOyrts/LmAluPPXYutGHExjhIX/QZHVjo4 5vxTKLcmPlBH+zdZ0FmnNeO/oXUWHEVyclSBqJpEXsOzZjHxDL+IYb2gC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAAA/na5b/5FdJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVIILZn8og3SURoFgCCWWaoFmCyOESQKDeyE3FQEDAQE?= =?us-ascii?q?CAQECbRwMhTkBBSMPAQVBEAsOCgICJgICVwYBDAgBAYMdAYIBD6RWgS6EMwc?= =?us-ascii?q?9hREFgQuJcxeBQT+BEicMgl+DGwIBAgGBKgESAYMgglcCiEyGLI4lCYZDiWc?= =?us-ascii?q?GF4FHhFqCY4N1gk+MBokdgVgiZFgRCDMaCBsVgyeLFoVeHzABiwoGCReCJwE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.54,316,1534809600"; d="scan'208";a="178278499" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2018 21:30:32 +0000 Received: from [10.32.173.55] ([10.32.173.55]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTP id w8SLUVxr002730; Fri, 28 Sep 2018 21:30:32 GMT To: Alvaro Retana , The IESG Cc: draft-ietf-lisp-gpe@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org References: <153789926133.5101.18151906676525764346.idtracker@ietfa.amsl.com> From: Fabio Maino Message-ID: <3301d278-0ded-9073-9f63-dc426356f1c8@cisco.com> Date: Fri, 28 Sep 2018 14:30:31 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153789926133.5101.18151906676525764346.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.32.173.55, [10.32.173.55] X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 21:30:36 -0000 Thanks for  your comments Alvaro. Please see below. On 9/25/18 11:14 AM, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-lisp-gpe-06: No Objection > > 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 https://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: > https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have some non-blocking comments (and nits): > > (1) §1: "LISP-GPE MAY also be used to extend the LISP Data-Plane header..." I > think that MAY is out of place because there's nothing normative about the > statement. ok. I'll fix in -07 with s/MAY/can/. > > (2) §3: "If the P-bit is clear (0) the LISP header conforms to the definition > in [I-D.ietf-lisp-rfc6830bis]." I find this statement a little confusing > because even with the bit set, the header still conforms to rfc6830bis, except > for the Nonce/Map-Version field. IOW, it sounds as if the bit makes the header > non-conforming. ok. I'll fix in -07 with s/conform/is bit-by-bit equivalent/ > > (3) §3: For clarity, it would be nice to add a figure showing the header with > the P and V bits set. A similar comment was raised by another reviewer. It was decided that this document will use the same convention of 6830bis (that doesn't have a figure with the V bit set). > > (4) §3.1: "...the specification of a new encapsulated payload MUST contain an > analysis of how LISP-GPE SHOULD deal with..." s/SHOULD/should In this case > the "SHOULD" is not normative. ok. will fix in -07 > > (5) For IP packets, two encapsulation mechanisms exist, the base one defined in > rfc6830bis and the generic one defined in this document. When encapsulating > towards a GPE-capable router, which mechanisms should be used? Should one have > preference over the other? I'm thinking it probably doesn't matter (since the > receiving router can understand both) -- I'm trying to figure out whether there > are operational considerations or guidance that are worth mentioning. > > I can't think of a strong reason why one would be better than the other, and I see no harm in allowing both behaviors. I'd leave the choice to the implementors. Thanks, Fabio From nobody Fri Sep 28 15:04:10 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C9A129385; Fri, 28 Sep 2018 15:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HJ4cVsUWn6Mb; Fri, 28 Sep 2018 15:03:56 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC8C130E1C; Fri, 28 Sep 2018 15:03:55 -0700 (PDT) X-AuditID: 12074423-10dff70000000a35-b2-5baea5470eec Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id A7.2D.02613.845AEAB5; Fri, 28 Sep 2018 18:03:53 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w8SM3kGU017478; Fri, 28 Sep 2018 18:03:47 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8SM3ebP011501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Sep 2018 18:03:43 -0400 Date: Fri, 28 Sep 2018 17:03:40 -0500 From: Benjamin Kaduk To: "Joel M. Halpern" Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Message-ID: <20180928220340.GO24695@kduck.kaduk.org> References: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com> <739fae18-85a5-26c2-85a6-7d7c830fcd32@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <739fae18-85a5-26c2-85a6-7d7c830fcd32@joelhalpern.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixG6nouu5dF20wdH5vBaX171jtVjVOo/F YsaficwWH0+9YbJ40badzWLKWXUHNo/ns9aweixZ8pPJ49yU74wBzFFcNimpOZllqUX6dglc GZ1dFxkLDmxhrGjbmdbAOKebsYuRk0NCwERizbtnbF2MXBxCAouZJLZM3ccC4WxklHg/u58V wrnKJPH8TQsrSAuLgKrEtnfrmEBsNgEViYbuy8wgtoiAtsT+JR+YQBqYBfoYJVrPPmMHSQgL pEgc+fIdrIgXaN+iA0/BBgkJtDNKXFpWAhEXlDg58wkLiM0soCVx499LoEEcQLa0xPJ/HCBh TgFnia4fH8BaRQWUJfb2HWKfwCgwC0n3LCTdsxC6FzAyr2KUTcmt0s1NzMwpTk3WLU5OzMtL LdI108vNLNFLTSndxAgObRflHYwv+7wPMQpwMCrx8DrYrosWYk0sK67MPcQoycGkJMrrOB0o xJeUn1KZkVicEV9UmpNafIhRgoNZSYT3dixQjjclsbIqtSgfJiXNwaIkzjuxZXG0kEB6Yklq dmpqQWoRTFaGg0NJgrdsCVCjYFFqempFWmZOCUKaiYMTZDgP0PAakBre4oLE3OLMdIj8KUZ7 jlUzOmYwc2w70wkk255eB5IdIFKIJS8/L1VKnJcdpE0ApC2jNA9uMihtSWTvr3nFKA70qDDv OpAqHmDKg5v9CmgtE9BakQNrQNaWJCKkpBoYbf1Oqi/z938Wz56x8HbgOZWNE//PV7Gxj+9W ETqTV/BFYWV+94v2i5cT7ZKmnVuvcHJnncWRd1cuZnIv8tKYGiNwueNjsEPlArt+v037S38J Bp3Iy/gYzLY5tEEyklE7hnPzG7F9+k5NvM+fr1sc9ZhJuXNnWEu4ooz0w90bN8fnXz7nHntf iaU4I9FQi7moOBEAHFuKRjYDAAA= Archived-At: Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 22:04:01 -0000 Hi Joel, On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote: > Is there text we can add about the scoping that will change your discuss > into a series of useful comments? I had attempted to structure my Discuss points so that they would either be useful comments as is, or rendered moot by a reduced scope. I guess I can try to clarify those below. (To be clear, reducing the scope is only going to move from "has potentially existentially bad problems" to "has substantial issues that likely require reengineering to resolve".) > If so, Some indication of how you would like that phrased would help us > address these. I think Ekr's ballot position on 6833bis has a good summary of the architecture assumptions that the reduced scope allows us to make. In order to have the document be able to plausibly make those claims, it looks like we'd need to at least: (1) update the Abstract/Introduction to clarify that the EID namespace is only defined within a single administrative domain. (2) (optionally, if it makes sense) mention in the introduction that this administrative domain can include transport over other networks in the same way that a VPN would function[*], without requiring cooperation from or interaction with the other networks' administrators (3) remove the "global" text from the EID-to-RLOC Database and Map-Cache definitions (4) update the EID-Prefix definition to talk about the local site or administrative domain's "address allocation authority" (5) Take a look at the EID definition to consider whether references to "on the public Internet" are still valid, and the text about assignment in a hierarchical manner should be revised for the new scope as well. Likewise for EID-internal structure that is "not visible to the global routing system" (I stopped skimming and looking for problematic text around section 6) [*] Ideally this would be done without using the term "VPN" itself, since I'd like to get a movement going to restrict "VPN" to include confidentiality (i.e., privacy) protection. "virtual network" or "overlay network" may or may not be good candidate replacement terms. > If not, we seem to have a larger problem. Well, we appear to have five ADs that are supporting making LISP-SEC a normative reference and thus MTI; I don't know if that scale of change meets your threshold for a "larger problem". > Yours, > Joel > > On 9/26/18 11:44 PM, Benjamin Kaduk wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-lisp-rfc6830bis-20: 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 https://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: > > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have grave concerns about the suitability of LISP as a whole, in its > > present form, for advancement to the Standards-Track. While some of my > > concerns are not specific to this document, as the core protocol > > (data-plane) spec, it seems an appropriate place to attach them to. > > > > I am told, out of band, that the intended deployment model is no longer to > > cover the entire Internet (c.f. the MISSREF-state > > draft-ietf-lisp-introduction's "with LISP, the dge of the Internet and the > > core can be logically separated and interconnected by LISP-capable > > routers", etc.), and that full Internet-scale operation is no longer a > > goal. However, since that does not seem to be reflected in the current > > batch of documents up for IESG review, I am forced to ballot on them > > "as-is", namely as targetting global Internet deployment. The requirements > > placed on the mapping system are so stringent so as to be arguably > > unachievable at Internet-scale, though that arguably has more of an > > interaction with the control-plane than the data-plane. It's still in > > scope here, though, as part of the overall description of the protocol > > flow. (rendered moot by scope reduction) > > There are an almost innumerable number of downgrade attacks possible, and > > the control-plane and data-plane security mechanisms are not normative > > dependencies of the current corpus of documents, and as such are not up for > > consideration as mitigating the security concerns with the core documents. The downgrade attacks will probably require some further analysis; LISP-SEC would protect a lot of the header bits but I think there may be some other data flows to be looked at. > > Section 3 defines the EID-to-RLOC Datbaase: > > > > EID-to-RLOC Database: The EID-to-RLOC Database is a global > > distributed database that contains all known EID-Prefix-to-RLOC > > mappings. Each potential ETR typically contains a small piece of > > the database: the EID-to-RLOC mappings for the EID-Prefixes > > "behind" the router. These map to one of the router's own > > globally visible IP addresses. Note that there MAY be transient > > conditions when the EID-Prefix for the site and Locator-Set for > > each EID-Prefix may not be the same on all ETRs. This has no > > negative implications, since a partial set of Locators can be > > used. > > > > No compelling architecture for a trustworthy global distributed database > > has been presented that I've seen so far, and LISP relies heavily on the > > mapping system's database for its functionality. I am concerned that so > > many requirements are placed on the mapping system so as to be in effect > > unimplementable, in which case it would seem that the architecture as a > > whole (that is, for a global Internet-scale system) is not fit for purpose. (rendered moot by scope reduction) > > Section 4.1's Step (6) only mentions parsing "to check for format > > validity". I think it is appropriate to mention (and refer to) source > > authentication checks as well, since bad Map-Reply data can allow all sorts > > of attacks to occur. (not affected by scope reduction) > > There are some fairly subtle ordering requirements between the order of > > entries in Map-Reply messages and the Locator-Status-Bits in data-plane > > traffic (so that the semantic meaning of the status bits are meaningful), > > which is only given a minimal treatment in the control-plane document. The > > need for synchronization in interpreting these bits should be mentioned > > more prominently in the data-plane document as well. (not affected by scope reduction) > > > > The usage of the Instance ID does not seem to be adequately covered; from > > what I've been able to pick up so far it seems that both source and > > destination participants must agree on the meaning of an Instance ID, and > > the source and destination EIDs must be in the same Instance. This does > > not seem like it is compatible with Internet scale, especially if there are > > only 24 usable bits of Instance ID. (not affected by scope reduction) > > > > There seems to be a lot of intra-site synchronization requirements, notably > > with respect to Map-Version consistency, the contents and ordering of > > locator sets for EIDs in the site, etc.; the actual hard requirements for > > synchronization within a site should be clearly called out, ideally in a > > single location. (not affected by scope reduction, since ETRs are affected and not just Map-Servers) > > > > The security considerations attempt to defer substantially to the > > threat-analysis in RFC 7835, which does not really seem like a complete > > threat analysis and does not provide analysis as to what requirements are > > placed on the boundaries between the different components of LISP (data > > plane, control plane, mapping system, various extensions, etc.). The > > secdir reviewer had some good thoughts in this space. (not affected by scope reduction) > > > > The security considerations throughout the LISP documents place a heavy > > focus on the risk of over-claiming for routing EID-prefixes. This is a > > real concern, to be clear, but it should not overshadow the risk of an > > attacker who is able to move traffic around at will, strip security > > protections, cause denial of service, alter data-plane payloads, etc. > > Similarly, this document's security considerations call out denial of > > service as a risk from Map-Cache insertion/spoofing, but the risks from an > > attacker being able to read and modify the traffic, perhaps even without > > detection, seems a much greater threat to me. (not affected by scope reduction) > > > > I am not convinced that this protocol meets the current IETF requirements > > for the security properties of Standards-Track Protocols without at least > > LISP-SEC as a mandatory-to-implement component, and possibly additional or > > stronger requirements. (I did not do a full analysis of the system in the > > presence of those security mechanisms, since that is not what is being > > presented for review.) (noting that LISP-SEC needs to be MTI and analysis performed under the new assumptions) > > Having an EID that is associated to user-correlatable devices has severe > > privacy considerations, but I could not find this mentioned anywhere in all > > of the LISP documents I've read so far. (not affected by scope reduction) -Benjamin > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I apologize for the somewhat scattered nature of these comments; there are > > a lot of them and I was focusing my time more on trying to understand the > > broader system, and the intended security posture, so they did not get as > > much clean-up as I would have liked. (Most of my review was performed on the > > -18, though I have tried to update to the -20 as relevant.) > > > > > > The instance ID provides for organizational correlation, another privacy > > exposure. > > > > Is there anything different between an "EID-to-RLOC Map-Request" and just a > > "Map-Request"? (Same question for "Map-Reply", too.) > > > > There's a lot of stuff that seems to work best if there is symmetric > > bidirectional traffic, with inline signalling of map version and > > reachability changes, though clearly everything is designed to also work > > with asymmetric connectivity or unidirectional traffic. It would be nice > > to have a high-level summary in or near the introduction about what kinds > > of behavior/performance differences are expected for bidirectional vs. > > unidirectional traffic. > > > > Section 2 > > > > That's not the 8174 boilerplate; it's more than just adding a cite to the > > 2119 boilerplate. > > > > Section 3 > > > > nit: "An address family that pertains to the Data-Plane." is a sentence > > fragment. > > > > Ingress Tunnel Router (ITR): An ITR is a router that resides in a > > [...] > > mapping lookup in the destination address field. Note that this > > destination RLOC MAY be an intermediate, proxy device that has > > better knowledge of the EID-to-RLOC mapping closer to the > > > > This doesn't seem like a 2119 MAY is necessary, but rather a statement of > > fact that may not be known to the encapsulating ITR. > > > > Specifically, when a service provider prepends a LISP header for > > Traffic Engineering purposes, the router that does this is also > > regarded as an ITR. The outer RLOC the ISP ITR uses can be based > > on the outer destination address (the originating ITR's supplied > > RLOC) or the inner destination address (the originating host's > > supplied EID). > > > > I'm confused here, perhaps in multiple ways. Are there now *two* LISP > > headers on the packet? Is the "outer RLOC the ISP ITR uses" the source > > RLOC or the destination RLOC? > > > > Negative Mapping Entry: A negative mapping entry, also known as a > > negative cache entry, is an EID-to-RLOC entry where an EID-Prefix > > is advertised or stored with no RLOCs. That is, the Locator-Set > > for the EID-to-RLOC entry is empty or has an encoded Locator count > > of 0. > > > > Is "empty" a distinct representation from "locator count of zero"? > > > > Perhaps something of an aside, but the check described for > > Route-Returnability is a somewhat weak check, and in some cases could still > > be spoofed. (I don't expect this to surprise anyone, of course, but > > perhaps some more qualifiers could be added to the text.) > > > > Section 4 > > > > An additional LISP header MAY be prepended to packets by a TE-ITR > > when re-routing of the path for a packet is desired. A potential > > use-case for this would be an ISP router that needs to perform > > Traffic Engineering for packets flowing through its network. In such > > a situation, termed "Recursive Tunneling", an ISP transit acts as an > > additional ITR, and the RLOC it uses for the new prepended header > > would be either a TE-ETR within the ISP (along an intra-ISP traffic > > engineered path) or a TE-ETR within another ISP (an inter-ISP traffic > > engineered path, where an agreement to build such a path exists). > > > > "the RLOC it uses for the new prepnded header", again, this is as the > > destination RLOC (vs. source RLOC)? > > > > Section 4.1 > > > > o Map-Replies are sent on the underlying routing system topology > > using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. > > > > Just to check my understanding: is the "underlying routing system topology" > > the same as the "underlay"? > > > > Is step (3) just describing more of what step (2) says is "not described in > > this example"? > > > > Section 5.3 > > > > The word "nonce" is normally used for something used exactly once. > > E.g., with some AEAD algorithms, if the same "nonce" input is used for > > different encryptions, the entire security of the system is compromised. > > It would be better to refer to this field with a different term, given > > that "the same nonce can be used for a period of time when encapsulating to > > the same ETR". "Uniquifier" or "random value" might be reasonable choices. > > > > Why is there no discussion of the Map-Version or Instance-ID fields > > in this section? > > > > When doing ETR/PETR decapsulation: > > > > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > > the case of IPv6) SHOULD be copied from the outer-header 'Time to > > Live' field, when the Time to Live value of the outer header is > > less than the Time to Live value of the inner header. Failing to > > perform this check can cause the Time to Live of the inner header > > to increment across encapsulation/decapsulation cycles. This > > check is also performed when doing initial encapsulation, when a > > packet comes to an ITR or PITR destined for a LISP site. > > > > Er, what is "this check" that is also performed for initial encapsulation? > > How are there multiple TTL values to compare? > > > > o The inner-header 'Differentiated Services Code Point' (DSCP) field > > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be > > copied from the outer-header DSCP field ('Traffic Class' field, in > > the case of IPv6) to the inner-header. > > > > nit: the first "inner-header" seems like an editing remnant? > > > > Section 7.1 > > > > How is this stateless if it invovles knowledge about the routers between > > the ITR and all possible ETRs (i.e., a set that could change over time)? > > > > Section 8 > > > > This 32-bit vs 24-bit thing is pretty hokey for a standards-track > > specification (yes, I know that LISP-DDT is not standards track at the > > moment). > > > > Section 9 > > > > Alternatively, RLOC information MAY be gleaned from received tunneled > > > > What is this an alternative to? The list of four options above? > > > > packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache > > entry, one learned from the source RLOC of a received encapsulated > > packet, is only stored and used for a few seconds, pending > > verification. Verification is performed by sending a Map-Request to > > the source EID (the inner-header IP source address) of the received > > encapsulated packet. > > > > The source EID is some random end system, right? So this relys on some > > magic in the ETR to detect that there's a Map-Request and reply directly > > instead of passing it on to the EID that won't know what to do with it? > > > > Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and > > might benefit from an explicit section reference to the other document. > > > > Section 10 > > > > What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it > > is not marked as well-known at > > https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion is > > probably in order. > > > > Again, when we are talking about the internal structure of the Map-Reply, a > > detailed section refernce to 6833bis is useful. > > > > Modifying LSBs seems like a fine DoS attack vector for an on-path attacker. > > > > value of 1. Locator-Status-Bits are associated with a Locator-Set > > per EID-Prefix. Therefore, when a Locator becomes unreachable, the > > Locator-Status-Bit that corresponds to that Locator's position in the > > list returned by the last Map-Reply will be set to zero for that > > particular EID-Prefix > > > > Doesn't this imply a stateful relationship between the ordering of > > Map-Replys and data-plane traffic? > > > > Section 10.1 > > > > Note that "ITR" and "ETR" are relative terms here. Both devices MUST > > be implementing both ITR and ETR functionality for the echo nonce > > mechanism to operate. > > > > Perhaps they could be given actual names so as to disambiguate which steps > > are performed with ITR vs. ETR role? > > > > The echo-nonce algorithm is bilateral. That is, if one side sets the > > E-bit and the other side is not enabled for echo-noncing, then the > > echoing of the nonce does not occur and the requesting side may > > erroneously consider the Locator unreachable. An ITR SHOULD only set > > the E-bit in an encapsulated data packet when it knows the ETR is > > enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- > > probe Map-Reply message. > > > > Why is this even optional? If it was mandatory to use, then there would > > not be a question. But at least clarify that the "this" that is conveyed > > is whether the peer supports the echo-nonce algorithm. (Also, subject to > > downgrade.) > > > > Section 13 > > > > When a Locator record is removed from a Locator-Set, ITRs that have > > the mapping cached will not use the removed Locator because the xTRs > > will set the Locator-Status-Bit to 0. So, even if the Locator is in > > the list, it will not be used. For new mapping requests, the xTRs > > can set the Locator AFI to 0 (indicating an unspecified address), as > > well as setting the corresponding Locator-Status-Bit to 0. This > > forces ITRs with old or new mappings to avoid using the removed > > Locator. > > > > The behavior describe here seems like it would be better described as "when > > a Locator is taken out of service" than "removed from a Locator-Set", since > > if it is not in the set at all, it has no index, and no LSB or AFI to set. > > Should actually depopulating it like this be forbidden? > > > > I guess the Map Versioning is supposed to help with this, but we need to > > nail down the semantics more and/or give a clearer reference to it. > > > > Section 13.1 > > > > An ITR, when it encapsulates packets to ETRs, can convey its own Map- > > Version Number. This is known as the Source Map-Version Number. > > > > Replacing "its own Map-Version Number" with something like "the Map-Version > > numer for the LISP site of which it is a part". Writing this causes me to > > note that the semantics of the Map-Version are unclear, here -- what is it > > scoped to? An EID-Prefix? An RLOC? Oh, you say that in the next > > paragraph (EID-Prefix). > > > > A Map-Version Number can be included in Map-Register messages as > > well. This is a good way for the Map-Server to assure that all ETRs > > for a site registering to it will be synchronized according to Map- > > Version Number. > > > > Huh? I must be confused how this works. (Also, wouldn't this be better in > > the control plane document which covers Map-Register?) > > > > Section 15 > > > > o When a tunnel-encapsulated packet is received by an ETR, the outer > > destination address may not be the address of the router. This > > makes it challenging for the control plane to get packets from the > > hardware. This may be mitigated by creating special Forwarding > > Information Base (FIB) entries for the EID-Prefixes of EIDs served > > by the ETR (those for which the router provides an RLOC > > translation). These FIB entries are marked with a flag indicating > > that Control-Plane processing SHOULD be performed. > > > > I assume this is just my lack of background showing, but I'm confused how > > it makes sense to mark these for control-plane processing. Isn't the > > control plane much slower, and we're not putting all of the LISP data-plane > > traffic onto the slow path? > > > > Section 18 > > > > o Data-Plane gleaning for creating map-cache entries has been made > > optional. If any ITR implementations depend or assume the remote > > ETR is gleaning should not do so. > > > > nit: this is ungrammatical; "they should not" or "Any ITR implementations > > that depend on or assume that" would fix it. > > > > Section 19.1 > > > > Presumably IANA also updated the reference column to point to this > > document? > > > > > > From nobody Fri Sep 28 15:38:42 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53DB127133 for ; Fri, 28 Sep 2018 15:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 ZN4h1amJN3nB for ; Fri, 28 Sep 2018 15:38:37 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD861130DC1 for ; Fri, 28 Sep 2018 15:38:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 928931C03CA for ; Fri, 28 Sep 2018 15:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1538174316; bh=r4LjnuDQ5Q3Hf95lhI0bWYZHBK5taqy0Jt8ojV5lKhU=; h=Subject:References:To:From:Date:In-Reply-To:From; b=pinbwkdX+z59NeCeSi7X2SaI7XdJP61IKFrhM0k0qPDMHzOwc0z0sxQc+Dnm6J4IJ SvUf4uBvePUlgop5xxrv8RJKllQ9AsupcIrWCx+4LjbQdOQAX9hlOdwehh6PkoptXg IYJqWf/i1yvbyRD8W5mg6MPOJCBnamoPPo0AHwTY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 EEDFA8201A8 for ; Fri, 28 Sep 2018 15:38:35 -0700 (PDT) References: <20180928220340.GO24695@kduck.kaduk.org> To: "lisp@ietf.org" From: "Joel M. Halpern" X-Forwarded-Message-Id: <20180928220340.GO24695@kduck.kaduk.org> Message-ID: <7924707d-e6c5-5080-7586-dcf1f96fed46@joelhalpern.com> Date: Fri, 28 Sep 2018 18:38:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180928220340.GO24695@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] Fwd: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 22:38:41 -0000 As co-chair, I would like to hear from the working group as to whether making LISP-SEC mandatory to Implement (not Mandatory to Use) for LISP6830bis and 6833bis implementations is a) desirable b) acceptable c) undesirable but livable d) unacceptable or worse. Please, do not just pick a letter. Include explanation of your opinion. This is not a decision the ADs and Authors can make for the working group. Yours, Joel -------- Forwarded Message -------- Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) Date: Fri, 28 Sep 2018 17:03:40 -0500 From: Benjamin Kaduk To: Joel M. Halpern CC: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Hi Joel, On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote: > Is there text we can add about the scoping that will change your discuss > into a series of useful comments? I had attempted to structure my Discuss points so that they would either be useful comments as is, or rendered moot by a reduced scope. I guess I can try to clarify those below. (To be clear, reducing the scope is only going to move from "has potentially existentially bad problems" to "has substantial issues that likely require reengineering to resolve".) > If so, Some indication of how you would like that phrased would help us > address these. I think Ekr's ballot position on 6833bis has a good summary of the architecture assumptions that the reduced scope allows us to make. In order to have the document be able to plausibly make those claims, it looks like we'd need to at least: (1) update the Abstract/Introduction to clarify that the EID namespace is only defined within a single administrative domain. (2) (optionally, if it makes sense) mention in the introduction that this administrative domain can include transport over other networks in the same way that a VPN would function[*], without requiring cooperation from or interaction with the other networks' administrators (3) remove the "global" text from the EID-to-RLOC Database and Map-Cache definitions (4) update the EID-Prefix definition to talk about the local site or administrative domain's "address allocation authority" (5) Take a look at the EID definition to consider whether references to "on the public Internet" are still valid, and the text about assignment in a hierarchical manner should be revised for the new scope as well. Likewise for EID-internal structure that is "not visible to the global routing system" (I stopped skimming and looking for problematic text around section 6) [*] Ideally this would be done without using the term "VPN" itself, since I'd like to get a movement going to restrict "VPN" to include confidentiality (i.e., privacy) protection. "virtual network" or "overlay network" may or may not be good candidate replacement terms. > If not, we seem to have a larger problem. Well, we appear to have five ADs that are supporting making LISP-SEC a normative reference and thus MTI; I don't know if that scale of change meets your threshold for a "larger problem". > Yours, > Joel > > On 9/26/18 11:44 PM, Benjamin Kaduk wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-lisp-rfc6830bis-20: 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 https://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: > > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have grave concerns about the suitability of LISP as a whole, in its > > present form, for advancement to the Standards-Track. While some of my > > concerns are not specific to this document, as the core protocol > > (data-plane) spec, it seems an appropriate place to attach them to. > > > > I am told, out of band, that the intended deployment model is no longer to > > cover the entire Internet (c.f. the MISSREF-state > > draft-ietf-lisp-introduction's "with LISP, the dge of the Internet and the > > core can be logically separated and interconnected by LISP-capable > > routers", etc.), and that full Internet-scale operation is no longer a > > goal. However, since that does not seem to be reflected in the current > > batch of documents up for IESG review, I am forced to ballot on them > > "as-is", namely as targetting global Internet deployment. The requirements > > placed on the mapping system are so stringent so as to be arguably > > unachievable at Internet-scale, though that arguably has more of an > > interaction with the control-plane than the data-plane. It's still in > > scope here, though, as part of the overall description of the protocol > > flow. (rendered moot by scope reduction) > > There are an almost innumerable number of downgrade attacks possible, and > > the control-plane and data-plane security mechanisms are not normative > > dependencies of the current corpus of documents, and as such are not up for > > consideration as mitigating the security concerns with the core documents. The downgrade attacks will probably require some further analysis; LISP-SEC would protect a lot of the header bits but I think there may be some other data flows to be looked at. > > Section 3 defines the EID-to-RLOC Datbaase: > > > > EID-to-RLOC Database: The EID-to-RLOC Database is a global > > distributed database that contains all known EID-Prefix-to-RLOC > > mappings. Each potential ETR typically contains a small piece of > > the database: the EID-to-RLOC mappings for the EID-Prefixes > > "behind" the router. These map to one of the router's own > > globally visible IP addresses. Note that there MAY be transient > > conditions when the EID-Prefix for the site and Locator-Set for > > each EID-Prefix may not be the same on all ETRs. This has no > > negative implications, since a partial set of Locators can be > > used. > > > > No compelling architecture for a trustworthy global distributed database > > has been presented that I've seen so far, and LISP relies heavily on the > > mapping system's database for its functionality. I am concerned that so > > many requirements are placed on the mapping system so as to be in effect > > unimplementable, in which case it would seem that the architecture as a > > whole (that is, for a global Internet-scale system) is not fit for purpose. (rendered moot by scope reduction) > > Section 4.1's Step (6) only mentions parsing "to check for format > > validity". I think it is appropriate to mention (and refer to) source > > authentication checks as well, since bad Map-Reply data can allow all sorts > > of attacks to occur. (not affected by scope reduction) > > There are some fairly subtle ordering requirements between the order of > > entries in Map-Reply messages and the Locator-Status-Bits in data-plane > > traffic (so that the semantic meaning of the status bits are meaningful), > > which is only given a minimal treatment in the control-plane document. The > > need for synchronization in interpreting these bits should be mentioned > > more prominently in the data-plane document as well. (not affected by scope reduction) > > > > The usage of the Instance ID does not seem to be adequately covered; from > > what I've been able to pick up so far it seems that both source and > > destination participants must agree on the meaning of an Instance ID, and > > the source and destination EIDs must be in the same Instance. This does > > not seem like it is compatible with Internet scale, especially if there are > > only 24 usable bits of Instance ID. (not affected by scope reduction) > > > > There seems to be a lot of intra-site synchronization requirements, notably > > with respect to Map-Version consistency, the contents and ordering of > > locator sets for EIDs in the site, etc.; the actual hard requirements for > > synchronization within a site should be clearly called out, ideally in a > > single location. (not affected by scope reduction, since ETRs are affected and not just Map-Servers) > > > > The security considerations attempt to defer substantially to the > > threat-analysis in RFC 7835, which does not really seem like a complete > > threat analysis and does not provide analysis as to what requirements are > > placed on the boundaries between the different components of LISP (data > > plane, control plane, mapping system, various extensions, etc.). The > > secdir reviewer had some good thoughts in this space. (not affected by scope reduction) > > > > The security considerations throughout the LISP documents place a heavy > > focus on the risk of over-claiming for routing EID-prefixes. This is a > > real concern, to be clear, but it should not overshadow the risk of an > > attacker who is able to move traffic around at will, strip security > > protections, cause denial of service, alter data-plane payloads, etc. > > Similarly, this document's security considerations call out denial of > > service as a risk from Map-Cache insertion/spoofing, but the risks from an > > attacker being able to read and modify the traffic, perhaps even without > > detection, seems a much greater threat to me. (not affected by scope reduction) > > > > I am not convinced that this protocol meets the current IETF requirements > > for the security properties of Standards-Track Protocols without at least > > LISP-SEC as a mandatory-to-implement component, and possibly additional or > > stronger requirements. (I did not do a full analysis of the system in the > > presence of those security mechanisms, since that is not what is being > > presented for review.) (noting that LISP-SEC needs to be MTI and analysis performed under the new assumptions) > > Having an EID that is associated to user-correlatable devices has severe > > privacy considerations, but I could not find this mentioned anywhere in all > > of the LISP documents I've read so far. (not affected by scope reduction) -Benjamin > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I apologize for the somewhat scattered nature of these comments; there are > > a lot of them and I was focusing my time more on trying to understand the > > broader system, and the intended security posture, so they did not get as > > much clean-up as I would have liked. (Most of my review was performed on the > > -18, though I have tried to update to the -20 as relevant.) > > > > > > The instance ID provides for organizational correlation, another privacy > > exposure. > > > > Is there anything different between an "EID-to-RLOC Map-Request" and just a > > "Map-Request"? (Same question for "Map-Reply", too.) > > > > There's a lot of stuff that seems to work best if there is symmetric > > bidirectional traffic, with inline signalling of map version and > > reachability changes, though clearly everything is designed to also work > > with asymmetric connectivity or unidirectional traffic. It would be nice > > to have a high-level summary in or near the introduction about what kinds > > of behavior/performance differences are expected for bidirectional vs. > > unidirectional traffic. > > > > Section 2 > > > > That's not the 8174 boilerplate; it's more than just adding a cite to the > > 2119 boilerplate. > > > > Section 3 > > > > nit: "An address family that pertains to the Data-Plane." is a sentence > > fragment. > > > > Ingress Tunnel Router (ITR): An ITR is a router that resides in a > > [...] > > mapping lookup in the destination address field. Note that this > > destination RLOC MAY be an intermediate, proxy device that has > > better knowledge of the EID-to-RLOC mapping closer to the > > > > This doesn't seem like a 2119 MAY is necessary, but rather a statement of > > fact that may not be known to the encapsulating ITR. > > > > Specifically, when a service provider prepends a LISP header for > > Traffic Engineering purposes, the router that does this is also > > regarded as an ITR. The outer RLOC the ISP ITR uses can be based > > on the outer destination address (the originating ITR's supplied > > RLOC) or the inner destination address (the originating host's > > supplied EID). > > > > I'm confused here, perhaps in multiple ways. Are there now *two* LISP > > headers on the packet? Is the "outer RLOC the ISP ITR uses" the source > > RLOC or the destination RLOC? > > > > Negative Mapping Entry: A negative mapping entry, also known as a > > negative cache entry, is an EID-to-RLOC entry where an EID-Prefix > > is advertised or stored with no RLOCs. That is, the Locator-Set > > for the EID-to-RLOC entry is empty or has an encoded Locator count > > of 0. > > > > Is "empty" a distinct representation from "locator count of zero"? > > > > Perhaps something of an aside, but the check described for > > Route-Returnability is a somewhat weak check, and in some cases could still > > be spoofed. (I don't expect this to surprise anyone, of course, but > > perhaps some more qualifiers could be added to the text.) > > > > Section 4 > > > > An additional LISP header MAY be prepended to packets by a TE-ITR > > when re-routing of the path for a packet is desired. A potential > > use-case for this would be an ISP router that needs to perform > > Traffic Engineering for packets flowing through its network. In such > > a situation, termed "Recursive Tunneling", an ISP transit acts as an > > additional ITR, and the RLOC it uses for the new prepended header > > would be either a TE-ETR within the ISP (along an intra-ISP traffic > > engineered path) or a TE-ETR within another ISP (an inter-ISP traffic > > engineered path, where an agreement to build such a path exists). > > > > "the RLOC it uses for the new prepnded header", again, this is as the > > destination RLOC (vs. source RLOC)? > > > > Section 4.1 > > > > o Map-Replies are sent on the underlying routing system topology > > using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. > > > > Just to check my understanding: is the "underlying routing system topology" > > the same as the "underlay"? > > > > Is step (3) just describing more of what step (2) says is "not described in > > this example"? > > > > Section 5.3 > > > > The word "nonce" is normally used for something used exactly once. > > E.g., with some AEAD algorithms, if the same "nonce" input is used for > > different encryptions, the entire security of the system is compromised. > > It would be better to refer to this field with a different term, given > > that "the same nonce can be used for a period of time when encapsulating to > > the same ETR". "Uniquifier" or "random value" might be reasonable choices. > > > > Why is there no discussion of the Map-Version or Instance-ID fields > > in this section? > > > > When doing ETR/PETR decapsulation: > > > > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > > the case of IPv6) SHOULD be copied from the outer-header 'Time to > > Live' field, when the Time to Live value of the outer header is > > less than the Time to Live value of the inner header. Failing to > > perform this check can cause the Time to Live of the inner header > > to increment across encapsulation/decapsulation cycles. This > > check is also performed when doing initial encapsulation, when a > > packet comes to an ITR or PITR destined for a LISP site. > > > > Er, what is "this check" that is also performed for initial encapsulation? > > How are there multiple TTL values to compare? > > > > o The inner-header 'Differentiated Services Code Point' (DSCP) field > > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be > > copied from the outer-header DSCP field ('Traffic Class' field, in > > the case of IPv6) to the inner-header. > > > > nit: the first "inner-header" seems like an editing remnant? > > > > Section 7.1 > > > > How is this stateless if it invovles knowledge about the routers between > > the ITR and all possible ETRs (i.e., a set that could change over time)? > > > > Section 8 > > > > This 32-bit vs 24-bit thing is pretty hokey for a standards-track > > specification (yes, I know that LISP-DDT is not standards track at the > > moment). > > > > Section 9 > > > > Alternatively, RLOC information MAY be gleaned from received tunneled > > > > What is this an alternative to? The list of four options above? > > > > packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache > > entry, one learned from the source RLOC of a received encapsulated > > packet, is only stored and used for a few seconds, pending > > verification. Verification is performed by sending a Map-Request to > > the source EID (the inner-header IP source address) of the received > > encapsulated packet. > > > > The source EID is some random end system, right? So this relys on some > > magic in the ETR to detect that there's a Map-Request and reply directly > > instead of passing it on to the EID that won't know what to do with it? > > > > Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and > > might benefit from an explicit section reference to the other document. > > > > Section 10 > > > > What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it > > is not marked as well-known at > > https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion is > > probably in order. > > > > Again, when we are talking about the internal structure of the Map-Reply, a > > detailed section refernce to 6833bis is useful. > > > > Modifying LSBs seems like a fine DoS attack vector for an on-path attacker. > > > > value of 1. Locator-Status-Bits are associated with a Locator-Set > > per EID-Prefix. Therefore, when a Locator becomes unreachable, the > > Locator-Status-Bit that corresponds to that Locator's position in the > > list returned by the last Map-Reply will be set to zero for that > > particular EID-Prefix > > > > Doesn't this imply a stateful relationship between the ordering of > > Map-Replys and data-plane traffic? > > > > Section 10.1 > > > > Note that "ITR" and "ETR" are relative terms here. Both devices MUST > > be implementing both ITR and ETR functionality for the echo nonce > > mechanism to operate. > > > > Perhaps they could be given actual names so as to disambiguate which steps > > are performed with ITR vs. ETR role? > > > > The echo-nonce algorithm is bilateral. That is, if one side sets the > > E-bit and the other side is not enabled for echo-noncing, then the > > echoing of the nonce does not occur and the requesting side may > > erroneously consider the Locator unreachable. An ITR SHOULD only set > > the E-bit in an encapsulated data packet when it knows the ETR is > > enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- > > probe Map-Reply message. > > > > Why is this even optional? If it was mandatory to use, then there would > > not be a question. But at least clarify that the "this" that is conveyed > > is whether the peer supports the echo-nonce algorithm. (Also, subject to > > downgrade.) > > > > Section 13 > > > > When a Locator record is removed from a Locator-Set, ITRs that have > > the mapping cached will not use the removed Locator because the xTRs > > will set the Locator-Status-Bit to 0. So, even if the Locator is in > > the list, it will not be used. For new mapping requests, the xTRs > > can set the Locator AFI to 0 (indicating an unspecified address), as > > well as setting the corresponding Locator-Status-Bit to 0. This > > forces ITRs with old or new mappings to avoid using the removed > > Locator. > > > > The behavior describe here seems like it would be better described as "when > > a Locator is taken out of service" than "removed from a Locator-Set", since > > if it is not in the set at all, it has no index, and no LSB or AFI to set. > > Should actually depopulating it like this be forbidden? > > > > I guess the Map Versioning is supposed to help with this, but we need to > > nail down the semantics more and/or give a clearer reference to it. > > > > Section 13.1 > > > > An ITR, when it encapsulates packets to ETRs, can convey its own Map- > > Version Number. This is known as the Source Map-Version Number. > > > > Replacing "its own Map-Version Number" with something like "the Map-Version > > numer for the LISP site of which it is a part". Writing this causes me to > > note that the semantics of the Map-Version are unclear, here -- what is it > > scoped to? An EID-Prefix? An RLOC? Oh, you say that in the next > > paragraph (EID-Prefix). > > > > A Map-Version Number can be included in Map-Register messages as > > well. This is a good way for the Map-Server to assure that all ETRs > > for a site registering to it will be synchronized according to Map- > > Version Number. > > > > Huh? I must be confused how this works. (Also, wouldn't this be better in > > the control plane document which covers Map-Register?) > > > > Section 15 > > > > o When a tunnel-encapsulated packet is received by an ETR, the outer > > destination address may not be the address of the router. This > > makes it challenging for the control plane to get packets from the > > hardware. This may be mitigated by creating special Forwarding > > Information Base (FIB) entries for the EID-Prefixes of EIDs served > > by the ETR (those for which the router provides an RLOC > > translation). These FIB entries are marked with a flag indicating > > that Control-Plane processing SHOULD be performed. > > > > I assume this is just my lack of background showing, but I'm confused how > > it makes sense to mark these for control-plane processing. Isn't the > > control plane much slower, and we're not putting all of the LISP data-plane > > traffic onto the slow path? > > > > Section 18 > > > > o Data-Plane gleaning for creating map-cache entries has been made > > optional. If any ITR implementations depend or assume the remote > > ETR is gleaning should not do so. > > > > nit: this is ungrammatical; "they should not" or "Any ITR implementations > > that depend on or assume that" would fix it. > > > > Section 19.1 > > > > Presumably IANA also updated the reference column to point to this > > document? > > > > > > From nobody Fri Sep 28 15:41:39 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4581F130DC1; Fri, 28 Sep 2018 15:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 8L-FBsLGs-6s; Fri, 28 Sep 2018 15:41:27 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C92127133; Fri, 28 Sep 2018 15:41:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id BAF9382256F; Fri, 28 Sep 2018 15:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1538174486; bh=JN/s8J2mDhmiGWDqrAmYfIizNXOl35bBp7bPIFMPpog=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kBXtFJDrwG6P+NEQ/9hhKqESWZr9FUQJn5S9ySxLixaeqI4zQTBedjRQ779yUtASD nh23Ixpg91e/nls1GaBN7PRzGs56KlxIEh+CP8h6lgvDO0zYHizNC0qIVkrQ6HIobV PHZ8k7U2YG6SOK0FxzktrvAbKqYxw5KAdBzaDQnE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 B232F1C041A; Fri, 28 Sep 2018 15:41:25 -0700 (PDT) To: Benjamin Kaduk Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org References: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com> <739fae18-85a5-26c2-85a6-7d7c830fcd32@joelhalpern.com> <20180928220340.GO24695@kduck.kaduk.org> From: "Joel M. Halpern" Message-ID: <0ed2e814-8bf6-cb78-7105-48a4bcb9d475@joelhalpern.com> Date: Fri, 28 Sep 2018 18:41:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180928220340.GO24695@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 22:41:30 -0000 Thank you Benjamin. This response helps me understand the situation. I have sent a note to the WG about making LISP-SEC MTI. That kind of change needs WG support. Yours, Joel On 9/28/18 6:03 PM, Benjamin Kaduk wrote: > Hi Joel, > > > On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote: >> Is there text we can add about the scoping that will change your discuss >> into a series of useful comments? > > I had attempted to structure my Discuss points so that they would either be > useful comments as is, or rendered moot by a reduced scope. I guess I can > try to clarify those below. (To be clear, reducing the scope is only going > to move from "has potentially existentially bad problems" to "has > substantial issues that likely require reengineering to resolve".) > >> If so, Some indication of how you would like that phrased would help us >> address these. > > I think Ekr's ballot position on 6833bis has a good summary of the > architecture assumptions that the reduced scope allows us to make. > In order to have the document be able to plausibly make those claims, it > looks like we'd need to at least: > (1) update the Abstract/Introduction to clarify that the EID namespace is > only defined within a single administrative domain. > (2) (optionally, if it makes sense) mention in the introduction that this > administrative domain can include transport over other networks in the > same way that a VPN would function[*], without requiring cooperation > from or interaction with the other networks' administrators > (3) remove the "global" text from the EID-to-RLOC Database and Map-Cache > definitions > (4) update the EID-Prefix definition to talk about the local site or > administrative domain's "address allocation authority" > (5) Take a look at the EID definition to consider whether references to "on > the public Internet" are still valid, and the text about assignment > in a hierarchical manner should be revised for the new scope as well. > Likewise for EID-internal structure that is "not visible to the global > routing system" > > (I stopped skimming and looking for problematic text around section 6) > > [*] Ideally this would be done without using the term "VPN" itself, since > I'd like to get a movement going to restrict "VPN" to include > confidentiality (i.e., privacy) protection. "virtual network" or "overlay > network" may or may not be good candidate replacement terms. > >> If not, we seem to have a larger problem. > > Well, we appear to have five ADs that are supporting making LISP-SEC a > normative reference and thus MTI; I don't know if that scale of change > meets your threshold for a "larger problem". > >> Yours, >> Joel >> >> On 9/26/18 11:44 PM, Benjamin Kaduk wrote: >>> Benjamin Kaduk has entered the following ballot position for >>> draft-ietf-lisp-rfc6830bis-20: 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 https://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: >>> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I have grave concerns about the suitability of LISP as a whole, in its >>> present form, for advancement to the Standards-Track. While some of my >>> concerns are not specific to this document, as the core protocol >>> (data-plane) spec, it seems an appropriate place to attach them to. >>> >>> I am told, out of band, that the intended deployment model is no longer to >>> cover the entire Internet (c.f. the MISSREF-state >>> draft-ietf-lisp-introduction's "with LISP, the dge of the Internet and the >>> core can be logically separated and interconnected by LISP-capable >>> routers", etc.), and that full Internet-scale operation is no longer a >>> goal. However, since that does not seem to be reflected in the current >>> batch of documents up for IESG review, I am forced to ballot on them >>> "as-is", namely as targetting global Internet deployment. The requirements >>> placed on the mapping system are so stringent so as to be arguably >>> unachievable at Internet-scale, though that arguably has more of an >>> interaction with the control-plane than the data-plane. It's still in >>> scope here, though, as part of the overall description of the protocol >>> flow. > > (rendered moot by scope reduction) > >>> There are an almost innumerable number of downgrade attacks possible, and >>> the control-plane and data-plane security mechanisms are not normative >>> dependencies of the current corpus of documents, and as such are not up for >>> consideration as mitigating the security concerns with the core documents. > > The downgrade attacks will probably require some further analysis; LISP-SEC > would protect a lot of the header bits but I think there may be some other > data flows to be looked at. > >>> Section 3 defines the EID-to-RLOC Datbaase: >>> >>> EID-to-RLOC Database: The EID-to-RLOC Database is a global >>> distributed database that contains all known EID-Prefix-to-RLOC >>> mappings. Each potential ETR typically contains a small piece of >>> the database: the EID-to-RLOC mappings for the EID-Prefixes >>> "behind" the router. These map to one of the router's own >>> globally visible IP addresses. Note that there MAY be transient >>> conditions when the EID-Prefix for the site and Locator-Set for >>> each EID-Prefix may not be the same on all ETRs. This has no >>> negative implications, since a partial set of Locators can be >>> used. >>> >>> No compelling architecture for a trustworthy global distributed database >>> has been presented that I've seen so far, and LISP relies heavily on the >>> mapping system's database for its functionality. I am concerned that so >>> many requirements are placed on the mapping system so as to be in effect >>> unimplementable, in which case it would seem that the architecture as a >>> whole (that is, for a global Internet-scale system) is not fit for purpose. > > (rendered moot by scope reduction) > >>> Section 4.1's Step (6) only mentions parsing "to check for format >>> validity". I think it is appropriate to mention (and refer to) source >>> authentication checks as well, since bad Map-Reply data can allow all sorts >>> of attacks to occur. > > (not affected by scope reduction) > >>> There are some fairly subtle ordering requirements between the order of >>> entries in Map-Reply messages and the Locator-Status-Bits in data-plane >>> traffic (so that the semantic meaning of the status bits are meaningful), >>> which is only given a minimal treatment in the control-plane document. The >>> need for synchronization in interpreting these bits should be mentioned >>> more prominently in the data-plane document as well. > > (not affected by scope reduction) > >>> >>> The usage of the Instance ID does not seem to be adequately covered; from >>> what I've been able to pick up so far it seems that both source and >>> destination participants must agree on the meaning of an Instance ID, and >>> the source and destination EIDs must be in the same Instance. This does >>> not seem like it is compatible with Internet scale, especially if there are >>> only 24 usable bits of Instance ID. > > (not affected by scope reduction) > >>> >>> There seems to be a lot of intra-site synchronization requirements, notably >>> with respect to Map-Version consistency, the contents and ordering of >>> locator sets for EIDs in the site, etc.; the actual hard requirements for >>> synchronization within a site should be clearly called out, ideally in a >>> single location. > > (not affected by scope reduction, since ETRs are affected and not just > Map-Servers) > >>> >>> The security considerations attempt to defer substantially to the >>> threat-analysis in RFC 7835, which does not really seem like a complete >>> threat analysis and does not provide analysis as to what requirements are >>> placed on the boundaries between the different components of LISP (data >>> plane, control plane, mapping system, various extensions, etc.). The >>> secdir reviewer had some good thoughts in this space. > > (not affected by scope reduction) > >>> >>> The security considerations throughout the LISP documents place a heavy >>> focus on the risk of over-claiming for routing EID-prefixes. This is a >>> real concern, to be clear, but it should not overshadow the risk of an >>> attacker who is able to move traffic around at will, strip security >>> protections, cause denial of service, alter data-plane payloads, etc. >>> Similarly, this document's security considerations call out denial of >>> service as a risk from Map-Cache insertion/spoofing, but the risks from an >>> attacker being able to read and modify the traffic, perhaps even without >>> detection, seems a much greater threat to me. > > (not affected by scope reduction) > >>> >>> I am not convinced that this protocol meets the current IETF requirements >>> for the security properties of Standards-Track Protocols without at least >>> LISP-SEC as a mandatory-to-implement component, and possibly additional or >>> stronger requirements. (I did not do a full analysis of the system in the >>> presence of those security mechanisms, since that is not what is being >>> presented for review.) > > (noting that LISP-SEC needs to be MTI and analysis performed under the new > assumptions) > >>> Having an EID that is associated to user-correlatable devices has severe >>> privacy considerations, but I could not find this mentioned anywhere in all >>> of the LISP documents I've read so far. > > (not affected by scope reduction) > > -Benjamin > >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I apologize for the somewhat scattered nature of these comments; there are >>> a lot of them and I was focusing my time more on trying to understand the >>> broader system, and the intended security posture, so they did not get as >>> much clean-up as I would have liked. (Most of my review was performed on the >>> -18, though I have tried to update to the -20 as relevant.) >>> >>> >>> The instance ID provides for organizational correlation, another privacy >>> exposure. >>> >>> Is there anything different between an "EID-to-RLOC Map-Request" and just a >>> "Map-Request"? (Same question for "Map-Reply", too.) >>> >>> There's a lot of stuff that seems to work best if there is symmetric >>> bidirectional traffic, with inline signalling of map version and >>> reachability changes, though clearly everything is designed to also work >>> with asymmetric connectivity or unidirectional traffic. It would be nice >>> to have a high-level summary in or near the introduction about what kinds >>> of behavior/performance differences are expected for bidirectional vs. >>> unidirectional traffic. >>> >>> Section 2 >>> >>> That's not the 8174 boilerplate; it's more than just adding a cite to the >>> 2119 boilerplate. >>> >>> Section 3 >>> >>> nit: "An address family that pertains to the Data-Plane." is a sentence >>> fragment. >>> >>> Ingress Tunnel Router (ITR): An ITR is a router that resides in a >>> [...] >>> mapping lookup in the destination address field. Note that this >>> destination RLOC MAY be an intermediate, proxy device that has >>> better knowledge of the EID-to-RLOC mapping closer to the >>> >>> This doesn't seem like a 2119 MAY is necessary, but rather a statement of >>> fact that may not be known to the encapsulating ITR. >>> >>> Specifically, when a service provider prepends a LISP header for >>> Traffic Engineering purposes, the router that does this is also >>> regarded as an ITR. The outer RLOC the ISP ITR uses can be based >>> on the outer destination address (the originating ITR's supplied >>> RLOC) or the inner destination address (the originating host's >>> supplied EID). >>> >>> I'm confused here, perhaps in multiple ways. Are there now *two* LISP >>> headers on the packet? Is the "outer RLOC the ISP ITR uses" the source >>> RLOC or the destination RLOC? >>> >>> Negative Mapping Entry: A negative mapping entry, also known as a >>> negative cache entry, is an EID-to-RLOC entry where an EID-Prefix >>> is advertised or stored with no RLOCs. That is, the Locator-Set >>> for the EID-to-RLOC entry is empty or has an encoded Locator count >>> of 0. >>> >>> Is "empty" a distinct representation from "locator count of zero"? >>> >>> Perhaps something of an aside, but the check described for >>> Route-Returnability is a somewhat weak check, and in some cases could still >>> be spoofed. (I don't expect this to surprise anyone, of course, but >>> perhaps some more qualifiers could be added to the text.) >>> >>> Section 4 >>> >>> An additional LISP header MAY be prepended to packets by a TE-ITR >>> when re-routing of the path for a packet is desired. A potential >>> use-case for this would be an ISP router that needs to perform >>> Traffic Engineering for packets flowing through its network. In such >>> a situation, termed "Recursive Tunneling", an ISP transit acts as an >>> additional ITR, and the RLOC it uses for the new prepended header >>> would be either a TE-ETR within the ISP (along an intra-ISP traffic >>> engineered path) or a TE-ETR within another ISP (an inter-ISP traffic >>> engineered path, where an agreement to build such a path exists). >>> >>> "the RLOC it uses for the new prepnded header", again, this is as the >>> destination RLOC (vs. source RLOC)? >>> >>> Section 4.1 >>> >>> o Map-Replies are sent on the underlying routing system topology >>> using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. >>> >>> Just to check my understanding: is the "underlying routing system topology" >>> the same as the "underlay"? >>> >>> Is step (3) just describing more of what step (2) says is "not described in >>> this example"? >>> >>> Section 5.3 >>> >>> The word "nonce" is normally used for something used exactly once. >>> E.g., with some AEAD algorithms, if the same "nonce" input is used for >>> different encryptions, the entire security of the system is compromised. >>> It would be better to refer to this field with a different term, given >>> that "the same nonce can be used for a period of time when encapsulating to >>> the same ETR". "Uniquifier" or "random value" might be reasonable choices. >>> >>> Why is there no discussion of the Map-Version or Instance-ID fields >>> in this section? >>> >>> When doing ETR/PETR decapsulation: >>> >>> o The inner-header 'Time to Live' field (or 'Hop Limit' field, in >>> the case of IPv6) SHOULD be copied from the outer-header 'Time to >>> Live' field, when the Time to Live value of the outer header is >>> less than the Time to Live value of the inner header. Failing to >>> perform this check can cause the Time to Live of the inner header >>> to increment across encapsulation/decapsulation cycles. This >>> check is also performed when doing initial encapsulation, when a >>> packet comes to an ITR or PITR destined for a LISP site. >>> >>> Er, what is "this check" that is also performed for initial encapsulation? >>> How are there multiple TTL values to compare? >>> >>> o The inner-header 'Differentiated Services Code Point' (DSCP) field >>> (or the 'Traffic Class' field, in the case of IPv6) SHOULD be >>> copied from the outer-header DSCP field ('Traffic Class' field, in >>> the case of IPv6) to the inner-header. >>> >>> nit: the first "inner-header" seems like an editing remnant? >>> >>> Section 7.1 >>> >>> How is this stateless if it invovles knowledge about the routers between >>> the ITR and all possible ETRs (i.e., a set that could change over time)? >>> >>> Section 8 >>> >>> This 32-bit vs 24-bit thing is pretty hokey for a standards-track >>> specification (yes, I know that LISP-DDT is not standards track at the >>> moment). >>> >>> Section 9 >>> >>> Alternatively, RLOC information MAY be gleaned from received tunneled >>> >>> What is this an alternative to? The list of four options above? >>> >>> packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache >>> entry, one learned from the source RLOC of a received encapsulated >>> packet, is only stored and used for a few seconds, pending >>> verification. Verification is performed by sending a Map-Request to >>> the source EID (the inner-header IP source address) of the received >>> encapsulated packet. >>> >>> The source EID is some random end system, right? So this relys on some >>> magic in the ETR to detect that there's a Map-Request and reply directly >>> instead of passing it on to the EID that won't know what to do with it? >>> >>> Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and >>> might benefit from an explicit section reference to the other document. >>> >>> Section 10 >>> >>> What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it >>> is not marked as well-known at >>> https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion is >>> probably in order. >>> >>> Again, when we are talking about the internal structure of the Map-Reply, a >>> detailed section refernce to 6833bis is useful. >>> >>> Modifying LSBs seems like a fine DoS attack vector for an on-path attacker. >>> >>> value of 1. Locator-Status-Bits are associated with a Locator-Set >>> per EID-Prefix. Therefore, when a Locator becomes unreachable, the >>> Locator-Status-Bit that corresponds to that Locator's position in the >>> list returned by the last Map-Reply will be set to zero for that >>> particular EID-Prefix >>> >>> Doesn't this imply a stateful relationship between the ordering of >>> Map-Replys and data-plane traffic? >>> >>> Section 10.1 >>> >>> Note that "ITR" and "ETR" are relative terms here. Both devices MUST >>> be implementing both ITR and ETR functionality for the echo nonce >>> mechanism to operate. >>> >>> Perhaps they could be given actual names so as to disambiguate which steps >>> are performed with ITR vs. ETR role? >>> >>> The echo-nonce algorithm is bilateral. That is, if one side sets the >>> E-bit and the other side is not enabled for echo-noncing, then the >>> echoing of the nonce does not occur and the requesting side may >>> erroneously consider the Locator unreachable. An ITR SHOULD only set >>> the E-bit in an encapsulated data packet when it knows the ETR is >>> enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- >>> probe Map-Reply message. >>> >>> Why is this even optional? If it was mandatory to use, then there would >>> not be a question. But at least clarify that the "this" that is conveyed >>> is whether the peer supports the echo-nonce algorithm. (Also, subject to >>> downgrade.) >>> >>> Section 13 >>> >>> When a Locator record is removed from a Locator-Set, ITRs that have >>> the mapping cached will not use the removed Locator because the xTRs >>> will set the Locator-Status-Bit to 0. So, even if the Locator is in >>> the list, it will not be used. For new mapping requests, the xTRs >>> can set the Locator AFI to 0 (indicating an unspecified address), as >>> well as setting the corresponding Locator-Status-Bit to 0. This >>> forces ITRs with old or new mappings to avoid using the removed >>> Locator. >>> >>> The behavior describe here seems like it would be better described as "when >>> a Locator is taken out of service" than "removed from a Locator-Set", since >>> if it is not in the set at all, it has no index, and no LSB or AFI to set. >>> Should actually depopulating it like this be forbidden? >>> >>> I guess the Map Versioning is supposed to help with this, but we need to >>> nail down the semantics more and/or give a clearer reference to it. >>> >>> Section 13.1 >>> >>> An ITR, when it encapsulates packets to ETRs, can convey its own Map- >>> Version Number. This is known as the Source Map-Version Number. >>> >>> Replacing "its own Map-Version Number" with something like "the Map-Version >>> numer for the LISP site of which it is a part". Writing this causes me to >>> note that the semantics of the Map-Version are unclear, here -- what is it >>> scoped to? An EID-Prefix? An RLOC? Oh, you say that in the next >>> paragraph (EID-Prefix). >>> >>> A Map-Version Number can be included in Map-Register messages as >>> well. This is a good way for the Map-Server to assure that all ETRs >>> for a site registering to it will be synchronized according to Map- >>> Version Number. >>> >>> Huh? I must be confused how this works. (Also, wouldn't this be better in >>> the control plane document which covers Map-Register?) >>> >>> Section 15 >>> >>> o When a tunnel-encapsulated packet is received by an ETR, the outer >>> destination address may not be the address of the router. This >>> makes it challenging for the control plane to get packets from the >>> hardware. This may be mitigated by creating special Forwarding >>> Information Base (FIB) entries for the EID-Prefixes of EIDs served >>> by the ETR (those for which the router provides an RLOC >>> translation). These FIB entries are marked with a flag indicating >>> that Control-Plane processing SHOULD be performed. >>> >>> I assume this is just my lack of background showing, but I'm confused how >>> it makes sense to mark these for control-plane processing. Isn't the >>> control plane much slower, and we're not putting all of the LISP data-plane >>> traffic onto the slow path? >>> >>> Section 18 >>> >>> o Data-Plane gleaning for creating map-cache entries has been made >>> optional. If any ITR implementations depend or assume the remote >>> ETR is gleaning should not do so. >>> >>> nit: this is ungrammatical; "they should not" or "Any ITR implementations >>> that depend on or assume that" would fix it. >>> >>> Section 19.1 >>> >>> Presumably IANA also updated the reference column to point to this >>> document? >>> >>> >>> > From nobody Fri Sep 28 15:44:41 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88419130E07 for ; Fri, 28 Sep 2018 15:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 cBlX0kSSAwWv for ; Fri, 28 Sep 2018 15:44:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3FE1127133 for ; Fri, 28 Sep 2018 15:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26005; q=dns/txt; s=iport; t=1538174675; x=1539384275; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=IMgvVIMPDFfiTa6YsraqSydfMzH9QKpRxi1oyBKsPtk=; b=WgCOqKEq61JXXayOV9yMjfaenjPbabVj6UekRoVUE96W3XuV6aOSxwNM 2DpuyEbWxu4/ZcaNcCLO6cBT1YRRIZaRmWjMuIaZGAF3x/VNgqT0FowqQ Y+Sdb5j+sUmRkL6elZAprC5nDFT/hYBg9snabnD9q95bh4z8qAufWMquU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAAC7ra5b/5NdJa1bGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBU4IMZn8og3SURoFgCCWWVhSBYwMLGAuESQKDeyE2FgEDAQE?= =?us-ascii?q?CAQECbRwMhTgBAQEDAQEBGAkPAQU2BAwLCQISBgICJgICJyIOEwYCAQGDHQG?= =?us-ascii?q?BeQgPiFmbTYEuhDMHPYUTBYELhyx2gVEXgUE/gRInDIFhfoMbAQEBAgGBKgE?= =?us-ascii?q?MBgEHAoMXglcCiCgkhiyEaIk9CYZDgwuGXAYXgUeEWoJjJoEPhQ+Id4MPhgy?= =?us-ascii?q?DEYFJATBBI1gRCDMaCBsVO4JsgiAFBRIRiEmFXh8wAQGLCg4XgicBAQ?= X-IronPort-AV: E=Sophos;i="5.54,316,1534809600"; d="scan'208";a="458930761" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2018 22:44:33 +0000 Received: from [10.32.173.55] ([10.32.173.55]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTP id w8SMiWB0008454 for ; Fri, 28 Sep 2018 22:44:33 GMT To: lisp@ietf.org References: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com> <739fae18-85a5-26c2-85a6-7d7c830fcd32@joelhalpern.com> <20180928220340.GO24695@kduck.kaduk.org> <0ed2e814-8bf6-cb78-7105-48a4bcb9d475@joelhalpern.com> From: Fabio Maino Message-ID: <5b962ae4-fe0a-8768-5a90-0115ea9ef8ca@cisco.com> Date: Fri, 28 Sep 2018 15:44:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0ed2e814-8bf6-cb78-7105-48a4bcb9d475@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.32.173.55, [10.32.173.55] X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 22:44:40 -0000 On 9/28/18 3:41 PM, Joel M. Halpern wrote: > Thank you Benjamin.  This response helps me understand the situation. I second that. The email was indeed very helpful, and I think we can use it (together with Eric's notes) as a guide to move forward. Thanks, Fabio > I have sent a note to the WG about making LISP-SEC MTI.  That kind of > change needs WG support. > > Yours, > Joel > > On 9/28/18 6:03 PM, Benjamin Kaduk wrote: >> Hi Joel, >> >> >> On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote: >>> Is there text we can add about the scoping that will change your >>> discuss >>> into a series of useful comments? >> >> I had attempted to structure my Discuss points so that they would >> either be >> useful comments as is, or rendered moot by a reduced scope.  I guess >> I can >> try to clarify those below.  (To be clear, reducing the scope is only >> going >> to move from "has potentially existentially bad problems" to "has >> substantial issues that likely require reengineering to resolve".) >> >>> If so, Some indication of how you would like that phrased would help us >>> address these. >> >> I think Ekr's ballot position on 6833bis has a good summary of the >> architecture assumptions that the reduced scope allows us to make. >> In order to have the document be able to plausibly make those claims, it >> looks like we'd need to at least: >> (1) update the Abstract/Introduction to clarify that the EID >> namespace is >>      only defined within a single administrative domain. >> (2) (optionally, if it makes sense) mention in the introduction that >> this >>      administrative domain can include transport over other networks >> in the >>      same way that a VPN would function[*], without requiring >> cooperation >>      from or interaction with the other networks' administrators >> (3) remove the "global" text from the EID-to-RLOC Database and Map-Cache >>      definitions >> (4) update the EID-Prefix definition to talk about the local site or >>      administrative domain's "address allocation authority" >> (5) Take a look at the EID definition to consider whether references >> to "on >>      the public Internet" are still valid, and the text about assignment >>      in a hierarchical manner should be revised for the new scope as >> well. >>      Likewise for EID-internal structure that is "not visible to the >> global >>      routing system" >> >> (I stopped skimming and looking for problematic text around section 6) >> >> [*] Ideally this would be done without using the term "VPN" itself, >> since >> I'd like to get a movement going to restrict "VPN" to include >> confidentiality (i.e., privacy) protection.  "virtual network" or >> "overlay >> network" may or may not be good candidate replacement terms. >> >>> If not, we seem to have a larger problem. >> >> Well, we appear to have five ADs that are supporting making LISP-SEC a >> normative reference and thus MTI; I don't know if that scale of change >> meets your threshold for a "larger problem". >> >>> Yours, >>> Joel >>> >>> On 9/26/18 11:44 PM, Benjamin Kaduk wrote: >>>> Benjamin Kaduk has entered the following ballot position for >>>> draft-ietf-lisp-rfc6830bis-20: 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 >>>> https://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: >>>> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> I have grave concerns about the suitability of LISP as a whole, in its >>>> present form, for advancement to the Standards-Track.  While some >>>> of my >>>> concerns are not specific to this document, as the core protocol >>>> (data-plane) spec, it seems an appropriate place to attach them to. >>>> >>>> I am told, out of band, that the intended deployment model is no >>>> longer to >>>> cover the entire Internet (c.f. the MISSREF-state >>>> draft-ietf-lisp-introduction's "with LISP, the dge of the Internet >>>> and the >>>> core can be logically separated and interconnected by LISP-capable >>>> routers", etc.), and that full Internet-scale operation is no longer a >>>> goal.  However, since that does not seem to be reflected in the >>>> current >>>> batch of documents up for IESG review, I am forced to ballot on them >>>> "as-is", namely as targetting global Internet deployment. The >>>> requirements >>>> placed on the mapping system are so stringent so as to be arguably >>>> unachievable at Internet-scale, though that arguably has more of an >>>> interaction with the control-plane than the data-plane. It's still in >>>> scope here, though, as part of the overall description of the protocol >>>> flow. >> >> (rendered moot by scope reduction) >> >>>> There are an almost innumerable number of downgrade attacks >>>> possible, and >>>> the control-plane and data-plane security mechanisms are not normative >>>> dependencies of the current corpus of documents, and as such are >>>> not up for >>>> consideration as mitigating the security concerns with the core >>>> documents. >> >> The downgrade attacks will probably require some further analysis; >> LISP-SEC >> would protect a lot of the header bits but I think there may be some >> other >> data flows to be looked at. >> >>>> Section 3 defines the EID-to-RLOC Datbaase: >>>> >>>>      EID-to-RLOC Database:   The EID-to-RLOC Database is a global >>>>         distributed database that contains all known >>>> EID-Prefix-to-RLOC >>>>         mappings.  Each potential ETR typically contains a small >>>> piece of >>>>         the database: the EID-to-RLOC mappings for the EID-Prefixes >>>>         "behind" the router.  These map to one of the router's own >>>>         globally visible IP addresses.  Note that there MAY be >>>> transient >>>>         conditions when the EID-Prefix for the site and Locator-Set >>>> for >>>>         each EID-Prefix may not be the same on all ETRs. This has no >>>>         negative implications, since a partial set of Locators can be >>>>         used. >>>> >>>> No compelling architecture for a trustworthy global distributed >>>> database >>>> has been presented that I've seen so far, and LISP relies heavily >>>> on the >>>> mapping system's database for its functionality.  I am concerned >>>> that so >>>> many requirements are placed on the mapping system so as to be in >>>> effect >>>> unimplementable, in which case it would seem that the architecture >>>> as a >>>> whole (that is, for a global Internet-scale system) is not fit for >>>> purpose. >> >> (rendered moot by scope reduction) >> >>>> Section 4.1's Step (6) only mentions parsing "to check for format >>>> validity".  I think it is appropriate to mention (and refer to) source >>>> authentication checks as well, since bad Map-Reply data can allow >>>> all sorts >>>> of attacks to occur. >> >> (not affected by scope reduction) >> >>>> There are some fairly subtle ordering requirements between the >>>> order of >>>> entries in Map-Reply messages and the Locator-Status-Bits in >>>> data-plane >>>> traffic (so that the semantic meaning of the status bits are >>>> meaningful), >>>> which is only given a minimal treatment in the control-plane >>>> document.  The >>>> need for synchronization in interpreting these bits should be >>>> mentioned >>>> more prominently in the data-plane document as well. >> >> (not affected by scope reduction) >> >>>> >>>> The usage of the Instance ID does not seem to be adequately >>>> covered; from >>>> what I've been able to pick up so far it seems that both source and >>>> destination participants must agree on the meaning of an Instance >>>> ID, and >>>> the source and destination EIDs must be in the same Instance.  This >>>> does >>>> not seem like it is compatible with Internet scale, especially if >>>> there are >>>> only 24 usable bits of Instance ID. >> >> (not affected by scope reduction) >> >>>> >>>> There seems to be a lot of intra-site synchronization requirements, >>>> notably >>>> with respect to Map-Version consistency, the contents and ordering of >>>> locator sets for EIDs in the site, etc.; the actual hard >>>> requirements for >>>> synchronization within a site should be clearly called out, ideally >>>> in a >>>> single location. >> >> (not affected by scope reduction, since ETRs are affected and not just >> Map-Servers) >> >>>> >>>> The security considerations attempt to defer substantially to the >>>> threat-analysis in RFC 7835, which does not really seem like a >>>> complete >>>> threat analysis and does not provide analysis as to what >>>> requirements are >>>> placed on the boundaries between the different components of LISP >>>> (data >>>> plane, control plane, mapping system, various extensions, etc.).  The >>>> secdir reviewer had some good thoughts in this space. >> >> (not affected by scope reduction) >> >>>> >>>> The security considerations throughout the LISP documents place a >>>> heavy >>>> focus on the risk of over-claiming for routing EID-prefixes.  This >>>> is a >>>> real concern, to be clear, but it should not overshadow the risk of an >>>> attacker who is able to move traffic around at will, strip security >>>> protections, cause denial of service, alter data-plane payloads, etc. >>>> Similarly, this document's security considerations call out denial of >>>> service as a risk from Map-Cache insertion/spoofing, but the risks >>>> from an >>>> attacker being able to read and modify the traffic, perhaps even >>>> without >>>> detection, seems a much greater threat to me. >> >> (not affected by scope reduction) >> >>>> >>>> I am not convinced that this protocol meets the current IETF >>>> requirements >>>> for the security properties of Standards-Track Protocols without at >>>> least >>>> LISP-SEC as a mandatory-to-implement component, and possibly >>>> additional or >>>> stronger requirements.  (I did not do a full analysis of the system >>>> in the >>>> presence of those security mechanisms, since that is not what is being >>>> presented for review.) >> >> (noting that LISP-SEC needs to be MTI and analysis performed under >> the new >> assumptions) >> >>>> Having an EID that is associated to user-correlatable devices has >>>> severe >>>> privacy considerations, but I could not find this mentioned >>>> anywhere in all >>>> of the LISP documents I've read so far. >> >> (not affected by scope reduction) >> >> -Benjamin >> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> I apologize for the somewhat scattered nature of these comments; >>>> there are >>>> a lot of them and I was focusing my time more on trying to >>>> understand the >>>> broader system, and the intended security posture, so they did not >>>> get as >>>> much clean-up as I would have liked.  (Most of my review was >>>> performed on the >>>> -18, though I have tried to update to the -20 as relevant.) >>>> >>>> >>>> The instance ID provides for organizational correlation, another >>>> privacy >>>> exposure. >>>> >>>> Is there anything different between an "EID-to-RLOC Map-Request" >>>> and just a >>>> "Map-Request"?  (Same question for "Map-Reply", too.) >>>> >>>> There's a lot of stuff that seems to work best if there is symmetric >>>> bidirectional traffic, with inline signalling of map version and >>>> reachability changes, though clearly everything is designed to also >>>> work >>>> with asymmetric connectivity or unidirectional traffic.  It would >>>> be nice >>>> to have a high-level summary in or near the introduction about what >>>> kinds >>>> of behavior/performance differences are expected for bidirectional vs. >>>> unidirectional traffic. >>>> >>>> Section 2 >>>> >>>> That's not the 8174 boilerplate; it's more than just adding a cite >>>> to the >>>> 2119 boilerplate. >>>> >>>> Section 3 >>>> >>>> nit: "An address family that pertains to the Data-Plane." is a >>>> sentence >>>> fragment. >>>> >>>>      Ingress Tunnel Router (ITR):   An ITR is a router that resides >>>> in a >>>>         [...] >>>>         mapping lookup in the destination address field. Note that >>>> this >>>>         destination RLOC MAY be an intermediate, proxy device that has >>>>         better knowledge of the EID-to-RLOC mapping closer to the >>>> >>>> This doesn't seem like a 2119 MAY is necessary, but rather a >>>> statement of >>>> fact that may not be known to the encapsulating ITR. >>>> >>>>         Specifically, when a service provider prepends a LISP >>>> header for >>>>         Traffic Engineering purposes, the router that does this is >>>> also >>>>         regarded as an ITR.  The outer RLOC the ISP ITR uses can be >>>> based >>>>         on the outer destination address (the originating ITR's >>>> supplied >>>>         RLOC) or the inner destination address (the originating host's >>>>         supplied EID). >>>> >>>> I'm confused here, perhaps in multiple ways.  Are there now *two* LISP >>>> headers on the packet?  Is the "outer RLOC the ISP ITR uses" the >>>> source >>>> RLOC or the destination RLOC? >>>> >>>>      Negative Mapping Entry:   A negative mapping entry, also known >>>> as a >>>>         negative cache entry, is an EID-to-RLOC entry where an >>>> EID-Prefix >>>>         is advertised or stored with no RLOCs.  That is, the >>>> Locator-Set >>>>         for the EID-to-RLOC entry is empty or has an encoded >>>> Locator count >>>>         of 0. >>>> >>>> Is "empty" a distinct representation from "locator count of zero"? >>>> >>>> Perhaps something of an aside, but the check described for >>>> Route-Returnability is a somewhat weak check, and in some cases >>>> could still >>>> be spoofed.  (I don't expect this to surprise anyone, of course, but >>>> perhaps some more qualifiers could be added to the text.) >>>> >>>> Section 4 >>>> >>>>      An additional LISP header MAY be prepended to packets by a TE-ITR >>>>      when re-routing of the path for a packet is desired.  A potential >>>>      use-case for this would be an ISP router that needs to perform >>>>      Traffic Engineering for packets flowing through its network.  >>>> In such >>>>      a situation, termed "Recursive Tunneling", an ISP transit acts >>>> as an >>>>      additional ITR, and the RLOC it uses for the new prepended header >>>>      would be either a TE-ETR within the ISP (along an intra-ISP >>>> traffic >>>>      engineered path) or a TE-ETR within another ISP (an inter-ISP >>>> traffic >>>>      engineered path, where an agreement to build such a path exists). >>>> >>>> "the RLOC it uses for the new prepnded header", again, this is as the >>>> destination RLOC (vs. source RLOC)? >>>> >>>> Section 4.1 >>>> >>>>      o  Map-Replies are sent on the underlying routing system topology >>>>         using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. >>>> >>>> Just to check my understanding: is the "underlying routing system >>>> topology" >>>> the same as the "underlay"? >>>> >>>> Is step (3) just describing more of what step (2) says is "not >>>> described in >>>> this example"? >>>> >>>> Section 5.3 >>>> >>>> The word "nonce" is normally used for something used exactly once. >>>> E.g., with some AEAD algorithms, if the same "nonce" input is used for >>>> different encryptions, the entire security of the system is >>>> compromised. >>>> It would be better to refer to this field with a different term, given >>>> that "the same nonce can be used for a period of time when >>>> encapsulating to >>>> the same ETR".  "Uniquifier" or "random value" might be reasonable >>>> choices. >>>> >>>> Why is there no discussion of the Map-Version or Instance-ID fields >>>> in this section? >>>> >>>> When doing ETR/PETR decapsulation: >>>> >>>>      o  The inner-header 'Time to Live' field (or 'Hop Limit' >>>> field, in >>>>         the case of IPv6) SHOULD be copied from the outer-header >>>> 'Time to >>>>         Live' field, when the Time to Live value of the outer >>>> header is >>>>         less than the Time to Live value of the inner header.  >>>> Failing to >>>>         perform this check can cause the Time to Live of the inner >>>> header >>>>         to increment across encapsulation/decapsulation cycles.  This >>>>         check is also performed when doing initial encapsulation, >>>> when a >>>>         packet comes to an ITR or PITR destined for a LISP site. >>>> >>>> Er, what is "this check" that is also performed for initial >>>> encapsulation? >>>> How are there multiple TTL values to compare? >>>> >>>>      o  The inner-header 'Differentiated Services Code Point' >>>> (DSCP) field >>>>         (or the 'Traffic Class' field, in the case of IPv6) SHOULD be >>>>         copied from the outer-header DSCP field ('Traffic Class' >>>> field, in >>>>         the case of IPv6) to the inner-header. >>>> >>>> nit: the first "inner-header" seems like an editing remnant? >>>> >>>> Section 7.1 >>>> >>>> How is this stateless if it invovles knowledge about the routers >>>> between >>>> the ITR and all possible ETRs (i.e., a set that could change over >>>> time)? >>>> >>>> Section 8 >>>> >>>> This 32-bit vs 24-bit thing is pretty hokey for a standards-track >>>> specification (yes, I know that LISP-DDT is not standards track at the >>>> moment). >>>> >>>> Section 9 >>>> >>>>      Alternatively, RLOC information MAY be gleaned from received >>>> tunneled >>>> >>>> What is this an alternative to?  The list of four options above? >>>> >>>>      packets or EID-to-RLOC Map-Request messages.  A "gleaned" >>>> Map-Cache >>>>      entry, one learned from the source RLOC of a received >>>> encapsulated >>>>      packet, is only stored and used for a few seconds, pending >>>>      verification.  Verification is performed by sending a >>>> Map-Request to >>>>      the source EID (the inner-header IP source address) of the >>>> received >>>>      encapsulated packet. >>>> >>>> The source EID is some random end system, right?  So this relys on >>>> some >>>> magic in the ETR to detect that there's a Map-Request and reply >>>> directly >>>> instead of passing it on to the EID that won't know what to do with >>>> it? >>>> >>>> Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and >>>> might benefit from an explicit section reference to the other >>>> document. >>>> >>>> Section 10 >>>> >>>> What is the "CE" of "CE-based ITRs"?  Presumably Customer Edge, but it >>>> is not marked as well-known at >>>> https://www.rfc-editor.org/materials/abbrev.expansion.txt so >>>> expansion is >>>> probably in order. >>>> >>>> Again, when we are talking about the internal structure of the >>>> Map-Reply, a >>>> detailed section refernce to 6833bis is useful. >>>> >>>> Modifying LSBs seems like a fine DoS attack vector for an on-path >>>> attacker. >>>> >>>>      value of 1.  Locator-Status-Bits are associated with a >>>> Locator-Set >>>>      per EID-Prefix.  Therefore, when a Locator becomes >>>> unreachable, the >>>>      Locator-Status-Bit that corresponds to that Locator's position >>>> in the >>>>      list returned by the last Map-Reply will be set to zero for that >>>>      particular EID-Prefix >>>> >>>> Doesn't this imply a stateful relationship between the ordering of >>>> Map-Replys and data-plane traffic? >>>> >>>> Section 10.1 >>>> >>>>      Note that "ITR" and "ETR" are relative terms here. Both >>>> devices MUST >>>>      be implementing both ITR and ETR functionality for the echo nonce >>>>      mechanism to operate. >>>> >>>> Perhaps they could be given actual names so as to disambiguate >>>> which steps >>>> are performed with ITR vs. ETR role? >>>> >>>>      The echo-nonce algorithm is bilateral.  That is, if one side >>>> sets the >>>>      E-bit and the other side is not enabled for echo-noncing, then >>>> the >>>>      echoing of the nonce does not occur and the requesting side may >>>>      erroneously consider the Locator unreachable.  An ITR SHOULD >>>> only set >>>>      the E-bit in an encapsulated data packet when it knows the ETR is >>>>      enabled for echo-noncing.  This is conveyed by the E-bit in >>>> the RLOC- >>>>      probe Map-Reply message. >>>> >>>> Why is this even optional?  If it was mandatory to use, then there >>>> would >>>> not be a question.  But at least clarify that the "this" that is >>>> conveyed >>>> is whether the peer supports the echo-nonce algorithm. (Also, >>>> subject to >>>> downgrade.) >>>> >>>> Section 13 >>>> >>>>      When a Locator record is removed from a Locator-Set, ITRs that >>>> have >>>>      the mapping cached will not use the removed Locator because >>>> the xTRs >>>>      will set the Locator-Status-Bit to 0.  So, even if the Locator >>>> is in >>>>      the list, it will not be used.  For new mapping requests, the >>>> xTRs >>>>      can set the Locator AFI to 0 (indicating an unspecified >>>> address), as >>>>      well as setting the corresponding Locator-Status-Bit to 0.  This >>>>      forces ITRs with old or new mappings to avoid using the removed >>>>      Locator. >>>> >>>> The behavior describe here seems like it would be better described >>>> as "when >>>> a Locator is taken out of service" than "removed from a >>>> Locator-Set", since >>>> if it is not in the set at all, it has no index, and no LSB or AFI >>>> to set. >>>> Should actually depopulating it like this be forbidden? >>>> >>>> I guess the Map Versioning is supposed to help with this, but we >>>> need to >>>> nail down the semantics more and/or give a clearer reference to it. >>>> >>>> Section 13.1 >>>> >>>>      An ITR, when it encapsulates packets to ETRs, can convey its >>>> own Map- >>>>      Version Number.  This is known as the Source Map-Version Number. >>>> >>>> Replacing "its own Map-Version Number" with something like "the >>>> Map-Version >>>> numer for the LISP site of which it is a part".  Writing this >>>> causes me to >>>> note that the semantics of the Map-Version are unclear, here -- >>>> what is it >>>> scoped to?  An EID-Prefix?  An RLOC?  Oh, you say that in the next >>>> paragraph (EID-Prefix). >>>> >>>>      A Map-Version Number can be included in Map-Register messages as >>>>      well.  This is a good way for the Map-Server to assure that >>>> all ETRs >>>>      for a site registering to it will be synchronized according to >>>> Map- >>>>      Version Number. >>>> >>>> Huh?  I must be confused how this works.  (Also, wouldn't this be >>>> better in >>>> the control plane document which covers Map-Register?) >>>> >>>> Section 15 >>>> >>>>      o  When a tunnel-encapsulated packet is received by an ETR, >>>> the outer >>>>         destination address may not be the address of the router.  >>>> This >>>>         makes it challenging for the control plane to get packets >>>> from the >>>>         hardware.  This may be mitigated by creating special >>>> Forwarding >>>>         Information Base (FIB) entries for the EID-Prefixes of EIDs >>>> served >>>>         by the ETR (those for which the router provides an RLOC >>>>         translation).  These FIB entries are marked with a flag >>>> indicating >>>>         that Control-Plane processing SHOULD be performed. >>>> >>>> I assume this is just my lack of background showing, but I'm >>>> confused how >>>> it makes sense to mark these for control-plane processing. Isn't the >>>> control plane much slower, and we're not putting all of the LISP >>>> data-plane >>>> traffic onto the slow path? >>>> >>>> Section 18 >>>> >>>>      o  Data-Plane gleaning for creating map-cache entries has been >>>> made >>>>         optional.  If any ITR implementations depend or assume the >>>> remote >>>>         ETR is gleaning should not do so. >>>> >>>> nit: this is ungrammatical; "they should not" or "Any ITR >>>> implementations >>>> that depend on or assume that" would fix it. >>>> >>>> Section 19.1 >>>> >>>> Presumably IANA also updated the reference column to point to this >>>> document? >>>> >>>> >>>> >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Sep 28 15:45:52 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1B3130DC1; Fri, 28 Sep 2018 15:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 2GIJyhy0kMPI; Fri, 28 Sep 2018 15:45:39 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB21127133; Fri, 28 Sep 2018 15:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26005; q=dns/txt; s=iport; t=1538174739; x=1539384339; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=quPECN12gE2C0pBQe4PhM6jTqATba+n7fAinPlZixIo=; b=OhUmdrNeMisF9EbRUiYzz8/G34ezSogZzFpsAZvpxefEyGRqRE6K2PEw gfEEFXPQpHNXDITITtJrHqSeMT72wXkj/DPq+sT8v1cmX+PSql6xpSjYZ Q0mbLfEowJ2XmqXDgrVSWEDrmNlWeGxyhBaCyqlpM22TG0usde2hAmTVI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAADjrq5b/51dJa1bDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVKCDWZ/KIN0lEaBYAglllYUgWMDCxgLhEkCg3shNRc?= =?us-ascii?q?BAwEBAgEBAm0cDIU4AQEBAwEBARgJDwEFNgQHBQsJAhIGAgImAgInIg4GAQw?= =?us-ascii?q?GAgEBgx0BgXkID4hfm02BLoQzBz2FEwWBC4csdoFRF4FBP4ESJwyBYX6DGwE?= =?us-ascii?q?BAQIBgSoBDAYBBwKDF4JXAogoJIYshGiJPQmGQ4MLhlwGF4FHhFqCYyaBD4U?= =?us-ascii?q?PiHeDD4YMgxGBRAI0QSNYEQgzGggbFTuCbIIgBQUSEYhJhQRaHzABAYsKDhe?= =?us-ascii?q?CJwEB?= X-IronPort-AV: E=Sophos;i="5.54,316,1534809600"; d="scan'208";a="178301709" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2018 22:45:30 +0000 Received: from [10.32.173.55] ([10.32.173.55]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTP id w8SMjTF8018573; Fri, 28 Sep 2018 22:45:29 GMT To: "Joel M. Halpern" , Benjamin Kaduk Cc: lisp-chairs@ietf.org, lisp@ietf.org, The IESG , draft-ietf-lisp-rfc6830bis@ietf.org References: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com> <739fae18-85a5-26c2-85a6-7d7c830fcd32@joelhalpern.com> <20180928220340.GO24695@kduck.kaduk.org> <0ed2e814-8bf6-cb78-7105-48a4bcb9d475@joelhalpern.com> From: Fabio Maino Message-ID: Date: Fri, 28 Sep 2018 15:45:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0ed2e814-8bf6-cb78-7105-48a4bcb9d475@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.32.173.55, [10.32.173.55] X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 22:45:44 -0000 On 9/28/18 3:41 PM, Joel M. Halpern wrote: > Thank you Benjamin.  This response helps me understand the situation. > I have sent a note to the WG about making LISP-SEC MTI.  That kind of > change needs WG support. > I second that. The email was indeed very helpful, and I think we can use it (together with Eric's notes) as a guide to move forward. Thanks, Fabio > Yours, > Joel > > On 9/28/18 6:03 PM, Benjamin Kaduk wrote: >> Hi Joel, >> >> >> On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote: >>> Is there text we can add about the scoping that will change your >>> discuss >>> into a series of useful comments? >> >> I had attempted to structure my Discuss points so that they would >> either be >> useful comments as is, or rendered moot by a reduced scope.  I guess >> I can >> try to clarify those below.  (To be clear, reducing the scope is only >> going >> to move from "has potentially existentially bad problems" to "has >> substantial issues that likely require reengineering to resolve".) >> >>> If so, Some indication of how you would like that phrased would help us >>> address these. >> >> I think Ekr's ballot position on 6833bis has a good summary of the >> architecture assumptions that the reduced scope allows us to make. >> In order to have the document be able to plausibly make those claims, it >> looks like we'd need to at least: >> (1) update the Abstract/Introduction to clarify that the EID >> namespace is >>      only defined within a single administrative domain. >> (2) (optionally, if it makes sense) mention in the introduction that >> this >>      administrative domain can include transport over other networks >> in the >>      same way that a VPN would function[*], without requiring >> cooperation >>      from or interaction with the other networks' administrators >> (3) remove the "global" text from the EID-to-RLOC Database and Map-Cache >>      definitions >> (4) update the EID-Prefix definition to talk about the local site or >>      administrative domain's "address allocation authority" >> (5) Take a look at the EID definition to consider whether references >> to "on >>      the public Internet" are still valid, and the text about assignment >>      in a hierarchical manner should be revised for the new scope as >> well. >>      Likewise for EID-internal structure that is "not visible to the >> global >>      routing system" >> >> (I stopped skimming and looking for problematic text around section 6) >> >> [*] Ideally this would be done without using the term "VPN" itself, >> since >> I'd like to get a movement going to restrict "VPN" to include >> confidentiality (i.e., privacy) protection.  "virtual network" or >> "overlay >> network" may or may not be good candidate replacement terms. >> >>> If not, we seem to have a larger problem. >> >> Well, we appear to have five ADs that are supporting making LISP-SEC a >> normative reference and thus MTI; I don't know if that scale of change >> meets your threshold for a "larger problem". >> >>> Yours, >>> Joel >>> >>> On 9/26/18 11:44 PM, Benjamin Kaduk wrote: >>>> Benjamin Kaduk has entered the following ballot position for >>>> draft-ietf-lisp-rfc6830bis-20: 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 >>>> https://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: >>>> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> I have grave concerns about the suitability of LISP as a whole, in its >>>> present form, for advancement to the Standards-Track.  While some >>>> of my >>>> concerns are not specific to this document, as the core protocol >>>> (data-plane) spec, it seems an appropriate place to attach them to. >>>> >>>> I am told, out of band, that the intended deployment model is no >>>> longer to >>>> cover the entire Internet (c.f. the MISSREF-state >>>> draft-ietf-lisp-introduction's "with LISP, the dge of the Internet >>>> and the >>>> core can be logically separated and interconnected by LISP-capable >>>> routers", etc.), and that full Internet-scale operation is no longer a >>>> goal.  However, since that does not seem to be reflected in the >>>> current >>>> batch of documents up for IESG review, I am forced to ballot on them >>>> "as-is", namely as targetting global Internet deployment. The >>>> requirements >>>> placed on the mapping system are so stringent so as to be arguably >>>> unachievable at Internet-scale, though that arguably has more of an >>>> interaction with the control-plane than the data-plane. It's still in >>>> scope here, though, as part of the overall description of the protocol >>>> flow. >> >> (rendered moot by scope reduction) >> >>>> There are an almost innumerable number of downgrade attacks >>>> possible, and >>>> the control-plane and data-plane security mechanisms are not normative >>>> dependencies of the current corpus of documents, and as such are >>>> not up for >>>> consideration as mitigating the security concerns with the core >>>> documents. >> >> The downgrade attacks will probably require some further analysis; >> LISP-SEC >> would protect a lot of the header bits but I think there may be some >> other >> data flows to be looked at. >> >>>> Section 3 defines the EID-to-RLOC Datbaase: >>>> >>>>      EID-to-RLOC Database:   The EID-to-RLOC Database is a global >>>>         distributed database that contains all known >>>> EID-Prefix-to-RLOC >>>>         mappings.  Each potential ETR typically contains a small >>>> piece of >>>>         the database: the EID-to-RLOC mappings for the EID-Prefixes >>>>         "behind" the router.  These map to one of the router's own >>>>         globally visible IP addresses.  Note that there MAY be >>>> transient >>>>         conditions when the EID-Prefix for the site and Locator-Set >>>> for >>>>         each EID-Prefix may not be the same on all ETRs. This has no >>>>         negative implications, since a partial set of Locators can be >>>>         used. >>>> >>>> No compelling architecture for a trustworthy global distributed >>>> database >>>> has been presented that I've seen so far, and LISP relies heavily >>>> on the >>>> mapping system's database for its functionality.  I am concerned >>>> that so >>>> many requirements are placed on the mapping system so as to be in >>>> effect >>>> unimplementable, in which case it would seem that the architecture >>>> as a >>>> whole (that is, for a global Internet-scale system) is not fit for >>>> purpose. >> >> (rendered moot by scope reduction) >> >>>> Section 4.1's Step (6) only mentions parsing "to check for format >>>> validity".  I think it is appropriate to mention (and refer to) source >>>> authentication checks as well, since bad Map-Reply data can allow >>>> all sorts >>>> of attacks to occur. >> >> (not affected by scope reduction) >> >>>> There are some fairly subtle ordering requirements between the >>>> order of >>>> entries in Map-Reply messages and the Locator-Status-Bits in >>>> data-plane >>>> traffic (so that the semantic meaning of the status bits are >>>> meaningful), >>>> which is only given a minimal treatment in the control-plane >>>> document.  The >>>> need for synchronization in interpreting these bits should be >>>> mentioned >>>> more prominently in the data-plane document as well. >> >> (not affected by scope reduction) >> >>>> >>>> The usage of the Instance ID does not seem to be adequately >>>> covered; from >>>> what I've been able to pick up so far it seems that both source and >>>> destination participants must agree on the meaning of an Instance >>>> ID, and >>>> the source and destination EIDs must be in the same Instance.  This >>>> does >>>> not seem like it is compatible with Internet scale, especially if >>>> there are >>>> only 24 usable bits of Instance ID. >> >> (not affected by scope reduction) >> >>>> >>>> There seems to be a lot of intra-site synchronization requirements, >>>> notably >>>> with respect to Map-Version consistency, the contents and ordering of >>>> locator sets for EIDs in the site, etc.; the actual hard >>>> requirements for >>>> synchronization within a site should be clearly called out, ideally >>>> in a >>>> single location. >> >> (not affected by scope reduction, since ETRs are affected and not just >> Map-Servers) >> >>>> >>>> The security considerations attempt to defer substantially to the >>>> threat-analysis in RFC 7835, which does not really seem like a >>>> complete >>>> threat analysis and does not provide analysis as to what >>>> requirements are >>>> placed on the boundaries between the different components of LISP >>>> (data >>>> plane, control plane, mapping system, various extensions, etc.).  The >>>> secdir reviewer had some good thoughts in this space. >> >> (not affected by scope reduction) >> >>>> >>>> The security considerations throughout the LISP documents place a >>>> heavy >>>> focus on the risk of over-claiming for routing EID-prefixes.  This >>>> is a >>>> real concern, to be clear, but it should not overshadow the risk of an >>>> attacker who is able to move traffic around at will, strip security >>>> protections, cause denial of service, alter data-plane payloads, etc. >>>> Similarly, this document's security considerations call out denial of >>>> service as a risk from Map-Cache insertion/spoofing, but the risks >>>> from an >>>> attacker being able to read and modify the traffic, perhaps even >>>> without >>>> detection, seems a much greater threat to me. >> >> (not affected by scope reduction) >> >>>> >>>> I am not convinced that this protocol meets the current IETF >>>> requirements >>>> for the security properties of Standards-Track Protocols without at >>>> least >>>> LISP-SEC as a mandatory-to-implement component, and possibly >>>> additional or >>>> stronger requirements.  (I did not do a full analysis of the system >>>> in the >>>> presence of those security mechanisms, since that is not what is being >>>> presented for review.) >> >> (noting that LISP-SEC needs to be MTI and analysis performed under >> the new >> assumptions) >> >>>> Having an EID that is associated to user-correlatable devices has >>>> severe >>>> privacy considerations, but I could not find this mentioned >>>> anywhere in all >>>> of the LISP documents I've read so far. >> >> (not affected by scope reduction) >> >> -Benjamin >> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> I apologize for the somewhat scattered nature of these comments; >>>> there are >>>> a lot of them and I was focusing my time more on trying to >>>> understand the >>>> broader system, and the intended security posture, so they did not >>>> get as >>>> much clean-up as I would have liked.  (Most of my review was >>>> performed on the >>>> -18, though I have tried to update to the -20 as relevant.) >>>> >>>> >>>> The instance ID provides for organizational correlation, another >>>> privacy >>>> exposure. >>>> >>>> Is there anything different between an "EID-to-RLOC Map-Request" >>>> and just a >>>> "Map-Request"?  (Same question for "Map-Reply", too.) >>>> >>>> There's a lot of stuff that seems to work best if there is symmetric >>>> bidirectional traffic, with inline signalling of map version and >>>> reachability changes, though clearly everything is designed to also >>>> work >>>> with asymmetric connectivity or unidirectional traffic.  It would >>>> be nice >>>> to have a high-level summary in or near the introduction about what >>>> kinds >>>> of behavior/performance differences are expected for bidirectional vs. >>>> unidirectional traffic. >>>> >>>> Section 2 >>>> >>>> That's not the 8174 boilerplate; it's more than just adding a cite >>>> to the >>>> 2119 boilerplate. >>>> >>>> Section 3 >>>> >>>> nit: "An address family that pertains to the Data-Plane." is a >>>> sentence >>>> fragment. >>>> >>>>      Ingress Tunnel Router (ITR):   An ITR is a router that resides >>>> in a >>>>         [...] >>>>         mapping lookup in the destination address field. Note that >>>> this >>>>         destination RLOC MAY be an intermediate, proxy device that has >>>>         better knowledge of the EID-to-RLOC mapping closer to the >>>> >>>> This doesn't seem like a 2119 MAY is necessary, but rather a >>>> statement of >>>> fact that may not be known to the encapsulating ITR. >>>> >>>>         Specifically, when a service provider prepends a LISP >>>> header for >>>>         Traffic Engineering purposes, the router that does this is >>>> also >>>>         regarded as an ITR.  The outer RLOC the ISP ITR uses can be >>>> based >>>>         on the outer destination address (the originating ITR's >>>> supplied >>>>         RLOC) or the inner destination address (the originating host's >>>>         supplied EID). >>>> >>>> I'm confused here, perhaps in multiple ways.  Are there now *two* LISP >>>> headers on the packet?  Is the "outer RLOC the ISP ITR uses" the >>>> source >>>> RLOC or the destination RLOC? >>>> >>>>      Negative Mapping Entry:   A negative mapping entry, also known >>>> as a >>>>         negative cache entry, is an EID-to-RLOC entry where an >>>> EID-Prefix >>>>         is advertised or stored with no RLOCs.  That is, the >>>> Locator-Set >>>>         for the EID-to-RLOC entry is empty or has an encoded >>>> Locator count >>>>         of 0. >>>> >>>> Is "empty" a distinct representation from "locator count of zero"? >>>> >>>> Perhaps something of an aside, but the check described for >>>> Route-Returnability is a somewhat weak check, and in some cases >>>> could still >>>> be spoofed.  (I don't expect this to surprise anyone, of course, but >>>> perhaps some more qualifiers could be added to the text.) >>>> >>>> Section 4 >>>> >>>>      An additional LISP header MAY be prepended to packets by a TE-ITR >>>>      when re-routing of the path for a packet is desired.  A potential >>>>      use-case for this would be an ISP router that needs to perform >>>>      Traffic Engineering for packets flowing through its network.  >>>> In such >>>>      a situation, termed "Recursive Tunneling", an ISP transit acts >>>> as an >>>>      additional ITR, and the RLOC it uses for the new prepended header >>>>      would be either a TE-ETR within the ISP (along an intra-ISP >>>> traffic >>>>      engineered path) or a TE-ETR within another ISP (an inter-ISP >>>> traffic >>>>      engineered path, where an agreement to build such a path exists). >>>> >>>> "the RLOC it uses for the new prepnded header", again, this is as the >>>> destination RLOC (vs. source RLOC)? >>>> >>>> Section 4.1 >>>> >>>>      o  Map-Replies are sent on the underlying routing system topology >>>>         using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. >>>> >>>> Just to check my understanding: is the "underlying routing system >>>> topology" >>>> the same as the "underlay"? >>>> >>>> Is step (3) just describing more of what step (2) says is "not >>>> described in >>>> this example"? >>>> >>>> Section 5.3 >>>> >>>> The word "nonce" is normally used for something used exactly once. >>>> E.g., with some AEAD algorithms, if the same "nonce" input is used for >>>> different encryptions, the entire security of the system is >>>> compromised. >>>> It would be better to refer to this field with a different term, given >>>> that "the same nonce can be used for a period of time when >>>> encapsulating to >>>> the same ETR".  "Uniquifier" or "random value" might be reasonable >>>> choices. >>>> >>>> Why is there no discussion of the Map-Version or Instance-ID fields >>>> in this section? >>>> >>>> When doing ETR/PETR decapsulation: >>>> >>>>      o  The inner-header 'Time to Live' field (or 'Hop Limit' >>>> field, in >>>>         the case of IPv6) SHOULD be copied from the outer-header >>>> 'Time to >>>>         Live' field, when the Time to Live value of the outer >>>> header is >>>>         less than the Time to Live value of the inner header.  >>>> Failing to >>>>         perform this check can cause the Time to Live of the inner >>>> header >>>>         to increment across encapsulation/decapsulation cycles.  This >>>>         check is also performed when doing initial encapsulation, >>>> when a >>>>         packet comes to an ITR or PITR destined for a LISP site. >>>> >>>> Er, what is "this check" that is also performed for initial >>>> encapsulation? >>>> How are there multiple TTL values to compare? >>>> >>>>      o  The inner-header 'Differentiated Services Code Point' >>>> (DSCP) field >>>>         (or the 'Traffic Class' field, in the case of IPv6) SHOULD be >>>>         copied from the outer-header DSCP field ('Traffic Class' >>>> field, in >>>>         the case of IPv6) to the inner-header. >>>> >>>> nit: the first "inner-header" seems like an editing remnant? >>>> >>>> Section 7.1 >>>> >>>> How is this stateless if it invovles knowledge about the routers >>>> between >>>> the ITR and all possible ETRs (i.e., a set that could change over >>>> time)? >>>> >>>> Section 8 >>>> >>>> This 32-bit vs 24-bit thing is pretty hokey for a standards-track >>>> specification (yes, I know that LISP-DDT is not standards track at the >>>> moment). >>>> >>>> Section 9 >>>> >>>>      Alternatively, RLOC information MAY be gleaned from received >>>> tunneled >>>> >>>> What is this an alternative to?  The list of four options above? >>>> >>>>      packets or EID-to-RLOC Map-Request messages.  A "gleaned" >>>> Map-Cache >>>>      entry, one learned from the source RLOC of a received >>>> encapsulated >>>>      packet, is only stored and used for a few seconds, pending >>>>      verification.  Verification is performed by sending a >>>> Map-Request to >>>>      the source EID (the inner-header IP source address) of the >>>> received >>>>      encapsulated packet. >>>> >>>> The source EID is some random end system, right?  So this relys on >>>> some >>>> magic in the ETR to detect that there's a Map-Request and reply >>>> directly >>>> instead of passing it on to the EID that won't know what to do with >>>> it? >>>> >>>> Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and >>>> might benefit from an explicit section reference to the other >>>> document. >>>> >>>> Section 10 >>>> >>>> What is the "CE" of "CE-based ITRs"?  Presumably Customer Edge, but it >>>> is not marked as well-known at >>>> https://www.rfc-editor.org/materials/abbrev.expansion.txt so >>>> expansion is >>>> probably in order. >>>> >>>> Again, when we are talking about the internal structure of the >>>> Map-Reply, a >>>> detailed section refernce to 6833bis is useful. >>>> >>>> Modifying LSBs seems like a fine DoS attack vector for an on-path >>>> attacker. >>>> >>>>      value of 1.  Locator-Status-Bits are associated with a >>>> Locator-Set >>>>      per EID-Prefix.  Therefore, when a Locator becomes >>>> unreachable, the >>>>      Locator-Status-Bit that corresponds to that Locator's position >>>> in the >>>>      list returned by the last Map-Reply will be set to zero for that >>>>      particular EID-Prefix >>>> >>>> Doesn't this imply a stateful relationship between the ordering of >>>> Map-Replys and data-plane traffic? >>>> >>>> Section 10.1 >>>> >>>>      Note that "ITR" and "ETR" are relative terms here. Both >>>> devices MUST >>>>      be implementing both ITR and ETR functionality for the echo nonce >>>>      mechanism to operate. >>>> >>>> Perhaps they could be given actual names so as to disambiguate >>>> which steps >>>> are performed with ITR vs. ETR role? >>>> >>>>      The echo-nonce algorithm is bilateral.  That is, if one side >>>> sets the >>>>      E-bit and the other side is not enabled for echo-noncing, then >>>> the >>>>      echoing of the nonce does not occur and the requesting side may >>>>      erroneously consider the Locator unreachable.  An ITR SHOULD >>>> only set >>>>      the E-bit in an encapsulated data packet when it knows the ETR is >>>>      enabled for echo-noncing.  This is conveyed by the E-bit in >>>> the RLOC- >>>>      probe Map-Reply message. >>>> >>>> Why is this even optional?  If it was mandatory to use, then there >>>> would >>>> not be a question.  But at least clarify that the "this" that is >>>> conveyed >>>> is whether the peer supports the echo-nonce algorithm. (Also, >>>> subject to >>>> downgrade.) >>>> >>>> Section 13 >>>> >>>>      When a Locator record is removed from a Locator-Set, ITRs that >>>> have >>>>      the mapping cached will not use the removed Locator because >>>> the xTRs >>>>      will set the Locator-Status-Bit to 0.  So, even if the Locator >>>> is in >>>>      the list, it will not be used.  For new mapping requests, the >>>> xTRs >>>>      can set the Locator AFI to 0 (indicating an unspecified >>>> address), as >>>>      well as setting the corresponding Locator-Status-Bit to 0.  This >>>>      forces ITRs with old or new mappings to avoid using the removed >>>>      Locator. >>>> >>>> The behavior describe here seems like it would be better described >>>> as "when >>>> a Locator is taken out of service" than "removed from a >>>> Locator-Set", since >>>> if it is not in the set at all, it has no index, and no LSB or AFI >>>> to set. >>>> Should actually depopulating it like this be forbidden? >>>> >>>> I guess the Map Versioning is supposed to help with this, but we >>>> need to >>>> nail down the semantics more and/or give a clearer reference to it. >>>> >>>> Section 13.1 >>>> >>>>      An ITR, when it encapsulates packets to ETRs, can convey its >>>> own Map- >>>>      Version Number.  This is known as the Source Map-Version Number. >>>> >>>> Replacing "its own Map-Version Number" with something like "the >>>> Map-Version >>>> numer for the LISP site of which it is a part".  Writing this >>>> causes me to >>>> note that the semantics of the Map-Version are unclear, here -- >>>> what is it >>>> scoped to?  An EID-Prefix?  An RLOC?  Oh, you say that in the next >>>> paragraph (EID-Prefix). >>>> >>>>      A Map-Version Number can be included in Map-Register messages as >>>>      well.  This is a good way for the Map-Server to assure that >>>> all ETRs >>>>      for a site registering to it will be synchronized according to >>>> Map- >>>>      Version Number. >>>> >>>> Huh?  I must be confused how this works.  (Also, wouldn't this be >>>> better in >>>> the control plane document which covers Map-Register?) >>>> >>>> Section 15 >>>> >>>>      o  When a tunnel-encapsulated packet is received by an ETR, >>>> the outer >>>>         destination address may not be the address of the router.  >>>> This >>>>         makes it challenging for the control plane to get packets >>>> from the >>>>         hardware.  This may be mitigated by creating special >>>> Forwarding >>>>         Information Base (FIB) entries for the EID-Prefixes of EIDs >>>> served >>>>         by the ETR (those for which the router provides an RLOC >>>>         translation).  These FIB entries are marked with a flag >>>> indicating >>>>         that Control-Plane processing SHOULD be performed. >>>> >>>> I assume this is just my lack of background showing, but I'm >>>> confused how >>>> it makes sense to mark these for control-plane processing. Isn't the >>>> control plane much slower, and we're not putting all of the LISP >>>> data-plane >>>> traffic onto the slow path? >>>> >>>> Section 18 >>>> >>>>      o  Data-Plane gleaning for creating map-cache entries has been >>>> made >>>>         optional.  If any ITR implementations depend or assume the >>>> remote >>>>         ETR is gleaning should not do so. >>>> >>>> nit: this is ungrammatical; "they should not" or "Any ITR >>>> implementations >>>> that depend on or assume that" would fix it. >>>> >>>> Section 19.1 >>>> >>>> Presumably IANA also updated the reference column to point to this >>>> document? >>>> >>>> >>>> >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Sep 28 15:57:07 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB20127148 for ; Fri, 28 Sep 2018 15:57:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AZbepXM0IL_m for ; Fri, 28 Sep 2018 15:57:00 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 90EC4129C6B for ; Fri, 28 Sep 2018 15:57:00 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id d4-v6so5264959pfn.0 for ; Fri, 28 Sep 2018 15:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/j0LcxUDl6Z03KR6p4mCb6J+JROApzs6mlQTStYBlD0=; b=gH4tMx5kCJIQMk6LYKWlQ+rHndwJo1aSYEdAy4mFaqRD9LB1PUoGGfjUh26cjqFR11 OzlxO28XsNAUONr5wKIliC5Z+gHuX2temaTBoBes+nhdz3SvO+v1263wpsBPvPc0VlhG 9AOxncq37T5jn66wBsVqfLg35sUllj7R52yEMJ9LUzthov5ygyDXUnYDZKJ+QwgFRpzf nZ9wOlaQcU99zgJTIaZDcGrmzfL/5+XUMFJ1S/+x8Bo7kJjUSoA4PqIbhOwnT4e5jG4S qjGZ5VZoyEdFGbLBzOSq9C6FfM3Uv5afL5yke+KiD40xpqHR3RLPsckpy1cSsaYiB3rf o4jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/j0LcxUDl6Z03KR6p4mCb6J+JROApzs6mlQTStYBlD0=; b=QJ4UxyIP+GHfg+RwlaotDghHdEUPzavdtrr5i/fWAet7DNy7jbBxXk9lKyFi4tRANv DklLfHYo2zS/oAkCfZtthu3wqeU1FwXV/VQlYkCCEOOjGhzQ38PFmbfXl7Xx2Fm4nLf+ DDW6U9H00K6/kMZwxvWsC0t3eYDzQcWE52+nj4gxx+3lOh5hVhBMeinCo8i5ky9nnoX9 693pN6J8LmgI3Va+WDLD9kC1Z0Sx5SLGG4NYRJyFotCyxkxpVkKpIOfFin4eN8YB3dZ1 1CFqyOzrKVaheshRRcqIY0N1k0OBPt7B+EhXuNQFXFZU3t+dJx7/qu6moLmHUbFjcZhh YHFQ== X-Gm-Message-State: ABuFfojZ29C23j8DvmUbwRiWa7R53fEFEMZFTaFLwDH7ub1LBdeaYPHW ONLoQnZ+agnzTkLxCQORXAedbTWf X-Google-Smtp-Source: ACcGV60dkvYRTMoeXfav0ntrAbadXW5kJBWMNKk7+U3wI7fpQ0J/6nKhW5QE/+dGkV2OfscCtcZBPw== X-Received: by 2002:a17:902:820a:: with SMTP id x10-v6mr627554pln.261.1538175419903; Fri, 28 Sep 2018 15:56:59 -0700 (PDT) Received: from [10.228.203.131] (72-172-185-190.bayarea.net. [72.172.185.190]) by smtp.gmail.com with ESMTPSA id a11-v6sm3820077pgw.54.2018.09.28.15.56.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 15:56:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <7924707d-e6c5-5080-7586-dcf1f96fed46@joelhalpern.com> Date: Fri, 28 Sep 2018 15:56:58 -0700 Cc: "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180928220340.GO24695@kduck.kaduk.org> <7924707d-e6c5-5080-7586-dcf1f96fed46@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Fwd: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 22:57:06 -0000 (a) Desirable, because more security is always more desirable. But the choices don=E2=80=99t seem to be comparable. Is =E2=80=9CDesirable= =E2=80=9D more important or more mandatory than =E2=80=9CAcceptable=E2=80=9D= ?=20 I would like better clarification what I=E2=80=99m voting for if I = choose =E2=80=9Cacceptable=E2=80=9D instead of =E2=80=9Cdesirable=E2=80=9D= . Dino > On Sep 28, 2018, at 3:38 PM, Joel M. Halpern = wrote: >=20 > As co-chair, I would like to hear from the working group as to whether = making LISP-SEC mandatory to Implement (not Mandatory to Use) for = LISP6830bis and 6833bis implementations is > a) desirable > b) acceptable > c) undesirable but livable > d) unacceptable or worse. >=20 > Please, do not just pick a letter. Include explanation of your = opinion. > This is not a decision the ADs and Authors can make for the working = group. >=20 > Yours, > Joel >=20 >=20 > -------- Forwarded Message -------- > Subject: Re: Benjamin Kaduk's Discuss on = draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) > Date: Fri, 28 Sep 2018 17:03:40 -0500 > From: Benjamin Kaduk > To: Joel M. Halpern > CC: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, = Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org >=20 > Hi Joel, >=20 >=20 > On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote: >> Is there text we can add about the scoping that will change your = discuss into a series of useful comments? >=20 > I had attempted to structure my Discuss points so that they would = either be > useful comments as is, or rendered moot by a reduced scope. I guess I = can > try to clarify those below. (To be clear, reducing the scope is only = going > to move from "has potentially existentially bad problems" to "has > substantial issues that likely require reengineering to resolve".) >=20 >> If so, Some indication of how you would like that phrased would help = us address these. >=20 > I think Ekr's ballot position on 6833bis has a good summary of the > architecture assumptions that the reduced scope allows us to make. > In order to have the document be able to plausibly make those claims, = it > looks like we'd need to at least: > (1) update the Abstract/Introduction to clarify that the EID namespace = is > only defined within a single administrative domain. > (2) (optionally, if it makes sense) mention in the introduction that = this > administrative domain can include transport over other networks in = the > same way that a VPN would function[*], without requiring = cooperation > from or interaction with the other networks' administrators > (3) remove the "global" text from the EID-to-RLOC Database and = Map-Cache > definitions > (4) update the EID-Prefix definition to talk about the local site or > administrative domain's "address allocation authority" > (5) Take a look at the EID definition to consider whether references = to "on > the public Internet" are still valid, and the text about assignment > in a hierarchical manner should be revised for the new scope as = well. > Likewise for EID-internal structure that is "not visible to the = global > routing system" >=20 > (I stopped skimming and looking for problematic text around section 6) >=20 > [*] Ideally this would be done without using the term "VPN" itself, = since > I'd like to get a movement going to restrict "VPN" to include > confidentiality (i.e., privacy) protection. "virtual network" or = "overlay > network" may or may not be good candidate replacement terms. >=20 >> If not, we seem to have a larger problem. >=20 > Well, we appear to have five ADs that are supporting making LISP-SEC a > normative reference and thus MTI; I don't know if that scale of change > meets your threshold for a "larger problem". >=20 >> Yours, >> Joel >> On 9/26/18 11:44 PM, Benjamin Kaduk wrote: >> > Benjamin Kaduk has entered the following ballot position for >> > draft-ietf-lisp-rfc6830bis-20: 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 = https://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: >> > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >> > > > > = ---------------------------------------------------------------------- >> > DISCUSS: >> > = ---------------------------------------------------------------------- >> > > I have grave concerns about the suitability of LISP as a whole, = in its >> > present form, for advancement to the Standards-Track. While some = of my >> > concerns are not specific to this document, as the core protocol >> > (data-plane) spec, it seems an appropriate place to attach them to. >> > > I am told, out of band, that the intended deployment model is no = longer to >> > cover the entire Internet (c.f. the MISSREF-state >> > draft-ietf-lisp-introduction's "with LISP, the dge of the Internet = and the >> > core can be logically separated and interconnected by LISP-capable >> > routers", etc.), and that full Internet-scale operation is no = longer a >> > goal. However, since that does not seem to be reflected in the = current >> > batch of documents up for IESG review, I am forced to ballot on = them >> > "as-is", namely as targetting global Internet deployment. The = requirements >> > placed on the mapping system are so stringent so as to be arguably >> > unachievable at Internet-scale, though that arguably has more of an >> > interaction with the control-plane than the data-plane. It's still = in >> > scope here, though, as part of the overall description of the = protocol >> > flow. >=20 > (rendered moot by scope reduction) >=20 >> > There are an almost innumerable number of downgrade attacks = possible, and >> > the control-plane and data-plane security mechanisms are not = normative >> > dependencies of the current corpus of documents, and as such are = not up for >> > consideration as mitigating the security concerns with the core = documents. >=20 > The downgrade attacks will probably require some further analysis; = LISP-SEC > would protect a lot of the header bits but I think there may be some = other > data flows to be looked at. >=20 >> > Section 3 defines the EID-to-RLOC Datbaase: >> > > EID-to-RLOC Database: The EID-to-RLOC Database is a global >> > distributed database that contains all known = EID-Prefix-to-RLOC >> > mappings. Each potential ETR typically contains a small = piece of >> > the database: the EID-to-RLOC mappings for the EID-Prefixes >> > "behind" the router. These map to one of the router's own >> > globally visible IP addresses. Note that there MAY be = transient >> > conditions when the EID-Prefix for the site and Locator-Set = for >> > each EID-Prefix may not be the same on all ETRs. This has = no >> > negative implications, since a partial set of Locators can = be >> > used. >> > > No compelling architecture for a trustworthy global distributed = database >> > has been presented that I've seen so far, and LISP relies heavily = on the >> > mapping system's database for its functionality. I am concerned = that so >> > many requirements are placed on the mapping system so as to be in = effect >> > unimplementable, in which case it would seem that the architecture = as a >> > whole (that is, for a global Internet-scale system) is not fit for = purpose. >=20 > (rendered moot by scope reduction) >=20 >> > Section 4.1's Step (6) only mentions parsing "to check for format >> > validity". I think it is appropriate to mention (and refer to) = source >> > authentication checks as well, since bad Map-Reply data can allow = all sorts >> > of attacks to occur. >=20 > (not affected by scope reduction) >=20 >> > There are some fairly subtle ordering requirements between the = order of >> > entries in Map-Reply messages and the Locator-Status-Bits in = data-plane >> > traffic (so that the semantic meaning of the status bits are = meaningful), >> > which is only given a minimal treatment in the control-plane = document. The >> > need for synchronization in interpreting these bits should be = mentioned >> > more prominently in the data-plane document as well. >=20 > (not affected by scope reduction) >=20 >> > > The usage of the Instance ID does not seem to be adequately = covered; from >> > what I've been able to pick up so far it seems that both source and >> > destination participants must agree on the meaning of an Instance = ID, and >> > the source and destination EIDs must be in the same Instance. This = does >> > not seem like it is compatible with Internet scale, especially if = there are >> > only 24 usable bits of Instance ID. >=20 > (not affected by scope reduction) >=20 >> > > There seems to be a lot of intra-site synchronization = requirements, notably >> > with respect to Map-Version consistency, the contents and ordering = of >> > locator sets for EIDs in the site, etc.; the actual hard = requirements for >> > synchronization within a site should be clearly called out, ideally = in a >> > single location. >=20 > (not affected by scope reduction, since ETRs are affected and not just > Map-Servers) >=20 >> > > The security considerations attempt to defer substantially to the >> > threat-analysis in RFC 7835, which does not really seem like a = complete >> > threat analysis and does not provide analysis as to what = requirements are >> > placed on the boundaries between the different components of LISP = (data >> > plane, control plane, mapping system, various extensions, etc.). = The >> > secdir reviewer had some good thoughts in this space. >=20 > (not affected by scope reduction) >=20 >> > > The security considerations throughout the LISP documents place a = heavy >> > focus on the risk of over-claiming for routing EID-prefixes. This = is a >> > real concern, to be clear, but it should not overshadow the risk of = an >> > attacker who is able to move traffic around at will, strip security >> > protections, cause denial of service, alter data-plane payloads, = etc. >> > Similarly, this document's security considerations call out denial = of >> > service as a risk from Map-Cache insertion/spoofing, but the risks = from an >> > attacker being able to read and modify the traffic, perhaps even = without >> > detection, seems a much greater threat to me. >=20 > (not affected by scope reduction) >=20 >> > > I am not convinced that this protocol meets the current IETF = requirements >> > for the security properties of Standards-Track Protocols without at = least >> > LISP-SEC as a mandatory-to-implement component, and possibly = additional or >> > stronger requirements. (I did not do a full analysis of the system = in the >> > presence of those security mechanisms, since that is not what is = being >> > presented for review.) >=20 > (noting that LISP-SEC needs to be MTI and analysis performed under the = new > assumptions) >=20 >> > Having an EID that is associated to user-correlatable devices has = severe >> > privacy considerations, but I could not find this mentioned = anywhere in all >> > of the LISP documents I've read so far. >=20 > (not affected by scope reduction) >=20 > -Benjamin >=20 >> > > > = ---------------------------------------------------------------------- >> > COMMENT: >> > = ---------------------------------------------------------------------- >> > > I apologize for the somewhat scattered nature of these comments; = there are >> > a lot of them and I was focusing my time more on trying to = understand the >> > broader system, and the intended security posture, so they did not = get as >> > much clean-up as I would have liked. (Most of my review was = performed on the >> > -18, though I have tried to update to the -20 as relevant.) >> > > > The instance ID provides for organizational correlation, = another privacy >> > exposure. >> > > Is there anything different between an "EID-to-RLOC Map-Request" = and just a >> > "Map-Request"? (Same question for "Map-Reply", too.) >> > > There's a lot of stuff that seems to work best if there is = symmetric >> > bidirectional traffic, with inline signalling of map version and >> > reachability changes, though clearly everything is designed to also = work >> > with asymmetric connectivity or unidirectional traffic. It would = be nice >> > to have a high-level summary in or near the introduction about what = kinds >> > of behavior/performance differences are expected for bidirectional = vs. >> > unidirectional traffic. >> > > Section 2 >> > > That's not the 8174 boilerplate; it's more than just adding a = cite to the >> > 2119 boilerplate. >> > > Section 3 >> > > nit: "An address family that pertains to the Data-Plane." is a = sentence >> > fragment. >> > > Ingress Tunnel Router (ITR): An ITR is a router that = resides in a >> > [...] >> > mapping lookup in the destination address field. Note that = this >> > destination RLOC MAY be an intermediate, proxy device that = has >> > better knowledge of the EID-to-RLOC mapping closer to the >> > > This doesn't seem like a 2119 MAY is necessary, but rather a = statement of >> > fact that may not be known to the encapsulating ITR. >> > > Specifically, when a service provider prepends a LISP = header for >> > Traffic Engineering purposes, the router that does this is = also >> > regarded as an ITR. The outer RLOC the ISP ITR uses can be = based >> > on the outer destination address (the originating ITR's = supplied >> > RLOC) or the inner destination address (the originating = host's >> > supplied EID). >> > > I'm confused here, perhaps in multiple ways. Are there now *two* = LISP >> > headers on the packet? Is the "outer RLOC the ISP ITR uses" the = source >> > RLOC or the destination RLOC? >> > > Negative Mapping Entry: A negative mapping entry, also = known as a >> > negative cache entry, is an EID-to-RLOC entry where an = EID-Prefix >> > is advertised or stored with no RLOCs. That is, the = Locator-Set >> > for the EID-to-RLOC entry is empty or has an encoded Locator = count >> > of 0. >> > > Is "empty" a distinct representation from "locator count of = zero"? >> > > Perhaps something of an aside, but the check described for >> > Route-Returnability is a somewhat weak check, and in some cases = could still >> > be spoofed. (I don't expect this to surprise anyone, of course, = but >> > perhaps some more qualifiers could be added to the text.) >> > > Section 4 >> > > An additional LISP header MAY be prepended to packets by a = TE-ITR >> > when re-routing of the path for a packet is desired. A = potential >> > use-case for this would be an ISP router that needs to perform >> > Traffic Engineering for packets flowing through its network. = In such >> > a situation, termed "Recursive Tunneling", an ISP transit acts = as an >> > additional ITR, and the RLOC it uses for the new prepended = header >> > would be either a TE-ETR within the ISP (along an intra-ISP = traffic >> > engineered path) or a TE-ETR within another ISP (an inter-ISP = traffic >> > engineered path, where an agreement to build such a path = exists). >> > > "the RLOC it uses for the new prepnded header", again, this is as = the >> > destination RLOC (vs. source RLOC)? >> > > Section 4.1 >> > > o Map-Replies are sent on the underlying routing system = topology >> > using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. >> > > Just to check my understanding: is the "underlying routing system = topology" >> > the same as the "underlay"? >> > > Is step (3) just describing more of what step (2) says is "not = described in >> > this example"? >> > > Section 5.3 >> > > The word "nonce" is normally used for something used exactly = once. >> > E.g., with some AEAD algorithms, if the same "nonce" input is used = for >> > different encryptions, the entire security of the system is = compromised. >> > It would be better to refer to this field with a different term, = given >> > that "the same nonce can be used for a period of time when = encapsulating to >> > the same ETR". "Uniquifier" or "random value" might be reasonable = choices. >> > > Why is there no discussion of the Map-Version or Instance-ID = fields >> > in this section? >> > > When doing ETR/PETR decapsulation: >> > > o The inner-header 'Time to Live' field (or 'Hop Limit' = field, in >> > the case of IPv6) SHOULD be copied from the outer-header = 'Time to >> > Live' field, when the Time to Live value of the outer header = is >> > less than the Time to Live value of the inner header. = Failing to >> > perform this check can cause the Time to Live of the inner = header >> > to increment across encapsulation/decapsulation cycles. = This >> > check is also performed when doing initial encapsulation, = when a >> > packet comes to an ITR or PITR destined for a LISP site. >> > > Er, what is "this check" that is also performed for initial = encapsulation? >> > How are there multiple TTL values to compare? >> > > o The inner-header 'Differentiated Services Code Point' = (DSCP) field >> > (or the 'Traffic Class' field, in the case of IPv6) SHOULD = be >> > copied from the outer-header DSCP field ('Traffic Class' = field, in >> > the case of IPv6) to the inner-header. >> > > nit: the first "inner-header" seems like an editing remnant? >> > > Section 7.1 >> > > How is this stateless if it invovles knowledge about the routers = between >> > the ITR and all possible ETRs (i.e., a set that could change over = time)? >> > > Section 8 >> > > This 32-bit vs 24-bit thing is pretty hokey for a standards-track >> > specification (yes, I know that LISP-DDT is not standards track at = the >> > moment). >> > > Section 9 >> > > Alternatively, RLOC information MAY be gleaned from received = tunneled >> > > What is this an alternative to? The list of four options above? >> > > packets or EID-to-RLOC Map-Request messages. A "gleaned" = Map-Cache >> > entry, one learned from the source RLOC of a received = encapsulated >> > packet, is only stored and used for a few seconds, pending >> > verification. Verification is performed by sending a = Map-Request to >> > the source EID (the inner-header IP source address) of the = received >> > encapsulated packet. >> > > The source EID is some random end system, right? So this relys = on some >> > magic in the ETR to detect that there's a Map-Request and reply = directly >> > instead of passing it on to the EID that won't know what to do with = it? >> > > Talking about the "R-bit" of the Map-Reply" is detail from = 6833bis and >> > might benefit from an explicit section reference to the other = document. >> > > Section 10 >> > > What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, = but it >> > is not marked as well-known at >> > https://www.rfc-editor.org/materials/abbrev.expansion.txt so = expansion is >> > probably in order. >> > > Again, when we are talking about the internal structure of the = Map-Reply, a >> > detailed section refernce to 6833bis is useful. >> > > Modifying LSBs seems like a fine DoS attack vector for an on-path = attacker. >> > > value of 1. Locator-Status-Bits are associated with a = Locator-Set >> > per EID-Prefix. Therefore, when a Locator becomes unreachable, = the >> > Locator-Status-Bit that corresponds to that Locator's position = in the >> > list returned by the last Map-Reply will be set to zero for = that >> > particular EID-Prefix >> > > Doesn't this imply a stateful relationship between the ordering = of >> > Map-Replys and data-plane traffic? >> > > Section 10.1 >> > > Note that "ITR" and "ETR" are relative terms here. Both = devices MUST >> > be implementing both ITR and ETR functionality for the echo = nonce >> > mechanism to operate. >> > > Perhaps they could be given actual names so as to disambiguate = which steps >> > are performed with ITR vs. ETR role? >> > > The echo-nonce algorithm is bilateral. That is, if one side = sets the >> > E-bit and the other side is not enabled for echo-noncing, then = the >> > echoing of the nonce does not occur and the requesting side may >> > erroneously consider the Locator unreachable. An ITR SHOULD = only set >> > the E-bit in an encapsulated data packet when it knows the ETR = is >> > enabled for echo-noncing. This is conveyed by the E-bit in the = RLOC- >> > probe Map-Reply message. >> > > Why is this even optional? If it was mandatory to use, then = there would >> > not be a question. But at least clarify that the "this" that is = conveyed >> > is whether the peer supports the echo-nonce algorithm. (Also, = subject to >> > downgrade.) >> > > Section 13 >> > > When a Locator record is removed from a Locator-Set, ITRs = that have >> > the mapping cached will not use the removed Locator because the = xTRs >> > will set the Locator-Status-Bit to 0. So, even if the Locator = is in >> > the list, it will not be used. For new mapping requests, the = xTRs >> > can set the Locator AFI to 0 (indicating an unspecified = address), as >> > well as setting the corresponding Locator-Status-Bit to 0. = This >> > forces ITRs with old or new mappings to avoid using the removed >> > Locator. >> > > The behavior describe here seems like it would be better = described as "when >> > a Locator is taken out of service" than "removed from a = Locator-Set", since >> > if it is not in the set at all, it has no index, and no LSB or AFI = to set. >> > Should actually depopulating it like this be forbidden? >> > > I guess the Map Versioning is supposed to help with this, but we = need to >> > nail down the semantics more and/or give a clearer reference to it. >> > > Section 13.1 >> > > An ITR, when it encapsulates packets to ETRs, can convey its = own Map- >> > Version Number. This is known as the Source Map-Version = Number. >> > > Replacing "its own Map-Version Number" with something like "the = Map-Version >> > numer for the LISP site of which it is a part". Writing this = causes me to >> > note that the semantics of the Map-Version are unclear, here -- = what is it >> > scoped to? An EID-Prefix? An RLOC? Oh, you say that in the next >> > paragraph (EID-Prefix). >> > > A Map-Version Number can be included in Map-Register messages = as >> > well. This is a good way for the Map-Server to assure that all = ETRs >> > for a site registering to it will be synchronized according to = Map- >> > Version Number. >> > > Huh? I must be confused how this works. (Also, wouldn't this be = better in >> > the control plane document which covers Map-Register?) >> > > Section 15 >> > > o When a tunnel-encapsulated packet is received by an ETR, = the outer >> > destination address may not be the address of the router. = This >> > makes it challenging for the control plane to get packets = from the >> > hardware. This may be mitigated by creating special = Forwarding >> > Information Base (FIB) entries for the EID-Prefixes of EIDs = served >> > by the ETR (those for which the router provides an RLOC >> > translation). These FIB entries are marked with a flag = indicating >> > that Control-Plane processing SHOULD be performed. >> > > I assume this is just my lack of background showing, but I'm = confused how >> > it makes sense to mark these for control-plane processing. Isn't = the >> > control plane much slower, and we're not putting all of the LISP = data-plane >> > traffic onto the slow path? >> > > Section 18 >> > > o Data-Plane gleaning for creating map-cache entries has = been made >> > optional. If any ITR implementations depend or assume the = remote >> > ETR is gleaning should not do so. >> > > nit: this is ungrammatical; "they should not" or "Any ITR = implementations >> > that depend on or assume that" would fix it. >> > > Section 19.1 >> > > Presumably IANA also updated the reference column to point to = this >> > document? >> > > >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Sep 28 15:58:13 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FEB130DC1 for ; Fri, 28 Sep 2018 15:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 WceRyM52Ak12 for ; Fri, 28 Sep 2018 15:58:05 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A087129C6B for ; Fri, 28 Sep 2018 15:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26063; q=dns/txt; s=iport; t=1538175485; x=1539385085; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=x+S71ryPbXeE3LeGeA3ObbOd9ZH1uhlgwoEvwkZUEvY=; b=Nom4d0PZPcOEvJ+N/ouOm794XGesAOlAn+ipCLcELTQQAcKYAe4nUcu4 cbwbmO0Pe6lKUxiRD04Ux6734H24sVUZBZaxHT63pjoUp3/tJphv3KFmn feYLUdIurXBMtM5t5LP1wzmOsEDrNGF5JvtxTWlrutNxcGy81UojvwN9A g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAAABsa5b/5tdJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUoINZn8og3SURoFgLZZWFIFjAwsYC4RJAoN7ITUXAQM?= =?us-ascii?q?BAQIBAQJtHAyFOAEBAQMBAQEYCQ8BBTYEDAsJAhEBAgECAQICHwcCAiciBgg?= =?us-ascii?q?TBgIBAYMdAYF5CA+ITptNgS6EMwc9hRMFgQuHLHaBUReBQT+BEieBbX6DGwE?= =?us-ascii?q?BAQIBgSoBDAYBBwJCglWCVwKIKCSGLIRoiT0JhkODC4ZcBheBR4RagmMmgQ+?= =?us-ascii?q?FD4h3gw+GDIMRgUMBNkEjWBEIMxoIGxU7gmyCIAUFEhGISYVeHzABAYsKDhe?= =?us-ascii?q?CJwEB?= X-IronPort-AV: E=Sophos;i="5.54,316,1534809600"; d="scan'208";a="178355331" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2018 22:58:03 +0000 Received: from [10.32.173.55] ([10.32.173.55]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w8SMw1fU013461 for ; Fri, 28 Sep 2018 22:58:02 GMT To: lisp@ietf.org References: <20180928220340.GO24695@kduck.kaduk.org> <7924707d-e6c5-5080-7586-dcf1f96fed46@joelhalpern.com> From: Fabio Maino Message-ID: Date: Fri, 28 Sep 2018 15:58:01 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7924707d-e6c5-5080-7586-dcf1f96fed46@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.32.173.55, [10.32.173.55] X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [lisp] Fwd: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 22:58:11 -0000 On 9/28/18 3:38 PM, Joel M. Halpern wrote: > As co-chair, I would like to hear from the working group as to whether > making LISP-SEC mandatory to Implement (not Mandatory to Use) for > LISP6830bis and 6833bis implementations is > a) desirable I have always seen LISP-SEC as part of the LISP "core" set of documents, so I agree that it is desirable to make it mandatory to implement. There are also quite a few comments from Benjamin and Eric's review, including to make more clear the scope of applicability, that would certainly benefit the RFCbis. As an author of LISP-SEC I'm willing to help addressing the changes above in the documents under review (as well as in LISP-SEC). Fabio > b) acceptable > c) undesirable but livable > d) unacceptable or worse. > > Please, do not just pick a letter.  Include explanation of your opinion. > This is not a decision the ADs and Authors can make for the working > group. > > Yours, > Joel > > > -------- Forwarded Message -------- > Subject: Re: Benjamin Kaduk's Discuss on > draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) > Date: Fri, 28 Sep 2018 17:03:40 -0500 > From: Benjamin Kaduk > To: Joel M. Halpern > CC: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, > Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org > > Hi Joel, > > > On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote: >> Is there text we can add about the scoping that will change your >> discuss into a series of useful comments? > > I had attempted to structure my Discuss points so that they would > either be > useful comments as is, or rendered moot by a reduced scope.  I guess I > can > try to clarify those below.  (To be clear, reducing the scope is only > going > to move from "has potentially existentially bad problems" to "has > substantial issues that likely require reengineering to resolve".) > >> If so, Some indication of how you would like that phrased would help >> us address these. > > I think Ekr's ballot position on 6833bis has a good summary of the > architecture assumptions that the reduced scope allows us to make. > In order to have the document be able to plausibly make those claims, it > looks like we'd need to at least: > (1) update the Abstract/Introduction to clarify that the EID namespace is >     only defined within a single administrative domain. > (2) (optionally, if it makes sense) mention in the introduction that this >     administrative domain can include transport over other networks in > the >     same way that a VPN would function[*], without requiring cooperation >     from or interaction with the other networks' administrators > (3) remove the "global" text from the EID-to-RLOC Database and Map-Cache >     definitions > (4) update the EID-Prefix definition to talk about the local site or >     administrative domain's "address allocation authority" > (5) Take a look at the EID definition to consider whether references > to "on >     the public Internet" are still valid, and the text about assignment >     in a hierarchical manner should be revised for the new scope as well. >     Likewise for EID-internal structure that is "not visible to the > global >     routing system" > > (I stopped skimming and looking for problematic text around section 6) > > [*] Ideally this would be done without using the term "VPN" itself, since > I'd like to get a movement going to restrict "VPN" to include > confidentiality (i.e., privacy) protection.  "virtual network" or > "overlay > network" may or may not be good candidate replacement terms. > >> If not, we seem to have a larger problem. > > Well, we appear to have five ADs that are supporting making LISP-SEC a > normative reference and thus MTI; I don't know if that scale of change > meets your threshold for a "larger problem". > >> Yours, >> Joel >> >> On 9/26/18 11:44 PM, Benjamin Kaduk wrote: >> > Benjamin Kaduk has entered the following ballot position for >> > draft-ietf-lisp-rfc6830bis-20: 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 >> https://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: >> > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >> > > > > >> ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > > I have grave concerns about the suitability of LISP as a whole, >> in its >> > present form, for advancement to the Standards-Track. While some of my >> > concerns are not specific to this document, as the core protocol >> > (data-plane) spec, it seems an appropriate place to attach them to. >> > > I am told, out of band, that the intended deployment model is no >> longer to >> > cover the entire Internet (c.f. the MISSREF-state >> > draft-ietf-lisp-introduction's "with LISP, the dge of the Internet >> and the >> > core can be logically separated and interconnected by LISP-capable >> > routers", etc.), and that full Internet-scale operation is no longer a >> > goal.  However, since that does not seem to be reflected in the >> current >> > batch of documents up for IESG review, I am forced to ballot on them >> > "as-is", namely as targetting global Internet deployment. The >> requirements >> > placed on the mapping system are so stringent so as to be arguably >> > unachievable at Internet-scale, though that arguably has more of an >> > interaction with the control-plane than the data-plane. It's still in >> > scope here, though, as part of the overall description of the protocol >> > flow. > > (rendered moot by scope reduction) > >> > There are an almost innumerable number of downgrade attacks >> possible, and >> > the control-plane and data-plane security mechanisms are not normative >> > dependencies of the current corpus of documents, and as such are >> not up for >> > consideration as mitigating the security concerns with the core >> documents. > > The downgrade attacks will probably require some further analysis; > LISP-SEC > would protect a lot of the header bits but I think there may be some > other > data flows to be looked at. > >> > Section 3 defines the EID-to-RLOC Datbaase: >> > >     EID-to-RLOC Database:   The EID-to-RLOC Database is a global >> >        distributed database that contains all known EID-Prefix-to-RLOC >> >        mappings.  Each potential ETR typically contains a small >> piece of >> >        the database: the EID-to-RLOC mappings for the EID-Prefixes >> >        "behind" the router.  These map to one of the router's own >> >        globally visible IP addresses.  Note that there MAY be >> transient >> >        conditions when the EID-Prefix for the site and Locator-Set for >> >        each EID-Prefix may not be the same on all ETRs. This has no >> >        negative implications, since a partial set of Locators can be >> >        used. >> > > No compelling architecture for a trustworthy global distributed >> database >> > has been presented that I've seen so far, and LISP relies heavily >> on the >> > mapping system's database for its functionality.  I am concerned >> that so >> > many requirements are placed on the mapping system so as to be in >> effect >> > unimplementable, in which case it would seem that the architecture >> as a >> > whole (that is, for a global Internet-scale system) is not fit for >> purpose. > > (rendered moot by scope reduction) > >> > Section 4.1's Step (6) only mentions parsing "to check for format >> > validity".  I think it is appropriate to mention (and refer to) source >> > authentication checks as well, since bad Map-Reply data can allow >> all sorts >> > of attacks to occur. > > (not affected by scope reduction) > >> > There are some fairly subtle ordering requirements between the >> order of >> > entries in Map-Reply messages and the Locator-Status-Bits in >> data-plane >> > traffic (so that the semantic meaning of the status bits are >> meaningful), >> > which is only given a minimal treatment in the control-plane >> document.  The >> > need for synchronization in interpreting these bits should be >> mentioned >> > more prominently in the data-plane document as well. > > (not affected by scope reduction) > >> > > The usage of the Instance ID does not seem to be adequately >> covered; from >> > what I've been able to pick up so far it seems that both source and >> > destination participants must agree on the meaning of an Instance >> ID, and >> > the source and destination EIDs must be in the same Instance.  This >> does >> > not seem like it is compatible with Internet scale, especially if >> there are >> > only 24 usable bits of Instance ID. > > (not affected by scope reduction) > >> > > There seems to be a lot of intra-site synchronization >> requirements, notably >> > with respect to Map-Version consistency, the contents and ordering of >> > locator sets for EIDs in the site, etc.; the actual hard >> requirements for >> > synchronization within a site should be clearly called out, ideally >> in a >> > single location. > > (not affected by scope reduction, since ETRs are affected and not just > Map-Servers) > >> > > The security considerations attempt to defer substantially to the >> > threat-analysis in RFC 7835, which does not really seem like a >> complete >> > threat analysis and does not provide analysis as to what >> requirements are >> > placed on the boundaries between the different components of LISP >> (data >> > plane, control plane, mapping system, various extensions, etc.).  The >> > secdir reviewer had some good thoughts in this space. > > (not affected by scope reduction) > >> > > The security considerations throughout the LISP documents place a >> heavy >> > focus on the risk of over-claiming for routing EID-prefixes.  This >> is a >> > real concern, to be clear, but it should not overshadow the risk of an >> > attacker who is able to move traffic around at will, strip security >> > protections, cause denial of service, alter data-plane payloads, etc. >> > Similarly, this document's security considerations call out denial of >> > service as a risk from Map-Cache insertion/spoofing, but the risks >> from an >> > attacker being able to read and modify the traffic, perhaps even >> without >> > detection, seems a much greater threat to me. > > (not affected by scope reduction) > >> > > I am not convinced that this protocol meets the current IETF >> requirements >> > for the security properties of Standards-Track Protocols without at >> least >> > LISP-SEC as a mandatory-to-implement component, and possibly >> additional or >> > stronger requirements.  (I did not do a full analysis of the system >> in the >> > presence of those security mechanisms, since that is not what is being >> > presented for review.) > > (noting that LISP-SEC needs to be MTI and analysis performed under the > new > assumptions) > >> > Having an EID that is associated to user-correlatable devices has >> severe >> > privacy considerations, but I could not find this mentioned >> anywhere in all >> > of the LISP documents I've read so far. > > (not affected by scope reduction) > > -Benjamin > >> > > > >> ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > > I apologize for the somewhat scattered nature of these comments; >> there are >> > a lot of them and I was focusing my time more on trying to >> understand the >> > broader system, and the intended security posture, so they did not >> get as >> > much clean-up as I would have liked.  (Most of my review was >> performed on the >> > -18, though I have tried to update to the -20 as relevant.) >> > > > The instance ID provides for organizational correlation, >> another privacy >> > exposure. >> > > Is there anything different between an "EID-to-RLOC Map-Request" >> and just a >> > "Map-Request"?  (Same question for "Map-Reply", too.) >> > > There's a lot of stuff that seems to work best if there is symmetric >> > bidirectional traffic, with inline signalling of map version and >> > reachability changes, though clearly everything is designed to also >> work >> > with asymmetric connectivity or unidirectional traffic.  It would >> be nice >> > to have a high-level summary in or near the introduction about what >> kinds >> > of behavior/performance differences are expected for bidirectional vs. >> > unidirectional traffic. >> > > Section 2 >> > > That's not the 8174 boilerplate; it's more than just adding a >> cite to the >> > 2119 boilerplate. >> > > Section 3 >> > > nit: "An address family that pertains to the Data-Plane." is a >> sentence >> > fragment. >> > >     Ingress Tunnel Router (ITR):   An ITR is a router that >> resides in a >> >        [...] >> >        mapping lookup in the destination address field. Note that this >> >        destination RLOC MAY be an intermediate, proxy device that has >> >        better knowledge of the EID-to-RLOC mapping closer to the >> > > This doesn't seem like a 2119 MAY is necessary, but rather a >> statement of >> > fact that may not be known to the encapsulating ITR. >> > >        Specifically, when a service provider prepends a LISP >> header for >> >        Traffic Engineering purposes, the router that does this is also >> >        regarded as an ITR.  The outer RLOC the ISP ITR uses can be >> based >> >        on the outer destination address (the originating ITR's >> supplied >> >        RLOC) or the inner destination address (the originating host's >> >        supplied EID). >> > > I'm confused here, perhaps in multiple ways.  Are there now *two* >> LISP >> > headers on the packet?  Is the "outer RLOC the ISP ITR uses" the >> source >> > RLOC or the destination RLOC? >> > >     Negative Mapping Entry:   A negative mapping entry, also >> known as a >> >        negative cache entry, is an EID-to-RLOC entry where an >> EID-Prefix >> >        is advertised or stored with no RLOCs.  That is, the >> Locator-Set >> >        for the EID-to-RLOC entry is empty or has an encoded Locator >> count >> >        of 0. >> > > Is "empty" a distinct representation from "locator count of zero"? >> > > Perhaps something of an aside, but the check described for >> > Route-Returnability is a somewhat weak check, and in some cases >> could still >> > be spoofed.  (I don't expect this to surprise anyone, of course, but >> > perhaps some more qualifiers could be added to the text.) >> > > Section 4 >> > >     An additional LISP header MAY be prepended to packets by a >> TE-ITR >> >     when re-routing of the path for a packet is desired.  A potential >> >     use-case for this would be an ISP router that needs to perform >> >     Traffic Engineering for packets flowing through its network.  >> In such >> >     a situation, termed "Recursive Tunneling", an ISP transit acts >> as an >> >     additional ITR, and the RLOC it uses for the new prepended header >> >     would be either a TE-ETR within the ISP (along an intra-ISP >> traffic >> >     engineered path) or a TE-ETR within another ISP (an inter-ISP >> traffic >> >     engineered path, where an agreement to build such a path exists). >> > > "the RLOC it uses for the new prepnded header", again, this is as >> the >> > destination RLOC (vs. source RLOC)? >> > > Section 4.1 >> > >     o  Map-Replies are sent on the underlying routing system >> topology >> >        using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. >> > > Just to check my understanding: is the "underlying routing system >> topology" >> > the same as the "underlay"? >> > > Is step (3) just describing more of what step (2) says is "not >> described in >> > this example"? >> > > Section 5.3 >> > > The word "nonce" is normally used for something used exactly once. >> > E.g., with some AEAD algorithms, if the same "nonce" input is used for >> > different encryptions, the entire security of the system is >> compromised. >> > It would be better to refer to this field with a different term, given >> > that "the same nonce can be used for a period of time when >> encapsulating to >> > the same ETR".  "Uniquifier" or "random value" might be reasonable >> choices. >> > > Why is there no discussion of the Map-Version or Instance-ID fields >> > in this section? >> > > When doing ETR/PETR decapsulation: >> > >     o  The inner-header 'Time to Live' field (or 'Hop Limit' >> field, in >> >        the case of IPv6) SHOULD be copied from the outer-header >> 'Time to >> >        Live' field, when the Time to Live value of the outer header is >> >        less than the Time to Live value of the inner header.  >> Failing to >> >        perform this check can cause the Time to Live of the inner >> header >> >        to increment across encapsulation/decapsulation cycles.  This >> >        check is also performed when doing initial encapsulation, >> when a >> >        packet comes to an ITR or PITR destined for a LISP site. >> > > Er, what is "this check" that is also performed for initial >> encapsulation? >> > How are there multiple TTL values to compare? >> > >     o  The inner-header 'Differentiated Services Code Point' >> (DSCP) field >> >        (or the 'Traffic Class' field, in the case of IPv6) SHOULD be >> >        copied from the outer-header DSCP field ('Traffic Class' >> field, in >> >        the case of IPv6) to the inner-header. >> > > nit: the first "inner-header" seems like an editing remnant? >> > > Section 7.1 >> > > How is this stateless if it invovles knowledge about the routers >> between >> > the ITR and all possible ETRs (i.e., a set that could change over >> time)? >> > > Section 8 >> > > This 32-bit vs 24-bit thing is pretty hokey for a standards-track >> > specification (yes, I know that LISP-DDT is not standards track at the >> > moment). >> > > Section 9 >> > >     Alternatively, RLOC information MAY be gleaned from received >> tunneled >> > > What is this an alternative to?  The list of four options above? >> > >     packets or EID-to-RLOC Map-Request messages.  A "gleaned" >> Map-Cache >> >     entry, one learned from the source RLOC of a received encapsulated >> >     packet, is only stored and used for a few seconds, pending >> >     verification.  Verification is performed by sending a >> Map-Request to >> >     the source EID (the inner-header IP source address) of the >> received >> >     encapsulated packet. >> > > The source EID is some random end system, right?  So this relys >> on some >> > magic in the ETR to detect that there's a Map-Request and reply >> directly >> > instead of passing it on to the EID that won't know what to do with >> it? >> > > Talking about the "R-bit" of the Map-Reply" is detail from >> 6833bis and >> > might benefit from an explicit section reference to the other >> document. >> > > Section 10 >> > > What is the "CE" of "CE-based ITRs"?  Presumably Customer Edge, >> but it >> > is not marked as well-known at >> > https://www.rfc-editor.org/materials/abbrev.expansion.txt so >> expansion is >> > probably in order. >> > > Again, when we are talking about the internal structure of the >> Map-Reply, a >> > detailed section refernce to 6833bis is useful. >> > > Modifying LSBs seems like a fine DoS attack vector for an on-path >> attacker. >> > >     value of 1.  Locator-Status-Bits are associated with a >> Locator-Set >> >     per EID-Prefix.  Therefore, when a Locator becomes unreachable, >> the >> >     Locator-Status-Bit that corresponds to that Locator's position >> in the >> >     list returned by the last Map-Reply will be set to zero for that >> >     particular EID-Prefix >> > > Doesn't this imply a stateful relationship between the ordering of >> > Map-Replys and data-plane traffic? >> > > Section 10.1 >> > >     Note that "ITR" and "ETR" are relative terms here.  Both >> devices MUST >> >     be implementing both ITR and ETR functionality for the echo nonce >> >     mechanism to operate. >> > > Perhaps they could be given actual names so as to disambiguate >> which steps >> > are performed with ITR vs. ETR role? >> > >     The echo-nonce algorithm is bilateral.  That is, if one side >> sets the >> >     E-bit and the other side is not enabled for echo-noncing, then the >> >     echoing of the nonce does not occur and the requesting side may >> >     erroneously consider the Locator unreachable.  An ITR SHOULD >> only set >> >     the E-bit in an encapsulated data packet when it knows the ETR is >> >     enabled for echo-noncing.  This is conveyed by the E-bit in the >> RLOC- >> >     probe Map-Reply message. >> > > Why is this even optional?  If it was mandatory to use, then >> there would >> > not be a question.  But at least clarify that the "this" that is >> conveyed >> > is whether the peer supports the echo-nonce algorithm. (Also, >> subject to >> > downgrade.) >> > > Section 13 >> > >     When a Locator record is removed from a Locator-Set, ITRs >> that have >> >     the mapping cached will not use the removed Locator because the >> xTRs >> >     will set the Locator-Status-Bit to 0.  So, even if the Locator >> is in >> >     the list, it will not be used.  For new mapping requests, the xTRs >> >     can set the Locator AFI to 0 (indicating an unspecified >> address), as >> >     well as setting the corresponding Locator-Status-Bit to 0.  This >> >     forces ITRs with old or new mappings to avoid using the removed >> >     Locator. >> > > The behavior describe here seems like it would be better >> described as "when >> > a Locator is taken out of service" than "removed from a >> Locator-Set", since >> > if it is not in the set at all, it has no index, and no LSB or AFI >> to set. >> > Should actually depopulating it like this be forbidden? >> > > I guess the Map Versioning is supposed to help with this, but we >> need to >> > nail down the semantics more and/or give a clearer reference to it. >> > > Section 13.1 >> > >     An ITR, when it encapsulates packets to ETRs, can convey its >> own Map- >> >     Version Number.  This is known as the Source Map-Version Number. >> > > Replacing "its own Map-Version Number" with something like "the >> Map-Version >> > numer for the LISP site of which it is a part".  Writing this >> causes me to >> > note that the semantics of the Map-Version are unclear, here -- >> what is it >> > scoped to?  An EID-Prefix?  An RLOC?  Oh, you say that in the next >> > paragraph (EID-Prefix). >> > >     A Map-Version Number can be included in Map-Register messages as >> >     well.  This is a good way for the Map-Server to assure that all >> ETRs >> >     for a site registering to it will be synchronized according to >> Map- >> >     Version Number. >> > > Huh?  I must be confused how this works.  (Also, wouldn't this be >> better in >> > the control plane document which covers Map-Register?) >> > > Section 15 >> > >     o  When a tunnel-encapsulated packet is received by an ETR, >> the outer >> >        destination address may not be the address of the router.  This >> >        makes it challenging for the control plane to get packets >> from the >> >        hardware.  This may be mitigated by creating special Forwarding >> >        Information Base (FIB) entries for the EID-Prefixes of EIDs >> served >> >        by the ETR (those for which the router provides an RLOC >> >        translation).  These FIB entries are marked with a flag >> indicating >> >        that Control-Plane processing SHOULD be performed. >> > > I assume this is just my lack of background showing, but I'm >> confused how >> > it makes sense to mark these for control-plane processing. Isn't the >> > control plane much slower, and we're not putting all of the LISP >> data-plane >> > traffic onto the slow path? >> > > Section 18 >> > >     o  Data-Plane gleaning for creating map-cache entries has >> been made >> >        optional.  If any ITR implementations depend or assume the >> remote >> >        ETR is gleaning should not do so. >> > > nit: this is ungrammatical; "they should not" or "Any ITR >> implementations >> > that depend on or assume that" would fix it. >> > > Section 19.1 >> > > Presumably IANA also updated the reference column to point to this >> > document? >> > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Sep 28 16:04:09 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926D6130DC1 for ; Fri, 28 Sep 2018 16:04:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 91IBZjE7nbSE for ; Fri, 28 Sep 2018 16:04:06 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 1C0A1129C6B for ; Fri, 28 Sep 2018 16:04:06 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id b129-v6so5421333pga.13 for ; Fri, 28 Sep 2018 16:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cICgFBo77eif1Brbfm2A28qK6a/+tV/lLWQI2TpkJ4U=; b=uapQB4791PksS3TQvTbEOdv4szWGFRbEXX3JI9NQwkUis2nWotYWlvbXbmpQL+vTHG GaoQkM//RSraIcwASvdJN6V58luvEeY0gJB9kMfsrJCvwb7huq+L9o3rppkLmCFSqQSG HC4XKrPmnbaobMALc35phNp4jiYAf2RhFnZXo6uwVm6oKL1aLGVBbENPusxm+0eNFCG+ NprAzdH1HcdiW6UpBdYcK8oe8BAZnL6RiLesqzWGyhl37JBD/fWpu4pyYN1XgCK8sT6e RaWokG1byXGc4bgvoqcvbdOYje//5DGKufDpgW/DDMMsGXOG7LQkT730+Ir1jn3zCHc7 Hb1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cICgFBo77eif1Brbfm2A28qK6a/+tV/lLWQI2TpkJ4U=; b=nPmQv9X4cDqrib4FCyYmJbAqBwcyB/Et0YYp11loPR3Us1R4y9+wzPFfx5leoAlBvP 5Nd4q/YvdErpxLmnfgdijwt0+1Quc0Dl7fRAVWHk5k8lVLjBfTgQxxvEedN0bj6tgzig R09trd6EaB80xbiFocSsjPaX01zBXoKHaqg3gbJQMv/JpxMXDNtUTEm0KUA9ijM1B44n xG97In8x1inzVT2mIxhqwqEXCYxNTJq4vi2zVXaq48n/Wlkw1Or5tMg4D4WCkvqwPizA tHv0gWL1TXiUR6+miDzPevp5K9/ZIGTwPu19XGnhAYNpGIU0Az+JH7FZaacAbWivwwEV w9/g== X-Gm-Message-State: ABuFfojj9g0Yh4QAlijXn1XyTjhyPYyJprpi/sFBaYkLuoObrbRbp0Rd Uflujzf4DGu2jUzDXHSbvOb+eAqj X-Google-Smtp-Source: ACcGV63WGro27VYIMYcWKL7B45D6SpSwikCDJ3XtZJQ0MHm8gCmVsgWtkb4M/q00j2oYQRVKvBZpeQ== X-Received: by 2002:a62:34c4:: with SMTP id b187-v6mr682829pfa.15.1538175845461; Fri, 28 Sep 2018 16:04:05 -0700 (PDT) Received: from [10.228.203.131] (72-172-185-190.bayarea.net. [72.172.185.190]) by smtp.gmail.com with ESMTPSA id h19-v6sm13817172pfk.71.2018.09.28.16.04.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 16:04:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Fri, 28 Sep 2018 16:04:04 -0700 Cc: lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180928220340.GO24695@kduck.kaduk.org> <7924707d-e6c5-5080-7586-dcf1f96fed46@joelhalpern.com> To: Fabio Maino X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Fwd: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 23:04:08 -0000 > As an author of LISP-SEC I'm willing to help addressing the changes = above in the documents under review (as well as in LISP-SEC). And I=E2=80=99m willing to help you as well. Dino From nobody Fri Sep 28 16:24:46 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBBA130E09; Fri, 28 Sep 2018 16:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pPrbkcM3fzfF; Fri, 28 Sep 2018 16:24:34 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335AE12F1AC; Fri, 28 Sep 2018 16:24:33 -0700 (PDT) X-AuditID: 12074423-10dff70000000a35-f6-5baeb82d5560 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id AA.70.02613.E28BEAB5; Fri, 28 Sep 2018 19:24:31 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w8SNOO2e026453; Fri, 28 Sep 2018 19:24:26 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8SNOKhq031324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Sep 2018 19:24:23 -0400 Date: Fri, 28 Sep 2018 18:24:20 -0500 From: Benjamin Kaduk To: Dino Farinacci Cc: The IESG , lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, lisp@ietf.org Message-ID: <20180928232420.GP24695@kduck.kaduk.org> References: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUixG6noqu/Y120wamXwhaX171jtWjffY3R YsaficwWL9q2s1lMOavuwOqxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGUcvf6YpeB3dMWi Kc8YGxgfunUxcnBICJhI3Hyn2MXIxSEksJhJ4ve36cwQzkZGiYWHt7FBOFeZJCb3HmDpYuTk YBFQlThw6C47iM0moCLR0H2ZGcQWEdCQuPt+N1icWSBfoulHCxOILSyQLdHwqYsVZBsv0Lbl f9NAwkICjYwSH/7kgti8AoISJ2c+YYFoVZf4M+8SM0g5s4C0xPJ/HBBheYnmrbPBwpwCthKX J4N1igooS+ztO8Q+gVFwFpJBs5AMmoUwaBaSQQsYWVYxyqbkVunmJmbmFKcm6xYnJ+blpRbp munlZpbopaaUbmIEB7uL8g7Gl33ehxgFOBiVeHgdbNdFC7EmlhVX5h5ilORgUhLldZwOFOJL yk+pzEgszogvKs1JLT7EKMHBrCTCezsWKMebklhZlVqUD5OS5mBREued2LI4WkggPbEkNTs1 tSC1CCYrw8GhJMEbux2oUbAoNT21Ii0zpwQhzcTBCTKcB2g4M0gNb3FBYm5xZjpE/hSjPceq GR0zmDm2nekEkm1PrwPJDhApxJKXn5cqJc57ZBtQmwBIW0ZpHtxkUCKTyN5f84pRHOhRYV5/ kOE8wCQIN/sV0FomoLUiB9aArC1JREhJNTD2CV/9VGug86NZ66qzkv+dkrIL4TOurPm0wjZt 04YUOeM9/Aa1v2fNn8lpXB4mOLP96PvTbCp3lzLN5ONWj7c7fMbWfcblvNQ7bwJsVbcb8QfW 2bRsVlD0KM1ec3Sj1vaTc+/MfqsoWVv2WepIyvkUw/XOZpWH1onYb/xm3vx+eS/TuajpVj+V WIozEg21mIuKEwF6amUoPwMAAA== Archived-At: Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 28 Sep 2018 23:24:38 -0000 On Thu, Sep 27, 2018 at 02:06:13PM -0700, Dino Farinacci wrote: > Fixing the simple issues first. Clipping out the rest of the text. > > > Is there anything different between an "EID-to-RLOC Map-Request" and just a > > "Map-Request"? (Same question for "Map-Reply", too.) > > No. But Map-Requests are used for lookups in the mapping system as well as for probing RLOCs for reachability. Okay. I don't know if "Probe Map-Request" and plain "Map-Request" would help the reader or not (I did find myself wondering the original question while reading, of course). > > > Section 3 > > > > nit: "An address family that pertains to the Data-Plane." is a sentence > > fragment. > > Fixed. > > > > > Ingress Tunnel Router (ITR): An ITR is a router that resides in a > > [...] > > mapping lookup in the destination address field. Note that this > > destination RLOC MAY be an intermediate, proxy device that has > > better knowledge of the EID-to-RLOC mapping closer to the > > > > This doesn't seem like a 2119 MAY is necessary, but rather a statement of > > fact that may not be known to the encapsulating ITR. > > Agree. Fixed. > > > > > Specifically, when a service provider prepends a LISP header for > > Traffic Engineering purposes, the router that does this is also > > regarded as an ITR. The outer RLOC the ISP ITR uses can be based > > on the outer destination address (the originating ITR's supplied > > RLOC) or the inner destination address (the originating host's > > supplied EID). > > > > I'm confused here, perhaps in multiple ways. Are there now *two* LISP > > headers on the packet? Is the "outer RLOC the ISP ITR uses" the source > > RLOC or the destination RLOC? > > No, just one. When referring to “inner” and “outer”, we mean IP headers. Okay, so the ITR is picking an "outer RLOC" based on either the "outer destination address" or the "inner destination address". My original reading is that the "outer RLOC" being picked is the same thing as the "outer destination address", which prompted me to think I was confused. Is it actually the outer source address that's being selected? It's sounding like I'm just not sure what field in the outer header the phrase "outer RLOC" is referring to. > > > > Negative Mapping Entry: A negative mapping entry, also known as a > > negative cache entry, is an EID-to-RLOC entry where an EID-Prefix > > is advertised or stored with no RLOCs. That is, the Locator-Set > > for the EID-to-RLOC entry is empty or has an encoded Locator count > > of 0. > > > > Is "empty" a distinct representation from "locator count of zero”? > > Yes. Added text to make that more clear. Thanks! (I thought I had found some text elsewhere, maybe not even in this document, to support my thought that they were the same, so it's good to know that they're not.) > > Section 4 > > > > An additional LISP header MAY be prepended to packets by a TE-ITR > > when re-routing of the path for a packet is desired. A potential > > use-case for this would be an ISP router that needs to perform > > Traffic Engineering for packets flowing through its network. In such > > a situation, termed "Recursive Tunneling", an ISP transit acts as an > > additional ITR, and the RLOC it uses for the new prepended header > > would be either a TE-ETR within the ISP (along an intra-ISP traffic > > engineered path) or a TE-ETR within another ISP (an inter-ISP traffic > > engineered path, where an agreement to build such a path exists). > > > > "the RLOC it uses for the new prepnded header", again, this is as the > > destination RLOC (vs. source RLOC)? > > Fixed. > > > Section 4.1 > > > > o Map-Replies are sent on the underlying routing system topology > > using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. > > > > Just to check my understanding: is the "underlying routing system topology" > > the same as the "underlay”? > > Yes. Okay. I don't request any text change here; I'm sure most readers are more used to these terms than I am. > > Is step (3) just describing more of what step (2) says is "not described in > > this example”? > > I lost your reference. Is it to the previous bulleted set or the one starting with “Client host1 …”? The "Client host1" one. Basically, I'm thinking that sending a Map-Request (step 3) is a method of mapping the destination EID to an RLOC (step 2). Well, assuming a useful Map-Reply eventually shows up, I suppose. > > > > When doing ETR/PETR decapsulation: > > > > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > > the case of IPv6) SHOULD be copied from the outer-header 'Time to > > Live' field, when the Time to Live value of the outer header is > > less than the Time to Live value of the inner header. Failing to > > perform this check can cause the Time to Live of the inner header > > to increment across encapsulation/decapsulation cycles. This > > check is also performed when doing initial encapsulation, when a > > packet comes to an ITR or PITR destined for a LISP site. > > > > Er, what is "this check" that is also performed for initial encapsulation? > > How are there multiple TTL values to compare? > > “This check” is outer-header-TTL is < the inner-header-TTL. Ah, I see now that "this check" is both in "Failing to perform this check" and the start of the following sentence. In the first sentence of the bullet point, though, it reads like "do X, if condition". The last sentece is just saying "check condition" without an apparent "do X" associated with it. So maybe it's better to say something about "when performing initial encapsulation, the ITR or PITR must ensure that the outer TTL is less than the inner TTL". > > o The inner-header 'Differentiated Services Code Point' (DSCP) field > > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be > > copied from the outer-header DSCP field ('Traffic Class' field, in > > the case of IPv6) to the inner-header. > > > > nit: the first "inner-header" seems like an editing remnant? > > Fixed. This text has changed so many times, it’s not a surprise it became confusing. Understandable! > > > > Section 7.1 > > > > How is this stateless if it invovles knowledge about the routers between > > the ITR and all possible ETRs (i.e., a set that could change over time)? > > The ITR does not keep state about underlay routers between it and the ETR. Ah, so this is basically a "computed once by the network administrator, then used as a configuration parameter" thing. > > Section 8 > > > > This 32-bit vs 24-bit thing is pretty hokey for a standards-track > > specification (yes, I know that LISP-DDT is not standards track at the > > moment). > > It is actually useful to allow more instance-IDs but not waste extra bits in the encapsulation header. > > > Section 9 > > > > Alternatively, RLOC information MAY be gleaned from received tunneled > > > > What is this an alternative to? The list of four options above? > > Doing a mapping system lookup to get an RLOC-set. I'd suggest something like "Instead of using the Map-Cache or mapping system, [...]", as I was very uncertain how "Alternatively" was intended to be interpreted. > > packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache > > entry, one learned from the source RLOC of a received encapsulated > > packet, is only stored and used for a few seconds, pending > > verification. Verification is performed by sending a Map-Request to > > the source EID (the inner-header IP source address) of the received > > encapsulated packet. > > > > The source EID is some random end system, right? So this relys on some > > magic in the ETR to detect that there's a Map-Request and reply directly > > instead of passing it on to the EID that won't know what to do with it? > > Not following your description. The xTR receives an encapsulated packet (i.e., a data-plane message), and can use the outer/inner IP headers to get an RLOC/EID pair. The EID of this pair, in general, is some end system, not necessarily an ITR or router at all. The xTR is supposed to do verification by sending a Map-Request to this source EID, some arbitrary end-user system. This Map-Request is presumably not actually going to get *delivered* to the system identified by that EID, right? So is it better to say "sending to the ETR responsible for that EID" or something like that? > > Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and > > might benefit from an explicit section reference to the other document. > > Done. > > > > > Section 10 > > > > What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it > > is not marked as well-known at > > https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion is > > probably in order. > > It is defined in the xTR definition. Ah, sorry for missing it. > > Section 10.1 > > > > Note that "ITR" and "ETR" are relative terms here. Both devices MUST > > be implementing both ITR and ETR functionality for the echo nonce > > mechanism to operate. > > > > Perhaps they could be given actual names so as to disambiguate which steps > > are performed with ITR vs. ETR role? > > They are. An ITR is an encapsulator. An ETR is a decapsulator. This is defined in the definition section. When the functions are co-located, they refer to an xTR, also in the definition section. In the narrative, we say things like "[w]hen the ETR next sends a data packet to the ITR". On the face of it, this phrase is absurd -- by definition, an ITR is sending a data packet to an ETR, not the other way around. I know that in this example both are xTRs, but I feel pretty strongly that it does a disservice to the reader by attempting to use the role from the initial exchange as an identifier, as opposed to using a distinct identifier that does not come into conflict with a later role. > > The echo-nonce algorithm is bilateral. That is, if one side sets the > > E-bit and the other side is not enabled for echo-noncing, then the > > echoing of the nonce does not occur and the requesting side may > > erroneously consider the Locator unreachable. An ITR SHOULD only set > > the E-bit in an encapsulated data packet when it knows the ETR is > > enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- > > probe Map-Reply message. > > > > Why is this even optional? If it was mandatory to use, then there would > > not be a question. But at least clarify that the "this" that is conveyed > > is whether the peer supports the echo-nonce algorithm. (Also, subject to > > downgrade.) > > Because it has cost implications in a hardware implementation. > > > Section 18 > > > > o Data-Plane gleaning for creating map-cache entries has been made > > optional. If any ITR implementations depend or assume the remote > > ETR is gleaning should not do so. > > > > nit: this is ungrammatical; "they should not" or "Any ITR implementations > > that depend on or assume that" would fix it. > > Fixed. Thanks. > > > Section 19.1 > > > > Presumably IANA also updated the reference column to point to this > > document? > > Yes, from my perspective. It could be useful to document that in the RFC, though I don't feel particularly strongly about it. Thanks, Benjamin From nobody Fri Sep 28 17:24:44 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE21130DFC for ; Fri, 28 Sep 2018 17:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 lbcC3pypMZ16 for ; Fri, 28 Sep 2018 17:24:39 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90FB5127148 for ; Fri, 28 Sep 2018 17:24:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 404B61CCD22; Fri, 28 Sep 2018 17:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1538180679; bh=gTq9AJPK+U4kKCiYYBqByUJM5qdMGEzcvoZ8ytT7Mqc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VHhdjMqNhVxOLPZugy/XuERwRTA82MiY6d6gqB+AlJ0tTsCrlY7ss47nEGox4UQtx X4LoQeH0bddCOg5yA0QuGe2Oi5cJlV/4D9cYxC6rv4iEQaBPT2zMtn+sPPx+RNC6Q4 Cr/kwQamOFrkhrP5jCeozcjlHDILnsH995pqxgtU= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 8A60C1C041A; Fri, 28 Sep 2018 17:24:38 -0700 (PDT) To: Dino Farinacci Cc: "lisp@ietf.org" References: <20180928220340.GO24695@kduck.kaduk.org> <7924707d-e6c5-5080-7586-dcf1f96fed46@joelhalpern.com> From: Joel Halpern Direct Message-ID: Date: Fri, 28 Sep 2018 20:24:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Fwd: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 29 Sep 2018 00:24:43 -0000 I gave several positive choices to allow folks with nuances to express it. Some folks who are willing to have a chnage, will not call it desirable. Some folks who desire a change are unhappy if I label the choice "acceptable". SO I gave folks both choices. The difference will help me unerstand the sentiment better. Still of bunch of people say "desirable" that probably produces the same result as if bunch of people say "acceptable". Yours, Joel On 9/28/18 6:56 PM, Dino Farinacci wrote: > (a) Desirable, because more security is always more desirable. > > But the choices don’t seem to be comparable. Is “Desirable” more important or more mandatory than “Acceptable”? > > I would like better clarification what I’m voting for if I choose “acceptable” instead of “desirable”. > > Dino > >> On Sep 28, 2018, at 3:38 PM, Joel M. Halpern wrote: >> >> As co-chair, I would like to hear from the working group as to whether making LISP-SEC mandatory to Implement (not Mandatory to Use) for LISP6830bis and 6833bis implementations is >> a) desirable >> b) acceptable >> c) undesirable but livable >> d) unacceptable or worse. >> >> Please, do not just pick a letter. Include explanation of your opinion. >> This is not a decision the ADs and Authors can make for the working group. >> >> Yours, >> Joel >> >> >> -------- Forwarded Message -------- >> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) >> Date: Fri, 28 Sep 2018 17:03:40 -0500 >> From: Benjamin Kaduk >> To: Joel M. Halpern >> CC: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org >> >> Hi Joel, >> >> >> On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote: >>> Is there text we can add about the scoping that will change your discuss into a series of useful comments? >> >> I had attempted to structure my Discuss points so that they would either be >> useful comments as is, or rendered moot by a reduced scope. I guess I can >> try to clarify those below. (To be clear, reducing the scope is only going >> to move from "has potentially existentially bad problems" to "has >> substantial issues that likely require reengineering to resolve".) >> >>> If so, Some indication of how you would like that phrased would help us address these. >> >> I think Ekr's ballot position on 6833bis has a good summary of the >> architecture assumptions that the reduced scope allows us to make. >> In order to have the document be able to plausibly make those claims, it >> looks like we'd need to at least: >> (1) update the Abstract/Introduction to clarify that the EID namespace is >> only defined within a single administrative domain. >> (2) (optionally, if it makes sense) mention in the introduction that this >> administrative domain can include transport over other networks in the >> same way that a VPN would function[*], without requiring cooperation >> from or interaction with the other networks' administrators >> (3) remove the "global" text from the EID-to-RLOC Database and Map-Cache >> definitions >> (4) update the EID-Prefix definition to talk about the local site or >> administrative domain's "address allocation authority" >> (5) Take a look at the EID definition to consider whether references to "on >> the public Internet" are still valid, and the text about assignment >> in a hierarchical manner should be revised for the new scope as well. >> Likewise for EID-internal structure that is "not visible to the global >> routing system" >> >> (I stopped skimming and looking for problematic text around section 6) >> >> [*] Ideally this would be done without using the term "VPN" itself, since >> I'd like to get a movement going to restrict "VPN" to include >> confidentiality (i.e., privacy) protection. "virtual network" or "overlay >> network" may or may not be good candidate replacement terms. >> >>> If not, we seem to have a larger problem. >> >> Well, we appear to have five ADs that are supporting making LISP-SEC a >> normative reference and thus MTI; I don't know if that scale of change >> meets your threshold for a "larger problem". >> >>> Yours, >>> Joel >>> On 9/26/18 11:44 PM, Benjamin Kaduk wrote: >>>> Benjamin Kaduk has entered the following ballot position for >>>> draft-ietf-lisp-rfc6830bis-20: 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 https://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: >>>> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >>>>>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>>> I have grave concerns about the suitability of LISP as a whole, in its >>>> present form, for advancement to the Standards-Track. While some of my >>>> concerns are not specific to this document, as the core protocol >>>> (data-plane) spec, it seems an appropriate place to attach them to. >>>>> I am told, out of band, that the intended deployment model is no longer to >>>> cover the entire Internet (c.f. the MISSREF-state >>>> draft-ietf-lisp-introduction's "with LISP, the dge of the Internet and the >>>> core can be logically separated and interconnected by LISP-capable >>>> routers", etc.), and that full Internet-scale operation is no longer a >>>> goal. However, since that does not seem to be reflected in the current >>>> batch of documents up for IESG review, I am forced to ballot on them >>>> "as-is", namely as targetting global Internet deployment. The requirements >>>> placed on the mapping system are so stringent so as to be arguably >>>> unachievable at Internet-scale, though that arguably has more of an >>>> interaction with the control-plane than the data-plane. It's still in >>>> scope here, though, as part of the overall description of the protocol >>>> flow. >> >> (rendered moot by scope reduction) >> >>>> There are an almost innumerable number of downgrade attacks possible, and >>>> the control-plane and data-plane security mechanisms are not normative >>>> dependencies of the current corpus of documents, and as such are not up for >>>> consideration as mitigating the security concerns with the core documents. >> >> The downgrade attacks will probably require some further analysis; LISP-SEC >> would protect a lot of the header bits but I think there may be some other >> data flows to be looked at. >> >>>> Section 3 defines the EID-to-RLOC Datbaase: >>>>> EID-to-RLOC Database: The EID-to-RLOC Database is a global >>>> distributed database that contains all known EID-Prefix-to-RLOC >>>> mappings. Each potential ETR typically contains a small piece of >>>> the database: the EID-to-RLOC mappings for the EID-Prefixes >>>> "behind" the router. These map to one of the router's own >>>> globally visible IP addresses. Note that there MAY be transient >>>> conditions when the EID-Prefix for the site and Locator-Set for >>>> each EID-Prefix may not be the same on all ETRs. This has no >>>> negative implications, since a partial set of Locators can be >>>> used. >>>>> No compelling architecture for a trustworthy global distributed database >>>> has been presented that I've seen so far, and LISP relies heavily on the >>>> mapping system's database for its functionality. I am concerned that so >>>> many requirements are placed on the mapping system so as to be in effect >>>> unimplementable, in which case it would seem that the architecture as a >>>> whole (that is, for a global Internet-scale system) is not fit for purpose. >> >> (rendered moot by scope reduction) >> >>>> Section 4.1's Step (6) only mentions parsing "to check for format >>>> validity". I think it is appropriate to mention (and refer to) source >>>> authentication checks as well, since bad Map-Reply data can allow all sorts >>>> of attacks to occur. >> >> (not affected by scope reduction) >> >>>> There are some fairly subtle ordering requirements between the order of >>>> entries in Map-Reply messages and the Locator-Status-Bits in data-plane >>>> traffic (so that the semantic meaning of the status bits are meaningful), >>>> which is only given a minimal treatment in the control-plane document. The >>>> need for synchronization in interpreting these bits should be mentioned >>>> more prominently in the data-plane document as well. >> >> (not affected by scope reduction) >> >>>>> The usage of the Instance ID does not seem to be adequately covered; from >>>> what I've been able to pick up so far it seems that both source and >>>> destination participants must agree on the meaning of an Instance ID, and >>>> the source and destination EIDs must be in the same Instance. This does >>>> not seem like it is compatible with Internet scale, especially if there are >>>> only 24 usable bits of Instance ID. >> >> (not affected by scope reduction) >> >>>>> There seems to be a lot of intra-site synchronization requirements, notably >>>> with respect to Map-Version consistency, the contents and ordering of >>>> locator sets for EIDs in the site, etc.; the actual hard requirements for >>>> synchronization within a site should be clearly called out, ideally in a >>>> single location. >> >> (not affected by scope reduction, since ETRs are affected and not just >> Map-Servers) >> >>>>> The security considerations attempt to defer substantially to the >>>> threat-analysis in RFC 7835, which does not really seem like a complete >>>> threat analysis and does not provide analysis as to what requirements are >>>> placed on the boundaries between the different components of LISP (data >>>> plane, control plane, mapping system, various extensions, etc.). The >>>> secdir reviewer had some good thoughts in this space. >> >> (not affected by scope reduction) >> >>>>> The security considerations throughout the LISP documents place a heavy >>>> focus on the risk of over-claiming for routing EID-prefixes. This is a >>>> real concern, to be clear, but it should not overshadow the risk of an >>>> attacker who is able to move traffic around at will, strip security >>>> protections, cause denial of service, alter data-plane payloads, etc. >>>> Similarly, this document's security considerations call out denial of >>>> service as a risk from Map-Cache insertion/spoofing, but the risks from an >>>> attacker being able to read and modify the traffic, perhaps even without >>>> detection, seems a much greater threat to me. >> >> (not affected by scope reduction) >> >>>>> I am not convinced that this protocol meets the current IETF requirements >>>> for the security properties of Standards-Track Protocols without at least >>>> LISP-SEC as a mandatory-to-implement component, and possibly additional or >>>> stronger requirements. (I did not do a full analysis of the system in the >>>> presence of those security mechanisms, since that is not what is being >>>> presented for review.) >> >> (noting that LISP-SEC needs to be MTI and analysis performed under the new >> assumptions) >> >>>> Having an EID that is associated to user-correlatable devices has severe >>>> privacy considerations, but I could not find this mentioned anywhere in all >>>> of the LISP documents I've read so far. >> >> (not affected by scope reduction) >> >> -Benjamin >> >>>>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>>> I apologize for the somewhat scattered nature of these comments; there are >>>> a lot of them and I was focusing my time more on trying to understand the >>>> broader system, and the intended security posture, so they did not get as >>>> much clean-up as I would have liked. (Most of my review was performed on the >>>> -18, though I have tried to update to the -20 as relevant.) >>>>>> The instance ID provides for organizational correlation, another privacy >>>> exposure. >>>>> Is there anything different between an "EID-to-RLOC Map-Request" and just a >>>> "Map-Request"? (Same question for "Map-Reply", too.) >>>>> There's a lot of stuff that seems to work best if there is symmetric >>>> bidirectional traffic, with inline signalling of map version and >>>> reachability changes, though clearly everything is designed to also work >>>> with asymmetric connectivity or unidirectional traffic. It would be nice >>>> to have a high-level summary in or near the introduction about what kinds >>>> of behavior/performance differences are expected for bidirectional vs. >>>> unidirectional traffic. >>>>> Section 2 >>>>> That's not the 8174 boilerplate; it's more than just adding a cite to the >>>> 2119 boilerplate. >>>>> Section 3 >>>>> nit: "An address family that pertains to the Data-Plane." is a sentence >>>> fragment. >>>>> Ingress Tunnel Router (ITR): An ITR is a router that resides in a >>>> [...] >>>> mapping lookup in the destination address field. Note that this >>>> destination RLOC MAY be an intermediate, proxy device that has >>>> better knowledge of the EID-to-RLOC mapping closer to the >>>>> This doesn't seem like a 2119 MAY is necessary, but rather a statement of >>>> fact that may not be known to the encapsulating ITR. >>>>> Specifically, when a service provider prepends a LISP header for >>>> Traffic Engineering purposes, the router that does this is also >>>> regarded as an ITR. The outer RLOC the ISP ITR uses can be based >>>> on the outer destination address (the originating ITR's supplied >>>> RLOC) or the inner destination address (the originating host's >>>> supplied EID). >>>>> I'm confused here, perhaps in multiple ways. Are there now *two* LISP >>>> headers on the packet? Is the "outer RLOC the ISP ITR uses" the source >>>> RLOC or the destination RLOC? >>>>> Negative Mapping Entry: A negative mapping entry, also known as a >>>> negative cache entry, is an EID-to-RLOC entry where an EID-Prefix >>>> is advertised or stored with no RLOCs. That is, the Locator-Set >>>> for the EID-to-RLOC entry is empty or has an encoded Locator count >>>> of 0. >>>>> Is "empty" a distinct representation from "locator count of zero"? >>>>> Perhaps something of an aside, but the check described for >>>> Route-Returnability is a somewhat weak check, and in some cases could still >>>> be spoofed. (I don't expect this to surprise anyone, of course, but >>>> perhaps some more qualifiers could be added to the text.) >>>>> Section 4 >>>>> An additional LISP header MAY be prepended to packets by a TE-ITR >>>> when re-routing of the path for a packet is desired. A potential >>>> use-case for this would be an ISP router that needs to perform >>>> Traffic Engineering for packets flowing through its network. In such >>>> a situation, termed "Recursive Tunneling", an ISP transit acts as an >>>> additional ITR, and the RLOC it uses for the new prepended header >>>> would be either a TE-ETR within the ISP (along an intra-ISP traffic >>>> engineered path) or a TE-ETR within another ISP (an inter-ISP traffic >>>> engineered path, where an agreement to build such a path exists). >>>>> "the RLOC it uses for the new prepnded header", again, this is as the >>>> destination RLOC (vs. source RLOC)? >>>>> Section 4.1 >>>>> o Map-Replies are sent on the underlying routing system topology >>>> using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. >>>>> Just to check my understanding: is the "underlying routing system topology" >>>> the same as the "underlay"? >>>>> Is step (3) just describing more of what step (2) says is "not described in >>>> this example"? >>>>> Section 5.3 >>>>> The word "nonce" is normally used for something used exactly once. >>>> E.g., with some AEAD algorithms, if the same "nonce" input is used for >>>> different encryptions, the entire security of the system is compromised. >>>> It would be better to refer to this field with a different term, given >>>> that "the same nonce can be used for a period of time when encapsulating to >>>> the same ETR". "Uniquifier" or "random value" might be reasonable choices. >>>>> Why is there no discussion of the Map-Version or Instance-ID fields >>>> in this section? >>>>> When doing ETR/PETR decapsulation: >>>>> o The inner-header 'Time to Live' field (or 'Hop Limit' field, in >>>> the case of IPv6) SHOULD be copied from the outer-header 'Time to >>>> Live' field, when the Time to Live value of the outer header is >>>> less than the Time to Live value of the inner header. Failing to >>>> perform this check can cause the Time to Live of the inner header >>>> to increment across encapsulation/decapsulation cycles. This >>>> check is also performed when doing initial encapsulation, when a >>>> packet comes to an ITR or PITR destined for a LISP site. >>>>> Er, what is "this check" that is also performed for initial encapsulation? >>>> How are there multiple TTL values to compare? >>>>> o The inner-header 'Differentiated Services Code Point' (DSCP) field >>>> (or the 'Traffic Class' field, in the case of IPv6) SHOULD be >>>> copied from the outer-header DSCP field ('Traffic Class' field, in >>>> the case of IPv6) to the inner-header. >>>>> nit: the first "inner-header" seems like an editing remnant? >>>>> Section 7.1 >>>>> How is this stateless if it invovles knowledge about the routers between >>>> the ITR and all possible ETRs (i.e., a set that could change over time)? >>>>> Section 8 >>>>> This 32-bit vs 24-bit thing is pretty hokey for a standards-track >>>> specification (yes, I know that LISP-DDT is not standards track at the >>>> moment). >>>>> Section 9 >>>>> Alternatively, RLOC information MAY be gleaned from received tunneled >>>>> What is this an alternative to? The list of four options above? >>>>> packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache >>>> entry, one learned from the source RLOC of a received encapsulated >>>> packet, is only stored and used for a few seconds, pending >>>> verification. Verification is performed by sending a Map-Request to >>>> the source EID (the inner-header IP source address) of the received >>>> encapsulated packet. >>>>> The source EID is some random end system, right? So this relys on some >>>> magic in the ETR to detect that there's a Map-Request and reply directly >>>> instead of passing it on to the EID that won't know what to do with it? >>>>> Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and >>>> might benefit from an explicit section reference to the other document. >>>>> Section 10 >>>>> What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it >>>> is not marked as well-known at >>>> https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion is >>>> probably in order. >>>>> Again, when we are talking about the internal structure of the Map-Reply, a >>>> detailed section refernce to 6833bis is useful. >>>>> Modifying LSBs seems like a fine DoS attack vector for an on-path attacker. >>>>> value of 1. Locator-Status-Bits are associated with a Locator-Set >>>> per EID-Prefix. Therefore, when a Locator becomes unreachable, the >>>> Locator-Status-Bit that corresponds to that Locator's position in the >>>> list returned by the last Map-Reply will be set to zero for that >>>> particular EID-Prefix >>>>> Doesn't this imply a stateful relationship between the ordering of >>>> Map-Replys and data-plane traffic? >>>>> Section 10.1 >>>>> Note that "ITR" and "ETR" are relative terms here. Both devices MUST >>>> be implementing both ITR and ETR functionality for the echo nonce >>>> mechanism to operate. >>>>> Perhaps they could be given actual names so as to disambiguate which steps >>>> are performed with ITR vs. ETR role? >>>>> The echo-nonce algorithm is bilateral. That is, if one side sets the >>>> E-bit and the other side is not enabled for echo-noncing, then the >>>> echoing of the nonce does not occur and the requesting side may >>>> erroneously consider the Locator unreachable. An ITR SHOULD only set >>>> the E-bit in an encapsulated data packet when it knows the ETR is >>>> enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- >>>> probe Map-Reply message. >>>>> Why is this even optional? If it was mandatory to use, then there would >>>> not be a question. But at least clarify that the "this" that is conveyed >>>> is whether the peer supports the echo-nonce algorithm. (Also, subject to >>>> downgrade.) >>>>> Section 13 >>>>> When a Locator record is removed from a Locator-Set, ITRs that have >>>> the mapping cached will not use the removed Locator because the xTRs >>>> will set the Locator-Status-Bit to 0. So, even if the Locator is in >>>> the list, it will not be used. For new mapping requests, the xTRs >>>> can set the Locator AFI to 0 (indicating an unspecified address), as >>>> well as setting the corresponding Locator-Status-Bit to 0. This >>>> forces ITRs with old or new mappings to avoid using the removed >>>> Locator. >>>>> The behavior describe here seems like it would be better described as "when >>>> a Locator is taken out of service" than "removed from a Locator-Set", since >>>> if it is not in the set at all, it has no index, and no LSB or AFI to set. >>>> Should actually depopulating it like this be forbidden? >>>>> I guess the Map Versioning is supposed to help with this, but we need to >>>> nail down the semantics more and/or give a clearer reference to it. >>>>> Section 13.1 >>>>> An ITR, when it encapsulates packets to ETRs, can convey its own Map- >>>> Version Number. This is known as the Source Map-Version Number. >>>>> Replacing "its own Map-Version Number" with something like "the Map-Version >>>> numer for the LISP site of which it is a part". Writing this causes me to >>>> note that the semantics of the Map-Version are unclear, here -- what is it >>>> scoped to? An EID-Prefix? An RLOC? Oh, you say that in the next >>>> paragraph (EID-Prefix). >>>>> A Map-Version Number can be included in Map-Register messages as >>>> well. This is a good way for the Map-Server to assure that all ETRs >>>> for a site registering to it will be synchronized according to Map- >>>> Version Number. >>>>> Huh? I must be confused how this works. (Also, wouldn't this be better in >>>> the control plane document which covers Map-Register?) >>>>> Section 15 >>>>> o When a tunnel-encapsulated packet is received by an ETR, the outer >>>> destination address may not be the address of the router. This >>>> makes it challenging for the control plane to get packets from the >>>> hardware. This may be mitigated by creating special Forwarding >>>> Information Base (FIB) entries for the EID-Prefixes of EIDs served >>>> by the ETR (those for which the router provides an RLOC >>>> translation). These FIB entries are marked with a flag indicating >>>> that Control-Plane processing SHOULD be performed. >>>>> I assume this is just my lack of background showing, but I'm confused how >>>> it makes sense to mark these for control-plane processing. Isn't the >>>> control plane much slower, and we're not putting all of the LISP data-plane >>>> traffic onto the slow path? >>>>> Section 18 >>>>> o Data-Plane gleaning for creating map-cache entries has been made >>>> optional. If any ITR implementations depend or assume the remote >>>> ETR is gleaning should not do so. >>>>> nit: this is ungrammatical; "they should not" or "Any ITR implementations >>>> that depend on or assume that" would fix it. >>>>> Section 19.1 >>>>> Presumably IANA also updated the reference column to point to this >>>> document? >>>>>> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > From nobody Sat Sep 29 09:30:47 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721C2130E37; Sat, 29 Sep 2018 09:30:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HiL4r14jX6Hq; Sat, 29 Sep 2018 09:30:34 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 9276E128C65; Sat, 29 Sep 2018 09:30:34 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id l9-v6so6309384pff.9; Sat, 29 Sep 2018 09:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/HU3qrTDbgjIUUpTw8K0izCJ5NPjj3FzXag2gtaGWpU=; b=Kx+aOToBAYXcBKlPCEvIvuXSdzf2cMUOtvLrGIzVpDjvsa72Xz0eYuwn/F4Mhghskz q8JmHdKboNWZv/TiSbqkMRFylFZgsQAch+8/Wj2DiowZRbICaJVTRWdSvQT04+zjVNKY YF/ek5816LSUlmhocZFnDq43LLuFdiEqCeyyXQXaCoj+7OxoMLw+rcwtDZtYnyo46fA9 Zlcq05e2OW6g7mDocGurG+ayjG/e+T/XBTJIxX3bFc367as4FR3IuICBXJs6kXzOc5md hd+dYsWEbJDFGhXLj3UOyI9NIIUaZ3HdGVcyIJgXI9+KuIvJTdgCEAg9dfSdgWqEvr+8 aVxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/HU3qrTDbgjIUUpTw8K0izCJ5NPjj3FzXag2gtaGWpU=; b=F38XtNbrAFQKOI800dn1gNV2/5Z77pfsHwzdtreMDms7/m5B9j7KGNZDIntV3hP5XO v0KddAT30j0XDscwU5N++Pj8TRiT8zAlLIuZ5q+7XDgrbi6FJBdNUHGxPS5RXl5ndgK9 WlUe9jCMc2akJJ4eDw0OP0b6ULHSpOjJdmpiDRI5jKi4YsdO3eUdGMaG/5Jhrg7GQIZN G66ohQtOzmS1EwgksL089FawnmKq6lvhbJFJvAdOuVuk0kMugEizOLsMO2X/L+t+ZFgv JF0NT5wKSAFWAmuZpYhkp4s01xUug3Tr3Q5mBd1xPH3aYlH4ILBwOgSytH3PSYPZiOhn zyqw== X-Gm-Message-State: ABuFfoiXO0hKRJukB44QS4lEi9GlEYftf/Z8OjHy0tU76aeLBcAl8yRO lIOcm0VXZJxfRL8sncy4NKQ= X-Google-Smtp-Source: ACcGV62ADfxO57O8G5buqWRF8efji4wQb3ehL/87cEBQvSf33t2UzEJrVyWqWfNaEzWJtKPZhtVksg== X-Received: by 2002:a62:9fc4:: with SMTP id v65-v6mr3738283pfk.130.1538238633906; Sat, 29 Sep 2018 09:30:33 -0700 (PDT) Received: from [10.31.79.57] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id c79-v6sm7164728pfc.92.2018.09.29.09.30.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Sep 2018 09:30:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> Date: Sat, 29 Sep 2018 09:30:32 -0700 Cc: The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 29 Sep 2018 16:30:38 -0000 Thanks Eric for your great comments. Like I said in previous emails, = I=E2=80=99ll address the simple things here and then handle all the = security related stuff separately next week. I will do the same with Benjamin=E2=80=99s comments as well. And in his = reply, send a diff with changes that reflect both Eric and Benjamin=E2=80=99= s comments. > On Sep 27, 2018, at 5:16 AM, Eric Rescorla wrote: >=20 > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D4115 >=20 >=20 > IMPORTANT > S 5.2. >> s: This is the SMR-invoked bit. This bit is set to 1 when an xTR = is >> sending a Map-Request in response to a received SMR-based Map- >> Request. >>=20 >> m: This is the LISP mobile-node m-bit. This bit is set by xTRs = that >> operate as a mobile node as defined in [I-D.ietf-lisp-mn]. >=20 > This would appear to create a normative reference to this document. To > avoid that, you need to specify how I behave if I receive it but I > don't implement lisp-mn. I am find making it a normative reference but need the lisp-chairs to = comment. I am not sure what the implications of that are. >=20 > S 5.2. >> m: This is the LISP mobile-node m-bit. This bit is set by xTRs = that >> operate as a mobile node as defined in [I-D.ietf-lisp-mn]. >>=20 >> I: This is the xTR-ID bit. When this bit is set, what is = appended to >> the Map-Request is a 128-bit xTR router-ID. See LISP PubSub = usage >> procedures in [I-D.ietf-lisp-pubsub] for details. >=20 > here too you seem to be creating a normative reference. LISP-chairs? > S 5.5. >> is being mapped from a multicast destination EID. >>=20 >> 5.5. EID-to-RLOC UDP Map-Reply Message >>=20 >> A Map-Reply returns an EID-Prefix with a prefix length that is = less >> than or equal to the EID being requested. The EID being = requested is >=20 > How do I behave if I receive an EID-Prefix that is less than any of my > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16 > and someone asks me for 10.0.0.0/8? Also, when you talk about prefix > length, I assume you mean the length fo the mask? Yes, this is explained later in this section. Was that not helpful?? > S 5.6. >> Authentication Data: This is the message digest used from the = output >> of the MAC algorithm. The entire Map-Register payload is >> authenticated with this field preset to 0. After the MAC is >> computed, it is placed in this field. Implementations of this >> specification MUST include support for HMAC-SHA-1-96 = [RFC2404], >> and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. >=20 > What prevents replay attacks here? I'm guessing it's the Map-Version- > Number, but as I understand it, I can set this to 0. Well there are many. The nonce can change for each Map-Register sent. = Same for Map-Version number as well as the key-id.=20 > S 6.1. >> receives an SMR-based Map-Request and the source is not in the >> Locator-Set for the stored Map-Cache entry, then the responding = Map- >> Request MUST be sent with an EID destination to the mapping = database >> system. Since the mapping database system is a more secure way = to >> reach an authoritative ETR, it will deliver the Map-Request to = the >> authoritative source of the mapping data. >=20 > If I'm understanding this correctly, this allows an ETR to prevent an > ITR from learning that it is no longer the appropriate ETR for a > prefix. The way this attack works is that before the topology shift, I > send SMRs, thus causing Map-Requests, which, because my entry is > cached, refresh the cache on the ITR past the topology shift. I can > keep doing this indefinitely. Am I missing something Well if the ETR is being spoofed, then there is Map-Request load, but it = won=E2=80=99t corrupt the ITR=E2=80=99s map-cache. The ITR always sends = a verifying Map-Request to the mapping system to get the latest and = authenticated RLOC-set for the mapping. Rate-limiting is necessary so = each SMR received DOES NOT result in a Map-Requerst to the mapping = system. > S 8.2. >> authentication data, so prior to sending a Map-Register message, = the >> ETR and Map-Server SHOULD be configured with a shared secret or = other >> relevant authentication information. A Map-Server's = configuration >> SHOULD also include a list of the EID-Prefixes for which each ETR = is >> authoritative. Upon receipt of a Map-Register from an ETR, a = Map- >> Server accepts only EID-Prefixes that are configured for that = ETR. >=20 > How does it know? It is provisioned by the mapping service provider (MSP). When the LISP = site is allocated an EID-prefix, it configures all the xTRs that connect = that site. And then the LISP site (the admins at the site), shop for an = MSP and tell them what EID-prefixes, they will be registering. That is = when the shared-key between the LISP site and MSP is exchanged via a = manul out-of-band business process. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > S 5. >> \ | UDP Length | UDP Checksum = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | = | >> | LISP Message = | >> | = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > What do these two diagrams correspond to? v4 and v6? This needs > explanation. It is th entire IP packet sent as a LISP control-message. The header = before the diagrams indicate they are UDP packets. > S 5.2. >> Type: 1 (Map-Request) >>=20 >> A: This is an authoritative bit, which is set to 0 for UDP-based = Map- >> Requests sent by an ITR. It is set to 1 when an ITR wants the >> destination site to return the Map-Reply rather than the = mapping >> database system. >=20 > I don't understand this sentence, as literally it would say that you > should not return "the mapping database system" but that doesn't make > any sense. This was already fixed in a later revision. Now says: A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. It is set to 1 when an ITR wants the destination site to return the Map-Reply rather than the mapping database system returning a Map-Reply. >=20 > S 5.2. >> P: This is the probe-bit, which indicates that a Map-Request = SHOULD >> be treated as a Locator reachability probe. The receiver = SHOULD >> respond with a Map-Reply with the probe-bit set, indicating = that >> the Map-Reply is a Locator reachability probe reply, with the >> nonce copied from the Map-Request. See RLOC-Probing Section = 7.1 >> for more details. >=20 > How am I supposed to handle this if I am a Map Server. It should be ignored. I will add text to reflect this point. Good point. >=20 > S 5.2. >> receipt. >>=20 >> L: This is the local-xtr bit. It is used by an xTR in a LISP = site to >> tell other xTRs in the same site that it is part of the = RLOC-set >> for the LISP site. The L-bit is set to 1 when the RLOC is the >> sender's IP address. >=20 > Is the xTR supposed to filter this on exiting the site. Nope. >=20 > S 5.2. >>=20 >> Nonce: This is an 8-octet random value created by the sender of = the >> Map-Request. This nonce will be returned in the Map-Reply. = The >> security of the LISP mapping protocol critically depends on = the >> strength of the nonce in the Map-Request message. The nonce >> SHOULD be generated by a properly seeded pseudo-random (or = strong >=20 > This seems like it needs to be a MUST. Yes, I agree. I cannot remember why we made it a SHOULD. >=20 > S 5.3. >> originating Map-Request source. If the RLOC is not in the = Locator- >> Set, then the ETR MUST send the "verifying Map-Request" to the >> "piggybacked" EID. Doing this forces the "verifying Map-Request" = to >> go through the mapping database system to reach the authoritative >> source of information about that EID, guarding against = RLOC-spoofing >> in the "piggybacked" mapping data. >=20 > This text here doesn't seem compatible with either of the two cases > listed in "EID-prefix" above. I don=E2=80=99t understand the comment Eric. Maybe because I can=E2=80=99t= find the exact reference to EID-prefix where you think there is a = conflict. Please cite for me. Thanks. >=20 > S 5.4. >>=20 >> Nonce: This is a 24-bit value set in a Data-Probe >> [I-D.ietf-lisp-rfc6830bis] or a 64-bit value from the = Map-Request >> is echoed in this 'Nonce' field of the Map-Reply. When a = 24-bit >> value is supplied, it resides in the low-order 64 bits of the >> 'Nonce' field. >=20 > Nit: a 64-bit quantity doesn't really have low-order bits if it's not > numeric. Do you mean "rightmost"? Also, what are the other bits. Really good point. I=E2=80=99ll fix. >=20 >=20 > S 5.4. >> 'Nonce' field. >>=20 >> Record TTL: This is the time in minutes the recipient of the = Map- >> Reply will store the mapping. If the TTL is 0, the entry MUST = be >> removed from the cache immediately. If the value is = 0xffffffff, >> the recipient can decide locally how long to store the = mapping. >=20 > Am I supposed to merge this with previous mappings? REmove them? No replace it. There is text that says this that is not in the packet = format description section. > S 8.3. >> of the mapping database protocols. >>=20 >> 8.3. Map-Server Processing >>=20 >> Once a Map-Server has EID-Prefixes registered by its client ETRs, = it >> can accept and process Map-Requests for them. >=20 > This section is confusing because the introduction says that this > function is only performed by Map-Resolvers: > ' > "The LISP Mapping Service defines two new types of LISP-speaking > devices: the Map-Resolver, which accepts Map-Requests from an > Ingress > Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a > mapping database; and the Map-Server, which learns authoritative > EID- > to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes > them in a database.=E2=80=9D The document does cover the operation of a Map-Resolver and a = Map-Server. Some functions are performed only by Map-Resolvers only and = other different functions are performed by Map-Servers only. I am not sure what you don=E2=80=99t understand. Thanks, Dino From nobody Sat Sep 29 09:46:42 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDB8130E3E; Sat, 29 Sep 2018 09:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yQ1-sztU_6_e; Sat, 29 Sep 2018 09:46:36 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 3AB10130E35; Sat, 29 Sep 2018 09:46:36 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id x17-v6so6346067pfh.5; Sat, 29 Sep 2018 09:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7xdIrRS7qmbS38/1RMrY4R7MPDflw11eVwsUBQ8PtTs=; b=U5+PXJZmfvipuSTz5pdc45aknYYncYtgkrfzmJ1VtT+c3CFmEiaangLmyus6L/YWgt qZDl/1OWvLutZ56KypUCO7Qg82N1P5GaYMBiBv3kHIC0Xeby+8/Zm8EQdrg3Ch9imJit Bn+kmd4bwM0nQ8xb0nVB6OcyLbEWMsiaqseUfBCW7Fl4WqiRMDWuNzm56WrlPkU9sU9/ Tu6TibPbXpcokWabs+C7Gs58VxCUvp2TCnikjCyTyqXzagExxuejVEA3RQuB4ca7BMw5 BAnYQqZLa6Xhr+8FDlHVF88N/O5J3YNEPo6iowaMd3LcungTXDmgxuOOGtfLq0ypL2cX Mq/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7xdIrRS7qmbS38/1RMrY4R7MPDflw11eVwsUBQ8PtTs=; b=uIkYPFdvLXrqYyKfOWvcJorzUOiK3+AkraStAXRrBRO7m3UBYyH6aYZMXcCRULdWOu 2MJ9zgOlsuQ4cqFs2OYpQNf9kpQ/LY+Xc8YgbdgsiYRCziX3SeXT7gT6FwkVDYlcQUDS rhL7bgjKqmF1I/+jlAPZeGkIEld7fNRc3l6CeGA0FH/3Sdqr1xzE5CtxlQ9SwpDR1MO3 4AqYGbGSESwojnObU9XL70kb3+B+9Ypze2uBWgtEC844nPJbZE379g39ow7o8NqP8EMk IZ5BE5yWymadx2YkQQmy7A+bsTeVu+g9bVFo73hABVnNqhOJBbUx3b3fv3LZTqRvX9jC Yc0g== X-Gm-Message-State: ABuFfojPlcf1zkfxtpknIMh4buBdKWl0xQEjoZm6CtjqF9ZTvxFrs6LX CZQD00xFk4GdMcoU9E1uFcU= X-Google-Smtp-Source: ACcGV60qG4NsZq0Ng20HJV2rk/NCbgY08SnYb10ReBOjEExGrIvZ+rpZD6Flr8glZoRkFwaWlQ7OvA== X-Received: by 2002:a17:902:8644:: with SMTP id y4-v6mr3962500plt.48.1538239595597; Sat, 29 Sep 2018 09:46:35 -0700 (PDT) Received: from [10.31.79.57] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id a90-v6sm11208138pfg.106.2018.09.29.09.46.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Sep 2018 09:46:34 -0700 (PDT) From: Dino Farinacci Message-Id: <60C8D83B-E5DB-4ADC-96E3-CC1DD6B8F434@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_A4FFBF8C-14C1-4C59-B904-F37CEFD956C6" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 29 Sep 2018 09:46:32 -0700 In-Reply-To: <20180928232420.GP24695@kduck.kaduk.org> Cc: The IESG , lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, lisp@ietf.org To: Benjamin Kaduk References: <153801986490.21574.14435994195001767765.idtracker@ietfa.amsl.com> <20180928232420.GP24695@kduck.kaduk.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 29 Sep 2018 16:46:42 -0000 --Apple-Mail=_A4FFBF8C-14C1-4C59-B904-F37CEFD956C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 New diff file enclosed for revisions to -21 of 6830bis. > On Sep 28, 2018, at 4:24 PM, Benjamin Kaduk wrote: >=20 > Okay. I don't know if "Probe Map-Request" and plain "Map-Request" = would > help the reader or not (I did find myself wondering the original = question > while reading, of course). We use the term RLOC-Probe Map-Requests in many places in the document. >=20 >>> headers on the packet? Is the "outer RLOC the ISP ITR uses" the = source >>> RLOC or the destination RLOC? >>=20 >> No, just one. When referring to =E2=80=9Cinner=E2=80=9D and = =E2=80=9Couter=E2=80=9D, we mean IP headers. >=20 > Okay, so the ITR is picking an "outer RLOC" based on either the "outer > destination address" or the "inner destination address". My original The inner destination address is the EID. The EID is looked up in its = local map-cache to get an RLOC-set. A RLOC is selected from the = RLOC-set. The selected RLOC address is the destination address in the = outer header. > reading is that the "outer RLOC" being picked is the same thing as the > "outer destination address", which prompted me to think I was = confused. Is > it actually the outer source address that's being selected? It's = sounding > like I'm just not sure what field in the outer header the phrase = "outer RLOC" > is referring to. The outer source address is the ITR=E2=80=99s RLOC address since it is = building the outer header. >=20 >>> Is step (3) just describing more of what step (2) says is "not = described in >>> this example=E2=80=9D? >>=20 >> I lost your reference. Is it to the previous bulleted set or the one = starting with =E2=80=9CClient host1 =E2=80=A6=E2=80=9D? >=20 > The "Client host1" one. Basically, I'm thinking that sending a = Map-Request > (step 3) is a method of mapping the destination EID to an RLOC (step = 2). > Well, assuming a useful Map-Reply eventually shows up, I suppose. I think the text is clear. I still don=E2=80=99t know where and why you = are confused. >=20 >>>=20 >>> When doing ETR/PETR decapsulation: >>>=20 >>> o The inner-header 'Time to Live' field (or 'Hop Limit' field, in >>> the case of IPv6) SHOULD be copied from the outer-header 'Time = to >>> Live' field, when the Time to Live value of the outer header is >>> less than the Time to Live value of the inner header. Failing = to >>> perform this check can cause the Time to Live of the inner = header >>> to increment across encapsulation/decapsulation cycles. This >>> check is also performed when doing initial encapsulation, when a >>> packet comes to an ITR or PITR destined for a LISP site. >>>=20 >>> Er, what is "this check" that is also performed for initial = encapsulation? >>> How are there multiple TTL values to compare? >>=20 >> =E2=80=9CThis check=E2=80=9D is outer-header-TTL is < the = inner-header-TTL. >=20 > Ah, I see now that "this check" is both in "Failing to perform this = check" > and the start of the following sentence. In the first sentence of the > bullet point, though, it reads like "do X, if condition". The last > sentece is just saying "check condition" without an apparent "do X" > associated with it. So maybe it's better to say something about "when > performing initial encapsulation, the ITR or PITR must ensure that the > outer TTL is less than the inner TTL=E2=80=9D. Will change. I want to keep the text the way it is because I want to = explain what would happen if a larger TTL is copied to the outer header. >>>=20 >>> Section 7.1 >>>=20 >>> How is this stateless if it invovles knowledge about the routers = between >>> the ITR and all possible ETRs (i.e., a set that could change over = time)? >>=20 >> The ITR does not keep state about underlay routers between it and the = ETR. >=20 > Ah, so this is basically a "computed once by the network = administrator, > then used as a configuration parameter" thing. Yes. >=20 >>> Section 8 >>>=20 >>> This 32-bit vs 24-bit thing is pretty hokey for a standards-track >>> specification (yes, I know that LISP-DDT is not standards track at = the >>> moment). >>=20 >> It is actually useful to allow more instance-IDs but not waste extra = bits in the encapsulation header. >>=20 >>> Section 9 >>>=20 >>> Alternatively, RLOC information MAY be gleaned from received = tunneled >>>=20 >>> What is this an alternative to? The list of four options above? >>=20 >> Doing a mapping system lookup to get an RLOC-set. >=20 > I'd suggest something like "Instead of using the Map-Cache or mapping > system, [...]", as I was very uncertain how "Alternatively" was = intended to > be interpreted. Changed. >=20 >>> packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache >>> entry, one learned from the source RLOC of a received encapsulated >>> packet, is only stored and used for a few seconds, pending >>> verification. Verification is performed by sending a Map-Request = to >>> the source EID (the inner-header IP source address) of the received >>> encapsulated packet. >>>=20 >>> The source EID is some random end system, right? So this relys on = some >>> magic in the ETR to detect that there's a Map-Request and reply = directly >>> instead of passing it on to the EID that won't know what to do with = it? >>=20 >> Not following your description. >=20 > The xTR receives an encapsulated packet (i.e., a data-plane message), = and > can use the outer/inner IP headers to get an RLOC/EID pair. The EID = of > this pair, in general, is some end system, not necessarily an ITR or > router at all. The xTR is supposed to do verification by sending a > Map-Request to this source EID, some arbitrary end-user system. This No, it sends a Map-Request FOR the source EID. But the Map-Request goes = to the mapping system (sent to a Map-Resolver). > Map-Request is presumably not actually going to get *delivered* to the > system identified by that EID, right? So is it better to say "sending = to Right. > the ETR responsible for that EID" or something like that? Right. >=20 >>> Section 10.1 >>>=20 >>> Note that "ITR" and "ETR" are relative terms here. Both devices = MUST >>> be implementing both ITR and ETR functionality for the echo nonce >>> mechanism to operate. >>>=20 >>> Perhaps they could be given actual names so as to disambiguate which = steps >>> are performed with ITR vs. ETR role? >>=20 >> They are. An ITR is an encapsulator. An ETR is a decapsulator. This = is defined in the definition section. When the functions are co-located, = they refer to an xTR, also in the definition section. >=20 > In the narrative, we say things like "[w]hen the ETR next sends a data > packet to the ITR". On the face of it, this phrase is absurd -- by > definition, an ITR is sending a data packet to an ETR, not the other = way Yes, you are right. Shoudl include =E2=80=9Cwhen an ETR is an xTR, = =E2=80=A6=E2=80=9D. I=E2=80=99ll change to make it more clear. Thanks, Dino --Apple-Mail=_A4FFBF8C-14C1-4C59-B904-F37CEFD956C6 Content-Disposition: attachment; filename=rfcdiff-6830bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6830bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6830bis-21.txt - = draft-ietf-lisp-rfc6830bis-22.txt=20 =20 =20 =20 =20 =20 =20 = = =
< draft-ietf-lisp-rfc6830bis-21.txt  =  draft-ietf-lisp-rfc6830bis-22.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = V. Fuller Internet-Draft = V. Fuller
Obsoletes: 6830 = (if approved) D. Meyer = Obsoletes: 6830 (if approved) = D. Meyer
Intended status: = Standards Track D. Lewis = Intended status: Standards Track = D. Lewis
Expires: March 31, 2019 = Cisco Systems Expires: April 2, 2019 = Cisco Systems
= A. Cabellos (Ed.) = A. Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= September 27, 2018 = September 29, 2018
=
= The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol = (LISP)
= draft-ietf-lisp-rfc6830bis-21 = = draft-ietf-lisp-rfc6830bis-22
=
Abstract = Abstract
=
This document = describes the Data-Plane protocol for the Locator/ID This document describes the Data-Plane protocol for = the Locator/ID
Separation = Protocol (LISP). LISP defines two namespaces, End-point = Separation Protocol (LISP). LISP defines = two namespaces, End-point
Identifiers = (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and = Routing Locators
(RLOCs) that = identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. = With this, LISP
effectively = separates control from data, and allows routers to create = effectively separates control from data, and = allows routers to create
overlay = networks. LISP-capable routers exchange encapsulated packets = overlay networks. LISP-capable routers = exchange encapsulated packets
according to = EID-to-RLOC mappings stored in a local Map-Cache. according to EID-to-RLOC mappings stored in a local = Map-Cache.
=
skipping to = change at = page 1, line 46 =C2=B6 = skipping to change at page 1, line 46 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on March 31, = 2019. This Internet-Draft will = expire on April 2, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 48 =C2=B6 = skipping to change at page 2, line 48 =C2=B6
10.1. Echo = Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 = 10.1. Echo Nonce Algorithm . . . . . . . = . . . . . . . . . . . 26
11. EID = Reachability within a LISP Site . . . . . . . . . . . . . 27 = 11. EID Reachability within a LISP Site . . = . . . . . . . . . . . 27
12. Routing = Locator Hashing . . . . . . . . . . . . . . . . . . . 28 = 12. Routing Locator Hashing . . . . . . . . = . . . . . . . . . . . 28
13. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 29 = 13. Changing the Contents of EID-to-RLOC = Mappings . . . . . . . . 29
13.1. = Database Map-Versioning . . . . . . . . . . . . . . . . 30 = 13.1. Database Map-Versioning . . . . . = . . . . . . . . . . . 30
14. Multicast = Considerations . . . . . . . . . . . . . . . . . . 31 = 14. Multicast Considerations . . . . . . . = . . . . . . . . . . . 31
15. Router = Performance Considerations . . . . . . . . . . . . . . 31 = 15. Router Performance Considerations . . . = . . . . . . . . . . . 31
16. Security = Considerations . . . . . . . . . . . . . . . . . . . 32 = 16. Security Considerations . . . . . . . . = . . . . . . . . . . . 32
17. Network = Management Considerations . . . . . . . . . . . . . . 33 = 17. Network Management Considerations . . . = . . . . . . . . . . . 33
18. Changes = since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 = 18. Changes since RFC 6830 . . . . . . . . = . . . . . . . . . . . 33
19. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 33 19. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 34
19.1. LISP = UDP Port Numbers . . . . . . . . . . . . . . . . . 34 = 19.1. LISP UDP Port Numbers . . . . . . = . . . . . . . . . . . 34
20. References = . . . . . . . . . . . . . . . . . . . . . . . . . 34 20. References . . . . . . . . . . . . . . . . . . . = . . . . . . 34
20.1. = Normative References . . . . . . . . . . . . . . . . . . 34 = 20.1. Normative References . . . . . . . = . . . . . . . . . . . 34
20.2. = Informative References . . . . . . . . . . . . . . . . . 35 = 20.2. Informative References . . . . . . = . . . . . . . . . . . 35
=
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 39 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 39 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 39
B.1. = Changes to draft-ietf-lisp-rfc6830bis-21 = . . . . . . . . 40 B.1. = Changes to draft-ietf-lisp-rfc6830bis-22 = . . . . . . . . 40
B.2. = Changes to draft-ietf-lisp-rfc6830bis-20 = . . . . . . . . 40 B.2. = Changes to draft-ietf-lisp-rfc6830bis-21 = . . . . . . . . 40
B.3. = Changes to draft-ietf-lisp-rfc6830bis-19 = . . . . . . . . 40 B.3. = Changes to draft-ietf-lisp-rfc6830bis-20 = . . . . . . . . 40
B.4. = Changes to draft-ietf-lisp-rfc6830bis-18 = . . . . . . . . 40 B.4. = Changes to draft-ietf-lisp-rfc6830bis-19 = . . . . . . . . 40
B.5. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 40 B.5. = Changes to draft-ietf-lisp-rfc6830bis-18 = . . . . . . . . 40
B.6. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 40 B.6. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 40
B.7. = Changes to draft-ietf-lisp-rfc6830bis-15 = . . . . . . . . 40 B.7. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 40
B.8. = Changes to draft-ietf-lisp-rfc6830bis-14 = . . . . . . . . 41 B.8. = Changes to draft-ietf-lisp-rfc6830bis-15 = . . . . . . . . 41
B.9. = Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 41 B.9. = Changes to draft-ietf-lisp-rfc6830bis-14 = . . . . . . . . 41
B.10. = Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 41 B.10. = Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 41
B.11. = Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 41 B.11. = Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 41
B.12. = Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 41 B.12. = Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 41
B.13. = Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 42 = B.13. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . = 41
B.14. Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 42 B.14. Changes to = draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 42
B.15. Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 42
B.16. Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 42 B.16. Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 42
B.17. Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 43 B.17. Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 42
B.18. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 43 B.18. Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 43
B.19. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 43 B.19. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 43
B.20. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 43 B.20. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 43
B.21. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 43 B.21. Changes to = draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 43
B.22. Changes to = draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 44 B.22. Changes to = draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 44
= B.23. = Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 44
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 44
=
1. = Introduction 1. Introduction
=
This document = describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier = Separation Protocol
(LISP). LISP = is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built = around the
fundamental = idea of separating the topological location of a network = fundamental idea of separating the = topological location of a network
attachment = point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. = As a result
LISP creates = two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers = (EIDs), that are
used to = identify end-hosts (e.g., nodes or Virtual Machines) and = used to identify end-hosts (e.g., nodes or = Virtual Machines) and
=
skipping to = change at = page 24, line 35 =C2=B6 = skipping to change at page 24, line = 35 =C2=B6
= outer-header source RLOC of received packets. The client-side = ITR outer-header source RLOC of = received packets. The client-side ITR
controls = how traffic is returned and can alternate using an outer- = controls how traffic is returned and can = alternate using an outer-
header = source RLOC, which then can be added to the list the header source RLOC, which then can be added to the = list the
server-side = ETR uses to return traffic. Since no Priority or server-side ETR uses to return traffic. Since no = Priority or
Weights are = provided using this method, the server-side ETR MUST Weights are provided using this method, the = server-side ETR MUST
assume that = each client-side ITR RLOC uses the same best Priority assume that each client-side ITR RLOC uses the = same best Priority
with a = Weight of zero. In addition, since EID-Prefix encoding = with a Weight of zero. In addition, = since EID-Prefix encoding
cannot be = conveyed in data packets, the EID-to-RLOC Cache on cannot be conveyed in data packets, the = EID-to-RLOC Cache on
Tunnel = Routers can grow to be very large. = Tunnel Routers can grow to be very large.
=
Alternatively, RLOC information MAY be gleaned = from received tunneled Instead of using the Map-Cache or mapping = system, RLOC information
packets or = EID-to-RLOC Map-Request messages. A = "gleaned" Map-Cache MAY be gleaned = from received tunneled packets or EID-to-RLOC Map-
entry, one = learned from the source RLOC of a received encapsulated = Request = messages. A "gleaned" Map-Cache entry, one learned from the
packet, is = only stored and used for a few seconds, pending source RLOC of a received encapsulated packet, is = only stored and
= verification. Verification is performed by sending a Map-Request = to used for a few seconds, pending = verification. Verification is
the source = EID (the inner-header IP source address) = of the received performed by = sending a Map-Request to the source EID (the inner-
encapsulated = packet. A reply to this "verifying Map-Request" is used = header IP = source address) of the received encapsulated packet. A
to fully = populate the Map-Cache entry for the "gleaned" EID and is = reply to this "verifying Map-Request" is = used to fully populate the
stored and = used for the time indicated from the 'TTL' field of a Map-Cache entry for the "gleaned" EID and is stored = and used for the
received = Map-Reply. When a verified Map-Cache entry is stored, data = time indicated from the 'TTL' field of a = received Map-Reply. When a
gleaning no = longer occurs for subsequent packets that have a source = verified Map-Cache entry is stored, data = gleaning no longer occurs
EID that = matches the EID-Prefix of the verified = entry. This for subsequent = packets that have a source EID that matches the EID-
"gleaning" = mechanism is OPTIONAL, refer to Section 16 for security = Prefix of the = verified entry. This "gleaning" mechanism is OPTIONAL,
issues = regarding this mechanism. refer to = Section 16 for security issues regarding this mechanism.
=
RLOCs that = appear in EID-to-RLOC Map-Reply messages are assumed to be = RLOCs that appear in EID-to-RLOC Map-Reply = messages are assumed to be
reachable when = the R-bit [I-D.ietf-lisp-rfc6833bis] for the Locator reachable when the R-bit [I-D.ietf-lisp-rfc6833bis] = for the Locator
record is set = to 1. When the R-bit is set to 0, an ITR or PITR MUST record is set to 1. When the R-bit is set to 0, an = ITR or PITR MUST
NOT = encapsulate to the RLOC. Neither the information contained in = a NOT encapsulate to the RLOC. = Neither the information contained in a
Map-Reply nor = that stored in the mapping database system provides Map-Reply nor that stored in the mapping database = system provides
reachability = information for RLOCs. Note that reachability is not reachability information for RLOCs. Note that = reachability is not
part of the = mapping system and is determined using one or more of the = part of the mapping system and is determined = using one or more of the
Routing = Locator reachability algorithms described in the next Routing Locator reachability algorithms described in = the next
= section. section.
=
skipping to = change at = page 26, line 44 =C2=B6 = skipping to change at page 26, line = 44 =C2=B6
10.1. Echo Nonce = Algorithm 10.1. Echo Nonce = Algorithm
=
When data = flows bidirectionally between Locators from different When data flows bidirectionally between Locators from = different
sites, a = Data-Plane mechanism called "nonce echoing" can be used to = sites, a Data-Plane mechanism called "nonce = echoing" can be used to
determine = reachability between an ITR and ETR. When an ITR wants to = determine reachability between an ITR and = ETR. When an ITR wants to
solicit a = nonce echo, it sets the N- and E-bits and places a 24-bit = solicit a nonce echo, it sets the N- and = E-bits and places a 24-bit
nonce = [RFC4086] in the LISP header of the next encapsulated data = nonce [RFC4086] in the LISP header of the = next encapsulated data
= packet. packet.
=
When this = packet is received by the ETR, the encapsulated packet is = When this packet is received by the ETR, the = encapsulated packet is
forwarded as = normal. When the ETR next sends a data packet to the forwarded as normal. When the ETR is an xTR (co-located as an ITR),
ITR, it includes the nonce received earlier with = the N-bit set and it next sends a data packet to the ITR (when it is an xTR co-located
E-bit = cleared. The ITR sees this "echoed nonce" and knows that the = as an ETR), = it includes the nonce received earlier with the N-bit set
path to and = from the ETR is up. and E-bit = cleared. The ITR sees this "echoed nonce" and knows that
= the path to and from the ETR is up.
=
The ITR will = set the E-bit and N-bit for every packet it sends while = The ITR will set the E-bit and N-bit for = every packet it sends while
in the = echo-nonce-request state. The time the ITR waits to process = in the echo-nonce-request state. The time = the ITR waits to process
the echoed = nonce before it determines the path is unreachable is the echoed nonce before it determines the path is = unreachable is
variable and = is a choice left for the implementation. variable and is a choice left for the = implementation.
=
If the ITR is = receiving packets from the ETR but does not see the If the ITR is receiving packets from the ETR but does = not see the
nonce echoed = while being in the echo-nonce-request state, then the nonce echoed while being in the echo-nonce-request = state, then the
path to the = ETR is unreachable. This decision MAY be overridden by = path to the ETR is unreachable. This = decision MAY be overridden by
other Locator = reachability algorithms. Once the ITR determines that other Locator reachability algorithms. Once the ITR = determines that
=
skipping to = change at = page 28, line 36 =C2=B6 = skipping to change at page 28, line = 41 =C2=B6
= destination addresses only from the header are used to compute = destination addresses only from the = header are used to compute
the = hash. the hash.
=
2. Take the = hash value and divide it by the number of Locators 2. Take the hash value and divide it by the number = of Locators
stored in = the Locator-Set for the EID-to-RLOC mapping. stored in the Locator-Set for the EID-to-RLOC = mapping.
=
3. The = remainder will yield a value of 0 to "number of Locators = 3. The remainder will yield a value of 0 to = "number of Locators
minus 1". = Use the remainder to select the Locator in the minus 1". Use the remainder to select the = Locator in the
= Locator-Set. = Locator-Set.
=
= The specific hash = algorithm the ITR uses for load-sharing is out of
= scope for this = document and does not prevent interoperability.
= =
Note that when = a packet is LISP encapsulated, the source port number Note that when a packet is LISP encapsulated, the = source port number
in the outer = UDP header needs to be set. Selecting a hashed value in the outer UDP header needs to be set. Selecting a = hashed value
allows core = routers that are attached to Link Aggregation Groups allows core routers that are attached to Link = Aggregation Groups
(LAGs) to = load-split the encapsulated packets across member links of = (LAGs) to load-split the encapsulated = packets across member links of
such LAGs. = Otherwise, core routers would see a single flow, since such LAGs. Otherwise, core routers would see a = single flow, since
packets have a = source address of the ITR, for packets that are packets have a source address of the ITR, for packets = that are
originated by = different EIDs at the source site. A suggested setting = originated by different EIDs at the source = site. A suggested setting
for the source = port number computed by an ITR is a 5-tuple hash for the source port number computed by an ITR is a = 5-tuple hash
function on = the inner header, as described above. The source port function on the inner header, as described above. = The source port
SHOULD be the = same for all packets belonging to the same flow. SHOULD be the same for all packets belonging to the = same flow.
=
skipping to = change at = page 40, line 5 =C2=B6 = skipping to change at page 40, line 5 =C2=B6
The LISP = working group would like to give a special thanks to Jari = The LISP working group would like to give a = special thanks to Jari
Arkko, the = Internet Area AD at the time that the set of LISP Arkko, the Internet Area AD at the time that the set = of LISP
documents were = being prepared for IESG last call, and for his documents were being prepared for IESG last call, and = for his
meticulous = reviews and detailed commentaries on the 7 working group = meticulous reviews and detailed commentaries = on the 7 working group
last call = documents progressing toward standards-track RFCs. last call documents progressing toward = standards-track RFCs.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6830bis-21 = B.1. Changes to = draft-ietf-lisp-rfc6830bis-22
=
o Late-September 2018. o Posted early October = 2018.
=
= o Changes to = reflect comments post Telechat.
=
= B.2. Changes to = draft-ietf-lisp-rfc6830bis-21
=
= o Posted = late-September 2018.
=
o Changes to = reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th = Telechat.
=
B.2. Changes to = draft-ietf-lisp-rfc6830bis-20 B.3. Changes to = draft-ietf-lisp-rfc6830bis-20
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o Fix old = reference to RFC3168, changed to RFC6040. o Fix old reference to RFC3168, changed to = RFC6040.
=
B.3. Changes to = draft-ietf-lisp-rfc6830bis-19 B.4. Changes to = draft-ietf-lisp-rfc6830bis-19
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o More = editorial changes. o More = editorial changes.
=
B.4. Changes to = draft-ietf-lisp-rfc6830bis-18 B.5. Changes to = draft-ietf-lisp-rfc6830bis-18
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Secdir review (Mirja). o Changes to reflect comments from Secdir review = (Mirja).
=
B.5. Changes to = draft-ietf-lisp-rfc6830bis-17 B.6. Changes to = draft-ietf-lisp-rfc6830bis-17
=
o Posted = September 2018. o Posted September = 2018.
=
o Indicate in = the "Changes since RFC 6830" section why the document o Indicate in the "Changes since RFC 6830" section = why the document
has been = shortened in length. has been = shortened in length.
=
o Make = reference to RFC 8085 about UDP congestion control. o Make reference to RFC 8085 about UDP congestion = control.
=
o More = editorial changes from multiple IESG reviews. o More editorial changes from multiple IESG = reviews.
=
B.6. Changes to = draft-ietf-lisp-rfc6830bis-16 B.7. Changes to = draft-ietf-lisp-rfc6830bis-16
=
o Posted late = August 2018. o Posted late August = 2018.
=
o Distinguish = the message type names between ICMP for IPv4 and ICMP o Distinguish the message type names between ICMP = for IPv4 and ICMP
for IPv6 = for handling MTU issues. for = IPv6 for handling MTU issues.
=
B.7. Changes to = draft-ietf-lisp-rfc6830bis-15 B.8. Changes to = draft-ietf-lisp-rfc6830bis-15
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6830" so implementers are o Added section "Changes since RFC 6830" so = implementers are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.8. Changes to = draft-ietf-lisp-rfc6830bis-14 B.9. Changes to = draft-ietf-lisp-rfc6830bis-14
=
o Posted July = 2018 IETF week. o Posted July 2018 = IETF week.
=
o Put = obsolete of RFC 6830 in Intro section in addition to abstract. = o Put obsolete of RFC 6830 in Intro section = in addition to abstract.
=
B.9. Changes to = draft-ietf-lisp-rfc6830bis-13 B.10. Changes to = draft-ietf-lisp-rfc6830bis-13
=
o Posted = March IETF Week 2018. o Posted = March IETF Week 2018.
=
o Clarified = that a new nonce is required per RLOC. = o Clarified that a new nonce is required per RLOC.
=
o Removed = 'Clock Sweep' section. This text must be placed in a new = o Removed 'Clock Sweep' section. This text = must be placed in a new
OAM = document. OAM document.
=
o Some = references changed from normative to informative o Some references changed from normative to = informative
=
B.10. Changes to = draft-ietf-lisp-rfc6830bis-12 B.11. Changes to = draft-ietf-lisp-rfc6830bis-12
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status. o Fixed Luigi editorial comments to ready draft for = RFC status.
=
B.11. Changes to = draft-ietf-lisp-rfc6830bis-11 B.12. Changes to = draft-ietf-lisp-rfc6830bis-11
=
o Posted = March 2018. o Posted March = 2018.
=
o Removed = sections 16, 17 and 18 (Mobility, Deployment and o Removed sections 16, 17 and 18 (Mobility, = Deployment and
Traceroute = considerations). This text must be placed in a new OAM = Traceroute considerations). This text = must be placed in a new OAM
= document. document.
=
B.12. Changes to = draft-ietf-lisp-rfc6830bis-10 B.13. Changes to = draft-ietf-lisp-rfc6830bis-10
=
o Posted = March 2018. o Posted March = 2018.
=
o Updated = section 'Router Locator Selection' stating that the Data- = o Updated section 'Router Locator = Selection' stating that the Data-
Plane MUST = follow what's stored in the Map-Cache (priorities and Plane MUST follow what's stored in the Map-Cache = (priorities and
= weights). weights).
=
o Section = 'Routing Locator Reachability': Removed bullet point 2 o Section 'Routing Locator Reachability': Removed = bullet point 2
(ICMP = Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port = (ICMP Network/Host Unreachable),3 (hints = from BGP),4 (ICMP Port
= Unreachable),5 (receive a Map-Reply as a response) and RLOC = Unreachable),5 (receive a Map-Reply as a = response) and RLOC
= probing probing
=
o Removed = 'Solicit-Map Request'. o Removed = 'Solicit-Map Request'.
=
B.13. Changes to = draft-ietf-lisp-rfc6830bis-09 B.14. Changes to = draft-ietf-lisp-rfc6830bis-09
=
o Posted = January 2018. o Posted January = 2018.
=
o Add more = details in section 5.3 about DSCP processing during o Add more details in section 5.3 about DSCP = processing during
= encapsulation and decapsulation. = encapsulation and decapsulation.
=
o Added = clarity to definitions in the Definition of Terms section = o Added clarity to definitions in the = Definition of Terms section
from = various commenters. from various = commenters.
=
o Removed PA = and PI definitions from Definition of Terms section. o Removed PA and PI definitions from Definition of = Terms section.
=
o More = editorial changes. o More = editorial changes.
=
o Removed = 4342 from IANA section and move to RFC6833 IANA section. = o Removed 4342 from IANA section and move = to RFC6833 IANA section.
=
B.14. Changes to = draft-ietf-lisp-rfc6830bis-08 B.15. Changes to = draft-ietf-lisp-rfc6830bis-08
=
o Posted = January 2018. o Posted January = 2018.
=
o Remove = references to research work for any protocol mechanisms. = o Remove references to research work for = any protocol mechanisms.
=
o Document = scanned to make sure it is RFC 2119 compliant. o Document scanned to make sure it is RFC 2119 = compliant.
=
o Made = changes to reflect comments from document WG shepherd Luigi = o Made changes to reflect comments from = document WG shepherd Luigi
= Iannone. Iannone.
=
o Ran IDNITs = on the document. o Ran IDNITs on = the document.
=
B.15. Changes to = draft-ietf-lisp-rfc6830bis-07 B.16. Changes to = draft-ietf-lisp-rfc6830bis-07
=
o Posted = November 2017. o Posted November = 2017.
=
o Rephrase = how Instance-IDs are used and don't refer to [RFC1918] o Rephrase how Instance-IDs are used and don't refer = to [RFC1918]
= addresses. addresses.
=
B.16. Changes to = draft-ietf-lisp-rfc6830bis-06 B.17. Changes to = draft-ietf-lisp-rfc6830bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Put RTR = definition before it is used. o = Put RTR definition before it is used.
=
o Rename = references that are now working group drafts. o Rename references that are now working group = drafts.
=
o Remove = "EIDs MUST NOT be used as used by a host to refer to other = o Remove "EIDs MUST NOT be used as used by = a host to refer to other
hosts. = Note that EID blocks MAY LISP RLOCs". = hosts. Note that EID blocks MAY LISP RLOCs".
=
=
skipping to = change at = page 43, line 15 =C2=B6 = skipping to change at page 43, line = 22 =C2=B6
o ETRs may, = rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send = Map-Replies.
=
o Recommend, = rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation = headers to 2.
=
o Reference = VPN draft when introducing Instance-ID. = o Reference VPN draft when introducing Instance-ID.
=
o Indicate = that SMRs can be sent when ITR/ETR are in the same node. = o Indicate that SMRs can be sent when = ITR/ETR are in the same node.
=
o Clarify = when private addresses can be used. = o Clarify when private addresses can be used.
=
B.17. Changes to = draft-ietf-lisp-rfc6830bis-05 B.18. Changes to = draft-ietf-lisp-rfc6830bis-05
=
o Posted = August 2017. o Posted August = 2017.
=
o Make it = clear that a Re-encapsulating Tunnel Router is an RTR. o Make it clear that a Re-encapsulating Tunnel = Router is an RTR.
=
B.18. Changes to = draft-ietf-lisp-rfc6830bis-04 B.19. Changes to = draft-ietf-lisp-rfc6830bis-04
=
o Posted July = 2017. o Posted July 2017.
=
o Changed = reference of IPv6 RFC2460 to RFC8200. = o Changed reference of IPv6 RFC2460 to RFC8200.
=
o Indicate = that the applicability statement for UDP zero checksums = o Indicate that the applicability statement = for UDP zero checksums
over IPv6 = adheres to RFC6936. over IPv6 = adheres to RFC6936.
=
B.19. Changes to = draft-ietf-lisp-rfc6830bis-03 B.20. Changes to = draft-ietf-lisp-rfc6830bis-03
=
o Posted May = 2017. o Posted May 2017.
=
o Move the = control-plane related codepoints in the IANA o Move the control-plane related codepoints in the = IANA
= Considerations section to RFC6833bis. = Considerations section to RFC6833bis.
=
B.20. Changes to = draft-ietf-lisp-rfc6830bis-02 B.21. Changes to = draft-ietf-lisp-rfc6830bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Reflect = some editorial comments from Damien Sausez. o Reflect some editorial comments from Damien = Sausez.
=
B.21. Changes to = draft-ietf-lisp-rfc6830bis-01 B.22. Changes to = draft-ietf-lisp-rfc6830bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Change = references from RFC6833 to RFC6833bis. = o Change references from RFC6833 to RFC6833bis.
=
o Clarified = LCAF text in the IANA section. o = Clarified LCAF text in the IANA section.
=
o Remove = references to "experimental". o = Remove references to "experimental".
=
B.22. Changes to = draft-ietf-lisp-rfc6830bis-00 B.23. Changes to = draft-ietf-lisp-rfc6830bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6830-00 = individual submission. No other changes made. -rfc6830-00 individual submission. No other = changes made.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
Cisco = Systems Cisco Systems
 End of changes. 32 change blocks. 
68 lines changed or = deleted 79 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_A4FFBF8C-14C1-4C59-B904-F37CEFD956C6-- From nobody Sat Sep 29 10:06:41 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD55130E51 for ; Sat, 29 Sep 2018 10:06:35 -0700 (PDT) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 UYGIFM7QJPoU for ; Sat, 29 Sep 2018 10:06:32 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 D07F5130E45 for ; Sat, 29 Sep 2018 10:06:28 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id u21-v6so1522323lja.8 for ; Sat, 29 Sep 2018 10:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=adCG5alzF/H6EbimsWKcnq2fePFiEtUn5sgQMDEILQU=; b=I6ULEmTvwCLDWUFi6LHmT38FhGykAt6gw8A9Ksewml7A9tNMadNyVXrG/K1JP0rizp QB6is2meAd+Dr/BeR/qnNNqR8BmTCz5NYklULieBDN2XGjiHif4H7mfpRwfhpLcuMc0t qbudEabIQ5aJPnUlwhymUR+XAGQez/LWsBmZmpPLuRxLldfehbVm4YuDOmOJgREBiteh RnV9oosLw+ZssvU/vg/omrwzmXKUTUoSp7UK5LW5VgXPeas9HvMc5sKbfY2ndLJVBjwY 1oQxLt+GLLt1N16nxBPQTYRMU/yeGlmYMm0whKdkOEZsZVAst30h1iyQ8/9Xit4CY2f7 toEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=adCG5alzF/H6EbimsWKcnq2fePFiEtUn5sgQMDEILQU=; b=bOkob2HQdIY6w0toyCmCgVe9Ts1/cWKJZCr/r03K2SjkmhsUmEsRjzdnTLozP1Bg4J sho2Xffje6bFsiGJHa2m45QEKXC3Oj+sZ93JKuLIMKBcYC/0aa57BcXODAiyfjEUfAJU qYV9z7MyvfkUd9+sQJlIB5nI/LYxKBxRlJG3B/1ts6P1h4LggUuxO7YecWYdAw++loU6 nGC/T2wNdKiiKFHkrXgZuMvPnaq23UyGpJCYCJvY9rwQDdfHWmEsUMulb9LfwXHbxz6Q eiKAFPaZOAjiBd9ebVLFntbnzOh25dbVErq+1VSdznmxTxzZoc6wS6h+YAY9sq3tB/37 U8VQ== X-Gm-Message-State: ABuFfoivCYWy82kUBglLA1keLWpTMXVALPhM+q+h931dHQP7utF2QlVC RXmUaTlE+ykdzVPMjnGwsn8VMr1+UHdwr3hpT925TQ== X-Google-Smtp-Source: ACcGV62wMmEkHHWQf5Nmghha9KfExGJE5rpkB1T8NBPytgWpPUhTDZJ2mWnrMKbsbXoIwhKR47kAdB+AJYInIFiUIM8= X-Received: by 2002:a2e:544f:: with SMTP id y15-v6mr2356771ljd.51.1538240786897; Sat, 29 Sep 2018 10:06:26 -0700 (PDT) MIME-Version: 1.0 References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Sat, 29 Sep 2018 10:05:49 -0700 Message-ID: To: Dino Farinacci Cc: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000aeadb405770597fd" Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 29 Sep 2018 17:06:36 -0000 --000000000000aeadb405770597fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci wrote: > Thanks Eric for your great comments. Like I said in previous emails, I=E2= =80=99ll > address the simple things here and then handle all the security related > stuff separately next week. > > I will do the same with Benjamin=E2=80=99s comments as well. And in his r= eply, > send a diff with changes that reflect both Eric and Benjamin=E2=80=99s co= mments. > > > On Sep 27, 2018, at 5:16 AM, Eric Rescorla wrote: > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D4115 > > > > > > IMPORTANT > > S 5.2. > >> s: This is the SMR-invoked bit. This bit is set to 1 when an xTR = is > >> sending a Map-Request in response to a received SMR-based Map- > >> Request. > >> > >> m: This is the LISP mobile-node m-bit. This bit is set by xTRs th= at > >> operate as a mobile node as defined in [I-D.ietf-lisp-mn]. > > > > This would appear to create a normative reference to this document. To > > avoid that, you need to specify how I behave if I receive it but I > > don't implement lisp-mn. > > I am find making it a normative reference but need the lisp-chairs to > comment. I am not sure what the implications of that are. > Me neither. Seems like it could go either way. My only interest is that the protocol be unambiguous. > > S 5.5. > >> is being mapped from a multicast destination EID. > >> > >> 5.5. EID-to-RLOC UDP Map-Reply Message > >> > >> A Map-Reply returns an EID-Prefix with a prefix length that is les= s > >> than or equal to the EID being requested. The EID being requested > is > > > > How do I behave if I receive an EID-Prefix that is less than any of my > > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16 > > and someone asks me for 10.0.0.0/8? I think I'm still unclear on this point. > Also, when you talk about prefix > > length, I assume you mean the length fo the mask? > > Yes, this is explained later in this section. Was that not helpful?? > I found it a bit confusing. It seems to me like there are two lengths involved here: - The length of the field (4 or 16) - The parts of the field that are significant (i.e., the mask) I had thought that "prefix length" referred to the former, but it seems like here it refers to the latter. > S 5.6. > >> Authentication Data: This is the message digest used from the > output > >> of the MAC algorithm. The entire Map-Register payload is > >> authenticated with this field preset to 0. After the MAC is > >> computed, it is placed in this field. Implementations of this > >> specification MUST include support for HMAC-SHA-1-96 [RFC2404], > >> and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. > > > > What prevents replay attacks here? I'm guessing it's the Map-Version- > > Number, but as I understand it, I can set this to 0. > > Well there are many. The nonce can change for each Map-Register sent. Sam= e > for Map-Version number as well as the key-id. > I think you need to describe the precise process of replay prevention here. > > S 6.1. > >> receives an SMR-based Map-Request and the source is not in the > >> Locator-Set for the stored Map-Cache entry, then the responding Ma= p- > >> Request MUST be sent with an EID destination to the mapping databa= se > >> system. Since the mapping database system is a more secure way to > >> reach an authoritative ETR, it will deliver the Map-Request to the > >> authoritative source of the mapping data. > > > > If I'm understanding this correctly, this allows an ETR to prevent an > > ITR from learning that it is no longer the appropriate ETR for a > > prefix. The way this attack works is that before the topology shift, I > > send SMRs, thus causing Map-Requests, which, because my entry is > > cached, refresh the cache on the ITR past the topology shift. I can > > keep doing this indefinitely. Am I missing something > > Well if the ETR is being spoofed, then there is Map-Request load, but it > won=E2=80=99t corrupt the ITR=E2=80=99s map-cache. The ITR always sends a= verifying > Map-Request to the mapping system to get the latest and authenticated > RLOC-set for the mapping. Rate-limiting is necessary so each SMR received > DOES NOT result in a Map-Requerst to the mapping system. > I'm probably just confused here: SMRs go through the mapping system, not directly? If so, I agree that this wont' work. > S 5. > >> \ | UDP Length | UDP Checksum > | > >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | > | > >> | LISP Message > | > >> | > | > >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > What do these two diagrams correspond to? v4 and v6? This needs > > explanation. > > It is th entire IP packet sent as a LISP control-message. The header > before the diagrams indicate they are UDP packets. > A caption would probably help. > S 5.2. > >> P: This is the probe-bit, which indicates that a Map-Request SHOUL= D > >> be treated as a Locator reachability probe. The receiver SHOUL= D > >> respond with a Map-Reply with the probe-bit set, indicating tha= t > >> the Map-Reply is a Locator reachability probe reply, with the > >> nonce copied from the Map-Request. See RLOC-Probing Section 7.= 1 > >> for more details. > > > > How am I supposed to handle this if I am a Map Server. > > It should be ignored. I will add text to reflect this point. Good point. > > > > > S 5.2. > >> receipt. > >> > >> L: This is the local-xtr bit. It is used by an xTR in a LISP site > to > >> tell other xTRs in the same site that it is part of the RLOC-se= t > >> for the LISP site. The L-bit is set to 1 when the RLOC is the > >> sender's IP address. > > > > Is the xTR supposed to filter this on exiting the site. > > Nope. > Won't this cause problems on ingress to another site? > > S 5.3. > >> originating Map-Request source. If the RLOC is not in the Locator= - > >> Set, then the ETR MUST send the "verifying Map-Request" to the > >> "piggybacked" EID. Doing this forces the "verifying Map-Request" = to > >> go through the mapping database system to reach the authoritative > >> source of information about that EID, guarding against RLOC-spoofi= ng > >> in the "piggybacked" mapping data. > > > > This text here doesn't seem compatible with either of the two cases > > listed in "EID-prefix" above. > > I don=E2=80=99t understand the comment Eric. Maybe because I can=E2=80=99= t find the exact > reference to EID-prefix where you think there is a conflict. Please cite > for me. Thanks. > > This does seem to have been assigned to the wrong text. I am referring to: " A Map-Reply returns an EID-Prefix with a prefix length that is less than or equal to the EID being requested. The EID being requested is either from the destination field of an IP header of a Data-Probe or the EID record of a Map-Request. The RLOCs in the Map-Reply are " versus " EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFI], the length varies and for the LCAF AFI the format is defined in [RFC8060]. When a Map- " This is just the question of whether "prefix length" refers to the field or the significant bits of the field. > > > > S 5.4. > >> 'Nonce' field. > >> > >> Record TTL: This is the time in minutes the recipient of the Map- > >> Reply will store the mapping. If the TTL is 0, the entry MUST = be > >> removed from the cache immediately. If the value is 0xffffffff= , > >> the recipient can decide locally how long to store the mapping. > > > > Am I supposed to merge this with previous mappings? REmove them? > > No replace it. There is text that says this that is not in the packet > format description section. > OK. > S 8.3. > >> of the mapping database protocols. > >> > >> 8.3. Map-Server Processing > >> > >> Once a Map-Server has EID-Prefixes registered by its client ETRs, = it > >> can accept and process Map-Requests for them. > > > > This section is confusing because the introduction says that this > > function is only performed by Map-Resolvers: > > ' > > "The LISP Mapping Service defines two new types of LISP-speaking > > devices: the Map-Resolver, which accepts Map-Requests from an > > Ingress > > Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a > > mapping database; and the Map-Server, which learns authoritative > > EID- > > to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes > > them in a database.=E2=80=9D > > The document does cover the operation of a Map-Resolver and a Map-Server. > Some functions are performed only by Map-Resolvers only and other differe= nt > functions are performed by Map-Servers only. > > I am not sure what you don=E2=80=99t understand. > Sure: As I understand it, Map Resolvers process Map Requests, and Map Servers do not (that's what the quoted text seems to say). However, this sentence talks about a Map Server processing a Map Request. That's where I am confused. -Ekr > Thanks, > Dino > > --000000000000aeadb405770597fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci = <farinacci@gmail.com> wrot= e:
Thanks Eric f= or your great comments. Like I said in previous emails, I=E2=80=99ll addres= s the simple things here and then handle all the security related stuff sep= arately next week.

I will do the same with Benjamin=E2=80=99s comments as well. And in his rep= ly, send a diff with changes that reflect both Eric and Benjamin=E2=80=99s = comments.

> On Sep 27, 2018, at 5:16 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D4115<= /a>
>
>
> IMPORTANT
> S 5.2.
>>=C2=A0 =C2=A0 =C2=A0s: This is the SMR-invoked bit.=C2=A0 This bit = is set to 1 when an xTR is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sending a Map-Request in response to a = received SMR-based Map-
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Request.
>>
>>=C2=A0 =C2=A0 =C2=A0m: This is the LISP mobile-node m-bit.=C2=A0 Th= is bit is set by xTRs that
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 operate as a mobile node as defined in = [I-D.ietf-lisp-mn].
>
> This would appear to create a normative reference to this document. To=
> avoid that, you need to specify how I behave if I receive it but I
> don't implement lisp-mn.

I am find making it a normative reference but need the lisp-chairs to comme= nt. I am not sure what the implications of that are.

=C2=A0
> S 5.5.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 is being mapped from a multicast destin= ation EID.
>>
>>=C2=A0 5.5.=C2=A0 EID-to-RLOC UDP Map-Reply Message
>>
>>=C2=A0 =C2=A0 =C2=A0A Map-Reply returns an EID-Prefix with a prefix= length that is less
>>=C2=A0 =C2=A0 =C2=A0than or equal to the EID being requested.=C2=A0= The EID being requested is
>
> How do I behave if I receive an EID-Prefix that is less than any of my=
> mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16
> and someone asks me for 10.0.0.0/8?

I thi= nk I'm still unclear on this point.
=C2=A0
Also, when you talk about pref= ix
> length, I assume you mean the length fo the mask?

Yes, this is explained later in this section. Was that not helpful??

I found it a bit confusing. It seems to me li= ke there are two lengths involved here:

- The leng= th of the field (4 or 16)
- The parts of the field that are signi= ficant (i.e., the mask)

I had thought that &qu= ot;prefix length" referred to the former, but it seems like here it
refers to the latter.


> S 5.6.
>>=C2=A0 =C2=A0 =C2=A0Authentication Data:=C2=A0 This is the message = digest used from the output
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the MAC algorithm.=C2=A0 The entire = Map-Register payload is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticated with this field preset to= 0.=C2=A0 After the MAC is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 computed, it is placed in this field.= =C2=A0 Implementations of this
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 specification MUST include support for = HMAC-SHA-1-96 [RFC2404],
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 and support for HMAC-SHA-256-128 [RFC48= 68] is RECOMMENDED.
>
> What prevents replay attacks here? I'm guessing it's the Map-V= ersion-
> Number, but as I understand it, I can set this to 0.

Well there are many. The nonce can change for each Map-Register sent. Same = for Map-Version number as well as the key-id.

I think you need to describe the precise process of replay preventi= on here.

=C2=A0
> S 6.1.
>>=C2=A0 =C2=A0 =C2=A0receives an SMR-based Map-Request and the sourc= e is not in the
>>=C2=A0 =C2=A0 =C2=A0Locator-Set for the stored Map-Cache entry, the= n the responding Map-
>>=C2=A0 =C2=A0 =C2=A0Request MUST be sent with an EID destination to= the mapping database
>>=C2=A0 =C2=A0 =C2=A0system.=C2=A0 Since the mapping database system= is a more secure way to
>>=C2=A0 =C2=A0 =C2=A0reach an authoritative ETR, it will deliver the= Map-Request to the
>>=C2=A0 =C2=A0 =C2=A0authoritative source of the mapping data.
>
> If I'm understanding this correctly, this allows an ETR to prevent= an
> ITR from learning that it is no longer the appropriate ETR for a
> prefix. The way this attack works is that before the topology shift, I=
> send SMRs, thus causing Map-Requests, which, because my entry is
> cached, refresh the cache on the ITR past the topology shift. I can > keep doing this indefinitely. Am I missing something

Well if the ETR is being spoofed, then there is Map-Request load, but it wo= n=E2=80=99t corrupt the ITR=E2=80=99s map-cache. The ITR always sends a ver= ifying Map-Request to the mapping system to get the latest and authenticate= d RLOC-set for the mapping. Rate-limiting is necessary so each SMR received= DOES NOT result in a Map-Requerst to the mapping system.
<= div>
I'm probably just confused here: SMRs go through the= mapping system, not directly? If so, I agree that this wont' work.
=


> S 5.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0\ |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0UDP Length=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 UDP Checksum=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LISP Message=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> What do these two diagrams correspond to? v4 and v6? This needs
> explanation.

It is th entire IP packet sent as a LISP control-message. The header before= the diagrams indicate they are UDP packets.

A caption would probably help.

> S 5.2.
>>=C2=A0 =C2=A0 =C2=A0P: This is the probe-bit, which indicates that = a Map-Request SHOULD
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 be treated as a Locator reachability pr= obe.=C2=A0 The receiver SHOULD
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 respond with a Map-Reply with the probe= -bit set, indicating that
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the Map-Reply is a Locator reachability= probe reply, with the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 nonce copied from the Map-Request.=C2= =A0 See RLOC-Probing Section 7.1
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for more details.
>
> How am I supposed to handle this if I am a Map Server.

It should be ignored. I will add text to reflect this point. Good point.
>
> S 5.2.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 receipt.
>>
>>=C2=A0 =C2=A0 =C2=A0L: This is the local-xtr bit.=C2=A0 It is used = by an xTR in a LISP site to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 tell other xTRs in the same site that i= t is part of the RLOC-set
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for the LISP site.=C2=A0 The L-bit is s= et to 1 when the RLOC is the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sender's IP address.
>
> Is the xTR supposed to filter this on exiting the site.

Nope.

Won't this cause problems on = ingress to another site?

=C2=A0
> S 5.3.
>>=C2=A0 =C2=A0 =C2=A0originating Map-Request source.=C2=A0 If the RL= OC is not in the Locator-
>>=C2=A0 =C2=A0 =C2=A0Set, then the ETR MUST send the "verifying= Map-Request" to the
>>=C2=A0 =C2=A0 =C2=A0"piggybacked" EID.=C2=A0 Doing this f= orces the "verifying Map-Request" to
>>=C2=A0 =C2=A0 =C2=A0go through the mapping database system to reach= the authoritative
>>=C2=A0 =C2=A0 =C2=A0source of information about that EID, guarding = against RLOC-spoofing
>>=C2=A0 =C2=A0 =C2=A0in the "piggybacked" mapping data. >
> This text here doesn't seem compatible with either of the two case= s
> listed in "EID-prefix" above.

I don=E2=80=99t understand the comment Eric. Maybe because I can=E2=80=99t = find the exact reference to EID-prefix where you think there is a conflict.= Please cite for me. Thanks.

This does seem to have been assigned to the wrong tex= t.

I am referring to:

&qu= ot;=C2=A0=C2=A0 A Map-Reply returns an EID-Prefix with a prefix length that= is less
=C2=A0=C2=A0 than or equal to the EID being requested.=C2=A0 Th= e EID being requested is
=C2=A0=C2=A0 either from the destination field = of an IP header of a Data-Probe or
=C2=A0=C2=A0 the EID record of a Map-= Request.=C2=A0 The RLOCs in the Map-Reply are
"

=
versus

"=C2=A0=C2=A0 EID-Prefix:= =C2=A0 This prefix is 4 octets for an IPv4 address family and
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 16 octets for an IPv6 address family when the EID-Pre= fix-AFI is 1
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or 2, respectively.=C2=A0 Fo= r other AFIs [AFI], the length varies and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= for the LCAF AFI the format is defined in [RFC8060].=C2=A0 When a Map-
= "

This is just the question of whether "= prefix length" refers to the field or
the significant bits o= f the field.




>
> S 5.4.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 'Nonce' field.
>>
>>=C2=A0 =C2=A0 =C2=A0Record TTL:=C2=A0 This is the time in minutes t= he recipient of the Map-
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Reply will store the mapping.=C2=A0 If = the TTL is 0, the entry MUST be
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 removed from the cache immediately.=C2= =A0 If the value is 0xffffffff,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the recipient can decide locally how lo= ng to store the mapping.
>
> Am I supposed to merge this with previous mappings? REmove them?

No replace it. There is text that says this that is not in the packet forma= t description section.

OK.

> S 8.3.
>>=C2=A0 =C2=A0 =C2=A0of the mapping database protocols.
>>
>>=C2=A0 8.3.=C2=A0 Map-Server Processing
>>
>>=C2=A0 =C2=A0 =C2=A0Once a Map-Server has EID-Prefixes registered b= y its client ETRs, it
>>=C2=A0 =C2=A0 =C2=A0can accept and process Map-Requests for them. >
> This section is confusing because the introduction says that this
> function is only performed by Map-Resolvers:
> '
> "The LISP Mapping Service defines two new types of LISP-speaking<= br> >=C2=A0 =C2=A0devices: the Map-Resolver, which accepts Map-Requests from= an
> Ingress
>=C2=A0 =C2=A0Tunnel Router (ITR) and "resolves" the EID-to-RL= OC mapping using a
>=C2=A0 =C2=A0mapping database; and the Map-Server, which learns authori= tative
> EID-
>=C2=A0 =C2=A0to-RLOC mappings from an Egress Tunnel Router (ETR) and pu= blishes
>=C2=A0 =C2=A0them in a database.=E2=80=9D

The document does cover the operation of a Map-Resolver and a Map-Server. S= ome functions are performed only by Map-Resolvers only and other different = functions are performed by Map-Servers only.

I am not sure what you don=E2=80=99t understand.

<= /div>
Sure: As I understand it, Map Resolvers process Map Requests, and= Map Servers do not (that's what the quoted text seems to say). However= , this sentence talks about a Map Server processing a Map Request.=C2=A0 Th= at's where I am confused.

-Ekr
<= br>

Thanks,
Dino

--000000000000aeadb405770597fd-- From nobody Sat Sep 29 10:19:01 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE04130E47; Sat, 29 Sep 2018 10:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 TlTS5qqf20tO; Sat, 29 Sep 2018 10:18:48 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B021412F1A5; Sat, 29 Sep 2018 10:18:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 6EBC5581C64; Sat, 29 Sep 2018 10:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1538241528; bh=CDlAj+wR/htURIvJzJbAU7LmhcYZqWhEjgoMkU12OdM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=a27Hee0P3zSEmKbjGvuaVq6fbqIDlzzW5D998GbVejX9Ye+zNsEMzoUZh1YPeoQue rbeEYQC4qOSVTaie0QzrJMyN/OoJ/gBSq7LLrjvZiBQ/IDUIthPDkReriDesJaBz4W /WAaAebQGYFGnfxB4cN9Gq1TajTx02EZYmKG4nS4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 4BB4D1C0331; Sat, 29 Sep 2018 10:18:47 -0700 (PDT) To: Eric Rescorla , Dino Farinacci Cc: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Sat, 29 Sep 2018 13:18:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 29 Sep 2018 17:18:52 -0000 With regard to the m-bit, I would prefer that this document leave the bit reserved, and the LISP mobile node document assign the bit fromthe registry. That keeps a clean separation. Yours, Joel On 9/29/18 1:05 PM, Eric Rescorla wrote: > > > On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci > wrote: > > Thanks Eric for your great comments. Like I said in previous emails, > I’ll address the simple things here and then handle all the security > related stuff separately next week. > > I will do the same with Benjamin’s comments as well. And in his > reply, send a diff with changes that reflect both Eric and > Benjamin’s comments. > > > On Sep 27, 2018, at 5:16 AM, Eric Rescorla > wrote: > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D4115 > > > > > > IMPORTANT > > S 5.2. > >>     s: This is the SMR-invoked bit.  This bit is set to 1 when > an xTR is > >>        sending a Map-Request in response to a received SMR-based > Map- > >>        Request. > >> > >>     m: This is the LISP mobile-node m-bit.  This bit is set by > xTRs that > >>        operate as a mobile node as defined in [I-D.ietf-lisp-mn]. > > > > This would appear to create a normative reference to this > document. To > > avoid that, you need to specify how I behave if I receive it but I > > don't implement lisp-mn. > > I am find making it a normative reference but need the lisp-chairs > to comment. I am not sure what the implications of that are. > > > Me neither. Seems like it could go either way. My only interest is that > the protocol be unambiguous. > > > > > S 5.5. > >>        is being mapped from a multicast destination EID. > >> > >>  5.5.  EID-to-RLOC UDP Map-Reply Message > >> > >>     A Map-Reply returns an EID-Prefix with a prefix length that > is less > >>     than or equal to the EID being requested.  The EID being > requested is > > > > How do I behave if I receive an EID-Prefix that is less than any > of my > > mappings. So, I might have mappings for 10.1.0.0/16 > and 10.2.0.0/16 > > and someone asks me for 10.0.0.0/8 ? > > > I think I'm still unclear on this point. > > Also, when you talk about prefix > > length, I assume you mean the length fo the mask? > > Yes, this is explained later in this section. Was that not helpful?? > > > I found it a bit confusing. It seems to me like there are two lengths > involved here: > > - The length of the field (4 or 16) > - The parts of the field that are significant (i.e., the mask) > > I had thought that "prefix length" referred to the former, but it seems > like here it > refers to the latter. > > > > S 5.6. > >>     Authentication Data:  This is the message digest used from > the output > >>        of the MAC algorithm.  The entire Map-Register payload is > >>        authenticated with this field preset to 0.  After the MAC is > >>        computed, it is placed in this field.  Implementations of > this > >>        specification MUST include support for HMAC-SHA-1-96 > [RFC2404], > >>        and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. > > > > What prevents replay attacks here? I'm guessing it's the Map-Version- > > Number, but as I understand it, I can set this to 0. > > Well there are many. The nonce can change for each Map-Register > sent. Same for Map-Version number as well as the key-id. > > > I think you need to describe the precise process of replay prevention here. > > > S 6.1. > >>     receives an SMR-based Map-Request and the source is not in the > >>     Locator-Set for the stored Map-Cache entry, then the > responding Map- > >>     Request MUST be sent with an EID destination to the mapping > database > >>     system.  Since the mapping database system is a more secure > way to > >>     reach an authoritative ETR, it will deliver the Map-Request > to the > >>     authoritative source of the mapping data. > > > > If I'm understanding this correctly, this allows an ETR to prevent an > > ITR from learning that it is no longer the appropriate ETR for a > > prefix. The way this attack works is that before the topology > shift, I > > send SMRs, thus causing Map-Requests, which, because my entry is > > cached, refresh the cache on the ITR past the topology shift. I can > > keep doing this indefinitely. Am I missing something > > Well if the ETR is being spoofed, then there is Map-Request load, > but it won’t corrupt the ITR’s map-cache. The ITR always sends a > verifying Map-Request to the mapping system to get the latest and > authenticated RLOC-set for the mapping. Rate-limiting is necessary > so each SMR received DOES NOT result in a Map-Requerst to the > mapping system. > > > I'm probably just confused here: SMRs go through the mapping system, not > directly? If so, I agree that this wont' work. > > > > S 5. > >>       \ |           UDP Length          |        UDP Checksum >        | > >> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>         | >        | > >>         |                         LISP Message >         | > >>         | >        | > >> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > What do these two diagrams correspond to? v4 and v6? This needs > > explanation. > > It is th entire IP packet sent as a LISP control-message. The header > before the diagrams indicate they are UDP packets. > > > A caption would probably help. > > > S 5.2. > >>     P: This is the probe-bit, which indicates that a Map-Request > SHOULD > >>        be treated as a Locator reachability probe.  The receiver > SHOULD > >>        respond with a Map-Reply with the probe-bit set, > indicating that > >>        the Map-Reply is a Locator reachability probe reply, with the > >>        nonce copied from the Map-Request.  See RLOC-Probing > Section 7.1 > >>        for more details. > > > > How am I supposed to handle this if I am a Map Server. > > It should be ignored. I will add text to reflect this point. Good point. > > > > > S 5.2. > >>        receipt. > >> > >>     L: This is the local-xtr bit.  It is used by an xTR in a > LISP site to > >>        tell other xTRs in the same site that it is part of the > RLOC-set > >>        for the LISP site.  The L-bit is set to 1 when the RLOC > is the > >>        sender's IP address. > > > > Is the xTR supposed to filter this on exiting the site. > > Nope. > > > Won't this cause problems on ingress to another site? > > > S 5.3. > >>     originating Map-Request source.  If the RLOC is not in the > Locator- > >>     Set, then the ETR MUST send the "verifying Map-Request" to the > >>     "piggybacked" EID.  Doing this forces the "verifying > Map-Request" to > >>     go through the mapping database system to reach the > authoritative > >>     source of information about that EID, guarding against > RLOC-spoofing > >>     in the "piggybacked" mapping data. > > > > This text here doesn't seem compatible with either of the two cases > > listed in "EID-prefix" above. > > I don’t understand the comment Eric. Maybe because I can’t find the > exact reference to EID-prefix where you think there is a conflict. > Please cite for me. Thanks. > > This does seem to have been assigned to the wrong text. > > I am referring to: > > "   A Map-Reply returns an EID-Prefix with a prefix length that is less >    than or equal to the EID being requested.  The EID being requested is >    either from the destination field of an IP header of a Data-Probe or >    the EID record of a Map-Request.  The RLOCs in the Map-Reply are > " > > versus > > "   EID-Prefix:  This prefix is 4 octets for an IPv4 address family and >       16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 >       or 2, respectively.  For other AFIs [AFI], the length varies and >       for the LCAF AFI the format is defined in [RFC8060].  When a Map- > " > > This is just the question of whether "prefix length" refers to the field or > the significant bits of the field. > > > > > > > > S 5.4. > >>        'Nonce' field. > >> > >>     Record TTL:  This is the time in minutes the recipient of > the Map- > >>        Reply will store the mapping.  If the TTL is 0, the entry > MUST be > >>        removed from the cache immediately.  If the value is > 0xffffffff, > >>        the recipient can decide locally how long to store the > mapping. > > > > Am I supposed to merge this with previous mappings? REmove them? > > No replace it. There is text that says this that is not in the > packet format description section. > > > OK. > > > > S 8.3. > >>     of the mapping database protocols. > >> > >>  8.3.  Map-Server Processing > >> > >>     Once a Map-Server has EID-Prefixes registered by its client > ETRs, it > >>     can accept and process Map-Requests for them. > > > > This section is confusing because the introduction says that this > > function is only performed by Map-Resolvers: > > ' > > "The LISP Mapping Service defines two new types of LISP-speaking > >   devices: the Map-Resolver, which accepts Map-Requests from an > > Ingress > >   Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a > >   mapping database; and the Map-Server, which learns authoritative > > EID- > >   to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes > >   them in a database.” > > The document does cover the operation of a Map-Resolver and a > Map-Server. Some functions are performed only by Map-Resolvers only > and other different functions are performed by Map-Servers only. > > I am not sure what you don’t understand. > > > Sure: As I understand it, Map Resolvers process Map Requests, and Map > Servers do not (that's what the quoted text seems to say). However, this > sentence talks about a Map Server processing a Map Request.  That's > where I am confused. > > -Ekr > > > Thanks, > Dino > From nobody Sat Sep 29 10:23:25 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DFB130E4A for ; Sat, 29 Sep 2018 10:23:23 -0700 (PDT) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 f72Rh9YOYjpQ for ; Sat, 29 Sep 2018 10:23:20 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 D6CF3130DCB for ; Sat, 29 Sep 2018 10:23:19 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id r8-v6so8569199ljc.10 for ; Sat, 29 Sep 2018 10:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h+orkpAQpgv/TnLCmfsh9S5BIR4g2HfsoKg7lr2QR+k=; b=vb/rpWcEQVFcTIFnJ5Zv/XfTRZmonXptu2saNBWtlo/3EFR/0bpmQ7SQEIJxW/FZnB yZ8EGjDL447+OEzYY1kQkrXKekhGM5jJeErcxdwVtJZBDVJ6yBjkNJoLbq+PjE/XHESP 7n2T6Etd7EUO/2laEF//eYXPlXaurV52vNOENBYWEqAee+tewk++0hJK3cAz33+cIty5 obkVHRNAhX0Tmp6liDYHnvAmRikt9K5DfXhqDnoc0Ic8Mr3U1JbcJ5lnB8pX8jMjr+V1 pHRW56Ff8OFhc5RmuEWTWSrthz+xOr0GYomA0xRsXFlKdi3/NK7J0a1mPnmO/RwJx/Ad LL0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h+orkpAQpgv/TnLCmfsh9S5BIR4g2HfsoKg7lr2QR+k=; b=Aev9pFjm9T7vyHUfHrt39VLKyaFWaTDc6YIubPZaRAY4Q90gcitMk7XbztXLTDw5UH ovptJ5z8LbTDpiDvpQAcMG85R2/FvIxq3We+/AW+XB/TGfCOL0y6NguB91lJxRQ/dnrf SDgmH3UADrG0AGnFPzeNaQZBt5+zyvVABB7p5uaxcIQADlQo2D+MxOj5HKSAroH5GKxs Mgw4W6za2yFxdigvttkFA/5XOuRxpitkDFeZfBQCGhb1Ni/WOR/0gJoo4MROFU+K5EqD rBxb/WshXXH/v2d1W4Kvnk42Ab17UHcLnxSAzfIdI88chq/wyvyFvSpd/hhJ1Zt+bHtW TRCg== X-Gm-Message-State: ABuFfoh2kIlw964XVOwQUWhQt03QMdlgXy7+fpLtvBHDHUNFeTVB/aNo RtScWF0tHI4FLsiz2mTv1JNEnFCnjo40FVz5g7piZg== X-Google-Smtp-Source: ACcGV605i3my2uSE5xhUzjoBQSaEwUyRfciHPw4ZuBPvY+wmohaASo4X541bZUAIB4vsHhwvVuAfYT0iD9G7kGWseik= X-Received: by 2002:a2e:2a43:: with SMTP id q64-v6mr1988761ljq.153.1538241798009; Sat, 29 Sep 2018 10:23:18 -0700 (PDT) MIME-Version: 1.0 References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Sat, 29 Sep 2018 10:22:41 -0700 Message-ID: To: "Joel M. Halpern" Cc: Dino Farinacci , IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000f309a7057705d3ae" Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 29 Sep 2018 17:23:24 -0000 --000000000000f309a7057705d3ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern wrote: > With regard to the m-bit, I would prefer that this document leave the > bit reserved, Just trying to think through the interop implications of this. Would it be must be zero and must ignore? something else? -Ekr and the LISP mobile node document assign the bit fromthe > registry. That keeps a clean separation. > > Yours, > Joel > > On 9/29/18 1:05 PM, Eric Rescorla wrote: > > > > > > On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci > > wrote: > > > > Thanks Eric for your great comments. Like I said in previous emails= , > > I=E2=80=99ll address the simple things here and then handle all the= security > > related stuff separately next week. > > > > I will do the same with Benjamin=E2=80=99s comments as well. And in= his > > reply, send a diff with changes that reflect both Eric and > > Benjamin=E2=80=99s comments. > > > > > On Sep 27, 2018, at 5:16 AM, Eric Rescorla > > wrote: > > > > > > Rich version of this review at: > > > https://mozphab-ietf.devsvcdev.mozaws.net/D4115 > > > > > > > > > IMPORTANT > > > S 5.2. > > >> s: This is the SMR-invoked bit. This bit is set to 1 when > > an xTR is > > >> sending a Map-Request in response to a received SMR-base= d > > Map- > > >> Request. > > >> > > >> m: This is the LISP mobile-node m-bit. This bit is set by > > xTRs that > > >> operate as a mobile node as defined in [I-D.ietf-lisp-mn= ]. > > > > > > This would appear to create a normative reference to this > > document. To > > > avoid that, you need to specify how I behave if I receive it but= I > > > don't implement lisp-mn. > > > > I am find making it a normative reference but need the lisp-chairs > > to comment. I am not sure what the implications of that are. > > > > > > Me neither. Seems like it could go either way. My only interest is that > > the protocol be unambiguous. > > > > > > > > > S 5.5. > > >> is being mapped from a multicast destination EID. > > >> > > >> 5.5. EID-to-RLOC UDP Map-Reply Message > > >> > > >> A Map-Reply returns an EID-Prefix with a prefix length that > > is less > > >> than or equal to the EID being requested. The EID being > > requested is > > > > > > How do I behave if I receive an EID-Prefix that is less than any > > of my > > > mappings. So, I might have mappings for 10.1.0.0/16 > > and 10.2.0.0/16 > > > and someone asks me for 10.0.0.0/8 ? > > > > > > I think I'm still unclear on this point. > > > > Also, when you talk about prefix > > > length, I assume you mean the length fo the mask? > > > > Yes, this is explained later in this section. Was that not helpful?= ? > > > > > > I found it a bit confusing. It seems to me like there are two lengths > > involved here: > > > > - The length of the field (4 or 16) > > - The parts of the field that are significant (i.e., the mask) > > > > I had thought that "prefix length" referred to the former, but it seems > > like here it > > refers to the latter. > > > > > > > S 5.6. > > >> Authentication Data: This is the message digest used from > > the output > > >> of the MAC algorithm. The entire Map-Register payload i= s > > >> authenticated with this field preset to 0. After the MA= C > is > > >> computed, it is placed in this field. Implementations o= f > > this > > >> specification MUST include support for HMAC-SHA-1-96 > > [RFC2404], > > >> and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDE= D. > > > > > > What prevents replay attacks here? I'm guessing it's the > Map-Version- > > > Number, but as I understand it, I can set this to 0. > > > > Well there are many. The nonce can change for each Map-Register > > sent. Same for Map-Version number as well as the key-id. > > > > > > I think you need to describe the precise process of replay prevention > here. > > > > > S 6.1. > > >> receives an SMR-based Map-Request and the source is not in > the > > >> Locator-Set for the stored Map-Cache entry, then the > > responding Map- > > >> Request MUST be sent with an EID destination to the mapping > > database > > >> system. Since the mapping database system is a more secure > > way to > > >> reach an authoritative ETR, it will deliver the Map-Request > > to the > > >> authoritative source of the mapping data. > > > > > > If I'm understanding this correctly, this allows an ETR to > prevent an > > > ITR from learning that it is no longer the appropriate ETR for a > > > prefix. The way this attack works is that before the topology > > shift, I > > > send SMRs, thus causing Map-Requests, which, because my entry is > > > cached, refresh the cache on the ITR past the topology shift. I > can > > > keep doing this indefinitely. Am I missing something > > > > Well if the ETR is being spoofed, then there is Map-Request load, > > but it won=E2=80=99t corrupt the ITR=E2=80=99s map-cache. The ITR a= lways sends a > > verifying Map-Request to the mapping system to get the latest and > > authenticated RLOC-set for the mapping. Rate-limiting is necessary > > so each SMR received DOES NOT result in a Map-Requerst to the > > mapping system. > > > > > > I'm probably just confused here: SMRs go through the mapping system, no= t > > directly? If so, I agree that this wont' work. > > > > > > > S 5. > > >> \ | UDP Length | UDP Checksum > > | > > >> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >> | > > | > > >> | LISP Message > > | > > >> | > > | > > >> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > What do these two diagrams correspond to? v4 and v6? This needs > > > explanation. > > > > It is th entire IP packet sent as a LISP control-message. The heade= r > > before the diagrams indicate they are UDP packets. > > > > > > A caption would probably help. > > > > > S 5.2. > > >> P: This is the probe-bit, which indicates that a Map-Reques= t > > SHOULD > > >> be treated as a Locator reachability probe. The receive= r > > SHOULD > > >> respond with a Map-Reply with the probe-bit set, > > indicating that > > >> the Map-Reply is a Locator reachability probe reply, wit= h > the > > >> nonce copied from the Map-Request. See RLOC-Probing > > Section 7.1 > > >> for more details. > > > > > > How am I supposed to handle this if I am a Map Server. > > > > It should be ignored. I will add text to reflect this point. Good > point. > > > > > > > > S 5.2. > > >> receipt. > > >> > > >> L: This is the local-xtr bit. It is used by an xTR in a > > LISP site to > > >> tell other xTRs in the same site that it is part of the > > RLOC-set > > >> for the LISP site. The L-bit is set to 1 when the RLOC > > is the > > >> sender's IP address. > > > > > > Is the xTR supposed to filter this on exiting the site. > > > > Nope. > > > > > > Won't this cause problems on ingress to another site? > > > > > S 5.3. > > >> originating Map-Request source. If the RLOC is not in the > > Locator- > > >> Set, then the ETR MUST send the "verifying Map-Request" to > the > > >> "piggybacked" EID. Doing this forces the "verifying > > Map-Request" to > > >> go through the mapping database system to reach the > > authoritative > > >> source of information about that EID, guarding against > > RLOC-spoofing > > >> in the "piggybacked" mapping data. > > > > > > This text here doesn't seem compatible with either of the two > cases > > > listed in "EID-prefix" above. > > > > I don=E2=80=99t understand the comment Eric. Maybe because I can=E2= =80=99t find the > > exact reference to EID-prefix where you think there is a conflict. > > Please cite for me. Thanks. > > > > This does seem to have been assigned to the wrong text. > > > > I am referring to: > > > > " A Map-Reply returns an EID-Prefix with a prefix length that is less > > than or equal to the EID being requested. The EID being requested = is > > either from the destination field of an IP header of a Data-Probe o= r > > the EID record of a Map-Request. The RLOCs in the Map-Reply are > > " > > > > versus > > > > " EID-Prefix: This prefix is 4 octets for an IPv4 address family and > > 16 octets for an IPv6 address family when the EID-Prefix-AFI is = 1 > > or 2, respectively. For other AFIs [AFI], the length varies and > > for the LCAF AFI the format is defined in [RFC8060]. When a Map= - > > " > > > > This is just the question of whether "prefix length" refers to the fiel= d > or > > the significant bits of the field. > > > > > > > > > > > > > > S 5.4. > > >> 'Nonce' field. > > >> > > >> Record TTL: This is the time in minutes the recipient of > > the Map- > > >> Reply will store the mapping. If the TTL is 0, the entr= y > > MUST be > > >> removed from the cache immediately. If the value is > > 0xffffffff, > > >> the recipient can decide locally how long to store the > > mapping. > > > > > > Am I supposed to merge this with previous mappings? REmove them? > > > > No replace it. There is text that says this that is not in the > > packet format description section. > > > > > > OK. > > > > > > > S 8.3. > > >> of the mapping database protocols. > > >> > > >> 8.3. Map-Server Processing > > >> > > >> Once a Map-Server has EID-Prefixes registered by its client > > ETRs, it > > >> can accept and process Map-Requests for them. > > > > > > This section is confusing because the introduction says that thi= s > > > function is only performed by Map-Resolvers: > > > ' > > > "The LISP Mapping Service defines two new types of LISP-speaking > > > devices: the Map-Resolver, which accepts Map-Requests from an > > > Ingress > > > Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping > using a > > > mapping database; and the Map-Server, which learns authoritati= ve > > > EID- > > > to-RLOC mappings from an Egress Tunnel Router (ETR) and > publishes > > > them in a database.=E2=80=9D > > > > The document does cover the operation of a Map-Resolver and a > > Map-Server. Some functions are performed only by Map-Resolvers only > > and other different functions are performed by Map-Servers only. > > > > I am not sure what you don=E2=80=99t understand. > > > > > > Sure: As I understand it, Map Resolvers process Map Requests, and Map > > Servers do not (that's what the quoted text seems to say). However, thi= s > > sentence talks about a Map Server processing a Map Request. That's > > where I am confused. > > > > -Ekr > > > > > > Thanks, > > Dino > > > --000000000000f309a7057705d3ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat= , Sep 29, 2018 at 10:18 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:
With regard to the m-bit, I would prefer that this document leav= e the
bit reserved,

Just trying to think through = the interop implications of this. Would it be must be zero and must ignore?= something else?

-Ekr

and the LISP mobile node document assign the bi= t fromthe
registry.=C2=A0 That keeps a clean separation.

Yours,
Joel

On 9/29/18 1:05 PM, Eric Rescorla wrote:
>
>
> On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci <farinacci@gmail.com
> <mailto:fa= rinacci@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Thanks Eric for your great comments. Like I said in= previous emails,
>=C2=A0 =C2=A0 =C2=A0I=E2=80=99ll address the simple things here and the= n handle all the security
>=C2=A0 =C2=A0 =C2=A0related stuff separately next week.
>
>=C2=A0 =C2=A0 =C2=A0I will do the same with Benjamin=E2=80=99s comments= as well. And in his
>=C2=A0 =C2=A0 =C2=A0reply, send a diff with changes that reflect both E= ric and
>=C2=A0 =C2=A0 =C2=A0Benjamin=E2=80=99s comments.
>
>=C2=A0 =C2=A0 =C2=A0 > On Sep 27, 2018, at 5:16 AM, Eric Rescorla &l= t;ekr@rtfm.com
>=C2=A0 =C2=A0 =C2=A0<mailto:ekr@rtfm.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Rich version of this review at:
>=C2=A0 =C2=A0 =C2=A0 > https://mozphab-ietf.de= vsvcdev.mozaws.net/D4115
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > IMPORTANT
>=C2=A0 =C2=A0 =C2=A0 > S 5.2.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0s: This is the SMR-inv= oked bit.=C2=A0 This bit is set to 1 when
>=C2=A0 =C2=A0 =C2=A0an xTR is
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sending a Map-= Request in response to a received SMR-based
>=C2=A0 =C2=A0 =C2=A0Map-
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Request.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0m: This is the LISP mo= bile-node m-bit.=C2=A0 This bit is set by
>=C2=A0 =C2=A0 =C2=A0xTRs that
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 operate as a m= obile node as defined in [I-D.ietf-lisp-mn].
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > This would appear to create a normative refer= ence to this
>=C2=A0 =C2=A0 =C2=A0document. To
>=C2=A0 =C2=A0 =C2=A0 > avoid that, you need to specify how I behave = if I receive it but I
>=C2=A0 =C2=A0 =C2=A0 > don't implement lisp-mn.
>
>=C2=A0 =C2=A0 =C2=A0I am find making it a normative reference but need = the lisp-chairs
>=C2=A0 =C2=A0 =C2=A0to comment. I am not sure what the implications of = that are.
>
>
> Me neither. Seems like it could go either way. My only interest is tha= t
> the protocol be unambiguous.
>
>
>
>=C2=A0 =C2=A0 =C2=A0 > S 5.5.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 is being mappe= d from a multicast destination EID.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 5.5.=C2=A0 EID-to-RLOC UDP Map-Repl= y Message
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0A Map-Reply returns an= EID-Prefix with a prefix length that
>=C2=A0 =C2=A0 =C2=A0is less
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0than or equal to the E= ID being requested.=C2=A0 The EID being
>=C2=A0 =C2=A0 =C2=A0requested is
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > How do I behave if I receive an EID-Prefix th= at is less than any
>=C2=A0 =C2=A0 =C2=A0of my
>=C2=A0 =C2=A0 =C2=A0 > mappings. So, I might have mappings for 10.1.0.0/16<= /a>
>=C2=A0 =C2=A0 =C2=A0<http://10.1.0.0/16> and 10.2.0.0/16 <http://10.2.0.0/1= 6>
>=C2=A0 =C2=A0 =C2=A0 > and someone asks me for 10.0.0.0/8 <http://10.0.0.0/8<= /a>>?
>
>
> I think I'm still unclear on this point.
>
>=C2=A0 =C2=A0 =C2=A0Also, when you talk about prefix
>=C2=A0 =C2=A0 =C2=A0 > length, I assume you mean the length fo the m= ask?
>
>=C2=A0 =C2=A0 =C2=A0Yes, this is explained later in this section. Was t= hat not helpful??
>
>
> I found it a bit confusing. It seems to me like there are two lengths =
> involved here:
>
> - The length of the field (4 or 16)
> - The parts of the field that are significant (i.e., the mask)
>
> I had thought that "prefix length" referred to the former, b= ut it seems
> like here it
> refers to the latter.
>
>
>=C2=A0 =C2=A0 =C2=A0 > S 5.6.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Authentication Data:= =C2=A0 This is the message digest used from
>=C2=A0 =C2=A0 =C2=A0the output
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the MAC alg= orithm.=C2=A0 The entire Map-Register payload is
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticated = with this field preset to 0.=C2=A0 After the MAC is
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 computed, it i= s placed in this field.=C2=A0 Implementations of
>=C2=A0 =C2=A0 =C2=A0this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 specification = MUST include support for HMAC-SHA-1-96
>=C2=A0 =C2=A0 =C2=A0[RFC2404],
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 and support fo= r HMAC-SHA-256-128 [RFC4868] is RECOMMENDED.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > What prevents replay attacks here? I'm gu= essing it's the Map-Version-
>=C2=A0 =C2=A0 =C2=A0 > Number, but as I understand it, I can set thi= s to 0.
>
>=C2=A0 =C2=A0 =C2=A0Well there are many. The nonce can change for each = Map-Register
>=C2=A0 =C2=A0 =C2=A0sent. Same for Map-Version number as well as the ke= y-id.
>
>
> I think you need to describe the precise process of replay prevention = here.
>
>=C2=A0 =C2=A0 =C2=A0 > S 6.1.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0receives an SMR-based = Map-Request and the source is not in the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Locator-Set for the st= ored Map-Cache entry, then the
>=C2=A0 =C2=A0 =C2=A0responding Map-
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Request MUST be sent w= ith an EID destination to the mapping
>=C2=A0 =C2=A0 =C2=A0database
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0system.=C2=A0 Since th= e mapping database system is a more secure
>=C2=A0 =C2=A0 =C2=A0way to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0reach an authoritative= ETR, it will deliver the Map-Request
>=C2=A0 =C2=A0 =C2=A0to the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0authoritative source o= f the mapping data.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > If I'm understanding this correctly, this= allows an ETR to prevent an
>=C2=A0 =C2=A0 =C2=A0 > ITR from learning that it is no longer the ap= propriate ETR for a
>=C2=A0 =C2=A0 =C2=A0 > prefix. The way this attack works is that bef= ore the topology
>=C2=A0 =C2=A0 =C2=A0shift, I
>=C2=A0 =C2=A0 =C2=A0 > send SMRs, thus causing Map-Requests, which, = because my entry is
>=C2=A0 =C2=A0 =C2=A0 > cached, refresh the cache on the ITR past the= topology shift. I can
>=C2=A0 =C2=A0 =C2=A0 > keep doing this indefinitely. Am I missing so= mething
>
>=C2=A0 =C2=A0 =C2=A0Well if the ETR is being spoofed, then there is Map= -Request load,
>=C2=A0 =C2=A0 =C2=A0but it won=E2=80=99t corrupt the ITR=E2=80=99s map-= cache. The ITR always sends a
>=C2=A0 =C2=A0 =C2=A0verifying Map-Request to the mapping system to get = the latest and
>=C2=A0 =C2=A0 =C2=A0authenticated RLOC-set for the mapping. Rate-limiti= ng is necessary
>=C2=A0 =C2=A0 =C2=A0so each SMR received DOES NOT result in a Map-Reque= rst to the
>=C2=A0 =C2=A0 =C2=A0mapping system.
>
>
> I'm probably just confused here: SMRs go through the mapping syste= m, not
> directly? If so, I agree that this wont' work.
>
>
>=C2=A0 =C2=A0 =C2=A0 > S 5.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0\ |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UDP Length=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 UDP Checksum=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0LISP Message=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > What do these two diagrams correspond to? v4 = and v6? This needs
>=C2=A0 =C2=A0 =C2=A0 > explanation.
>
>=C2=A0 =C2=A0 =C2=A0It is th entire IP packet sent as a LISP control-me= ssage. The header
>=C2=A0 =C2=A0 =C2=A0before the diagrams indicate they are UDP packets.<= br> >
>
> A caption would probably help.
>
>=C2=A0 =C2=A0 =C2=A0 > S 5.2.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0P: This is the probe-b= it, which indicates that a Map-Request
>=C2=A0 =C2=A0 =C2=A0SHOULD
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 be treated as = a Locator reachability probe.=C2=A0 The receiver
>=C2=A0 =C2=A0 =C2=A0SHOULD
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 respond with a= Map-Reply with the probe-bit set,
>=C2=A0 =C2=A0 =C2=A0indicating that
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the Map-Reply = is a Locator reachability probe reply, with the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 nonce copied f= rom the Map-Request.=C2=A0 See RLOC-Probing
>=C2=A0 =C2=A0 =C2=A0Section 7.1
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for more detai= ls.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > How am I supposed to handle this if I am a Ma= p Server.
>
>=C2=A0 =C2=A0 =C2=A0It should be ignored. I will add text to reflect th= is point. Good point.
>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > S 5.2.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 receipt.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0L: This is the local-x= tr bit.=C2=A0 It is used by an xTR in a
>=C2=A0 =C2=A0 =C2=A0LISP site to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 tell other xTR= s in the same site that it is part of the
>=C2=A0 =C2=A0 =C2=A0RLOC-set
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for the LISP s= ite.=C2=A0 The L-bit is set to 1 when the RLOC
>=C2=A0 =C2=A0 =C2=A0is the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sender's I= P address.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Is the xTR supposed to filter this on exiting= the site.
>
>=C2=A0 =C2=A0 =C2=A0Nope.
>
>
> Won't this cause problems on ingress to another site?
>
>=C2=A0 =C2=A0 =C2=A0 > S 5.3.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0originating Map-Reques= t source.=C2=A0 If the RLOC is not in the
>=C2=A0 =C2=A0 =C2=A0Locator-
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Set, then the ETR MUST= send the "verifying Map-Request" to the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0"piggybacked"= ; EID.=C2=A0 Doing this forces the "verifying
>=C2=A0 =C2=A0 =C2=A0Map-Request" to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0go through the mapping= database system to reach the
>=C2=A0 =C2=A0 =C2=A0authoritative
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0source of information = about that EID, guarding against
>=C2=A0 =C2=A0 =C2=A0RLOC-spoofing
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0in the "piggyback= ed" mapping data.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > This text here doesn't seem compatible wi= th either of the two cases
>=C2=A0 =C2=A0 =C2=A0 > listed in "EID-prefix" above.
>
>=C2=A0 =C2=A0 =C2=A0I don=E2=80=99t understand the comment Eric. Maybe = because I can=E2=80=99t find the
>=C2=A0 =C2=A0 =C2=A0exact reference to EID-prefix where you think there= is a conflict.
>=C2=A0 =C2=A0 =C2=A0Please cite for me. Thanks.
>
> This does seem to have been assigned to the wrong text.
>
> I am referring to:
>
> "=C2=A0=C2=A0 A Map-Reply returns an EID-Prefix with a prefix len= gth that is less
>=C2=A0 =C2=A0=C2=A0 than or equal to the EID being requested.=C2=A0 The= EID being requested is
>=C2=A0 =C2=A0=C2=A0 either from the destination field of an IP header o= f a Data-Probe or
>=C2=A0 =C2=A0=C2=A0 the EID record of a Map-Request.=C2=A0 The RLOCs in= the Map-Reply are
> "
>
> versus
>
> "=C2=A0=C2=A0 EID-Prefix:=C2=A0 This prefix is 4 octets for an IP= v4 address family and
>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16 octets for an IPv6 address fam= ily when the EID-Prefix-AFI is 1
>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or 2, respectively.=C2=A0 For oth= er AFIs [AFI], the length varies and
>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for the LCAF AFI the format is de= fined in [RFC8060].=C2=A0 When a Map-
> "
>
> This is just the question of whether "prefix length" refers = to the field or
> the significant bits of the field.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > S 5.4.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 'Nonce'= ; field.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Record TTL:=C2=A0 This= is the time in minutes the recipient of
>=C2=A0 =C2=A0 =C2=A0the Map-
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Reply will sto= re the mapping.=C2=A0 If the TTL is 0, the entry
>=C2=A0 =C2=A0 =C2=A0MUST be
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 removed from t= he cache immediately.=C2=A0 If the value is
>=C2=A0 =C2=A0 =C2=A00xffffffff,
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the recipient = can decide locally how long to store the
>=C2=A0 =C2=A0 =C2=A0mapping.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Am I supposed to merge this with previous map= pings? REmove them?
>
>=C2=A0 =C2=A0 =C2=A0No replace it. There is text that says this that is= not in the
>=C2=A0 =C2=A0 =C2=A0packet format description section.
>
>
> OK.
>
>
>=C2=A0 =C2=A0 =C2=A0 > S 8.3.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0of the mapping databas= e protocols.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 8.3.=C2=A0 Map-Server Processing >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Once a Map-Server has = EID-Prefixes registered by its client
>=C2=A0 =C2=A0 =C2=A0ETRs, it
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0can accept and process= Map-Requests for them.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > This section is confusing because the introdu= ction says that this
>=C2=A0 =C2=A0 =C2=A0 > function is only performed by Map-Resolvers:<= br> >=C2=A0 =C2=A0 =C2=A0 > '
>=C2=A0 =C2=A0 =C2=A0 > "The LISP Mapping Service defines two ne= w types of LISP-speaking
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0devices: the Map-Resolver, which = accepts Map-Requests from an
>=C2=A0 =C2=A0 =C2=A0 > Ingress
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0Tunnel Router (ITR) and "res= olves" the EID-to-RLOC mapping using a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0mapping database; and the Map-Ser= ver, which learns authoritative
>=C2=A0 =C2=A0 =C2=A0 > EID-
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0to-RLOC mappings from an Egress T= unnel Router (ETR) and publishes
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0them in a database.=E2=80=9D
>
>=C2=A0 =C2=A0 =C2=A0The document does cover the operation of a Map-Reso= lver and a
>=C2=A0 =C2=A0 =C2=A0Map-Server. Some functions are performed only by Ma= p-Resolvers only
>=C2=A0 =C2=A0 =C2=A0and other different functions are performed by Map-= Servers only.
>
>=C2=A0 =C2=A0 =C2=A0I am not sure what you don=E2=80=99t understand. >
>
> Sure: As I understand it, Map Resolvers process Map Requests, and Map =
> Servers do not (that's what the quoted text seems to say). However= , this
> sentence talks about a Map Server processing a Map Request.=C2=A0 That= 's
> where I am confused.
>
> -Ekr
>
>
>=C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0Dino
>
--000000000000f309a7057705d3ae-- From nobody Sat Sep 29 10:25:07 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39942130DCB; Sat, 29 Sep 2018 10:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 Mvz4vLxdd2J5; Sat, 29 Sep 2018 10:24:54 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1061286D9; Sat, 29 Sep 2018 10:24:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8CBC81C03CA; Sat, 29 Sep 2018 10:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1538241894; bh=t6YSvdD8Wt2W1WwRoDRes2teNwTdiAV7WDYFShFiaG4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XJU99i5iO+4COixlz0fqC6lTSSkoeQ5v6o09DWtEA++CIO8xqU4QC5hQ2n6ADSMx8 lGMwmirVngBvEqmygDMfKJylAVf+3M/kpqH/X0hLOSv6WAfsAez+eQzYvcPM8VoIGH qVQocG/M4Spk2n9iyej3SpWAzU0TlHwmUR7+nmeo= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 5639E1C0331; Sat, 29 Sep 2018 10:24:53 -0700 (PDT) To: Eric Rescorla Cc: Dino Farinacci , IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <9f4b18df-f0f5-49ec-b909-4b92755bbb7b@joelhalpern.com> Date: Sat, 29 Sep 2018 13:24:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 29 Sep 2018 17:24:57 -0000 Like any other flag bits that are not assigned, this would be MBZ on transmission, must be ignored on reception. Once assigned, implementations that support the assignment would do whatever the assigning document says. Very normal procedure. Yours, Joel On 9/29/18 1:22 PM, Eric Rescorla wrote: > > > On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern > wrote: > > With regard to the m-bit, I would prefer that this document leave the > bit reserved, > > > Just trying to think through the interop implications of this. Would it > be must be zero and must ignore? something else? > > -Ekr > > and the LISP mobile node document assign the bit fromthe > registry.  That keeps a clean separation. > > Yours, > Joel > > On 9/29/18 1:05 PM, Eric Rescorla wrote: > > > > > > On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci > > > >> wrote: > > > >     Thanks Eric for your great comments. Like I said in previous > emails, > >     I’ll address the simple things here and then handle all the > security > >     related stuff separately next week. > > > >     I will do the same with Benjamin’s comments as well. And in his > >     reply, send a diff with changes that reflect both Eric and > >     Benjamin’s comments. > > > >      > On Sep 27, 2018, at 5:16 AM, Eric Rescorla > >     >> wrote: > >      > > >      > Rich version of this review at: > >      > https://mozphab-ietf.devsvcdev.mozaws.net/D4115 > >      > > >      > > >      > IMPORTANT > >      > S 5.2. > >      >>     s: This is the SMR-invoked bit.  This bit is set to 1 > when > >     an xTR is > >      >>        sending a Map-Request in response to a received > SMR-based > >     Map- > >      >>        Request. > >      >> > >      >>     m: This is the LISP mobile-node m-bit.  This bit is > set by > >     xTRs that > >      >>        operate as a mobile node as defined in > [I-D.ietf-lisp-mn]. > >      > > >      > This would appear to create a normative reference to this > >     document. To > >      > avoid that, you need to specify how I behave if I receive > it but I > >      > don't implement lisp-mn. > > > >     I am find making it a normative reference but need the > lisp-chairs > >     to comment. I am not sure what the implications of that are. > > > > > > Me neither. Seems like it could go either way. My only interest > is that > > the protocol be unambiguous. > > > > > > > >      > S 5.5. > >      >>        is being mapped from a multicast destination EID. > >      >> > >      >>  5.5.  EID-to-RLOC UDP Map-Reply Message > >      >> > >      >>     A Map-Reply returns an EID-Prefix with a prefix > length that > >     is less > >      >>     than or equal to the EID being requested.  The EID being > >     requested is > >      > > >      > How do I behave if I receive an EID-Prefix that is less > than any > >     of my > >      > mappings. So, I might have mappings for 10.1.0.0/16 > > >      and 10.2.0.0/16 > > >      > and someone asks me for 10.0.0.0/8 > ? > > > > > > I think I'm still unclear on this point. > > > >     Also, when you talk about prefix > >      > length, I assume you mean the length fo the mask? > > > >     Yes, this is explained later in this section. Was that not > helpful?? > > > > > > I found it a bit confusing. It seems to me like there are two > lengths > > involved here: > > > > - The length of the field (4 or 16) > > - The parts of the field that are significant (i.e., the mask) > > > > I had thought that "prefix length" referred to the former, but it > seems > > like here it > > refers to the latter. > > > > > >      > S 5.6. > >      >>     Authentication Data:  This is the message digest used > from > >     the output > >      >>        of the MAC algorithm.  The entire Map-Register > payload is > >      >>        authenticated with this field preset to 0.  After > the MAC is > >      >>        computed, it is placed in this field. > Implementations of > >     this > >      >>        specification MUST include support for HMAC-SHA-1-96 > >     [RFC2404], > >      >>        and support for HMAC-SHA-256-128 [RFC4868] is > RECOMMENDED. > >      > > >      > What prevents replay attacks here? I'm guessing it's the > Map-Version- > >      > Number, but as I understand it, I can set this to 0. > > > >     Well there are many. The nonce can change for each Map-Register > >     sent. Same for Map-Version number as well as the key-id. > > > > > > I think you need to describe the precise process of replay > prevention here. > > > >      > S 6.1. > >      >>     receives an SMR-based Map-Request and the source is > not in the > >      >>     Locator-Set for the stored Map-Cache entry, then the > >     responding Map- > >      >>     Request MUST be sent with an EID destination to the > mapping > >     database > >      >>     system.  Since the mapping database system is a more > secure > >     way to > >      >>     reach an authoritative ETR, it will deliver the > Map-Request > >     to the > >      >>     authoritative source of the mapping data. > >      > > >      > If I'm understanding this correctly, this allows an ETR to > prevent an > >      > ITR from learning that it is no longer the appropriate ETR > for a > >      > prefix. The way this attack works is that before the topology > >     shift, I > >      > send SMRs, thus causing Map-Requests, which, because my > entry is > >      > cached, refresh the cache on the ITR past the topology > shift. I can > >      > keep doing this indefinitely. Am I missing something > > > >     Well if the ETR is being spoofed, then there is Map-Request load, > >     but it won’t corrupt the ITR’s map-cache. The ITR always sends a > >     verifying Map-Request to the mapping system to get the latest and > >     authenticated RLOC-set for the mapping. Rate-limiting is > necessary > >     so each SMR received DOES NOT result in a Map-Requerst to the > >     mapping system. > > > > > > I'm probably just confused here: SMRs go through the mapping > system, not > > directly? If so, I agree that this wont' work. > > > > > >      > S 5. > >      >>       \ |           UDP Length          |        UDP > Checksum > >             | > >      >> > > >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >      >>         | > >             | > >      >>         |                         LISP Message > >              | > >      >>         | > >             | > >      >> > > >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >      > > >      > What do these two diagrams correspond to? v4 and v6? This > needs > >      > explanation. > > > >     It is th entire IP packet sent as a LISP control-message. The > header > >     before the diagrams indicate they are UDP packets. > > > > > > A caption would probably help. > > > >      > S 5.2. > >      >>     P: This is the probe-bit, which indicates that a > Map-Request > >     SHOULD > >      >>        be treated as a Locator reachability probe.  The > receiver > >     SHOULD > >      >>        respond with a Map-Reply with the probe-bit set, > >     indicating that > >      >>        the Map-Reply is a Locator reachability probe > reply, with the > >      >>        nonce copied from the Map-Request.  See RLOC-Probing > >     Section 7.1 > >      >>        for more details. > >      > > >      > How am I supposed to handle this if I am a Map Server. > > > >     It should be ignored. I will add text to reflect this point. > Good point. > > > >      > > >      > S 5.2. > >      >>        receipt. > >      >> > >      >>     L: This is the local-xtr bit.  It is used by an xTR in a > >     LISP site to > >      >>        tell other xTRs in the same site that it is part > of the > >     RLOC-set > >      >>        for the LISP site.  The L-bit is set to 1 when the > RLOC > >     is the > >      >>        sender's IP address. > >      > > >      > Is the xTR supposed to filter this on exiting the site. > > > >     Nope. > > > > > > Won't this cause problems on ingress to another site? > > > >      > S 5.3. > >      >>     originating Map-Request source.  If the RLOC is not > in the > >     Locator- > >      >>     Set, then the ETR MUST send the "verifying > Map-Request" to the > >      >>     "piggybacked" EID.  Doing this forces the "verifying > >     Map-Request" to > >      >>     go through the mapping database system to reach the > >     authoritative > >      >>     source of information about that EID, guarding against > >     RLOC-spoofing > >      >>     in the "piggybacked" mapping data. > >      > > >      > This text here doesn't seem compatible with either of the > two cases > >      > listed in "EID-prefix" above. > > > >     I don’t understand the comment Eric. Maybe because I can’t > find the > >     exact reference to EID-prefix where you think there is a > conflict. > >     Please cite for me. Thanks. > > > > This does seem to have been assigned to the wrong text. > > > > I am referring to: > > > > "   A Map-Reply returns an EID-Prefix with a prefix length that > is less > >     than or equal to the EID being requested.  The EID being > requested is > >     either from the destination field of an IP header of a > Data-Probe or > >     the EID record of a Map-Request.  The RLOCs in the Map-Reply are > > " > > > > versus > > > > "   EID-Prefix:  This prefix is 4 octets for an IPv4 address > family and > >        16 octets for an IPv6 address family when the > EID-Prefix-AFI is 1 > >        or 2, respectively.  For other AFIs [AFI], the length > varies and > >        for the LCAF AFI the format is defined in [RFC8060].  When > a Map- > > " > > > > This is just the question of whether "prefix length" refers to > the field or > > the significant bits of the field. > > > > > > > > > >      > > >      > S 5.4. > >      >>        'Nonce' field. > >      >> > >      >>     Record TTL:  This is the time in minutes the recipient of > >     the Map- > >      >>        Reply will store the mapping.  If the TTL is 0, > the entry > >     MUST be > >      >>        removed from the cache immediately.  If the value is > >     0xffffffff, > >      >>        the recipient can decide locally how long to store the > >     mapping. > >      > > >      > Am I supposed to merge this with previous mappings? REmove > them? > > > >     No replace it. There is text that says this that is not in the > >     packet format description section. > > > > > > OK. > > > > > >      > S 8.3. > >      >>     of the mapping database protocols. > >      >> > >      >>  8.3.  Map-Server Processing > >      >> > >      >>     Once a Map-Server has EID-Prefixes registered by its > client > >     ETRs, it > >      >>     can accept and process Map-Requests for them. > >      > > >      > This section is confusing because the introduction says > that this > >      > function is only performed by Map-Resolvers: > >      > ' > >      > "The LISP Mapping Service defines two new types of > LISP-speaking > >      >   devices: the Map-Resolver, which accepts Map-Requests > from an > >      > Ingress > >      >   Tunnel Router (ITR) and "resolves" the EID-to-RLOC > mapping using a > >      >   mapping database; and the Map-Server, which learns > authoritative > >      > EID- > >      >   to-RLOC mappings from an Egress Tunnel Router (ETR) and > publishes > >      >   them in a database.” > > > >     The document does cover the operation of a Map-Resolver and a > >     Map-Server. Some functions are performed only by > Map-Resolvers only > >     and other different functions are performed by Map-Servers only. > > > >     I am not sure what you don’t understand. > > > > > > Sure: As I understand it, Map Resolvers process Map Requests, and > Map > > Servers do not (that's what the quoted text seems to say). > However, this > > sentence talks about a Map Server processing a Map Request.  That's > > where I am confused. > > > > -Ekr > > > > > >     Thanks, > >     Dino > > > From nobody Sat Sep 29 10:31:41 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012F6130E4C for ; Sat, 29 Sep 2018 10:31:39 -0700 (PDT) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 2sllDCPwG3Ks for ; Sat, 29 Sep 2018 10:31:35 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 0C9141286D9 for ; Sat, 29 Sep 2018 10:31:35 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id f8-v6so8632840ljk.1 for ; Sat, 29 Sep 2018 10:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DbZVzn6HWQ1UDC1kVkbdVRzWFgBMoQJXtuQTYxWq4Kk=; b=lO0QxYg9wCnuBBnfq4S0IzGsU3tNhGeVz8llpscirkZNfOJZc81BjceV6HC9e5nO5e 8XXim5Ear31dWvecu39484DqcPhL04AR4uw+k5JGE/vUOjn3PkV5+6jpXQfctfajJTF/ PjOJlFb6SZEme4OvuUhL/jBRirWHafmfD3nN7GmgYVIuHje8uzlnGcwHv1TVZRVB/TMD pqDsiq+Ym+uAHMDeiW7zuwPt+YG85pjgb9J8BZX5ET6X05KS2zgfK4EVp1MD9jc9VEVC xd7IJ1aHpsedmvYl1wO7XLJ2RLx8GoQdjR5BcY+S1E96GSlTpSdnq1HSrjMi6yVTGxwP joGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DbZVzn6HWQ1UDC1kVkbdVRzWFgBMoQJXtuQTYxWq4Kk=; b=KvP5waFu/YBvnkqRUPH/R8XnOvhONTbAw4XOrz7o6ZnZAJ0VCXv8ftKJM/VG5vL8dz 32glbftPHwvs1qVSzU2LM2+nnO4cgx81GhH8IzcZ0nUvPUSt/JzrZnKLqhgC8s+l5l9K 4OJspi2J9HI5ol3jgwNrMZSG0Ay9/vNVhUSu7yuw84vgir0CILtGohJxg3D0exuYwhd9 uGrT2BjUkOQ84zW5yJCfo5ANPQIIYEP7b2/dLfq3zSEqpi34JnL3O6BXuIoOjdoDvqzs PzrZyQSzonuVT2G0vRO+JX5ivpdduQR/8xuUuuBNscy9M/r+N/gkwd9tVpsms4DDqgwd AY2g== X-Gm-Message-State: ABuFfohdIN3rCbxXFfUmad2XsF7BjfiNJAZ3qdjXNnG1RqNW6IHlMvee uWGORqsuTx15hIa4Fzinx8vBD7TxNioDnCWt9WQv8w== X-Google-Smtp-Source: ACcGV62kBuorI3TeT/fJNgOXRDuTTT1KSK4q4NhYUPoICm0OR/s7vywJXz2tkIl4KyF2dM+eDFkFVyzlqx2yUybujHM= X-Received: by 2002:a2e:4e01:: with SMTP id c1-v6mr2359332ljb.157.1538242293104; Sat, 29 Sep 2018 10:31:33 -0700 (PDT) MIME-Version: 1.0 References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> <9f4b18df-f0f5-49ec-b909-4b92755bbb7b@joelhalpern.com> In-Reply-To: <9f4b18df-f0f5-49ec-b909-4b92755bbb7b@joelhalpern.com> From: Eric Rescorla Date: Sat, 29 Sep 2018 10:30:56 -0700 Message-ID: To: "Joel M. Halpern" Cc: Dino Farinacci , IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000759313057705f17d" Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 29 Sep 2018 17:31:39 -0000 --000000000000759313057705f17d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 29, 2018 at 10:24 AM Joel M. Halpern wrote: > Like any other flag bits that are not assigned, this would be MBZ on > transmission, must be ignored on reception. Once assigned, > implementations that support the assignment would do whatever the > assigning document says. Very normal procedure. > OK, I haven't read the -mn- draft so I don't know if that will have a clean upgrade path. -Ekr > Yours, > Joel > > On 9/29/18 1:22 PM, Eric Rescorla wrote: > > > > > > On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern > > wrote: > > > > With regard to the m-bit, I would prefer that this document leave t= he > > bit reserved, > > > > > > Just trying to think through the interop implications of this. Would it > > be must be zero and must ignore? something else? > > > > -Ekr > > > > and the LISP mobile node document assign the bit fromthe > > registry. That keeps a clean separation. > > > > Yours, > > Joel > > > > On 9/29/18 1:05 PM, Eric Rescorla wrote: > > > > > > > > > On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci > > > > > >> wrote= : > > > > > > Thanks Eric for your great comments. Like I said in previous > > emails, > > > I=E2=80=99ll address the simple things here and then handle = all the > > security > > > related stuff separately next week. > > > > > > I will do the same with Benjamin=E2=80=99s comments as well.= And in > his > > > reply, send a diff with changes that reflect both Eric and > > > Benjamin=E2=80=99s comments. > > > > > > > On Sep 27, 2018, at 5:16 AM, Eric Rescorla > > > > >> wrote: > > > > > > > > Rich version of this review at: > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D4115 > > > > > > > > > > > > IMPORTANT > > > > S 5.2. > > > >> s: This is the SMR-invoked bit. This bit is set to = 1 > > when > > > an xTR is > > > >> sending a Map-Request in response to a received > > SMR-based > > > Map- > > > >> Request. > > > >> > > > >> m: This is the LISP mobile-node m-bit. This bit is > > set by > > > xTRs that > > > >> operate as a mobile node as defined in > > [I-D.ietf-lisp-mn]. > > > > > > > > This would appear to create a normative reference to this > > > document. To > > > > avoid that, you need to specify how I behave if I receive > > it but I > > > > don't implement lisp-mn. > > > > > > I am find making it a normative reference but need the > > lisp-chairs > > > to comment. I am not sure what the implications of that are. > > > > > > > > > Me neither. Seems like it could go either way. My only interest > > is that > > > the protocol be unambiguous. > > > > > > > > > > > > > S 5.5. > > > >> is being mapped from a multicast destination EID. > > > >> > > > >> 5.5. EID-to-RLOC UDP Map-Reply Message > > > >> > > > >> A Map-Reply returns an EID-Prefix with a prefix > > length that > > > is less > > > >> than or equal to the EID being requested. The EID > being > > > requested is > > > > > > > > How do I behave if I receive an EID-Prefix that is less > > than any > > > of my > > > > mappings. So, I might have mappings for 10.1.0.0/16 > > > > > and 10.2.0.0/16 > > > > > > and someone asks me for 10.0.0.0/8 > > ? > > > > > > > > > I think I'm still unclear on this point. > > > > > > Also, when you talk about prefix > > > > length, I assume you mean the length fo the mask? > > > > > > Yes, this is explained later in this section. Was that not > > helpful?? > > > > > > > > > I found it a bit confusing. It seems to me like there are two > > lengths > > > involved here: > > > > > > - The length of the field (4 or 16) > > > - The parts of the field that are significant (i.e., the mask) > > > > > > I had thought that "prefix length" referred to the former, but i= t > > seems > > > like here it > > > refers to the latter. > > > > > > > > > > S 5.6. > > > >> Authentication Data: This is the message digest use= d > > from > > > the output > > > >> of the MAC algorithm. The entire Map-Register > > payload is > > > >> authenticated with this field preset to 0. After > > the MAC is > > > >> computed, it is placed in this field. > > Implementations of > > > this > > > >> specification MUST include support for > HMAC-SHA-1-96 > > > [RFC2404], > > > >> and support for HMAC-SHA-256-128 [RFC4868] is > > RECOMMENDED. > > > > > > > > What prevents replay attacks here? I'm guessing it's the > > Map-Version- > > > > Number, but as I understand it, I can set this to 0. > > > > > > Well there are many. The nonce can change for each > Map-Register > > > sent. Same for Map-Version number as well as the key-id. > > > > > > > > > I think you need to describe the precise process of replay > > prevention here. > > > > > > > S 6.1. > > > >> receives an SMR-based Map-Request and the source is > > not in the > > > >> Locator-Set for the stored Map-Cache entry, then the > > > responding Map- > > > >> Request MUST be sent with an EID destination to the > > mapping > > > database > > > >> system. Since the mapping database system is a more > > secure > > > way to > > > >> reach an authoritative ETR, it will deliver the > > Map-Request > > > to the > > > >> authoritative source of the mapping data. > > > > > > > > If I'm understanding this correctly, this allows an ETR t= o > > prevent an > > > > ITR from learning that it is no longer the appropriate ET= R > > for a > > > > prefix. The way this attack works is that before the > topology > > > shift, I > > > > send SMRs, thus causing Map-Requests, which, because my > > entry is > > > > cached, refresh the cache on the ITR past the topology > > shift. I can > > > > keep doing this indefinitely. Am I missing something > > > > > > Well if the ETR is being spoofed, then there is Map-Request > load, > > > but it won=E2=80=99t corrupt the ITR=E2=80=99s map-cache. Th= e ITR always > sends a > > > verifying Map-Request to the mapping system to get the lates= t > and > > > authenticated RLOC-set for the mapping. Rate-limiting is > > necessary > > > so each SMR received DOES NOT result in a Map-Requerst to th= e > > > mapping system. > > > > > > > > > I'm probably just confused here: SMRs go through the mapping > > system, not > > > directly? If so, I agree that this wont' work. > > > > > > > > > > S 5. > > > >> \ | UDP Length | UDP > > Checksum > > > | > > > >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >> | > > > | > > > >> | LISP Message > > > | > > > >> | > > > | > > > >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > What do these two diagrams correspond to? v4 and v6? This > > needs > > > > explanation. > > > > > > It is th entire IP packet sent as a LISP control-message. Th= e > > header > > > before the diagrams indicate they are UDP packets. > > > > > > > > > A caption would probably help. > > > > > > > S 5.2. > > > >> P: This is the probe-bit, which indicates that a > > Map-Request > > > SHOULD > > > >> be treated as a Locator reachability probe. The > > receiver > > > SHOULD > > > >> respond with a Map-Reply with the probe-bit set, > > > indicating that > > > >> the Map-Reply is a Locator reachability probe > > reply, with the > > > >> nonce copied from the Map-Request. See > RLOC-Probing > > > Section 7.1 > > > >> for more details. > > > > > > > > How am I supposed to handle this if I am a Map Server. > > > > > > It should be ignored. I will add text to reflect this point. > > Good point. > > > > > > > > > > > S 5.2. > > > >> receipt. > > > >> > > > >> L: This is the local-xtr bit. It is used by an xTR > in a > > > LISP site to > > > >> tell other xTRs in the same site that it is part > > of the > > > RLOC-set > > > >> for the LISP site. The L-bit is set to 1 when th= e > > RLOC > > > is the > > > >> sender's IP address. > > > > > > > > Is the xTR supposed to filter this on exiting the site. > > > > > > Nope. > > > > > > > > > Won't this cause problems on ingress to another site? > > > > > > > S 5.3. > > > >> originating Map-Request source. If the RLOC is not > > in the > > > Locator- > > > >> Set, then the ETR MUST send the "verifying > > Map-Request" to the > > > >> "piggybacked" EID. Doing this forces the "verifying > > > Map-Request" to > > > >> go through the mapping database system to reach the > > > authoritative > > > >> source of information about that EID, guarding again= st > > > RLOC-spoofing > > > >> in the "piggybacked" mapping data. > > > > > > > > This text here doesn't seem compatible with either of the > > two cases > > > > listed in "EID-prefix" above. > > > > > > I don=E2=80=99t understand the comment Eric. Maybe because I= can=E2=80=99t > > find the > > > exact reference to EID-prefix where you think there is a > > conflict. > > > Please cite for me. Thanks. > > > > > > This does seem to have been assigned to the wrong text. > > > > > > I am referring to: > > > > > > " A Map-Reply returns an EID-Prefix with a prefix length that > > is less > > > than or equal to the EID being requested. The EID being > > requested is > > > either from the destination field of an IP header of a > > Data-Probe or > > > the EID record of a Map-Request. The RLOCs in the Map-Reply > are > > > " > > > > > > versus > > > > > > " EID-Prefix: This prefix is 4 octets for an IPv4 address > > family and > > > 16 octets for an IPv6 address family when the > > EID-Prefix-AFI is 1 > > > or 2, respectively. For other AFIs [AFI], the length > > varies and > > > for the LCAF AFI the format is defined in [RFC8060]. Whe= n > > a Map- > > > " > > > > > > This is just the question of whether "prefix length" refers to > > the field or > > > the significant bits of the field. > > > > > > > > > > > > > > > > > > > > S 5.4. > > > >> 'Nonce' field. > > > >> > > > >> Record TTL: This is the time in minutes the > recipient of > > > the Map- > > > >> Reply will store the mapping. If the TTL is 0, > > the entry > > > MUST be > > > >> removed from the cache immediately. If the value > is > > > 0xffffffff, > > > >> the recipient can decide locally how long to stor= e > the > > > mapping. > > > > > > > > Am I supposed to merge this with previous mappings? REmov= e > > them? > > > > > > No replace it. There is text that says this that is not in t= he > > > packet format description section. > > > > > > > > > OK. > > > > > > > > > > S 8.3. > > > >> of the mapping database protocols. > > > >> > > > >> 8.3. Map-Server Processing > > > >> > > > >> Once a Map-Server has EID-Prefixes registered by its > > client > > > ETRs, it > > > >> can accept and process Map-Requests for them. > > > > > > > > This section is confusing because the introduction says > > that this > > > > function is only performed by Map-Resolvers: > > > > ' > > > > "The LISP Mapping Service defines two new types of > > LISP-speaking > > > > devices: the Map-Resolver, which accepts Map-Requests > > from an > > > > Ingress > > > > Tunnel Router (ITR) and "resolves" the EID-to-RLOC > > mapping using a > > > > mapping database; and the Map-Server, which learns > > authoritative > > > > EID- > > > > to-RLOC mappings from an Egress Tunnel Router (ETR) and > > publishes > > > > them in a database.=E2=80=9D > > > > > > The document does cover the operation of a Map-Resolver and = a > > > Map-Server. Some functions are performed only by > > Map-Resolvers only > > > and other different functions are performed by Map-Servers > only. > > > > > > I am not sure what you don=E2=80=99t understand. > > > > > > > > > Sure: As I understand it, Map Resolvers process Map Requests, an= d > > Map > > > Servers do not (that's what the quoted text seems to say). > > However, this > > > sentence talks about a Map Server processing a Map Request. > That's > > > where I am confused. > > > > > > -Ekr > > > > > > > > > Thanks, > > > Dino > > > > > > --000000000000759313057705f17d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Like any other flag bits that are not assigned, this would be MB= Z on
transmission, must be ignored on reception.=C2=A0 Once assigned,
implementations that support the assignment would do whatever the
assigning document says.=C2=A0 Very normal procedure.
=
OK, I haven't read the -mn- draft so I don't know if= that will have a clean upgrade path.

-Ekr


Yours,
Joel

On 9/29/18 1:22 PM, Eric Rescorla wrote:
>
>
> On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern <jmh@joelhalpern.com
> <mailto:jm= h@joelhalpern.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0With regard to the m-bit, I would prefer that this = document leave the
>=C2=A0 =C2=A0 =C2=A0bit reserved,
>
>
> Just trying to think through the interop implications of this. Would i= t
> be must be zero and must ignore? something else?
>
> -Ekr
>
>=C2=A0 =C2=A0 =C2=A0and the LISP mobile node document assign the bit fr= omthe
>=C2=A0 =C2=A0 =C2=A0registry.=C2=A0 That keeps a clean separation.
>
>=C2=A0 =C2=A0 =C2=A0Yours,
>=C2=A0 =C2=A0 =C2=A0Joel
>
>=C2=A0 =C2=A0 =C2=A0On 9/29/18 1:05 PM, Eric Rescorla wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacc= i
>=C2=A0 =C2=A0 =C2=A0<farinacci@gmail.com <mailto:farinacci@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:farinacci@gmail.com <mailto:farinacci@gmail.com>>>= wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Thanks Eric for your great= comments. Like I said in previous
>=C2=A0 =C2=A0 =C2=A0emails,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I=E2=80=99ll address the s= imple things here and then handle all the
>=C2=A0 =C2=A0 =C2=A0security
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0related stuff separately n= ext week.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I will do the same with Be= njamin=E2=80=99s comments as well. And in his
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0reply, send a diff with ch= anges that reflect both Eric and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Benjamin=E2=80=99s comment= s.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On Sep 27, 2018, at = 5:16 AM, Eric Rescorla <ekr@rtfm.com
>=C2=A0 =C2=A0 =C2=A0<mailto:ekr@rtfm.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:ekr@rtfm.com <mailto:ekr@rtfm.com>>> wrote: >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Rich version of this= review at:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > https://mozphab-ietf.devsvcdev.mozaws.net/D4115
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > IMPORTANT
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > S 5.2.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0s: This is the SMR-invoked bit.=C2=A0 This bit is set to 1
>=C2=A0 =C2=A0 =C2=A0when
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0an xTR is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 sending a Map-Request in response to a received
>=C2=A0 =C2=A0 =C2=A0SMR-based
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Map-
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Request.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0m: This is the LISP mobile-node m-bit.=C2=A0 This bit is
>=C2=A0 =C2=A0 =C2=A0set by
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0xTRs that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 operate as a mobile node as defined in
>=C2=A0 =C2=A0 =C2=A0[I-D.ietf-lisp-mn].
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > This would appear to= create a normative reference to this
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0document. To
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > avoid that, you need= to specify how I behave if I receive
>=C2=A0 =C2=A0 =C2=A0it but I
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > don't implement = lisp-mn.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I am find making it a norm= ative reference but need the
>=C2=A0 =C2=A0 =C2=A0lisp-chairs
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to comment. I am not sure = what the implications of that are.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Me neither. Seems like it could go either way= . My only interest
>=C2=A0 =C2=A0 =C2=A0is that
>=C2=A0 =C2=A0 =C2=A0 > the protocol be unambiguous.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > S 5.5.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 is being mapped from a multicast destination EID.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 5.5.=C2=A0= EID-to-RLOC UDP Map-Reply Message
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0A Map-Reply returns an EID-Prefix with a prefix
>=C2=A0 =C2=A0 =C2=A0length that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0is less
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0than or equal to the EID being requested.=C2=A0 The EID being
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0requested is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > How do I behave if I= receive an EID-Prefix that is less
>=C2=A0 =C2=A0 =C2=A0than any
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0of my
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > mappings. So, I migh= t have mappings for 10.1.0.0/16
>=C2=A0 =C2=A0 =C2=A0<http://10.1.0.0/16>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<http://10.1.0.0/16> an= d 10.2.= 0.0/16 <http://10.2.0.0/16>
>=C2=A0 =C2=A0 =C2=A0<http://10.2.0.0/16>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > and someone asks me = for 10.0= .0.0/8 <http://10.0.0.0/8>
>=C2=A0 =C2=A0 =C2=A0<http://10.0.0.0/8>?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I think I'm still unclear on this point.<= br> >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Also, when you talk about = prefix
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > length, I assume you= mean the length fo the mask?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Yes, this is explained lat= er in this section. Was that not
>=C2=A0 =C2=A0 =C2=A0helpful??
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I found it a bit confusing. It seems to me li= ke there are two
>=C2=A0 =C2=A0 =C2=A0lengths
>=C2=A0 =C2=A0 =C2=A0 > involved here:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > - The length of the field (4 or 16)
>=C2=A0 =C2=A0 =C2=A0 > - The parts of the field that are significant= (i.e., the mask)
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I had thought that "prefix length" = referred to the former, but it
>=C2=A0 =C2=A0 =C2=A0seems
>=C2=A0 =C2=A0 =C2=A0 > like here it
>=C2=A0 =C2=A0 =C2=A0 > refers to the latter.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > S 5.6.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0Authentication Data:=C2=A0 This is the message digest used
>=C2=A0 =C2=A0 =C2=A0from
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the output
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 of the MAC algorithm.=C2=A0 The entire Map-Register
>=C2=A0 =C2=A0 =C2=A0payload is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 authenticated with this field preset to 0.=C2=A0 After
>=C2=A0 =C2=A0 =C2=A0the MAC is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 computed, it is placed in this field.
>=C2=A0 =C2=A0 =C2=A0Implementations of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0this
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 specification MUST include support for HMAC-SHA-1-96
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[RFC2404],
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 and support for HMAC-SHA-256-128 [RFC4868] is
>=C2=A0 =C2=A0 =C2=A0RECOMMENDED.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > What prevents replay= attacks here? I'm guessing it's the
>=C2=A0 =C2=A0 =C2=A0Map-Version-
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Number, but as I und= erstand it, I can set this to 0.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Well there are many. The n= once can change for each Map-Register
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0sent. Same for Map-Version= number as well as the key-id.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I think you need to describe the precise proc= ess of replay
>=C2=A0 =C2=A0 =C2=A0prevention here.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > S 6.1.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0receives an SMR-based Map-Request and the source is
>=C2=A0 =C2=A0 =C2=A0not in the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0Locator-Set for the stored Map-Cache entry, then the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0responding Map-
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0Request MUST be sent with an EID destination to the
>=C2=A0 =C2=A0 =C2=A0mapping
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0database
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0system.=C2=A0 Since the mapping database system is a more
>=C2=A0 =C2=A0 =C2=A0secure
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0way to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0reach an authoritative ETR, it will deliver the
>=C2=A0 =C2=A0 =C2=A0Map-Request
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0authoritative source of the mapping data.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > If I'm understan= ding this correctly, this allows an ETR to
>=C2=A0 =C2=A0 =C2=A0prevent an
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > ITR from learning th= at it is no longer the appropriate ETR
>=C2=A0 =C2=A0 =C2=A0for a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > prefix. The way this= attack works is that before the topology
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0shift, I
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > send SMRs, thus caus= ing Map-Requests, which, because my
>=C2=A0 =C2=A0 =C2=A0entry is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > cached, refresh the = cache on the ITR past the topology
>=C2=A0 =C2=A0 =C2=A0shift. I can
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > keep doing this inde= finitely. Am I missing something
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Well if the ETR is being s= poofed, then there is Map-Request load,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0but it won=E2=80=99t corru= pt the ITR=E2=80=99s map-cache. The ITR always sends a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0verifying Map-Request to t= he mapping system to get the latest and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0authenticated RLOC-set for= the mapping. Rate-limiting is
>=C2=A0 =C2=A0 =C2=A0necessary
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0so each SMR received DOES = NOT result in a Map-Requerst to the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0mapping system.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I'm probably just confused here: SMRs go = through the mapping
>=C2=A0 =C2=A0 =C2=A0system, not
>=C2=A0 =C2=A0 =C2=A0 > directly? If so, I agree that this wont' = work.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > S 5.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0\ |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UDP Length=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 UDP
>=C2=A0 =C2=A0 =C2=A0Checksum
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LISP Message
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > What do these two di= agrams correspond to? v4 and v6? This
>=C2=A0 =C2=A0 =C2=A0needs
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > explanation.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0It is th entire IP packet = sent as a LISP control-message. The
>=C2=A0 =C2=A0 =C2=A0header
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0before the diagrams indica= te they are UDP packets.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > A caption would probably help.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > S 5.2.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0P: This is the probe-bit, which indicates that a
>=C2=A0 =C2=A0 =C2=A0Map-Request
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0SHOULD
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 be treated as a Locator reachability probe.=C2=A0 The
>=C2=A0 =C2=A0 =C2=A0receiver
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0SHOULD
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 respond with a Map-Reply with the probe-bit set,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0indicating that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 the Map-Reply is a Locator reachability probe
>=C2=A0 =C2=A0 =C2=A0reply, with the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 nonce copied from the Map-Request.=C2=A0 See RLOC-Probing
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Section 7.1
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 for more details.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > How am I supposed to= handle this if I am a Map Server.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0It should be ignored. I wi= ll add text to reflect this point.
>=C2=A0 =C2=A0 =C2=A0Good point.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > S 5.2.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 receipt.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0L: This is the local-xtr bit.=C2=A0 It is used by an xTR in a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0LISP site to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 tell other xTRs in the same site that it is part
>=C2=A0 =C2=A0 =C2=A0of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0RLOC-set
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 for the LISP site.=C2=A0 The L-bit is set to 1 when the
>=C2=A0 =C2=A0 =C2=A0RLOC
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0is the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 sender's IP address.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Is the xTR supposed = to filter this on exiting the site.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Nope.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Won't this cause problems on ingress to a= nother site?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > S 5.3.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0originating Map-Request source.=C2=A0 If the RLOC is not
>=C2=A0 =C2=A0 =C2=A0in the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Locator-
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0Set, then the ETR MUST send the "verifying
>=C2=A0 =C2=A0 =C2=A0Map-Request" to the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0"piggybacked" EID.=C2=A0 Doing this forces the "verifying=
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Map-Request" to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0go through the mapping database system to reach the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0authoritative
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0source of information about that EID, guarding against
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0RLOC-spoofing
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0in the "piggybacked" mapping data.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > This text here doesn= 't seem compatible with either of the
>=C2=A0 =C2=A0 =C2=A0two cases
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > listed in "EID-= prefix" above.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I don=E2=80=99t understand= the comment Eric. Maybe because I can=E2=80=99t
>=C2=A0 =C2=A0 =C2=A0find the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0exact reference to EID-pre= fix where you think there is a
>=C2=A0 =C2=A0 =C2=A0conflict.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Please cite for me. Thanks= .
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > This does seem to have been assigned to the w= rong text.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I am referring to:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > "=C2=A0=C2=A0 A Map-Reply returns an EID= -Prefix with a prefix length that
>=C2=A0 =C2=A0 =C2=A0is less
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0=C2=A0 than or equal to the EID b= eing requested.=C2=A0 The EID being
>=C2=A0 =C2=A0 =C2=A0requested is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0=C2=A0 either from the destinatio= n field of an IP header of a
>=C2=A0 =C2=A0 =C2=A0Data-Probe or
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0=C2=A0 the EID record of a Map-Re= quest.=C2=A0 The RLOCs in the Map-Reply are
>=C2=A0 =C2=A0 =C2=A0 > "
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > versus
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > "=C2=A0=C2=A0 EID-Prefix:=C2=A0 This pre= fix is 4 octets for an IPv4 address
>=C2=A0 =C2=A0 =C2=A0family and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16 octet= s for an IPv6 address family when the
>=C2=A0 =C2=A0 =C2=A0EID-Prefix-AFI is 1
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or 2, re= spectively.=C2=A0 For other AFIs [AFI], the length
>=C2=A0 =C2=A0 =C2=A0varies and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for the = LCAF AFI the format is defined in [RFC8060].=C2=A0 When
>=C2=A0 =C2=A0 =C2=A0a Map-
>=C2=A0 =C2=A0 =C2=A0 > "
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > This is just the question of whether "pr= efix length" refers to
>=C2=A0 =C2=A0 =C2=A0the field or
>=C2=A0 =C2=A0 =C2=A0 > the significant bits of the field.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > S 5.4.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 'Nonce' field.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0Record TTL:=C2=A0 This is the time in minutes the recipient of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the Map-
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Reply will store the mapping.=C2=A0 If the TTL is 0,
>=C2=A0 =C2=A0 =C2=A0the entry
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0MUST be
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 removed from the cache immediately.=C2=A0 If the value is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A00xffffffff,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 the recipient can decide locally how long to store the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0mapping.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Am I supposed to mer= ge this with previous mappings? REmove
>=C2=A0 =C2=A0 =C2=A0them?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0No replace it. There is te= xt that says this that is not in the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0packet format description = section.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > OK.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > S 8.3.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0of the mapping database protocols.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 8.3.=C2=A0= Map-Server Processing
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0Once a Map-Server has EID-Prefixes registered by its
>=C2=A0 =C2=A0 =C2=A0client
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0ETRs, it
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2= =A0can accept and process Map-Requests for them.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > This section is conf= using because the introduction says
>=C2=A0 =C2=A0 =C2=A0that this
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > function is only per= formed by Map-Resolvers:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > '
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > "The LISP Mappi= ng Service defines two new types of
>=C2=A0 =C2=A0 =C2=A0LISP-speaking
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0devices:= the Map-Resolver, which accepts Map-Requests
>=C2=A0 =C2=A0 =C2=A0from an
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Ingress
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0Tunnel R= outer (ITR) and "resolves" the EID-to-RLOC
>=C2=A0 =C2=A0 =C2=A0mapping using a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0mapping = database; and the Map-Server, which learns
>=C2=A0 =C2=A0 =C2=A0authoritative
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > EID-
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0to-RLOC = mappings from an Egress Tunnel Router (ETR) and
>=C2=A0 =C2=A0 =C2=A0publishes
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0them in = a database.=E2=80=9D
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0The document does cover th= e operation of a Map-Resolver and a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Map-Server. Some functions= are performed only by
>=C2=A0 =C2=A0 =C2=A0Map-Resolvers only
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0and other different functi= ons are performed by Map-Servers only.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I am not sure what you don= =E2=80=99t understand.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Sure: As I understand it, Map Resolvers proce= ss Map Requests, and
>=C2=A0 =C2=A0 =C2=A0Map
>=C2=A0 =C2=A0 =C2=A0 > Servers do not (that's what the quoted te= xt seems to say).
>=C2=A0 =C2=A0 =C2=A0However, this
>=C2=A0 =C2=A0 =C2=A0 > sentence talks about a Map Server processing = a Map Request.=C2=A0 That's
>=C2=A0 =C2=A0 =C2=A0 > where I am confused.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > -Ekr
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Dino
>=C2=A0 =C2=A0 =C2=A0 >
>
--000000000000759313057705f17d-- From nobody Sat Sep 29 10:42:17 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB8F130DCD; Sat, 29 Sep 2018 10:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 3yj8I3bVTlv5; Sat, 29 Sep 2018 10:42:04 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71893130DCB; Sat, 29 Sep 2018 10:42:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 44073581C3F; Sat, 29 Sep 2018 10:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1538242924; bh=hXY+XlD56HG2/KInvxn7otVXEGU+efUkp50ufFwjkGU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=OmK5Z56FKJxhV0AWnUfHnIYjmZp+k4aOqKv48L5hr2j69RajxveowQNNyxnMk4cUo UDo7uAExICa9QXTpjslx/rNpiwYGDukTzVlVrKWuytp2+rLGpgW/YiVAcLCrP5WJGH p73Ran7GSNK8TEGTTsfWF2bGzWC9P5v63+lbiu9E= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 25D2B1C0331; Sat, 29 Sep 2018 10:42:02 -0700 (PDT) To: Eric Rescorla Cc: Dino Farinacci , IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> <9f4b18df-f0f5-49ec-b909-4b92755bbb7b@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <2c23c59a-2dfd-d35b-c21f-91eff3804e8d@joelhalpern.com> Date: Sat, 29 Sep 2018 13:42:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 29 Sep 2018 17:42:09 -0000 This draft explicitly states that the m-bit can be ignored by nodes that do not support the lisp mobile node behavior. Which seems pretty clear that it is nicely separable. Yours, Joel On 9/29/18 1:30 PM, Eric Rescorla wrote: > > > On Sat, Sep 29, 2018 at 10:24 AM Joel M. Halpern > wrote: > > Like any other flag bits that are not assigned, this would be MBZ on > transmission, must be ignored on reception.  Once assigned, > implementations that support the assignment would do whatever the > assigning document says.  Very normal procedure. > > > OK, I haven't read the -mn- draft so I don't know if that will have a > clean upgrade path. > > -Ekr > > > Yours, > Joel > > On 9/29/18 1:22 PM, Eric Rescorla wrote: > > > > > > On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern > > > >> wrote: > > > >     With regard to the m-bit, I would prefer that this document > leave the > >     bit reserved, > > > > > > Just trying to think through the interop implications of this. > Would it > > be must be zero and must ignore? something else? > > > > -Ekr > > > >     and the LISP mobile node document assign the bit fromthe > >     registry.  That keeps a clean separation. > > > >     Yours, > >     Joel > > > >     On 9/29/18 1:05 PM, Eric Rescorla wrote: > >      > > >      > > >      > On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci > >      > > > >      > > >>> wrote: > >      > > >      >     Thanks Eric for your great comments. Like I said in > previous > >     emails, > >      >     I’ll address the simple things here and then handle > all the > >     security > >      >     related stuff separately next week. > >      > > >      >     I will do the same with Benjamin’s comments as well. > And in his > >      >     reply, send a diff with changes that reflect both Eric and > >      >     Benjamin’s comments. > >      > > >      >      > On Sep 27, 2018, at 5:16 AM, Eric Rescorla > > >     > > >      >      > >>> wrote: > >      >      > > >      >      > Rich version of this review at: > >      >      > https://mozphab-ietf.devsvcdev.mozaws.net/D4115 > >      >      > > >      >      > > >      >      > IMPORTANT > >      >      > S 5.2. > >      >      >>     s: This is the SMR-invoked bit.  This bit is > set to 1 > >     when > >      >     an xTR is > >      >      >>        sending a Map-Request in response to a received > >     SMR-based > >      >     Map- > >      >      >>        Request. > >      >      >> > >      >      >>     m: This is the LISP mobile-node m-bit.  This > bit is > >     set by > >      >     xTRs that > >      >      >>        operate as a mobile node as defined in > >     [I-D.ietf-lisp-mn]. > >      >      > > >      >      > This would appear to create a normative reference > to this > >      >     document. To > >      >      > avoid that, you need to specify how I behave if I > receive > >     it but I > >      >      > don't implement lisp-mn. > >      > > >      >     I am find making it a normative reference but need the > >     lisp-chairs > >      >     to comment. I am not sure what the implications of > that are. > >      > > >      > > >      > Me neither. Seems like it could go either way. My only > interest > >     is that > >      > the protocol be unambiguous. > >      > > >      > > >      > > >      >      > S 5.5. > >      >      >>        is being mapped from a multicast > destination EID. > >      >      >> > >      >      >>  5.5.  EID-to-RLOC UDP Map-Reply Message > >      >      >> > >      >      >>     A Map-Reply returns an EID-Prefix with a prefix > >     length that > >      >     is less > >      >      >>     than or equal to the EID being requested.  The > EID being > >      >     requested is > >      >      > > >      >      > How do I behave if I receive an EID-Prefix that is less > >     than any > >      >     of my > >      >      > mappings. So, I might have mappings for 10.1.0.0/16 > > >      > >      >      and 10.2.0.0/16 > > >      > >      >      > and someone asks me for 10.0.0.0/8 > > >     ? > >      > > >      > > >      > I think I'm still unclear on this point. > >      > > >      >     Also, when you talk about prefix > >      >      > length, I assume you mean the length fo the mask? > >      > > >      >     Yes, this is explained later in this section. Was that not > >     helpful?? > >      > > >      > > >      > I found it a bit confusing. It seems to me like there are two > >     lengths > >      > involved here: > >      > > >      > - The length of the field (4 or 16) > >      > - The parts of the field that are significant (i.e., the mask) > >      > > >      > I had thought that "prefix length" referred to the former, > but it > >     seems > >      > like here it > >      > refers to the latter. > >      > > >      > > >      >      > S 5.6. > >      >      >>     Authentication Data:  This is the message > digest used > >     from > >      >     the output > >      >      >>        of the MAC algorithm.  The entire Map-Register > >     payload is > >      >      >>        authenticated with this field preset to 0. > After > >     the MAC is > >      >      >>        computed, it is placed in this field. > >     Implementations of > >      >     this > >      >      >>        specification MUST include support for > HMAC-SHA-1-96 > >      >     [RFC2404], > >      >      >>        and support for HMAC-SHA-256-128 [RFC4868] is > >     RECOMMENDED. > >      >      > > >      >      > What prevents replay attacks here? I'm guessing > it's the > >     Map-Version- > >      >      > Number, but as I understand it, I can set this to 0. > >      > > >      >     Well there are many. The nonce can change for each > Map-Register > >      >     sent. Same for Map-Version number as well as the key-id. > >      > > >      > > >      > I think you need to describe the precise process of replay > >     prevention here. > >      > > >      >      > S 6.1. > >      >      >>     receives an SMR-based Map-Request and the > source is > >     not in the > >      >      >>     Locator-Set for the stored Map-Cache entry, > then the > >      >     responding Map- > >      >      >>     Request MUST be sent with an EID destination > to the > >     mapping > >      >     database > >      >      >>     system.  Since the mapping database system is > a more > >     secure > >      >     way to > >      >      >>     reach an authoritative ETR, it will deliver the > >     Map-Request > >      >     to the > >      >      >>     authoritative source of the mapping data. > >      >      > > >      >      > If I'm understanding this correctly, this allows an > ETR to > >     prevent an > >      >      > ITR from learning that it is no longer the > appropriate ETR > >     for a > >      >      > prefix. The way this attack works is that before > the topology > >      >     shift, I > >      >      > send SMRs, thus causing Map-Requests, which, because my > >     entry is > >      >      > cached, refresh the cache on the ITR past the topology > >     shift. I can > >      >      > keep doing this indefinitely. Am I missing something > >      > > >      >     Well if the ETR is being spoofed, then there is > Map-Request load, > >      >     but it won’t corrupt the ITR’s map-cache. The ITR > always sends a > >      >     verifying Map-Request to the mapping system to get the > latest and > >      >     authenticated RLOC-set for the mapping. Rate-limiting is > >     necessary > >      >     so each SMR received DOES NOT result in a Map-Requerst > to the > >      >     mapping system. > >      > > >      > > >      > I'm probably just confused here: SMRs go through the mapping > >     system, not > >      > directly? If so, I agree that this wont' work. > >      > > >      > > >      >      > S 5. > >      >      >>       \ |           UDP Length          |        UDP > >     Checksum > >      >             | > >      >      >> > >      > > > >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >      >      >>         | > >      >             | > >      >      >>         |                         LISP Message > >      >              | > >      >      >>         | > >      >             | > >      >      >> > >      > > > >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >      >      > > >      >      > What do these two diagrams correspond to? v4 and > v6? This > >     needs > >      >      > explanation. > >      > > >      >     It is th entire IP packet sent as a LISP > control-message. The > >     header > >      >     before the diagrams indicate they are UDP packets. > >      > > >      > > >      > A caption would probably help. > >      > > >      >      > S 5.2. > >      >      >>     P: This is the probe-bit, which indicates that a > >     Map-Request > >      >     SHOULD > >      >      >>        be treated as a Locator reachability > probe.  The > >     receiver > >      >     SHOULD > >      >      >>        respond with a Map-Reply with the probe-bit > set, > >      >     indicating that > >      >      >>        the Map-Reply is a Locator reachability probe > >     reply, with the > >      >      >>        nonce copied from the Map-Request.  See > RLOC-Probing > >      >     Section 7.1 > >      >      >>        for more details. > >      >      > > >      >      > How am I supposed to handle this if I am a Map Server. > >      > > >      >     It should be ignored. I will add text to reflect this > point. > >     Good point. > >      > > >      >      > > >      >      > S 5.2. > >      >      >>        receipt. > >      >      >> > >      >      >>     L: This is the local-xtr bit.  It is used by > an xTR in a > >      >     LISP site to > >      >      >>        tell other xTRs in the same site that it is > part > >     of the > >      >     RLOC-set > >      >      >>        for the LISP site.  The L-bit is set to 1 > when the > >     RLOC > >      >     is the > >      >      >>        sender's IP address. > >      >      > > >      >      > Is the xTR supposed to filter this on exiting the site. > >      > > >      >     Nope. > >      > > >      > > >      > Won't this cause problems on ingress to another site? > >      > > >      >      > S 5.3. > >      >      >>     originating Map-Request source.  If the RLOC > is not > >     in the > >      >     Locator- > >      >      >>     Set, then the ETR MUST send the "verifying > >     Map-Request" to the > >      >      >>     "piggybacked" EID.  Doing this forces the > "verifying > >      >     Map-Request" to > >      >      >>     go through the mapping database system to > reach the > >      >     authoritative > >      >      >>     source of information about that EID, guarding > against > >      >     RLOC-spoofing > >      >      >>     in the "piggybacked" mapping data. > >      >      > > >      >      > This text here doesn't seem compatible with either > of the > >     two cases > >      >      > listed in "EID-prefix" above. > >      > > >      >     I don’t understand the comment Eric. Maybe because I can’t > >     find the > >      >     exact reference to EID-prefix where you think there is a > >     conflict. > >      >     Please cite for me. Thanks. > >      > > >      > This does seem to have been assigned to the wrong text. > >      > > >      > I am referring to: > >      > > >      > "   A Map-Reply returns an EID-Prefix with a prefix length > that > >     is less > >      >     than or equal to the EID being requested.  The EID being > >     requested is > >      >     either from the destination field of an IP header of a > >     Data-Probe or > >      >     the EID record of a Map-Request.  The RLOCs in the > Map-Reply are > >      > " > >      > > >      > versus > >      > > >      > "   EID-Prefix:  This prefix is 4 octets for an IPv4 address > >     family and > >      >        16 octets for an IPv6 address family when the > >     EID-Prefix-AFI is 1 > >      >        or 2, respectively.  For other AFIs [AFI], the length > >     varies and > >      >        for the LCAF AFI the format is defined in > [RFC8060].  When > >     a Map- > >      > " > >      > > >      > This is just the question of whether "prefix length" refers to > >     the field or > >      > the significant bits of the field. > >      > > >      > > >      > > >      > > >      >      > > >      >      > S 5.4. > >      >      >>        'Nonce' field. > >      >      >> > >      >      >>     Record TTL:  This is the time in minutes the > recipient of > >      >     the Map- > >      >      >>        Reply will store the mapping.  If the TTL is 0, > >     the entry > >      >     MUST be > >      >      >>        removed from the cache immediately.  If the > value is > >      >     0xffffffff, > >      >      >>        the recipient can decide locally how long > to store the > >      >     mapping. > >      >      > > >      >      > Am I supposed to merge this with previous mappings? > REmove > >     them? > >      > > >      >     No replace it. There is text that says this that is > not in the > >      >     packet format description section. > >      > > >      > > >      > OK. > >      > > >      > > >      >      > S 8.3. > >      >      >>     of the mapping database protocols. > >      >      >> > >      >      >>  8.3.  Map-Server Processing > >      >      >> > >      >      >>     Once a Map-Server has EID-Prefixes registered > by its > >     client > >      >     ETRs, it > >      >      >>     can accept and process Map-Requests for them. > >      >      > > >      >      > This section is confusing because the introduction says > >     that this > >      >      > function is only performed by Map-Resolvers: > >      >      > ' > >      >      > "The LISP Mapping Service defines two new types of > >     LISP-speaking > >      >      >   devices: the Map-Resolver, which accepts Map-Requests > >     from an > >      >      > Ingress > >      >      >   Tunnel Router (ITR) and "resolves" the EID-to-RLOC > >     mapping using a > >      >      >   mapping database; and the Map-Server, which learns > >     authoritative > >      >      > EID- > >      >      >   to-RLOC mappings from an Egress Tunnel Router > (ETR) and > >     publishes > >      >      >   them in a database.” > >      > > >      >     The document does cover the operation of a > Map-Resolver and a > >      >     Map-Server. Some functions are performed only by > >     Map-Resolvers only > >      >     and other different functions are performed by > Map-Servers only. > >      > > >      >     I am not sure what you don’t understand. > >      > > >      > > >      > Sure: As I understand it, Map Resolvers process Map > Requests, and > >     Map > >      > Servers do not (that's what the quoted text seems to say). > >     However, this > >      > sentence talks about a Map Server processing a Map > Request.  That's > >      > where I am confused. > >      > > >      > -Ekr > >      > > >      > > >      >     Thanks, > >      >     Dino > >      > > > > From nobody Sat Sep 29 10:43:36 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B260B130E3B for ; Sat, 29 Sep 2018 10:43:33 -0700 (PDT) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 C53JIHKtX3Ju for ; Sat, 29 Sep 2018 10:43:30 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 0FB73130E48 for ; Sat, 29 Sep 2018 10:43:26 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id y10-v6so7181001lfj.1 for ; Sat, 29 Sep 2018 10:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1bdGqX/T8FLJ9OGLMI2UpQsEvD7HgQ0Fsv+rTAHgBw4=; b=OyEyGHur9N6j+w2DosOqmvxKtcyO+wYJdv8hxr8W/xP//HjrmeQML2/AuzOjUtM84o 339rE8vJ4jOicaqhW/cW38BxzBOCXdNGS2BikjiOylxuc6dJ0aMXBYwYXxJ5fCfbU6Pe GDeVqvYKSLUfI0Ff2L0iyccPojG1uYFtgLrKyuHf/+jfzG3Q20IVsHDdnlBz+u2jjcMK zdATHWPr/EngwSyiM/ILjxZg9IC+n73hLIq795y7bDTnLddzQmmXEuAJj5MslWWd0Do0 0vVkdw8CZ9hbhjQ+cVXQd8S7h02cECWPfnjXkkVlnos8YFU6CtZuYJyY6i9IPtwFKjGJ 3pvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1bdGqX/T8FLJ9OGLMI2UpQsEvD7HgQ0Fsv+rTAHgBw4=; b=dOlHbgQse15O+vFMTISAIA+ubDPxBFqgp02Z8+Frvesc8WTjkV2eQo/5Sq8p5UBnGN FWqO9O1dHZMSGNr2Aq5rmIl9NOMnltaZ2qIWlsO+lWRw2k9R43gdXitaPmEpotzdZRdC jmJbaPQgTCJAuOQg4PLLNiXL768kK0thzOMui9SBICiCd53f6cOPDxCrmZ5fXbBPTrq+ u9KDbLdXwBa0amV2ugR4Pjbc03wSbxyCPtXvPg0gqT2kzHofdDXYeZubz3SCnd4gtqRr g805GvOK7xligM6ukuMZKuhQ4gvKjMhcznCxcIbbT69NKgWaNnp2yBwA6lMUDUBUo4xb r5yw== X-Gm-Message-State: ABuFfohM8tLkcvumsn9oVwukdFRo2O4U7Ft8LQrwt7K7KSbCgSgQMJuz cK2/NFqQA9gkQ8JP8HhY1Om43QqfTM3KSeBtzeEflw== X-Google-Smtp-Source: ACcGV62k2WZvIaUCfzn2xzaUEx+oisepIjeGiGVPKCjGGa7N4AkNPrqZMEtyISV9U/HYiEQNvzHcLRZXC3Hjsk95NNw= X-Received: by 2002:a19:910c:: with SMTP id t12-v6mr1810811lfd.98.1538243003954; Sat, 29 Sep 2018 10:43:23 -0700 (PDT) MIME-Version: 1.0 References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> <9f4b18df-f0f5-49ec-b909-4b92755bbb7b@joelhalpern.com> <2c23c59a-2dfd-d35b-c21f-91eff3804e8d@joelhalpern.com> In-Reply-To: <2c23c59a-2dfd-d35b-c21f-91eff3804e8d@joelhalpern.com> From: Eric Rescorla Date: Sat, 29 Sep 2018 10:42:46 -0700 Message-ID: To: "Joel M. Halpern" Cc: Dino Farinacci , IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000d44d620577061b12" Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 29 Sep 2018 17:43:34 -0000 --000000000000d44d620577061b12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 29, 2018 at 10:42 AM Joel M. Halpern wrote: > This draft explicitly states that the m-bit can be ignored by nodes that > do not support the lisp mobile node behavior. Which seems pretty clear > that it is nicely separable. > OK. -Ekr > Yours, > Joel > > On 9/29/18 1:30 PM, Eric Rescorla wrote: > > > > > > On Sat, Sep 29, 2018 at 10:24 AM Joel M. Halpern > > wrote: > > > > Like any other flag bits that are not assigned, this would be MBZ o= n > > transmission, must be ignored on reception. Once assigned, > > implementations that support the assignment would do whatever the > > assigning document says. Very normal procedure. > > > > > > OK, I haven't read the -mn- draft so I don't know if that will have a > > clean upgrade path. > > > > -Ekr > > > > > > Yours, > > Joel > > > > On 9/29/18 1:22 PM, Eric Rescorla wrote: > > > > > > > > > On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern > > > > > >> wrote= : > > > > > > With regard to the m-bit, I would prefer that this document > > leave the > > > bit reserved, > > > > > > > > > Just trying to think through the interop implications of this. > > Would it > > > be must be zero and must ignore? something else? > > > > > > -Ekr > > > > > > and the LISP mobile node document assign the bit fromthe > > > registry. That keeps a clean separation. > > > > > > Yours, > > > Joel > > > > > > On 9/29/18 1:05 PM, Eric Rescorla wrote: > > > > > > > > > > > > On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci > > > > > > > > > > > > >>> wrote: > > > > > > > > Thanks Eric for your great comments. Like I said in > > previous > > > emails, > > > > I=E2=80=99ll address the simple things here and then = handle > > all the > > > security > > > > related stuff separately next week. > > > > > > > > I will do the same with Benjamin=E2=80=99s comments a= s well. > > And in his > > > > reply, send a diff with changes that reflect both Eri= c > and > > > > Benjamin=E2=80=99s comments. > > > > > > > > > On Sep 27, 2018, at 5:16 AM, Eric Rescorla > > > > > > > > > > > > >>> wrote: > > > > > > > > > > Rich version of this review at: > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D4115 > > > > > > > > > > > > > > > IMPORTANT > > > > > S 5.2. > > > > >> s: This is the SMR-invoked bit. This bit is > > set to 1 > > > when > > > > an xTR is > > > > >> sending a Map-Request in response to a > received > > > SMR-based > > > > Map- > > > > >> Request. > > > > >> > > > > >> m: This is the LISP mobile-node m-bit. This > > bit is > > > set by > > > > xTRs that > > > > >> operate as a mobile node as defined in > > > [I-D.ietf-lisp-mn]. > > > > > > > > > > This would appear to create a normative reference > > to this > > > > document. To > > > > > avoid that, you need to specify how I behave if I > > receive > > > it but I > > > > > don't implement lisp-mn. > > > > > > > > I am find making it a normative reference but need th= e > > > lisp-chairs > > > > to comment. I am not sure what the implications of > > that are. > > > > > > > > > > > > Me neither. Seems like it could go either way. My only > > interest > > > is that > > > > the protocol be unambiguous. > > > > > > > > > > > > > > > > > S 5.5. > > > > >> is being mapped from a multicast > > destination EID. > > > > >> > > > > >> 5.5. EID-to-RLOC UDP Map-Reply Message > > > > >> > > > > >> A Map-Reply returns an EID-Prefix with a pref= ix > > > length that > > > > is less > > > > >> than or equal to the EID being requested. Th= e > > EID being > > > > requested is > > > > > > > > > > How do I behave if I receive an EID-Prefix that is > less > > > than any > > > > of my > > > > > mappings. So, I might have mappings for 10.1.0.0/1= 6 > > > > > > > > > and 10.2.0.0/16 > > > > > > > > > > and someone asks me for 10.0.0.0/8 > > > > > ? > > > > > > > > > > > > I think I'm still unclear on this point. > > > > > > > > Also, when you talk about prefix > > > > > length, I assume you mean the length fo the mask? > > > > > > > > Yes, this is explained later in this section. Was tha= t > not > > > helpful?? > > > > > > > > > > > > I found it a bit confusing. It seems to me like there are > two > > > lengths > > > > involved here: > > > > > > > > - The length of the field (4 or 16) > > > > - The parts of the field that are significant (i.e., the > mask) > > > > > > > > I had thought that "prefix length" referred to the former= , > > but it > > > seems > > > > like here it > > > > refers to the latter. > > > > > > > > > > > > > S 5.6. > > > > >> Authentication Data: This is the message > > digest used > > > from > > > > the output > > > > >> of the MAC algorithm. The entire > Map-Register > > > payload is > > > > >> authenticated with this field preset to 0. > > After > > > the MAC is > > > > >> computed, it is placed in this field. > > > Implementations of > > > > this > > > > >> specification MUST include support for > > HMAC-SHA-1-96 > > > > [RFC2404], > > > > >> and support for HMAC-SHA-256-128 [RFC4868] > is > > > RECOMMENDED. > > > > > > > > > > What prevents replay attacks here? I'm guessing > > it's the > > > Map-Version- > > > > > Number, but as I understand it, I can set this to = 0. > > > > > > > > Well there are many. The nonce can change for each > > Map-Register > > > > sent. Same for Map-Version number as well as the > key-id. > > > > > > > > > > > > I think you need to describe the precise process of repla= y > > > prevention here. > > > > > > > > > S 6.1. > > > > >> receives an SMR-based Map-Request and the > > source is > > > not in the > > > > >> Locator-Set for the stored Map-Cache entry, > > then the > > > > responding Map- > > > > >> Request MUST be sent with an EID destination > > to the > > > mapping > > > > database > > > > >> system. Since the mapping database system is > > a more > > > secure > > > > way to > > > > >> reach an authoritative ETR, it will deliver t= he > > > Map-Request > > > > to the > > > > >> authoritative source of the mapping data. > > > > > > > > > > If I'm understanding this correctly, this allows a= n > > ETR to > > > prevent an > > > > > ITR from learning that it is no longer the > > appropriate ETR > > > for a > > > > > prefix. The way this attack works is that before > > the topology > > > > shift, I > > > > > send SMRs, thus causing Map-Requests, which, > because my > > > entry is > > > > > cached, refresh the cache on the ITR past the > topology > > > shift. I can > > > > > keep doing this indefinitely. Am I missing somethi= ng > > > > > > > > Well if the ETR is being spoofed, then there is > > Map-Request load, > > > > but it won=E2=80=99t corrupt the ITR=E2=80=99s map-ca= che. The ITR > > always sends a > > > > verifying Map-Request to the mapping system to get th= e > > latest and > > > > authenticated RLOC-set for the mapping. Rate-limiting > is > > > necessary > > > > so each SMR received DOES NOT result in a Map-Requers= t > > to the > > > > mapping system. > > > > > > > > > > > > I'm probably just confused here: SMRs go through the > mapping > > > system, not > > > > directly? If so, I agree that this wont' work. > > > > > > > > > > > > > S 5. > > > > >> \ | UDP Length | > UDP > > > Checksum > > > > | > > > > >> > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >> | > > > > | > > > > >> | LISP Message > > > > | > > > > >> | > > > > | > > > > >> > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > What do these two diagrams correspond to? v4 and > > v6? This > > > needs > > > > > explanation. > > > > > > > > It is th entire IP packet sent as a LISP > > control-message. The > > > header > > > > before the diagrams indicate they are UDP packets. > > > > > > > > > > > > A caption would probably help. > > > > > > > > > S 5.2. > > > > >> P: This is the probe-bit, which indicates tha= t > a > > > Map-Request > > > > SHOULD > > > > >> be treated as a Locator reachability > > probe. The > > > receiver > > > > SHOULD > > > > >> respond with a Map-Reply with the probe-bi= t > > set, > > > > indicating that > > > > >> the Map-Reply is a Locator reachability > probe > > > reply, with the > > > > >> nonce copied from the Map-Request. See > > RLOC-Probing > > > > Section 7.1 > > > > >> for more details. > > > > > > > > > > How am I supposed to handle this if I am a Map > Server. > > > > > > > > It should be ignored. I will add text to reflect this > > point. > > > Good point. > > > > > > > > > > > > > > S 5.2. > > > > >> receipt. > > > > >> > > > > >> L: This is the local-xtr bit. It is used by > > an xTR in a > > > > LISP site to > > > > >> tell other xTRs in the same site that it i= s > > part > > > of the > > > > RLOC-set > > > > >> for the LISP site. The L-bit is set to 1 > > when the > > > RLOC > > > > is the > > > > >> sender's IP address. > > > > > > > > > > Is the xTR supposed to filter this on exiting the > site. > > > > > > > > Nope. > > > > > > > > > > > > Won't this cause problems on ingress to another site? > > > > > > > > > S 5.3. > > > > >> originating Map-Request source. If the RLOC > > is not > > > in the > > > > Locator- > > > > >> Set, then the ETR MUST send the "verifying > > > Map-Request" to the > > > > >> "piggybacked" EID. Doing this forces the > > "verifying > > > > Map-Request" to > > > > >> go through the mapping database system to > > reach the > > > > authoritative > > > > >> source of information about that EID, guardin= g > > against > > > > RLOC-spoofing > > > > >> in the "piggybacked" mapping data. > > > > > > > > > > This text here doesn't seem compatible with either > > of the > > > two cases > > > > > listed in "EID-prefix" above. > > > > > > > > I don=E2=80=99t understand the comment Eric. Maybe be= cause I > can=E2=80=99t > > > find the > > > > exact reference to EID-prefix where you think there i= s > a > > > conflict. > > > > Please cite for me. Thanks. > > > > > > > > This does seem to have been assigned to the wrong text. > > > > > > > > I am referring to: > > > > > > > > " A Map-Reply returns an EID-Prefix with a prefix lengt= h > > that > > > is less > > > > than or equal to the EID being requested. The EID > being > > > requested is > > > > either from the destination field of an IP header of = a > > > Data-Probe or > > > > the EID record of a Map-Request. The RLOCs in the > > Map-Reply are > > > > " > > > > > > > > versus > > > > > > > > " EID-Prefix: This prefix is 4 octets for an IPv4 > address > > > family and > > > > 16 octets for an IPv6 address family when the > > > EID-Prefix-AFI is 1 > > > > or 2, respectively. For other AFIs [AFI], the > length > > > varies and > > > > for the LCAF AFI the format is defined in > > [RFC8060]. When > > > a Map- > > > > " > > > > > > > > This is just the question of whether "prefix length" > refers to > > > the field or > > > > the significant bits of the field. > > > > > > > > > > > > > > > > > > > > > > > > > > S 5.4. > > > > >> 'Nonce' field. > > > > >> > > > > >> Record TTL: This is the time in minutes the > > recipient of > > > > the Map- > > > > >> Reply will store the mapping. If the TTL > is 0, > > > the entry > > > > MUST be > > > > >> removed from the cache immediately. If th= e > > value is > > > > 0xffffffff, > > > > >> the recipient can decide locally how long > > to store the > > > > mapping. > > > > > > > > > > Am I supposed to merge this with previous mappings= ? > > REmove > > > them? > > > > > > > > No replace it. There is text that says this that is > > not in the > > > > packet format description section. > > > > > > > > > > > > OK. > > > > > > > > > > > > > S 8.3. > > > > >> of the mapping database protocols. > > > > >> > > > > >> 8.3. Map-Server Processing > > > > >> > > > > >> Once a Map-Server has EID-Prefixes registered > > by its > > > client > > > > ETRs, it > > > > >> can accept and process Map-Requests for them. > > > > > > > > > > This section is confusing because the introduction > says > > > that this > > > > > function is only performed by Map-Resolvers: > > > > > ' > > > > > "The LISP Mapping Service defines two new types of > > > LISP-speaking > > > > > devices: the Map-Resolver, which accepts > Map-Requests > > > from an > > > > > Ingress > > > > > Tunnel Router (ITR) and "resolves" the EID-to-RL= OC > > > mapping using a > > > > > mapping database; and the Map-Server, which lear= ns > > > authoritative > > > > > EID- > > > > > to-RLOC mappings from an Egress Tunnel Router > > (ETR) and > > > publishes > > > > > them in a database.=E2=80=9D > > > > > > > > The document does cover the operation of a > > Map-Resolver and a > > > > Map-Server. Some functions are performed only by > > > Map-Resolvers only > > > > and other different functions are performed by > > Map-Servers only. > > > > > > > > I am not sure what you don=E2=80=99t understand. > > > > > > > > > > > > Sure: As I understand it, Map Resolvers process Map > > Requests, and > > > Map > > > > Servers do not (that's what the quoted text seems to say)= . > > > However, this > > > > sentence talks about a Map Server processing a Map > > Request. That's > > > > where I am confused. > > > > > > > > -Ekr > > > > > > > > > > > > Thanks, > > > > Dino > > > > > > > > > > --000000000000d44d620577061b12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9 Imx0ciI+T24gU2F0LCBTZXAgMjksIDIwMTggYXQgMTA6NDIgQU0gSm9lbCBNLiBIYWxwZXJuICZs dDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNv bTwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk aW5nLWxlZnQ6MWV4Ij5UaGlzIGRyYWZ0IGV4cGxpY2l0bHkgc3RhdGVzIHRoYXQgdGhlIG0tYml0 IGNhbiBiZSBpZ25vcmVkIGJ5IG5vZGVzIHRoYXQgPGJyPg0KZG8gbm90IHN1cHBvcnTCoCB0aGUg bGlzcCBtb2JpbGUgbm9kZSBiZWhhdmlvci7CoCBXaGljaCBzZWVtcyBwcmV0dHkgY2xlYXIgPGJy Pg0KdGhhdCBpdCBpcyBuaWNlbHkgc2VwYXJhYmxlLjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+ PC9kaXY+PGRpdj5PSy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pi1Fa3I8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxi cj4NCllvdXJzLDxicj4NCkpvZWw8YnI+DQo8YnI+DQpPbiA5LzI5LzE4IDE6MzAgUE0sIEVyaWMg UmVzY29ybGEgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gU2F0LCBT ZXAgMjksIDIwMTggYXQgMTA6MjQgQU0gSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5j b208L2E+IDxicj4NCiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyZndDsg d3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7wqAgwqAgwqBMaWtlIGFueSBvdGhlciBmbGFnIGJp dHMgdGhhdCBhcmUgbm90IGFzc2lnbmVkLCB0aGlzIHdvdWxkIGJlIE1CWiBvbjxicj4NCiZndDvC oCDCoCDCoHRyYW5zbWlzc2lvbiwgbXVzdCBiZSBpZ25vcmVkIG9uIHJlY2VwdGlvbi7CoCBPbmNl IGFzc2lnbmVkLDxicj4NCiZndDvCoCDCoCDCoGltcGxlbWVudGF0aW9ucyB0aGF0IHN1cHBvcnQg dGhlIGFzc2lnbm1lbnQgd291bGQgZG8gd2hhdGV2ZXIgdGhlPGJyPg0KJmd0O8KgIMKgIMKgYXNz aWduaW5nIGRvY3VtZW50IHNheXMuwqAgVmVyeSBub3JtYWwgcHJvY2VkdXJlLjxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9LLCBJIGhhdmVuJiMzOTt0IHJlYWQgdGhlIC1tbi0gZHJh ZnQgc28gSSBkb24mIzM5O3Qga25vdyBpZiB0aGF0IHdpbGwgaGF2ZSBhIDxicj4NCiZndDsgY2xl YW4gdXBncmFkZSBwYXRoLjxicj4NCiZndDsgPGJyPg0KJmd0OyAtRWtyPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDvCoCDCoCDCoFlvdXJzLDxicj4NCiZndDvCoCDCoCDCoEpvZWw8YnI+ DQomZ3Q7IDxicj4NCiZndDvCoCDCoCDCoE9uIDkvMjkvMTggMToyMiBQTSwgRXJpYyBSZXNjb3Js YSB3cm90ZTo8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7PGJy Pg0KJmd0O8KgIMKgIMKgICZndDsgT24gU2F0LCBTZXAgMjksIDIwMTggYXQgMTA6MTggQU0gSm9l bCBNLiBIYWxwZXJuPGJyPg0KJmd0O8KgIMKgIMKgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4gJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7ICZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2Js YW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwv YT4mZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAg wqAgwqAgJmd0O8KgIMKgIMKgV2l0aCByZWdhcmQgdG8gdGhlIG0tYml0LCBJIHdvdWxkIHByZWZl ciB0aGF0IHRoaXMgZG9jdW1lbnQ8YnI+DQomZ3Q7wqAgwqAgwqBsZWF2ZSB0aGU8YnI+DQomZ3Q7 wqAgwqAgwqAgJmd0O8KgIMKgIMKgYml0IHJlc2VydmVkLDxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7 PGJyPg0KJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0OyBKdXN0IHRyeWlu ZyB0byB0aGluayB0aHJvdWdoIHRoZSBpbnRlcm9wIGltcGxpY2F0aW9ucyBvZiB0aGlzLjxicj4N CiZndDvCoCDCoCDCoFdvdWxkIGl0PGJyPg0KJmd0O8KgIMKgIMKgICZndDsgYmUgbXVzdCBiZSB6 ZXJvIGFuZCBtdXN0IGlnbm9yZT8gc29tZXRoaW5nIGVsc2U/PGJyPg0KJmd0O8KgIMKgIMKgICZn dDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0OyAtRWtyPGJyPg0KJmd0O8KgIMKgIMKgICZndDs8YnI+ DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgYW5kIHRoZSBMSVNQIG1vYmlsZSBub2RlIGRvY3Vt ZW50IGFzc2lnbiB0aGUgYml0IGZyb210aGU8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKg cmVnaXN0cnkuwqAgVGhhdCBrZWVwcyBhIGNsZWFuIHNlcGFyYXRpb24uPGJyPg0KJmd0O8KgIMKg IMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgWW91cnMsPGJyPg0KJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoEpvZWw8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvC oCDCoCDCoCAmZ3Q7wqAgwqAgwqBPbiA5LzI5LzE4IDE6MDUgUE0sIEVyaWMgUmVzY29ybGEgd3Jv dGU6PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKg ICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7IE9u IFNhdCwgU2VwIDI5LCAyMDE4IGF0IDk6MzAgQU0gRGlubyBGYXJpbmFjY2k8YnI+DQomZ3Q7wqAg wqAgwqAgJmd0O8KgIMKgIMKgJmx0OzxhIGhyZWY9Im1haWx0bzpmYXJpbmFjY2lAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZmFyaW5hY2NpQGdtYWlsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZhcmluYWNj aUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDvCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5mYXJpbmFjY2lAZ21h aWwuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpmYXJpbmFjY2lAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZmFyaW5hY2NpQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0Ozxicj4NCiZn dDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpm YXJpbmFjY2lAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZmFyaW5hY2NpQGdtYWlsLmNvbTwv YT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmZhcmluYWNjaUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDvCoCDCoCDCoCZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5mYXJpbmFjY2lAZ21haWwuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpm YXJpbmFjY2lAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZmFyaW5hY2NpQGdtYWlsLmNvbTwv YT4mZ3Q7Jmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAg Jmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgVGhhbmtzIEVy aWMgZm9yIHlvdXIgZ3JlYXQgY29tbWVudHMuIExpa2UgSSBzYWlkIGluPGJyPg0KJmd0O8KgIMKg IMKgcHJldmlvdXM8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgZW1haWxzLDxicj4NCiZn dDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgSeKAmWxsIGFkZHJlc3MgdGhlIHNp bXBsZSB0aGluZ3MgaGVyZSBhbmQgdGhlbiBoYW5kbGU8YnI+DQomZ3Q7wqAgwqAgwqBhbGwgdGhl PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoHNlY3VyaXR5PGJyPg0KJmd0O8KgIMKgIMKg ICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqByZWxhdGVkIHN0dWZmIHNlcGFyYXRlbHkgbmV4dCB3 ZWVrLjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDC oCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgSSB3aWxsIGRvIHRoZSBzYW1lIHdpdGggQmVuamFt aW7igJlzIGNvbW1lbnRzIGFzIHdlbGwuPGJyPg0KJmd0O8KgIMKgIMKgQW5kIGluIGhpczxicj4N CiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgcmVwbHksIHNlbmQgYSBkaWZm IHdpdGggY2hhbmdlcyB0aGF0IHJlZmxlY3QgYm90aCBFcmljIGFuZDxicj4NCiZndDvCoCDCoCDC oCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgQmVuamFtaW7igJlzIGNvbW1lbnRzLjxicj4NCiZn dDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAg wqAgJmd0O8KgIMKgIMKgICZndDsgT24gU2VwIDI3LCAyMDE4LCBhdCA1OjE2IEFNLCBFcmljIFJl c2NvcmxhPGJyPg0KJmd0O8KgIMKgIMKgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20i IHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7PGJy Pg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmVr ckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4gJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29t PC9hPiZndDsmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5l a3JAcnRmbS5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWty QHJ0Zm0uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRh cmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0OyZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyBSaWNoIHZlcnNpb24gb2YgdGhp cyByZXZpZXcgYXQ6PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAg Jmd0OyA8YSBocmVmPSJodHRwczovL21venBoYWItaWV0Zi5kZXZzdmNkZXYubW96YXdzLm5ldC9E NDExNSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9tb3pwaGFiLWll dGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQxMTU8L2E+PGJyPg0KJmd0O8KgIMKgIMKgICZndDvC oCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAg Jmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDC oCDCoCAmZ3Q7IElNUE9SVEFOVDxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgICZndDsgUyA1LjIuPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAg wqAgwqAgJmd0OyZndDvCoCDCoCDCoHM6IFRoaXMgaXMgdGhlIFNNUi1pbnZva2VkIGJpdC7CoCBU aGlzIGJpdCBpczxicj4NCiZndDvCoCDCoCDCoHNldCB0byAxPGJyPg0KJmd0O8KgIMKgIMKgICZn dDvCoCDCoCDCoHdoZW48YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDC oGFuIHhUUiBpczxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZn dDsmZ3Q7wqAgwqAgwqAgwqAgc2VuZGluZyBhIE1hcC1SZXF1ZXN0IGluIHJlc3BvbnNlIHRvIGEg cmVjZWl2ZWQ8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgU01SLWJhc2VkPGJyPg0KJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBNYXAtPGJyPg0KJmd0O8KgIMKgIMKg ICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDCoCDCoCBSZXF1ZXN0Ljxi cj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7PGJyPg0K Jmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDCoG06 IFRoaXMgaXMgdGhlIExJU1AgbW9iaWxlLW5vZGUgbS1iaXQuwqAgVGhpczxicj4NCiZndDvCoCDC oCDCoGJpdCBpczxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBzZXQgYnk8YnI+DQomZ3Q7 wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoHhUUnMgdGhhdDxicj4NCiZndDvCoCDC oCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7wqAgwqAgwqAgwqAgb3BlcmF0 ZSBhcyBhIG1vYmlsZSBub2RlIGFzIGRlZmluZWQgaW48YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgW0ktRC5pZXRmLWxpc3AtbW5dLjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAg Jmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDC oCDCoCAmZ3Q7IFRoaXMgd291bGQgYXBwZWFyIHRvIGNyZWF0ZSBhIG5vcm1hdGl2ZSByZWZlcmVu Y2U8YnI+DQomZ3Q7wqAgwqAgwqB0byB0aGlzPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDC oCAmZ3Q7wqAgwqAgwqBkb2N1bWVudC4gVG88YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKg ICZndDvCoCDCoCDCoCAmZ3Q7IGF2b2lkIHRoYXQsIHlvdSBuZWVkIHRvIHNwZWNpZnkgaG93IEkg YmVoYXZlIGlmIEk8YnI+DQomZ3Q7wqAgwqAgwqByZWNlaXZlPGJyPg0KJmd0O8KgIMKgIMKgICZn dDvCoCDCoCDCoGl0IGJ1dCBJPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAg wqAgwqAgJmd0OyBkb24mIzM5O3QgaW1wbGVtZW50IGxpc3AtbW4uPGJyPg0KJmd0O8KgIMKgIMKg ICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAg wqAgwqBJIGFtIGZpbmQgbWFraW5nIGl0IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSBidXQgbmVlZCB0 aGU8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgbGlzcC1jaGFpcnM8YnI+DQomZ3Q7wqAg wqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoHRvIGNvbW1lbnQuIEkgYW0gbm90IHN1cmUg d2hhdCB0aGUgaW1wbGljYXRpb25zIG9mPGJyPg0KJmd0O8KgIMKgIMKgdGhhdCBhcmUuPGJyPg0K Jmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDC oCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7IE1lIG5laXRoZXIu IFNlZW1zIGxpa2UgaXQgY291bGQgZ28gZWl0aGVyIHdheS4gTXkgb25seTxicj4NCiZndDvCoCDC oCDCoGludGVyZXN0PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoGlzIHRoYXQ8YnI+DQom Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgdGhlIHByb3RvY29sIGJlIHVuYW1iaWd1b3Vz Ljxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAm Z3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4N CiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgUyA1LjUuPGJyPg0K Jmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDCoCDC oCBpcyBiZWluZyBtYXBwZWQgZnJvbSBhIG11bHRpY2FzdDxicj4NCiZndDvCoCDCoCDCoGRlc3Rp bmF0aW9uIEVJRC48YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAm Z3Q7Jmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsm Z3Q7wqAgNS41LsKgIEVJRC10by1STE9DIFVEUCBNYXAtUmVwbHkgTWVzc2FnZTxicj4NCiZndDvC oCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7PGJyPg0KJmd0O8KgIMKg IMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDCoEEgTWFwLVJlcGx5 IHJldHVybnMgYW4gRUlELVByZWZpeCB3aXRoIGEgcHJlZml4PGJyPg0KJmd0O8KgIMKgIMKgICZn dDvCoCDCoCDCoGxlbmd0aCB0aGF0PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7 wqAgwqAgwqBpcyBsZXNzPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAg wqAgJmd0OyZndDvCoCDCoCDCoHRoYW4gb3IgZXF1YWwgdG8gdGhlIEVJRCBiZWluZyByZXF1ZXN0 ZWQuwqAgVGhlPGJyPg0KJmd0O8KgIMKgIMKgRUlEIGJlaW5nPGJyPg0KJmd0O8KgIMKgIMKgICZn dDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqByZXF1ZXN0ZWQgaXM8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDC oCAmZ3Q7wqAgwqAgwqAgJmd0OyBIb3cgZG8gSSBiZWhhdmUgaWYgSSByZWNlaXZlIGFuIEVJRC1Q cmVmaXggdGhhdCBpcyBsZXNzPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoHRoYW4gYW55 PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBvZiBteTxicj4NCiZn dDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgbWFwcGluZ3MuIFNvLCBJ IG1pZ2h0IGhhdmUgbWFwcGluZ3MgZm9yIDxhIGhyZWY9Imh0dHA6Ly8xMC4xLjAuMC8xNiIgcmVs PSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+MTAuMS4wLjAvMTY8L2E+PGJyPg0KJmd0O8Kg IMKgIMKgJmx0OzxhIGhyZWY9Imh0dHA6Ly8xMC4xLjAuMC8xNiIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovLzEwLjEuMC4wLzE2PC9hPiZndDs8YnI+DQomZ3Q7wqAgwqAg wqAgJmd0O8KgIMKgIMKgJmx0OzxhIGhyZWY9Imh0dHA6Ly8xMC4xLjAuMC8xNiIgcmVsPSJub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovLzEwLjEuMC4wLzE2PC9hPiZndDs8YnI+DQom Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCZsdDs8YSBocmVmPSJodHRwOi8v MTAuMS4wLjAvMTYiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly8xMC4x LjAuMC8xNjwvYT4mZ3Q7IGFuZCA8YSBocmVmPSJodHRwOi8vMTAuMi4wLjAvMTYiIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPjEwLjIuMC4wLzE2PC9hPjxicj4NCiZndDvCoCDCoCDC oCZsdDs8YSBocmVmPSJodHRwOi8vMTAuMi4wLjAvMTYiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly8xMC4yLjAuMC8xNjwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJodHRwOi8v MTAuMi4wLjAvMTYiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly8xMC4y LjAuMC8xNjwvYT4mZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCZsdDs8YSBocmVm PSJodHRwOi8vMTAuMi4wLjAvMTYiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly8xMC4yLjAuMC8xNjwvYT4mZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAm Z3Q7wqAgwqAgwqAgJmd0OyBhbmQgc29tZW9uZSBhc2tzIG1lIGZvciA8YSBocmVmPSJodHRwOi8v MTAuMC4wLjAvOCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+MTAuMC4wLjAvODwv YT48YnI+DQomZ3Q7wqAgwqAgwqAmbHQ7PGEgaHJlZj0iaHR0cDovLzEwLjAuMC4wLzgiIHJlbD0i bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly8xMC4wLjAuMC84PC9hPiZndDsgJmx0 OzxhIGhyZWY9Imh0dHA6Ly8xMC4wLjAuMC84IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2Js YW5rIj5odHRwOi8vMTAuMC4wLjAvODwvYT4mZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDC oCDCoCZsdDs8YSBocmVmPSJodHRwOi8vMTAuMC4wLjAvOCIgcmVsPSJub3JlZmVycmVyIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovLzEwLjAuMC4wLzg8L2E+Jmd0Oz88YnI+DQomZ3Q7wqAgwqAgwqAg Jmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+ DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgSSB0aGluayBJJiMzOTttIHN0aWxsIHVu Y2xlYXIgb24gdGhpcyBwb2ludC48YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8 YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoEFsc28sIHdoZW4geW91 IHRhbGsgYWJvdXQgcHJlZml4PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAg wqAgwqAgJmd0OyBsZW5ndGgsIEkgYXNzdW1lIHlvdSBtZWFuIHRoZSBsZW5ndGggZm8gdGhlIG1h c2s/PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKg ICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBZZXMsIHRoaXMgaXMgZXhwbGFpbmVkIGxhdGVyIGlu IHRoaXMgc2VjdGlvbi4gV2FzIHRoYXQgbm90PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDC oGhlbHBmdWw/Pzxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvC oCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAg Jmd0OyBJIGZvdW5kIGl0IGEgYml0IGNvbmZ1c2luZy4gSXQgc2VlbXMgdG8gbWUgbGlrZSB0aGVy ZSBhcmUgdHdvPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoGxlbmd0aHM8YnI+DQomZ3Q7 wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgaW52b2x2ZWQgaGVyZTo8YnI+DQomZ3Q7wqAgwqAg wqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsg LSBUaGUgbGVuZ3RoIG9mIHRoZSBmaWVsZCAoNCBvciAxNik8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgICZndDsgLSBUaGUgcGFydHMgb2YgdGhlIGZpZWxkIHRoYXQgYXJlIHNpZ25pZmlj YW50IChpLmUuLCB0aGUgbWFzayk8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8 YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgSSBoYWQgdGhvdWdodCB0aGF0ICZx dW90O3ByZWZpeCBsZW5ndGgmcXVvdDsgcmVmZXJyZWQgdG8gdGhlIGZvcm1lciw8YnI+DQomZ3Q7 wqAgwqAgwqBidXQgaXQ8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgc2VlbXM8YnI+DQom Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgbGlrZSBoZXJlIGl0PGJyPg0KJmd0O8KgIMKg IMKgICZndDvCoCDCoCDCoCAmZ3Q7IHJlZmVycyB0byB0aGUgbGF0dGVyLjxicj4NCiZndDvCoCDC oCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0 Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgUyA1LjYu PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDC oCDCoEF1dGhlbnRpY2F0aW9uIERhdGE6wqAgVGhpcyBpcyB0aGUgbWVzc2FnZTxicj4NCiZndDvC oCDCoCDCoGRpZ2VzdCB1c2VkPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoGZyb208YnI+ DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoHRoZSBvdXRwdXQ8YnI+DQom Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7Jmd0O8KgIMKgIMKgIMKg IG9mIHRoZSBNQUMgYWxnb3JpdGhtLsKgIFRoZSBlbnRpcmUgTWFwLVJlZ2lzdGVyPGJyPg0KJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoHBheWxvYWQgaXM8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7Jmd0O8KgIMKgIMKgIMKgIGF1dGhlbnRpY2F0ZWQgd2l0 aCB0aGlzIGZpZWxkIHByZXNldCB0byAwLiA8YnI+DQomZ3Q7wqAgwqAgwqBBZnRlcjxicj4NCiZn dDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqB0aGUgTUFDIGlzPGJyPg0KJmd0O8KgIMKgIMKgICZndDvC oCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDCoCDCoCBjb21wdXRlZCwgaXQgaXMg cGxhY2VkIGluIHRoaXMgZmllbGQuPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoEltcGxl bWVudGF0aW9ucyBvZjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKg dGhpczxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7 wqAgwqAgwqAgwqAgc3BlY2lmaWNhdGlvbiBNVVNUIGluY2x1ZGUgc3VwcG9ydCBmb3I8YnI+DQom Z3Q7wqAgwqAgwqBITUFDLVNIQS0xLTk2PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAm Z3Q7wqAgwqAgwqBbUkZDMjQwNF0sPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7 wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDCoCDCoCBhbmQgc3VwcG9ydCBmb3IgSE1BQy1TSEEtMjU2 LTEyOCBbUkZDNDg2OF0gaXM8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgUkVDT01NRU5E RUQuPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4N CiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgV2hhdCBwcmV2ZW50 cyByZXBsYXkgYXR0YWNrcyBoZXJlPyBJJiMzOTttIGd1ZXNzaW5nPGJyPg0KJmd0O8KgIMKgIMKg aXQmIzM5O3MgdGhlPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoE1hcC1WZXJzaW9uLTxi cj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgTnVtYmVyLCBi dXQgYXMgSSB1bmRlcnN0YW5kIGl0LCBJIGNhbiBzZXQgdGhpcyB0byAwLjxicj4NCiZndDvCoCDC oCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgV2VsbCB0aGVyZSBhcmUgbWFueS4gVGhlIG5vbmNlIGNhbiBjaGFuZ2UgZm9yIGVh Y2g8YnI+DQomZ3Q7wqAgwqAgwqBNYXAtUmVnaXN0ZXI8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoHNlbnQuIFNhbWUgZm9yIE1hcC1WZXJzaW9uIG51bWJlciBhcyB3 ZWxsIGFzIHRoZSBrZXktaWQuPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJy Pg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvC oCDCoCDCoCAmZ3Q7IEkgdGhpbmsgeW91IG5lZWQgdG8gZGVzY3JpYmUgdGhlIHByZWNpc2UgcHJv Y2VzcyBvZiByZXBsYXk8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgcHJldmVudGlvbiBo ZXJlLjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDC oCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgUyA2LjEuPGJyPg0KJmd0O8KgIMKgIMKg ICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDCoHJlY2VpdmVzIGFuIFNN Ui1iYXNlZCBNYXAtUmVxdWVzdCBhbmQgdGhlPGJyPg0KJmd0O8KgIMKgIMKgc291cmNlIGlzPGJy Pg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoG5vdCBpbiB0aGU8YnI+DQomZ3Q7wqAgwqAgwqAg Jmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7Jmd0O8KgIMKgIMKgTG9jYXRvci1TZXQgZm9y IHRoZSBzdG9yZWQgTWFwLUNhY2hlIGVudHJ5LDxicj4NCiZndDvCoCDCoCDCoHRoZW4gdGhlPGJy Pg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqByZXNwb25kaW5nIE1hcC08 YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7Jmd0O8KgIMKg IMKgUmVxdWVzdCBNVVNUIGJlIHNlbnQgd2l0aCBhbiBFSUQgZGVzdGluYXRpb248YnI+DQomZ3Q7 wqAgwqAgwqB0byB0aGU8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgbWFwcGluZzxicj4N CiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgZGF0YWJhc2U8YnI+DQomZ3Q7 wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7Jmd0O8KgIMKgIMKgc3lzdGVt LsKgIFNpbmNlIHRoZSBtYXBwaW5nIGRhdGFiYXNlIHN5c3RlbSBpczxicj4NCiZndDvCoCDCoCDC oGEgbW9yZTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBzZWN1cmU8YnI+DQomZ3Q7wqAg wqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoHdheSB0bzxicj4NCiZndDvCoCDCoCDCoCAm Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7wqAgwqAgwqByZWFjaCBhbiBhdXRob3Jp dGF0aXZlIEVUUiwgaXQgd2lsbCBkZWxpdmVyIHRoZTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAg wqAgwqBNYXAtUmVxdWVzdDxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKg IMKgdG8gdGhlPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0 OyZndDvCoCDCoCDCoGF1dGhvcml0YXRpdmUgc291cmNlIG9mIHRoZSBtYXBwaW5nIGRhdGEuPGJy Pg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvC oCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgSWYgSSYjMzk7bSB1bmRlcnN0 YW5kaW5nIHRoaXMgY29ycmVjdGx5LCB0aGlzIGFsbG93cyBhbjxicj4NCiZndDvCoCDCoCDCoEVU UiB0bzxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBwcmV2ZW50IGFuPGJyPg0KJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyBJVFIgZnJvbSBsZWFybmluZyB0 aGF0IGl0IGlzIG5vIGxvbmdlciB0aGU8YnI+DQomZ3Q7wqAgwqAgwqBhcHByb3ByaWF0ZSBFVFI8 YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgZm9yIGE8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7IHByZWZpeC4gVGhlIHdheSB0aGlzIGF0dGFjayB3 b3JrcyBpcyB0aGF0IGJlZm9yZTxicj4NCiZndDvCoCDCoCDCoHRoZSB0b3BvbG9neTxicj4NCiZn dDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgc2hpZnQsIEk8YnI+DQomZ3Q7wqAg wqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7IHNlbmQgU01ScywgdGh1cyBjYXVz aW5nIE1hcC1SZXF1ZXN0cywgd2hpY2gsIGJlY2F1c2UgbXk8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgZW50cnkgaXM8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDC oCDCoCAmZ3Q7IGNhY2hlZCwgcmVmcmVzaCB0aGUgY2FjaGUgb24gdGhlIElUUiBwYXN0IHRoZSB0 b3BvbG9neTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBzaGlmdC4gSSBjYW48YnI+DQom Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7IGtlZXAgZG9pbmcgdGhp cyBpbmRlZmluaXRlbHkuIEFtIEkgbWlzc2luZyBzb21ldGhpbmc8YnI+DQomZ3Q7wqAgwqAgwqAg Jmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDC oCDCoFdlbGwgaWYgdGhlIEVUUiBpcyBiZWluZyBzcG9vZmVkLCB0aGVuIHRoZXJlIGlzPGJyPg0K Jmd0O8KgIMKgIMKgTWFwLVJlcXVlc3QgbG9hZCw8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKg IMKgICZndDvCoCDCoCDCoGJ1dCBpdCB3b27igJl0IGNvcnJ1cHQgdGhlIElUUuKAmXMgbWFwLWNh Y2hlLiBUaGUgSVRSPGJyPg0KJmd0O8KgIMKgIMKgYWx3YXlzIHNlbmRzIGE8YnI+DQomZ3Q7wqAg wqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoHZlcmlmeWluZyBNYXAtUmVxdWVzdCB0byB0 aGUgbWFwcGluZyBzeXN0ZW0gdG8gZ2V0IHRoZTxicj4NCiZndDvCoCDCoCDCoGxhdGVzdCBhbmQ8 YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoGF1dGhlbnRpY2F0ZWQg UkxPQy1zZXQgZm9yIHRoZSBtYXBwaW5nLiBSYXRlLWxpbWl0aW5nIGlzPGJyPg0KJmd0O8KgIMKg IMKgICZndDvCoCDCoCDCoG5lY2Vzc2FyeTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAg Jmd0O8KgIMKgIMKgc28gZWFjaCBTTVIgcmVjZWl2ZWQgRE9FUyBOT1QgcmVzdWx0IGluIGEgTWFw LVJlcXVlcnN0PGJyPg0KJmd0O8KgIMKgIMKgdG8gdGhlPGJyPg0KJmd0O8KgIMKgIMKgICZndDvC oCDCoCDCoCAmZ3Q7wqAgwqAgwqBtYXBwaW5nIHN5c3RlbS48YnI+DQomZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQom Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgSSYjMzk7bSBwcm9iYWJseSBqdXN0IGNvbmZ1 c2VkIGhlcmU6IFNNUnMgZ28gdGhyb3VnaCB0aGUgbWFwcGluZzxicj4NCiZndDvCoCDCoCDCoCAm Z3Q7wqAgwqAgwqBzeXN0ZW0sIG5vdDxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0 OyBkaXJlY3RseT8gSWYgc28sIEkgYWdyZWUgdGhhdCB0aGlzIHdvbnQmIzM5OyB3b3JrLjxicj4N CiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAg wqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZn dDsgUyA1Ljxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsm Z3Q7wqAgwqAgwqAgwqBcIHzCoCDCoCDCoCDCoCDCoCDCoFVEUCBMZW5ndGjCoCDCoCDCoCDCoCDC oCB8wqAgwqAgwqAgwqAgVURQPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoENoZWNrc3Vt PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqB8 PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDs8YnI+ DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgPGJyPg0KJmd0O8KgIMKgIMKgIMKgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgfDxicj4NCiZndDvC oCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCiZndDvC oCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7wqAgwqAgwqAgwqAgwqB8 wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBMSVNQIE1lc3NhZ2U8YnI+DQom Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0K Jmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDCoCDC oCDCoHw8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCDCoCDCoCDC oCDCoHw8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7Jmd0 Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAm Z3Q7wqAgwqAgwqA8YnI+DQomZ3Q7wqAgwqAgwqAgwqArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxicj4NCiZndDvCoCDCoCDC oCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7IFdoYXQgZG8gdGhlc2UgdHdvIGRpYWdyYW1zIGNvcnJl c3BvbmQgdG8/IHY0IGFuZDxicj4NCiZndDvCoCDCoCDCoHY2PyBUaGlzPGJyPg0KJmd0O8KgIMKg IMKgICZndDvCoCDCoCDCoG5lZWRzPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7 wqAgwqAgwqAgJmd0OyBleHBsYW5hdGlvbi48YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKg ICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoEl0IGlzIHRo IGVudGlyZSBJUCBwYWNrZXQgc2VudCBhcyBhIExJU1A8YnI+DQomZ3Q7wqAgwqAgwqBjb250cm9s LW1lc3NhZ2UuIFRoZTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBoZWFkZXI8YnI+DQom Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoGJlZm9yZSB0aGUgZGlhZ3JhbXMg aW5kaWNhdGUgdGhleSBhcmUgVURQIHBhY2tldHMuPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDC oCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7IEEgY2FwdGlvbiB3b3VsZCBwcm9iYWJseSBoZWxwLjxi cj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7 wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgUyA1LjIuPGJyPg0KJmd0O8KgIMKgIMKgICZndDvC oCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDCoFA6IFRoaXMgaXMgdGhlIHByb2Jl LWJpdCwgd2hpY2ggaW5kaWNhdGVzIHRoYXQgYTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAg wqBNYXAtUmVxdWVzdDxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKg U0hPVUxEPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZn dDvCoCDCoCDCoCDCoCBiZSB0cmVhdGVkIGFzIGEgTG9jYXRvciByZWFjaGFiaWxpdHk8YnI+DQom Z3Q7wqAgwqAgwqBwcm9iZS7CoCBUaGU8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgcmVj ZWl2ZXI8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoFNIT1VMRDxi cj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7wqAgwqAg wqAgwqAgcmVzcG9uZCB3aXRoIGEgTWFwLVJlcGx5IHdpdGggdGhlIHByb2JlLWJpdDxicj4NCiZn dDvCoCDCoCDCoHNldCw8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDC oGluZGljYXRpbmcgdGhhdDxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKg IMKgICZndDsmZ3Q7wqAgwqAgwqAgwqAgdGhlIE1hcC1SZXBseSBpcyBhIExvY2F0b3IgcmVhY2hh YmlsaXR5IHByb2JlPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoHJlcGx5LCB3aXRoIHRo ZTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7wqAg wqAgwqAgwqAgbm9uY2UgY29waWVkIGZyb20gdGhlIE1hcC1SZXF1ZXN0LsKgIFNlZTxicj4NCiZn dDvCoCDCoCDCoFJMT0MtUHJvYmluZzxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgU2VjdGlvbiA3LjE8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvC oCDCoCDCoCAmZ3Q7Jmd0O8KgIMKgIMKgIMKgIGZvciBtb3JlIGRldGFpbHMuPGJyPg0KJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAm Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgSG93IGFtIEkgc3VwcG9zZWQgdG8gaGFuZGxl IHRoaXMgaWYgSSBhbSBhIE1hcCBTZXJ2ZXIuPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDC oCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBJdCBzaG91 bGQgYmUgaWdub3JlZC4gSSB3aWxsIGFkZCB0ZXh0IHRvIHJlZmxlY3QgdGhpczxicj4NCiZndDvC oCDCoCDCoHBvaW50Ljxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBHb29kIHBvaW50Ljxi cj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7 wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKg ICZndDvCoCDCoCDCoCAmZ3Q7IFMgNS4yLjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAg Jmd0O8KgIMKgIMKgICZndDsmZ3Q7wqAgwqAgwqAgwqAgcmVjZWlwdC48YnI+DQomZ3Q7wqAgwqAg wqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7Jmd0Ozxicj4NCiZndDvCoCDCoCDCoCAm Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7wqAgwqAgwqBMOiBUaGlzIGlzIHRoZSBs b2NhbC14dHIgYml0LsKgIEl0IGlzIHVzZWQgYnk8YnI+DQomZ3Q7wqAgwqAgwqBhbiB4VFIgaW4g YTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgTElTUCBzaXRlIHRv PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDC oCDCoCDCoCB0ZWxsIG90aGVyIHhUUnMgaW4gdGhlIHNhbWUgc2l0ZSB0aGF0IGl0IGlzPGJyPg0K Jmd0O8KgIMKgIMKgcGFydDxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBvZiB0aGU8YnI+ DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoFJMT0Mtc2V0PGJyPg0KJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDCoCDCoCBm b3IgdGhlIExJU1Agc2l0ZS7CoCBUaGUgTC1iaXQgaXMgc2V0IHRvIDE8YnI+DQomZ3Q7wqAgwqAg wqB3aGVuIHRoZTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBSTE9DPGJyPg0KJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBpcyB0aGU8YnI+DQomZ3Q7wqAgwqAgwqAg Jmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7Jmd0O8KgIMKgIMKgIMKgIHNlbmRlciYjMzk7 cyBJUCBhZGRyZXNzLjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKg ICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7IElz IHRoZSB4VFIgc3VwcG9zZWQgdG8gZmlsdGVyIHRoaXMgb24gZXhpdGluZyB0aGUgc2l0ZS48YnI+ DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoE5vcGUuPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAm Z3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKg ICZndDvCoCDCoCDCoCAmZ3Q7IFdvbiYjMzk7dCB0aGlzIGNhdXNlIHByb2JsZW1zIG9uIGluZ3Jl c3MgdG8gYW5vdGhlciBzaXRlPzxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxi cj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgUyA1LjMuPGJy Pg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDC oG9yaWdpbmF0aW5nIE1hcC1SZXF1ZXN0IHNvdXJjZS7CoCBJZiB0aGUgUkxPQzxicj4NCiZndDvC oCDCoCDCoGlzIG5vdDxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBpbiB0aGU8YnI+DQom Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoExvY2F0b3ItPGJyPg0KJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDCoFNldCwgdGhl biB0aGUgRVRSIE1VU1Qgc2VuZCB0aGUgJnF1b3Q7dmVyaWZ5aW5nPGJyPg0KJmd0O8KgIMKgIMKg ICZndDvCoCDCoCDCoE1hcC1SZXF1ZXN0JnF1b3Q7IHRvIHRoZTxicj4NCiZndDvCoCDCoCDCoCAm Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7wqAgwqAgwqAmcXVvdDtwaWdneWJhY2tl ZCZxdW90OyBFSUQuwqAgRG9pbmcgdGhpcyBmb3JjZXMgdGhlPGJyPg0KJmd0O8KgIMKgIMKgJnF1 b3Q7dmVyaWZ5aW5nPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBN YXAtUmVxdWVzdCZxdW90OyB0bzxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgICZndDsmZ3Q7wqAgwqAgwqBnbyB0aHJvdWdoIHRoZSBtYXBwaW5nIGRhdGFiYXNlIHN5 c3RlbSB0bzxicj4NCiZndDvCoCDCoCDCoHJlYWNoIHRoZTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7 wqAgwqAgwqAgJmd0O8KgIMKgIMKgYXV0aG9yaXRhdGl2ZTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7 wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7wqAgwqAgwqBzb3VyY2Ugb2YgaW5mb3JtYXRp b24gYWJvdXQgdGhhdCBFSUQsIGd1YXJkaW5nPGJyPg0KJmd0O8KgIMKgIMKgYWdhaW5zdDxicj4N CiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgUkxPQy1zcG9vZmluZzxicj4N CiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7wqAgwqAgwqBp biB0aGUgJnF1b3Q7cGlnZ3liYWNrZWQmcXVvdDsgbWFwcGluZyBkYXRhLjxicj4NCiZndDvCoCDC oCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7IFRoaXMgdGV4dCBoZXJlIGRvZXNuJiMzOTt0IHNl ZW0gY29tcGF0aWJsZSB3aXRoIGVpdGhlcjxicj4NCiZndDvCoCDCoCDCoG9mIHRoZTxicj4NCiZn dDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqB0d28gY2FzZXM8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7IGxpc3RlZCBpbiAmcXVvdDtFSUQtcHJlZml4JnF1b3Q7 IGFib3ZlLjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDC oCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGNv bW1lbnQgRXJpYy4gTWF5YmUgYmVjYXVzZSBJIGNhbuKAmXQ8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgZmluZCB0aGU8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDC oCDCoGV4YWN0IHJlZmVyZW5jZSB0byBFSUQtcHJlZml4IHdoZXJlIHlvdSB0aGluayB0aGVyZSBp cyBhPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoGNvbmZsaWN0Ljxicj4NCiZndDvCoCDC oCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgUGxlYXNlIGNpdGUgZm9yIG1lLiBUaGFua3Mu PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZn dDvCoCDCoCDCoCAmZ3Q7IFRoaXMgZG9lcyBzZWVtIHRvIGhhdmUgYmVlbiBhc3NpZ25lZCB0byB0 aGUgd3JvbmcgdGV4dC48YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQom Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgSSBhbSByZWZlcnJpbmcgdG86PGJyPg0KJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDC oCAmZ3Q7ICZxdW90O8KgwqAgQSBNYXAtUmVwbHkgcmV0dXJucyBhbiBFSUQtUHJlZml4IHdpdGgg YSBwcmVmaXggbGVuZ3RoPGJyPg0KJmd0O8KgIMKgIMKgdGhhdDxicj4NCiZndDvCoCDCoCDCoCAm Z3Q7wqAgwqAgwqBpcyBsZXNzPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAg wqDCoCB0aGFuIG9yIGVxdWFsIHRvIHRoZSBFSUQgYmVpbmcgcmVxdWVzdGVkLsKgIFRoZSBFSUQg YmVpbmc8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgcmVxdWVzdGVkIGlzPGJyPg0KJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqDCoCBlaXRoZXIgZnJvbSB0aGUgZGVzdGlu YXRpb24gZmllbGQgb2YgYW4gSVAgaGVhZGVyIG9mIGE8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgRGF0YS1Qcm9iZSBvcjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgwqAgdGhlIEVJRCByZWNvcmQgb2YgYSBNYXAtUmVxdWVzdC7CoCBUaGUgUkxPQ3MgaW4gdGhl PGJyPg0KJmd0O8KgIMKgIMKgTWFwLVJlcGx5IGFyZTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAg wqAgwqAgJmd0OyAmcXVvdDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+ DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgdmVyc3VzPGJyPg0KJmd0O8KgIMKgIMKg ICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7ICZx dW90O8KgwqAgRUlELVByZWZpeDrCoCBUaGlzIHByZWZpeCBpcyA0IG9jdGV0cyBmb3IgYW4gSVB2 NCBhZGRyZXNzPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoGZhbWlseSBhbmQ8YnI+DQom Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoMKgwqDCoMKgIDE2IG9jdGV0cyBmb3Ig YW4gSVB2NiBhZGRyZXNzIGZhbWlseSB3aGVuIHRoZTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAg wqAgwqBFSUQtUHJlZml4LUFGSSBpcyAxPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAm Z3Q7wqAgwqDCoMKgwqDCoCBvciAyLCByZXNwZWN0aXZlbHkuwqAgRm9yIG90aGVyIEFGSXMgW0FG SV0sIHRoZSBsZW5ndGg8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgdmFyaWVzIGFuZDxi cj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgwqDCoMKgwqAgZm9yIHRoZSBM Q0FGIEFGSSB0aGUgZm9ybWF0IGlzIGRlZmluZWQgaW48YnI+DQomZ3Q7wqAgwqAgwqBbUkZDODA2 MF0uwqAgV2hlbjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBhIE1hcC08YnI+DQomZ3Q7 wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgJnF1b3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvC oCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7IFRoaXMgaXMg anVzdCB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciAmcXVvdDtwcmVmaXggbGVuZ3RoJnF1b3Q7IHJl ZmVycyB0bzxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqB0aGUgZmllbGQgb3I8YnI+DQom Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgdGhlIHNpZ25pZmljYW50IGJpdHMgb2YgdGhl IGZpZWxkLjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDC oCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0 Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZndDvCoCDCoCDCoCAm Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKg IMKgICZndDvCoCDCoCDCoCAmZ3Q7IFMgNS40Ljxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAg wqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7wqAgwqAgwqAgwqAgJiMzOTtOb25jZSYjMzk7IGZpZWxk Ljxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsmZ3Q7PGJy Pg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDvCoCDCoCDC oFJlY29yZCBUVEw6wqAgVGhpcyBpcyB0aGUgdGltZSBpbiBtaW51dGVzIHRoZTxicj4NCiZndDvC oCDCoCDCoHJlY2lwaWVudCBvZjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgdGhlIE1hcC08YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDC oCAmZ3Q7Jmd0O8KgIMKgIMKgIMKgIFJlcGx5IHdpbGwgc3RvcmUgdGhlIG1hcHBpbmcuwqAgSWYg dGhlIFRUTCBpcyAwLDxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqB0aGUgZW50cnk8YnI+ DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoE1VU1QgYmU8YnI+DQomZ3Q7 wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7Jmd0O8KgIMKgIMKgIMKgIHJl bW92ZWQgZnJvbSB0aGUgY2FjaGUgaW1tZWRpYXRlbHkuwqAgSWYgdGhlPGJyPg0KJmd0O8KgIMKg IMKgdmFsdWUgaXM8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoDB4 ZmZmZmZmZmYsPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0 OyZndDvCoCDCoCDCoCDCoCB0aGUgcmVjaXBpZW50IGNhbiBkZWNpZGUgbG9jYWxseSBob3cgbG9u Zzxicj4NCiZndDvCoCDCoCDCoHRvIHN0b3JlIHRoZTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAg wqAgwqAgJmd0O8KgIMKgIMKgbWFwcGluZy48YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKg ICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAg wqAgwqAgJmd0OyBBbSBJIHN1cHBvc2VkIHRvIG1lcmdlIHRoaXMgd2l0aCBwcmV2aW91cyBtYXBw aW5ncz88YnI+DQomZ3Q7wqAgwqAgwqBSRW1vdmU8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKg IMKgdGhlbT88YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAg wqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoE5vIHJlcGxhY2UgaXQuIFRoZXJlIGlzIHRl eHQgdGhhdCBzYXlzIHRoaXMgdGhhdCBpczxicj4NCiZndDvCoCDCoCDCoG5vdCBpbiB0aGU8YnI+ DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoHBhY2tldCBmb3JtYXQgZGVz Y3JpcHRpb24gc2VjdGlvbi48YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+ DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgICZndDsgT0suPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0K Jmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDC oCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyBTIDguMy48YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKg IMKgICZndDvCoCDCoCDCoCAmZ3Q7Jmd0O8KgIMKgIMKgb2YgdGhlIG1hcHBpbmcgZGF0YWJhc2Ug cHJvdG9jb2xzLjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZn dDsmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZn dDvCoCA4LjMuwqAgTWFwLVNlcnZlciBQcm9jZXNzaW5nPGJyPg0KJmd0O8KgIMKgIMKgICZndDvC oCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKg IMKgICZndDvCoCDCoCDCoCAmZ3Q7Jmd0O8KgIMKgIMKgT25jZSBhIE1hcC1TZXJ2ZXIgaGFzIEVJ RC1QcmVmaXhlcyByZWdpc3RlcmVkPGJyPg0KJmd0O8KgIMKgIMKgYnkgaXRzPGJyPg0KJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoGNsaWVudDxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAg Jmd0O8KgIMKgIMKgRVRScywgaXQ8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvC oCDCoCDCoCAmZ3Q7Jmd0O8KgIMKgIMKgY2FuIGFjY2VwdCBhbmQgcHJvY2VzcyBNYXAtUmVxdWVz dHMgZm9yIHRoZW0uPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAg Jmd0Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgVGhp cyBzZWN0aW9uIGlzIGNvbmZ1c2luZyBiZWNhdXNlIHRoZSBpbnRyb2R1Y3Rpb24gc2F5czxicj4N CiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqB0aGF0IHRoaXM8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7IGZ1bmN0aW9uIGlzIG9ubHkgcGVyZm9ybWVkIGJ5 IE1hcC1SZXNvbHZlcnM6PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAg wqAgJmd0OyAmIzM5Ozxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKg ICZndDsgJnF1b3Q7VGhlIExJU1AgTWFwcGluZyBTZXJ2aWNlIGRlZmluZXMgdHdvIG5ldyB0eXBl cyBvZjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBMSVNQLXNwZWFraW5nPGJyPg0KJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgZGV2aWNlczogdGhl IE1hcC1SZXNvbHZlciwgd2hpY2ggYWNjZXB0cyBNYXAtUmVxdWVzdHM8YnI+DQomZ3Q7wqAgwqAg wqAgJmd0O8KgIMKgIMKgZnJvbSBhbjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgICZndDsgSW5ncmVzczxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgICZndDvCoCDCoFR1bm5lbCBSb3V0ZXIgKElUUikgYW5kICZxdW90O3Jlc29sdmVz JnF1b3Q7IHRoZSBFSUQtdG8tUkxPQzxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBtYXBw aW5nIHVzaW5nIGE8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAm Z3Q7wqAgwqBtYXBwaW5nIGRhdGFiYXNlOyBhbmQgdGhlIE1hcC1TZXJ2ZXIsIHdoaWNoIGxlYXJu czxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBhdXRob3JpdGF0aXZlPGJyPg0KJmd0O8Kg IMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyBFSUQtPGJyPg0KJmd0O8KgIMKg IMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgdG8tUkxPQyBtYXBwaW5ncyBm cm9tIGFuIEVncmVzcyBUdW5uZWwgUm91dGVyPGJyPg0KJmd0O8KgIMKgIMKgKEVUUikgYW5kPGJy Pg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoHB1Ymxpc2hlczxicj4NCiZndDvCoCDCoCDCoCAm Z3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDvCoCDCoHRoZW0gaW4gYSBkYXRhYmFzZS7igJ08 YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoFRoZSBkb2N1bWVudCBkb2VzIGNvdmVyIHRoZSBvcGVyYXRp b24gb2YgYTxicj4NCiZndDvCoCDCoCDCoE1hcC1SZXNvbHZlciBhbmQgYTxicj4NCiZndDvCoCDC oCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgTWFwLVNlcnZlci4gU29tZSBmdW5jdGlvbnMg YXJlIHBlcmZvcm1lZCBvbmx5IGJ5PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoE1hcC1S ZXNvbHZlcnMgb25seTxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKg YW5kIG90aGVyIGRpZmZlcmVudCBmdW5jdGlvbnMgYXJlIHBlcmZvcm1lZCBieTxicj4NCiZndDvC oCDCoCDCoE1hcC1TZXJ2ZXJzIG9ubHkuPGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAm Z3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBJIGFtIG5vdCBz dXJlIHdoYXQgeW91IGRvbuKAmXQgdW5kZXJzdGFuZC48YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8Kg IMKgIMKgICZndDs8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7 wqAgwqAgwqAgJmd0O8KgIMKgIMKgICZndDsgU3VyZTogQXMgSSB1bmRlcnN0YW5kIGl0LCBNYXAg UmVzb2x2ZXJzIHByb2Nlc3MgTWFwPGJyPg0KJmd0O8KgIMKgIMKgUmVxdWVzdHMsIGFuZDxicj4N CiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBNYXA8YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKg IMKgICZndDsgU2VydmVycyBkbyBub3QgKHRoYXQmIzM5O3Mgd2hhdCB0aGUgcXVvdGVkIHRleHQg c2VlbXMgdG8gc2F5KS48YnI+DQomZ3Q7wqAgwqAgwqAgJmd0O8KgIMKgIMKgSG93ZXZlciwgdGhp czxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyBzZW50ZW5jZSB0YWxrcyBhYm91 dCBhIE1hcCBTZXJ2ZXIgcHJvY2Vzc2luZyBhIE1hcDxicj4NCiZndDvCoCDCoCDCoFJlcXVlc3Qu wqAgVGhhdCYjMzk7czxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyB3aGVyZSBJ IGFtIGNvbmZ1c2VkLjxicj4NCiZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0Ozxicj4NCiZn dDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqAgJmd0OyAtRWtyPGJyPg0KJmd0O8KgIMKgIMKgICZndDvC oCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7PGJyPg0KJmd0 O8KgIMKgIMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBUaGFua3MsPGJyPg0KJmd0O8KgIMKg IMKgICZndDvCoCDCoCDCoCAmZ3Q7wqAgwqAgwqBEaW5vPGJyPg0KJmd0O8KgIMKgIMKgICZndDvC oCDCoCDCoCAmZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgICZndDs8YnI+DQomZ3Q7IDxicj4NCjwvYmxv Y2txdW90ZT48L2Rpdj48L2Rpdj4NCg== --000000000000d44d620577061b12-- From nobody Sat Sep 29 11:53:20 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB28130E4D; Sat, 29 Sep 2018 11:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZERy2I6X-Gxn; Sat, 29 Sep 2018 11:53:00 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 ADDD3126CB6; Sat, 29 Sep 2018 11:52:59 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id y18-v6so6736541pge.0; Sat, 29 Sep 2018 11:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WYrRtMRhY9GkZM6RYF5TK+vGfG/csM4vLowxyVqhZ+A=; b=FyIkwTuOhXvv883slDeBIpuNst6qs8C4njQvAB1WykOm+OrTnlLAWeXudcOYB8qdVl 43w7vfcRf5cvg9QXsV/o4KM+EJsdIIOKPl4L7n1abeJx/OjVceu7S+ZozyjAp1YqvVyj izCJoic84z2pOmwwYACTOLAkTqhTJmhb9JLKYtSBh/x/mgrwm9tiNNcvbTD24P0KedSV unxkPrejI48TChPd3crStjLliLA6iCZIJ22YAs45Brptbo8PFO/pr3suBEEDh3Kn/eSu lbbv0qWevmLndbjkWXiKZ6yUO4biHMbxbBszvNt+J6UhhzN1EuDbir9HqupU0EgwxNLd Q4cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WYrRtMRhY9GkZM6RYF5TK+vGfG/csM4vLowxyVqhZ+A=; b=QKBndsj63hWnCJg/rIcp7uNRJV700gmKOm6RSwZZrqa8dC9lzrotAQ2TmdfGACcG9n bKAnpX3PTZrBuu1mz2csmU7d8BpnqZOA8BEwxsdj10/bl4ozT8Coix1liUMBeUGVcrLp MFME77bKi7fbFFTSNE78fo0hdyBS/06cPCb0h6LgYTFztLQcEgZ/CohSr7IK3bD4GbLh L1XkhaG+JtjwAKWb+5Bfa+Ggqf6d5pdbLoAbkxw1s9IETUX0BVrbS5Hf/6Iuyzo0EYpu 2Zt5Z/9zzLXTPXlHAtZlfaXRPav5cjVXexjIR3XB8u7mJeU/04Ss7ZQaS0joSvDVoyfP cDog== X-Gm-Message-State: ABuFfog06kXlgEJhPIczjTRc3dFjFYMYnSLoxGSlrzI3Th0vHigzCZLB XQEgEOKnMamE6dqFZhFxPAeG84SN X-Google-Smtp-Source: ACcGV63HFYH3+hgkD9DSV2WgfTzHMGlu4fnyXJinPcGyO0YdWVgUjgzG/zmjOY0vqAEOgXIkLdDvvA== X-Received: by 2002:a62:8dcd:: with SMTP id p74-v6mr3298753pfk.217.1538247178918; Sat, 29 Sep 2018 11:52:58 -0700 (PDT) Received: from [10.31.79.57] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id t123-v6sm12225113pfd.51.2018.09.29.11.52.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Sep 2018 11:52:57 -0700 (PDT) From: Dino Farinacci Message-Id: <9C2DD767-413D-4FE6-B5A3-5EC5863AC80D@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_7BF7407E-EF83-4B8E-8D3D-3368F8E09350" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 29 Sep 2018 11:52:55 -0700 In-Reply-To: <153802389933.21595.7512100936069393959.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, lisp@ietf.org To: Benjamin Kaduk References: <153802389933.21595.7512100936069393959.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 29 Sep 2018 18:53:09 -0000 --Apple-Mail=_7BF7407E-EF83-4B8E-8D3D-3368F8E09350 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Benjamin for your comments. Both yours and Eric=E2=80=99s were = really detailed and right on. Its folks like you that will make the = Internet much better. Thanks for that. As I said with Eric=E2=80=99s comments, I=E2=80=99m fixing the simple = things from your comment section. I have attached a diff file for -22 of = 6833bis that include changes for Eric=E2=80=99s comments (last email I = sent) and comments from this email. > On Sep 26, 2018, at 9:51 PM, Benjamin Kaduk wrote: >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I apologize for the somewhat scattered nature of these comments; there = are > a lot of them and I was focusing my time more on trying to understand = the > broader system, and the intended security posture, so they did not get = as > much clean-up as I would have liked. >=20 > Map-Reply will typically forward a packet that got a negative reply > onto the public internet, adding extra latency to all flows through > a LISP-enabled ITR; is that correct? If the packet that arrives at the ITR has a source EID in the source = address field and the destination is not an EID (and in this case it it = not because the destination address does not match a mapping in the = mapping system), then the packet is forwarded natively. And the delay = incurred is a map-cache lookup versus a regular FIB lookup from a = typical IP forwarding engine. There is an internal latency added yes. > Section 1 >=20 > Note this document doesn't assume any particular database mapping > infrastructure to illustrate certain aspects of Map-Server and Map- > Resolver operation, the Mapping Service interface can (and likely > will) be used by ITRs and ETRs to access other mapping database > systems as the LISP infrastructure evolves. >=20 > nit: This looks like a comma splice, though I'm not sure I'm parsing = everything > correctly. I made it 2 sentences. > Section 2 >=20 > Use the actual boilerplate from RFC 8174; don't just tack on a new > reference to the existing (and without errata fix!) RFC 2119 = boilerplate. Changed. >=20 > Section 3 >=20 > Should the Map-Register message's definition also mention that the > Map-Server returns the registered RLOCs in normal Map-Replys? It says that in the last sentence of the =E2=80=9CMap-Register = message=E2=80=9D definition. > Section 4 >=20 > A Map-Server is a device that publishes EID-Prefixes in a LISP > mapping database on behalf of a set of ETRs. When it receives a Map > Request (typically from an ITR), it consults the mapping database to > find an ETR that can answer with the set of RLOCs for an EID-Prefix. >=20 > My understanding from the intro document, etc., was that the ITR = generally > was not sending Map-Requests directly to Map-Servers, and that rather = there > was some triangle routing, with the Map-Request going from ITR to > Map-Resolver to Map-Server, and the Map-Reply directly from Map-Server = to > ITR (so "typically one initiated by an ITR" or similar). It's also = odd > language (to me) to have the Map-Server "consult the mapping database" = when > the Map-Server comprises part of the mapping database and has local > authoritative data. Map-Servers get Map-Requests indirectly via the Map-Resolver an the = Database Mapping Transport system. And yes, the map-server needs to = consult the mapping system beacuse it is a sharded database and it may = not have the entries it needs to look up. > Section 5 >=20 > Are we really just duplicating the IPv4+UDP and IPv6+UDP packet = headers > here? Yes, we are for a desire to be explicit. > Section 5.1 >=20 > Values in the "Not Assigned" range can be assigned according to > procedures in [RFC8126]. Documents that request for a new LISP > packet type may indicate a preferred value. >=20 > 8126 has lots of procedures; generally we use a name to indicate which = one > is to be followed. Have a suggestion? > Section 5.2 >=20 > Using the same letter with different case for different flag bits = sounds > confusing. We want them to be easily remembered and the text is consistent about = how we reference them. And I have dealt with them quite easily after = doing 2 different LISP implementations. > Lots of potential fun tampering with these flag bits, whether = downgrade > attacks on features or otherwise mucking around. >=20 > Source EID address in Map-Request has privacy considerations. I think less when it is opaque via random address assignment or use of = crypto-EIDs (see draft-ietf-lisp-ecdsa-auth for details). > If the multiple ITR-RLOC Addresses is soleyl "to give the ETR the = option of > selecting the destination address from any address family" then there > should be a restriction to one ITR address per AFI. (But it's not, so = this > text should be tweaked to avoid suggesting that it is.) There is no need for this restriction. It is not helpful. > When an EID mask-len smaller than the full length of the given address = type > is used, what are the values of the bits in the EID-Prefix field that = are > "masked away"? Leaving unspecified bits like this makes for an easy = covert The low-order bits. This is a well-known technique used in routing = protocols for decades. > channel, especially so when the protocol messages are not covered by = any > integrity protection scheme and subject to on-path tampering. >=20 > Section 5.3 >=20 > A Map-Request is sent from an ITR when it needs a mapping for an = EID, > wants to test an RLOC for reachability, or wants to refresh a = mapping > before TTL expiration. For the initial case, the destination IP > address used for the Map-Request is the data packet's destination > address (i.e., the destination EID) that had a mapping cache lookup > failure. For the latter two cases, the destination IP address used > for the Map-Request is one of the RLOC addresses from the = Locator-Set > of the Map-Cache entry. >=20 > I seem to be confused by the "destination IP address" bits here. > Are we really sending Map-Request UDPgrams from an ITR to the EID > destination address that we failed to look up, hoping that some magic = in > the network will cause it to end up at an ETR or Map-Server that can = reply? > Or is this talking about how we set the EID-Prefix portion of the > Map-Request? The latter two cases do seem to be using RLOCs in a way > that I expect, which makes me think I'm confused. The Map-Request has an IP header in front of it. That packet is = encapsulated in an ECM message which has another IP header wrapped = around it. This is a Map-Request sent to the mapping system. > Where is the term "Map-Replier" defined? Can=E2=80=99t you assume it is the sender of a Map-Reply? I don=E2=80=99t = tink tha tis a stretch. ;-) >=20 > [...] If the ITR erroneously > provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- > Request. >=20 > It's unclear how the Map-Replier would detect this, as opposed to just > blindly trying to interpret the start of the request records as an > ITR-RLOC. It would be a field with all 0s. A martian IPv4 address perhaps. > An ITR that is configured with mapping database information (i.e., = it > is also an ETR) MAY optionally include those mappings in a Map- > Request. When an ETR configured to accept and verify such > "piggybacked" mapping data receives such a Map-Request and it does > not have this mapping in the Map-Cache, it MAY originate a = "verifying > Map-Request", addressed to the map-requesting ITR and the ETR MAY = add > a Map-Cache entry. [...] >=20 > This seems like a place where naming the xTRs not by role would help > clarify the flows and the role in which each entity is acting, at each > point. But in this case, the role is very important. Generalizing it would lose = the specification of which side does what. >=20 > [...] If the ETR has a Map-Cache entry that matches the I changed this to =E2=80=9CIf the ETR (when it is an xTR co-located as = an ITR) =E2=80=A6=E2=80=9D > "piggybacked" EID and the RLOC is in the Locator-Set for the entry, > then it MAY send the "verifying Map-Request" directly to the > originating Map-Request source. If the RLOC is not in the Locator- > Set, then the ETR MUST send the "verifying Map-Request" to the > "piggybacked" EID. >=20 > It's probably worth disambiguating that "the RLOC" is the cached RLOC = for > the EID in the "piggybacked" Map-Reply record. (Of course, there = could be > more than one cached RLOC for a given EID, so "the" is not really = right > anyway.) Similarly, "the Locator-Set" could become "the Locator-Set = in the > piggybacked Map-Reply record". Additionally, and this may just be my > confusion, but is "send ... to the piggybacked EID" the right = terminology? > In my mental model at least, "perform a fresh mapping lookup for the = EID in > order to send a verifying Map-Request" would be better. Hmm, it is clear to me. There is only one RLOC to verify because each = remote xTR may not have to full RLOC-set (example is two xTRs each = behind different NATs, where they need to determine their global RLOC = address). >=20 > Section 5.4 >=20 > 'S' bit, so clearing that bit and dropping the AD trailer allows an > attacker to modify the contents. We would perhaps only saved by the = bit in > 6830bis where if you ask for a secure resolution you have to get one = back, > but that's not deployable. The LISP-SEC MUST specify the use of DTLS to avoid this attack. And we = are going through discussions to ask the WG if it is desirable to make = LISP-SEC normative. > Nonce: This is a 24-bit value set in a Data-Probe > [I-D.ietf-lisp-rfc6830bis] or a 64-bit value from the Map-Request > is echoed in this 'Nonce' field of the Map-Reply. When a 24-bit > value is supplied, it resides in the low-order 64 bits of the > 'Nonce' field. >=20 > Just a 6830bis reference isn't quite enough to describe this case, I = think; > don't you need to say that the other 40 bits are used by the mapping > implementation? We removed Data-Probes and this text didn=E2=80=99t get removed. The = reference to 24-bits will be removed. >=20 > In the ACT field, is the "No-Action" value ever used for Negative > Map-Replies? If so, I'm confused what the semantics are supposed to = be. No. > Differentiating between Drop/policy and Drop/authentication may open = up > a side channel for an attacker to learn about authentication or policy > information. (But maybe not; this needs more analysis) We thought it would be useful for network management purposes to = distinguish the two cases. > A: The Authoritative bit, when sent, is always set to 1 by an ETR. >=20 > What does "when sent" mean? The field is part of the structure; it's > always sent. Or is this supposed to be "has value 1 if and only if = the > Map-Reply is sent by an ETR=E2=80=9D? Changed to =E2=80=9Cwhen set to 1=E2=80=9D. >=20 > The EID-Prefix entry should probably reuse (or refer to) the text from = the > Map-Request field, covering length for other AFIs. > Also, say what goes on for the bits that are "masked out=E2=80=9D. No, it is completely a different record type. Unless I=E2=80=99m not = following your point. > I feel like perhaps less could be said about the 'M' priority and = weight > fields, as what's currently there just leaves me confused about ETR = vs. ITR > vs. xTR and how this information flow is consumed. It would be no different than =E2=80=9CU=E2=80=9D priority and weight so = not sure why are say this. > p: When this bit is set, an ETR informs the RLOC-Probing ITR that = the > locator address for which this bit is set is the one being RLOC- > probed and may be different from the source address of the Map- > Reply. An ITR that RLOC-probes a particular Locator MUST use = this > Locator for retrieving the data structure used to store the fact > that the Locator is reachable. The p-bit is set for a single > Locator in the same Locator-Set. If an implementation sets more >=20 > Exactly one or at most one? We are saying it should not set more than one. >=20 > than one p-bit erroneously, the receiver of the Map-Reply MUST > select the first Locator. The p-bit MUST NOT be set for Locator- >=20 > First overall or first that sets the p bit? I changed to =E2=80=9Cfirst set p-bit locator=E2=80=9D. >=20 > Set records sent in Map-Request and Map-Register messages. >=20 > Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- > AFI' field) assigned to an ETR. Note that the destination RLOC > address MAY be an anycast address. A source RLOC can be an > anycast address as well. The source or destination RLOC MUST NOT > be the broadcast address (255.255.255.255 or any subnet broadcast > address known to the router) and MUST NOT be a link-local > multicast address. The source RLOC MUST NOT be a multicast > address. The destination RLOC SHOULD be a multicast address if = it > is being mapped from a multicast destination EID. >=20 > This is the section on the contents of the Map-Reply message. Why are = we > talking about source RLOCs? Oh, we're going to refer back to this = from > other sections for just the "EID-record" portion (a term which is not > properly defined). It would be good to mention that up front at the = start > of this section or the list of fields in the EID-record. We are referring to RLOCs in a data-packet. I=E2=80=99ll make more = clear. > Section 5.5 >=20 > A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a > record count of 3 to be returned with mapping records for EID- > Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32. = Note > filling out the /24 with more-specifics that exist in the mapping > system. >=20 > nit: This last sentence is a sentence fragment. Fixed. >=20 > Requiring numerical sort of the locators seems to make the "inserted = in > the middle" case very difficult to reason about, especially relating = to > synchronization with the data plane and LSBs in data-plane messages. >=20 > [...] The source address of the Map-Reply is one of > the local IP addresses chosen to allow Unicast Reverse Path > Forwarding (uRPF) checks to succeed in the upstream service = provider. >=20 > nit: should there be a comma before "chosen=E2=80=9D? Added. > Section 5.6 >=20 > Huh, why did I think that Map-Register was always sent encapsulated? I have no idea. ;-) > The key-ID description is a great example of how to best describe the > security properties of a field; thanks! >=20 > Authentication Data: This is the message digest used from the = output >=20 > "digest" is a term of art and is not appropriate here. Probably best = to > just say "This is the output of the MAC algorithm.=E2=80=9D Done. I think Eric made this comment too. > of the MAC algorithm. The entire Map-Register payload is > authenticated with this field preset to 0. After the MAC is > computed, it is placed in this field. Implementations of this > specification MUST include support for HMAC-SHA-1-96 [RFC2404], > and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. >=20 > It's probably good to explictly clarify that "entire payload" means > "from and including the LISP message type field through the end of the = last > record and its locators". > Also, the MUST/RECOMMENDED status seems backwards. Changed. > I guess referring back to Section 5.4 for the duplicated fields is = probably > okay, but I would suggest calling out the portions that are only = applicable > or uniquely handled for the Map-Register message. That is explained in sections that are not packet format sections. > Section 5.7 >=20 > [...] An implementation SHOULD retransmit up to 3 times at 3 > second retransmission intervals, after which time the retransmission > interval is exponentially backed-off for another 3 retransmission > attempts. >=20 > This is underdefined without specifying the exponent base for the > exponential backoff. In routing protocols, it is known as doubling the backoff. How would you = want to explain that? > Why is it allowed to Map-Register without requesting a Map-Notify? It=E2=80=99s an option to have reliability through periodic transmission = versus incremental transmission. > Section 5.8 >=20 > An Encapsulated Control Message (ECM) is used to encapsulate control > packets sent between xTRs and the mapping database system. >=20 > Please be explicit about whether all such messages are encapsulated or = only > some of them. We do in other sections. >=20 > S: This is the Security bit. When set to 1, the field following > the 'Reserved' field will have the following Authentication > Data format and follow the procedures from = [I-D.ietf-lisp-sec]. >=20 > Could there be some indication of "optional security fields" in the = figure? That is too much detail to put in here and we have a whole LISP-SEC = document to explain that. > It's a bit odd to have the 'D' bit in the encapsulation as opposed to > directly in the Map-Request, though I guess it's a bit late to be = changing > that. It is necessary for the Map-Resolver that gets ECM based Map-Request. >=20 > E: This is the to-ETR bit. When set to 1, the Map-Server's > intention is to forward the ECM to an authoritative ETR. >=20 > I think this needs to say more about which message flows this bit is > defined for. Presumably the ITR will never use it for sending an > encapsulated Map-Request to a Map-Resolver, but there seem to be = plenty of > places where ECM wrapping is used. This is LISP-DDT related and in that document. > M: This is the to-MS bit. When set to 1, a Map-Request is being > sent to a co-located Map-Resolver and Map-Server where the > message can be processed directly by the Map-Server versus the > Map-Resolver using the LISP-DDT procedures in [RFC8111]. >=20 > How does the sender know that its configured Map-Resolver is also a > Map-Server? It's unclear to me why this needs a bit in the message as It doesn=E2=80=99t need to know. The ITR can set the bit for efficiency = purposes but the MSP (mapping system provider needs to tell them to set = the bit). > opposed to just happening based on the attributes of the receiving > Map-Server. >=20 > LCM: The format is one of the control message formats described in > this section. At this time, only Map-Request messages are > allowed to be Control-Plane (ECM) encapsulated. In the = future, > PIM Join/Prune messages [RFC6831] might be allowed. > Encapsulating other types of LISP control messages is for > further study. When Map-Requests are sent for RLOC-Probing > purposes (i.e., the probe-bit is set), they MUST NOT be sent > inside Encapsulated Control Messages. >=20 > This type of forward-looking language seems unusuabl for a PS = document; I > would expect to not see predictions on what might happen, but rather = the > specification of what procedure is used to allow new message types. This is being done in RFC6831. Rather than predicting, I=E2=80=99ll make = a refrence to it. The prediction came true. ;-) Good catch. Another reminder, that we have been working on these specs = for way too long. > Section 6.1 >=20 > Since the ETRs don't keep track of remote ITRs that have cached = their > mappings, they do not know which ITRs need to have their mappings > updated. [...] >=20 > Nothing *prevents* ETRs from doing this tracking; they're just not = required > to do so. So it would be better to say something like "Since ETRs are = not > required to keep track of [...]=E2=80=9D. Changed. >=20 > [...] In particular, an ETR will send an SMR to > an ITR to which it has recently sent encapsulated data. This can > only occur when both ITR and ETR functionality reside in the same > router. >=20 > Having just come from the section on the "encapsulated control = message", > perhaps the reader could use an extra hint that the "encapsulated = data" is > just "LISP-tunneled data-plane traffic". Also, is this intended to be = a > normative requirement (with the use of "will=E2=80=9D)? Change to =E2=80=9CLISP encapsulated data packets=E2=80=9D. >=20 > 1. When the database mappings in an ETR change, the ETRs at the = site > begin to send Map-Requests with the SMR bit set for each Locator > in each Map-Cache entry the ETR caches. >=20 > Map-Cache is an ITR function; this is probably another case where = naming > the routers would allow for a more clear description of the protocol > exchanges. Also, this seems in disagreement with the previous text = about > sending data in the previous minute, since Map-Cache entries can = persist > for longer than a minute. Change to =E2=80=9C...in each Map-Cache entry the ETR (when it is an xTR = co-located as an ITR) caches=E2=80=A6.=E2=80=9D >=20 > 5. The ETRs at the site with the changed mapping record the fact > that the site that sent the Map-Request has received the new > mapping data in the Map-Cache entry for the remote site so the > Locator-Status-Bits are reflective of the new mapping for = packets > going to the remote site. The ETR then stops sending SMR > messages. >=20 > Perhaps a nit, but the "site with the changed mapping" doesn't make = sense > -- the map applies to the EID, and in principle the EID could have = moved to > a different site. So this could be "the site sending SMR messages" > perhaps. Also, I think there needs to be greater clarity about which > Locator-Status bits are being described. Finally, the cessation of = sending > SMR messages is presumably scoped to those targetted to the sender of = the > Map-Request in question and not a global property? >=20 Changed text to your suggestion. > For security reasons, an ITR MUST NOT process unsolicited Map- > Replies. To avoid Map-Cache entry corruption by a third party, a > sender of an SMR-based Map-Request MUST be verified. If an ITR > receives an SMR-based Map-Request and the source is not in the > Locator-Set for the stored Map-Cache entry, then the responding Map- > Request MUST be sent with an EID destination to the mapping database > system. Since the mapping database system is a more secure way to > reach an authoritative ETR, it will deliver the Map-Request to the > authoritative source of the mapping data. >=20 > The only verification possible in this set of documents does not = constitute > a security mechanism worthy of the name. > Also, allowing off-path attackers to induce requests to the mapping = system > seems like a DoS vector only partially mitgiated by rate limiting. I am deferring answer security questions in this email until we have the = conference call. >=20 > Section 7 >=20 > One could perhaps quibble as to whether (1) through (3) constitute > "control-plane", vs. "out-of-band" given that this documents the LISP > Control-Plane as specific UDP messages. >=20 > Section 7.1 >=20 > When an ETR receives a Map-Request message with the probe-bit set, = it > returns a Map-Reply with the probe-bit set. The source address of > the Map-Reply is set according to the procedure described in > [I-D.ietf-lisp-rfc6830bis]. Since we did a shuffle of the control-plane and data-plane documents, I = will fix this. Thanks for the comment. >=20 > Please provide a detailed section reference; 6830bis does not = specifically > cover source address selection for probes. >=20 > [...] The greatest > benefit of RLOC-Probing is that it can handle many failure scenarios > allowing the ITR to determine when the path to a specific Locator is > reachable or has become unreachable, thus providing a robust > mechanism for switching to using another Locator from the cached > Locator. >=20 > nit: "greatest benefit ... handle many failure scenarios" is a strange > wording to me. Presumably the failures are not failures of the = probing, > but rather network failures of some form? Changed =E2=80=9Cgreatest=E2=80=9D to =E2=80=9Cmain=E2=80=9D. Is that = okay? > Section 8.1 >=20 > o An immediate Negative Map-Reply (with action code of "Natively- > Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if > the Map-Resolver can determine that the requested EID does not > exist. [...] >=20 > This seems to be attempting to instill a normative requirement of = setting > the 15-minute TTL for this case; please use normative language to that > effect. It is. So why is that bothering you? The text is providing an = architectural constant. >=20 > [...] If the > requested EID matches a more-specific EID-Prefix that has been > delegated by the Map-Server but for which no ETRs are currently > registered, a 1-minute TTL is returned. If the requested EID > matches a non-delegated part of the authoritative EID-Prefix, = then > it is not a LISP EID and a 15-minute TTL is returned. [...] >=20 > (Same comment as above about normative language) Same response. > A Map-Server's configuration > SHOULD also include a list of the EID-Prefixes for which each ETR is > authoritative. Upon receipt of a Map-Register from an ETR, a Map- > Server accepts only EID-Prefixes that are configured for that ETR. >=20 > I think there also needs to be some text about the ETR and associated > Map-Server being part of a single administrative domain. They usually are not and we shouldn=E2=80=99t imply they are. > Failure to implement such a check would leave the mapping system > vulnerable to trivial EID-Prefix hijacking attacks. As developers >=20 > As described here, this is essentially relying on local configuration = for > information about who is authoritative for what EID prefixes, which is > prone to becoming stale and does not scale. I am not sure what you think I should change. > Section 8.3 >=20 > If there is no match, the Map- > Server returns a Negative Map-Reply with action code "Natively- > Forward" and a 15-minute TTL. [...] >=20 > In light of my comments in section 8.2, perhaps we can consolidate the > normative requirements to just one location and have a pointer from = the > other(s)? I would like to keep them where they are introduced. >=20 > If the EID-prefix is either registered or not registered to the > mapping system and there is a policy in the Map-Server to have the > requestor drop packets for the matching EID-prefix, then a Drop/ > Policy-Denied action is returned. [...] >=20 > In a Map-Server state machine or flow chart, it seems like this policy > application would come before even the above checks for negative = responses. > Should the document reflect that ordering as well? Leaving it up to the implementation. >=20 > If the EID-prefix is registered = or > not registered and there is a authentication failure, then a Drop/ > Authentication- failure action is returned. [...] >=20 > I'm confused what kind of authentication failure is possible here -- = there > does not seem to be any end-to-end client authentication of mapping > requests that I have seen in any LISP documents I've read so far. This was added to support draft-ietf-lisp-ecdsa-auth. If a Map-Request = is required to be signed by a map-server and doesn=E2=80=99t include a = signature, than Drop-Action/Auth-failure is returned. If a Map-Request = includes a signature and it verifies false or the public-key cannot be = found, than Drop-Action/Auth-failure is returned. > Section 9 >=20 > To publish an authoritative EID-to-RLOC mapping with a Map-Server, = an > ETR includes authentication data that is a hash of the message using > a pair-wise shared key. [...] >=20 > "hash" is a term of art and is not appropriate here; please use = "MAC=E2=80=9D. Done. >=20 > [I-D.ietf-lisp-sec] defines a proposed mechanism for providing = origin > authentication, integrity, anti-replay protection, and prevention of > man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- > Reply exchange. Work is ongoing on this and other proposals for > resolving these open security issues. >=20 > It only partially mitigates some of those, and for others relies on = the > mapping system to provide some properties that are not clearly = achievable. > It is unwise to claim that they are possible absent further clarity on = what > behavior mapping systems can currently provide. > [edit: this text changed in the -16] Let=E2=80=99s save this for the conference call. >=20 > Section 11.3 >=20 > In addition, LISP has a number of flag fields and reserved fields, > such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New > bits for flags in these fields can be implemented after IETF review > or IESG approval, but these need not be managed by IANA. >=20 > How will a prospective implementor know that they have found all = defined > flags fields? Are documents allocating new ones supposed to Update: = this > one? They are all documented in 6830bis. And the one reserved bit is used for = LISP-GPE. And we are deciding if it should be put in there or kept out. = WG mulling this over. > Section 11.4 >=20 > The IANA registry "LISP Canonical Address Format (LCAF) Types" is > used for LCAF types, the registry for LCAF types use the > Specification Required policy [RFC8126]. [...] >=20 > nit: comma splice Fixed. > Section 11.5 >=20 > I would suggest Expert Review rather than FCFS, for such a scarce = codepoint > space with only 256 total values. The WG decided on this. The WG needs to discuss this. Thanks so much for your thorough comments. They are really helpful and = making the documents better! Dino --Apple-Mail=_7BF7407E-EF83-4B8E-8D3D-3368F8E09350 Content-Disposition: attachment; filename=rfcdiff-6833bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6833bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-16.txt - = draft-ietf-lisp-rfc6833bis-17.txt=20 =20 =20 =20 =20 =20 =20 =
< draft-ietf-lisp-rfc6833bis-16.txt  =  draft-ietf-lisp-rfc6833bis-17.txt >
=
Network Working = Group V. Fuller = Network Working Group = V. Fuller
Internet-Draft = D. Farinacci Internet-Draft = D. Farinacci
Obsoletes: 6833 = (if approved) Cisco Systems = Obsoletes: 6833 (if approved) = Cisco Systems
Intended status: = Standards Track A. Cabellos (Ed.) = Intended status: Standards Track = A. Cabellos (Ed.)
Expires: March 30, 2019 = UPC/BarcelonaTech Expires: April 2, 2019 = UPC/BarcelonaTech
= September 26, 2018 = September 29, 2018
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-16 = = draft-ietf-lisp-rfc6833bis-17
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = Control-Plane service interface and communicating with By using this Control-Plane service interface and = communicating with
Map-Resolvers = and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and = Map-Resolvers and Map-Servers, LISP Ingress = Tunnel Routers (ITRs) and
Egress Tunnel = Routers (ETRs) are not dependent on the details of Egress Tunnel Routers (ETRs) are not dependent on the = details of
mapping = database systems, which facilitates modularity with different = mapping database systems, which facilitates = modularity with different
database = designs. Since these devices implement the "edge" of the = database designs. Since these devices = implement the "edge" of the
LISP = Control-Plane infrastructure, connect directly to = LISP-capable LISP = Control-Plane infrastructure, connecting EID = addressable nodes
Internet end sites, and comprising the bulk = of LISP-speaking devices, = of a LISP = site, their implementation and operational complexity
reducing their implementation and operational = complexity should also reduces the overall = cost and effort of deploying LISP.
reduce the overall cost and effort of = deploying LISP.
=
This document = obsoletes RFC 6830 and 6833. This = document obsoletes RFC 6830 and 6833.
=
Status of This = Memo Status of This Memo
=
This = Internet-Draft is submitted in full conformance with the = This Internet-Draft is submitted in full = conformance with the
provisions of = BCP 78 and BCP 79. provisions of = BCP 78 and BCP 79.
=
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on March 30, = 2019. This Internet-Draft will = expire on April 2, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 26 =C2=B6 = skipping to change at page 2, line 26 =C2=B6
include = Simplified BSD License text as described in Section 4.e of = include Simplified BSD License text as = described in Section 4.e of
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
described in = the Simplified BSD License. = described in the Simplified BSD License.
=
Table of = Contents Table of Contents
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. = Requirements Notation . . . . . . . . . . . . . . . . . . . . = 4 2. Requirements Notation . . . . = . . . . . . . . . . . . . . . . 4
3. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
4. Basic = Overview . . . . . . . . . . . . . . . . . . . . . . . 6 = 4. Basic Overview . . . . . . . . . . . . = . . . . . . . . . . . 6
5. LISP = IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 5. LISP = IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8
5.1. LISP = Control Packet Type Allocations . . . . . . . . . . 9 5.1. = LISP Control Packet Type Allocations . . . . . . . . . . 10
5.2. = Map-Request Message Format . . . . . . . . . . . . . . . 10 5.2. = Map-Request Message Format . . . . . . . . . . . . . . . 11
5.3. = EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 5.3. = EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 14
5.4. = Map-Reply Message Format . . . . . . . . . . . . . . . . 15 5.4. = Map-Reply Message Format . . . . . . . . . . . . . . . . 16
5.5. = EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 5.5. = EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 20
5.6. = Map-Register Message Format . . . . . . . . . . . . . . . 22 5.6. = Map-Register Message Format . . . . . . . . . . . . . . . 23
5.7. = Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 5.7. = Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 26
5.8. = Encapsulated Control Message Format . . . . . . . . . . . 27 5.8. = Encapsulated Control Message Format . . . . . . . . . . . 28
6. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 29 6. = Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30
6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 29 6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 30
7. Routing = Locator Reachability . . . . . . . . . . . . . . . . 30 7. = Routing Locator Reachability . . . . . . . . . . . . . . . . 31
7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 32 7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 33
8. = Interactions with Other LISP Components . . . . . . . . . . . 33 8. = Interactions with Other LISP Components . . . . . . . . . . . 34
8.1. ITR = EID-to-RLOC Mapping Resolution . . . . . . . . . . . 33 8.1. = ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 34
8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 34 8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 35
8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 36 8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 37
8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 37 8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 38
8.4.1. = Anycast Operation . . . . . . . . . . . . . . . . . . 37 = 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 38
9. Security = Considerations . . . . . . . . . . . . . . . . . . . 37 9. = Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. Changes = since RFC 6833 . . . . . . . . . . . . . . . . . . . 38 10. = Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 40
11. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 39 11. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11.1. = LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 40 11.1. = LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 41
11.2. = LISP Packet Type Codes . . . . . . . . . . . . . . . . . 40 11.2. = LISP Packet Type Codes . . . . . . . . . . . . . . . . . 41
11.3. = LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 40 11.3. = LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 41
11.4. = LISP Address Type Codes . . . . . . . . . . . . . . . . 41 11.4. = LISP Address Type Codes . . . . . . . . . . . . . . . . 42
11.5. = LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 41 11.5. = LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 42
=
12. = References . . . . . . . . . . . . . . . . . . . . . . . . . 41 12. = References . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. = Normative References . . . . . . . . . . . . . . . . . . 41 12.1. = Normative References . . . . . . . . . . . . . . . . . . 43
12.2. = Informative References . . . . . . . . . . . . . . . . . 42 12.2. = Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 47 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 48
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 47 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 48
B.1. = Changes to draft-ietf-lisp-rfc6833bis-16 = . . . . . . . . 47 B.1. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . = 48
B.2. = Changes to draft-ietf-lisp-rfc6833bis-15 = . . . . . . . . 47 B.2. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . = 48
B.3. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 47 B.3. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . = 48
B.4. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 47 B.4. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . = 48
B.5. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 48 B.5. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 48
B.6. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 48 B.6. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . = 49
B.7. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 48 B.7. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . = 49
B.8. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 48 B.8. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . = 49
B.9. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 48 B.9. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . = 49
B.10. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 48 B.10. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . = 49
B.11. = Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 49 B.11. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . = 50
B.12. = Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 49 B.12. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . = 50
B.13. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 49 B.13. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . = 50
B.14. = Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 50 B.14. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . = 51
B.15. = Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 50 B.15. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . = 51
B.16. = Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 50 B.16. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . = 51
B.17. = Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 50 B.17. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . = 51
B.18. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 51 B.18. = Changes to draft-ietf-lisp-rfc6833bis-00 . . . . = . . . . 52
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 B.19. Changes to = draft-farinacci-lisp-rfc6833bis-00 . . . . . . 52
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 52
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol = [I-D.ietf-lisp-rfc6830bis] (see
also = [I-D.ietf-lisp-introduction]) specifies an architecture and = also [I-D.ietf-lisp-introduction]) specifies = an architecture and
mechanism for = dynamic tunneling by logically separating the addresses = mechanism for dynamic tunneling by logically = separating the addresses
currently used = by IP in two separate name spaces: Endpoint IDs currently used by IP in two separate name spaces: = Endpoint IDs
(EIDs), used = within sites; and Routing Locators (RLOCs), used on the = (EIDs), used within sites; and Routing = Locators (RLOCs), used on the
transit = networks that make up the Internet infrastructure. To transit networks that make up the Internet = infrastructure. To
achieve this = separation, LISP defines protocol mechanisms for mapping = achieve this separation, LISP defines = protocol mechanisms for mapping
=
skipping to = change at = page 4, line 22 =C2=B6 = skipping to change at page 4, line 24 =C2=B6
=
Conceptually, = LISP Map-Servers share some of the same basic Conceptually, LISP Map-Servers share some of the same = basic
configuration = and maintenance properties as Domain Name System (DNS) configuration and maintenance properties as Domain = Name System (DNS)
[RFC1035] = servers; likewise, Map-Resolvers are conceptually similar = [RFC1035] servers; likewise, Map-Resolvers = are conceptually similar
to DNS caching = resolvers. With this in mind, this specification to DNS caching resolvers. With this in mind, this = specification
borrows = familiar terminology (resolver and server) from the DNS = borrows familiar terminology (resolver and = server) from the DNS
= specifications. = specifications.
=
Note this = document doesn't assume any particular database mapping = Note this document doesn't assume any = particular database mapping
infrastructure = to illustrate certain aspects of Map-Server and Map- infrastructure to illustrate certain aspects of = Map-Server and Map-
Resolver = operation, the Mapping Service interface = can (and likely Resolver = operation. The Mapping Service interface = can (and likely
will) be used = by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other = mapping database
systems as the = LISP infrastructure evolves. = systems as the LISP infrastructure evolves.
=
The LISP = Mapping Service is an important component of the LISP The LISP Mapping Service is an important component of = the LISP
toolset. = Issues and concerns about the deployment of LISP for toolset. Issues and concerns about the deployment of = LISP for
Internet = traffic are discussed in [I-D.ietf-lisp-rfc6830bis], Internet traffic are discussed in = [I-D.ietf-lisp-rfc6830bis],
[RFC7215], and = [I-D.rodrigueznatal-lisp-oam]. = [RFC7215], and [I-D.rodrigueznatal-lisp-oam].
=
This document = obsoletes RFC 6830 and 6833. This = document obsoletes RFC 6830 and 6833.
=
2. Requirements = Notation 2. Requirements = Notation
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
"SHOULD", = "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = "SHOULD", "SHOULD NOT", "RECOMMENDED", = "NOT RECOMMENDED", "MAY", and
document are = to be interpreted as described in [RFC2119] and "OPTIONAL" in this document are to be interpreted as = described in BCP
[RFC8174]. 14 [RFC2119] [RFC8174] when, and only = when, they appear in all
= capitals, as shown = here.
=
3. Definition of = Terms 3. Definition of Terms
=
Map-Server: = A network infrastructure component that learns of EID- Map-Server: A network infrastructure component that = learns of EID-
Prefix = mapping entries from an ETR, via the registration mechanism = Prefix mapping entries from an ETR, via = the registration mechanism
described = below, or some other authoritative source if one exists. = described below, or some other = authoritative source if one exists.
A = Map-Server publishes these EID-Prefixes in a mapping database. = A Map-Server publishes these EID-Prefixes = in a mapping database.
=
Map-Request: = A LISP Map-Request is a Control-Plane message to query Map-Request: A LISP Map-Request is a Control-Plane = message to query
the mapping = system to resolve an EID. A LISP Map-Request can also the mapping system to resolve an EID. A LISP = Map-Request can also
=
skipping to = change at = page 9, line 38 =C2=B6 = skipping to change at page 10, line = 38 =C2=B6
recommended to = use the LISP Shared Extension Message Type described recommended to use the LISP Shared Extension Message = Type described
in = [RFC8113]. in [RFC8113].
=
All LISP = Control-Plane messages use Address Family Identifiers (AFI) = All LISP Control-Plane messages use Address = Family Identifiers (AFI)
[AFI] or LISP = Canonical Address Format (LCAF) [RFC8060] formats to [AFI] or LISP Canonical Address Format (LCAF) = [RFC8060] formats to
encode either = fixed or variable length addresses. This includes encode either fixed or variable length addresses. = This includes
explicit = fields in each control message or part of EID-records or = explicit fields in each control message or = part of EID-records or
RLOC-records = in commonly formatted messages. = RLOC-records in commonly formatted messages.
=
The LISP = control-plane describes how other data-planes can encode = The LISP control-plane describes how other = data-planes can encode
messages to = support the SMR and RLOC-probing = procedures. messages to support = the Soliciting of Map-Requests as well as = RLOC-
= probing = procedures.
=
5.2. Map-Request = Message Format 5.2. Map-Request = Message Format
=
0 = 1 2 3 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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3D1 = |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | Record Count | = |Type=3D1 |A|M|P|S|p|s|m|I| Rsvd = |L|D| IRC | Record Count |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Nonce . . . | | Nonce . . . = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
skipping to = change at = page 10, line 38 =C2=B6 = skipping to change at page 11, line = 38 =C2=B6
| = Map-Reply Record ... | | Map-Reply Record ... = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Packet field = descriptions: Packet field = descriptions:
=
Type: 1 = (Map-Request) Type: 1 = (Map-Request)
=
A: This is an = authoritative bit, which is set to 0 for UDP-based Map- = A: This is an authoritative bit, which is = set to 0 for UDP-based Map-
Requests = sent by an ITR. It is set to 1 when an ITR wants the Requests sent by an ITR. It is set to 1 when an = ITR wants the
destination = site to return the Map-Reply rather than the mapping destination site to return the Map-Reply rather = than the mapping
database = system. database system returning a Map-Reply.
=
M: This is the = map-data-present bit. When set, it indicates that a M: This is the map-data-present bit. When set, it = indicates that a
Map-Reply = Record segment is included in the Map-Request. Map-Reply Record segment is included in the = Map-Request.
=
P: This is the = probe-bit, which indicates that a Map-Request SHOULD P: This is the probe-bit, which indicates that a = Map-Request SHOULD
be treated = as a Locator reachability probe. The receiver SHOULD be treated as a Locator reachability probe. The = receiver SHOULD
respond = with a Map-Reply with the probe-bit set, indicating that = respond with a Map-Reply with the = probe-bit set, indicating that
the = Map-Reply is a Locator reachability probe reply, with the = the Map-Reply is a Locator reachability = probe reply, with the
nonce = copied from the Map-Request. See RLOC-Probing Section 7.1 = nonce copied from the Map-Request. See = RLOC-Probing Section 7.1
for more = details. for more details. = This RLOC-probe Map-Request MUST not be sent = to
= the mapping = system. If a Map-Resolver or Map-Server receives a
= Map-Request with = the probe-bit set, it MUST drop the message.
=
S: This is the = Solicit-Map-Request (SMR) bit. See Solicit-Map- S: This is the Solicit-Map-Request (SMR) bit. See = Solicit-Map-
Request = (SMRs) Section 6.1 for details. = Request (SMRs) Section 6.1 for details.
=
p: This is the = PITR bit. This bit is set to 1 when a PITR sends a p: This is the PITR bit. This bit is set to 1 when a = PITR sends a
= Map-Request. = Map-Request.
=
s: This is the = SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 = when an xTR is
sending a = Map-Request in response to a received SMR-based Map- sending a Map-Request in response to a received = SMR-based Map-
= Request. Request.
=
skipping to = change at = page 12, line 4 =C2=B6 = skipping to change at page 13, line 6 =C2=B6
value of 0, = there is 1 ITR-RLOC address encoded; for a value of 1, value of 0, there is 1 ITR-RLOC address encoded; = for a value of 1,
there are 2 = ITR-RLOC addresses encoded, and so on up to 31, which there are 2 ITR-RLOC addresses encoded, and so on = up to 31, which
encodes a = total of 32 ITR-RLOC addresses. = encodes a total of 32 ITR-RLOC addresses.
=
Record Count: = This is the number of records in this Map-Request Record Count: This is the number of records in this = Map-Request
message. A = record is comprised of the portion of the packet that message. A record is comprised of the portion of = the packet that
is labeled = 'Rec' above and occurs the number of times equal to is labeled 'Rec' above and occurs the number of = times equal to
Record = Count. For this version of the protocol, a receiver MUST = Record Count. For this version of the = protocol, a receiver MUST
accept and = process Map-Requests that contain one or more records, accept and process Map-Requests that contain one = or more records,
but a = sender MUST only send Map-Requests containing one record. = but a sender MUST only send Map-Requests = containing one record.
=
Support for = processing multiple EIDs in a single Map-Request Support for processing multiple EIDs in a single = Map-Request
message = will be specified in a future version of the protocol. message will be specified in a future version of = the protocol.
=
Nonce: This = is an 8-octet random value created by the sender of the = Nonce: This is an 8-octet random value = created by the sender of the
= Map-Request. This nonce will be returned in the Map-Reply. = The Map-Request. This nonce = will be returned in the Map-Reply. The
security of = the LISP mapping protocol critically depends on the security of the LISP mapping protocol critically = depends on the
strength = of the nonce in the Map-Request message. The nonce strength of the nonce in the Map-Request message. = The nonce MUST
SHOULD be generated by a properly seeded = pseudo-random (or strong be = generated by a properly seeded pseudo-random (or strong random)
random) = source. See [RFC4086] for advice on generating security- = source. See [RFC4086] for advice on generating security-sensitive
sensitive random data. random data.
=
= Source-EID-AFI: This is the address family of the 'Source EID = Source-EID-AFI: This is the address family = of the 'Source EID
Address' = field. Address' field.
=
Source EID = Address: This is the EID of the source host that Source EID Address: This is the EID of the source = host that
originated = the packet that caused the Map-Request. When Map- originated the packet that caused the Map-Request. = When Map-
Requests = are used for refreshing a Map-Cache entry or for RLOC- Requests are used for refreshing a Map-Cache entry = or for RLOC-
Probing, an = AFI value 0 is used and this field is of zero length. Probing, an AFI value 0 is used and this field is = of zero length.
=
ITR-RLOC-AFI: = This is the address family of the 'ITR-RLOC Address' ITR-RLOC-AFI: This is the address family of the = 'ITR-RLOC Address'
=
skipping to = change at = page 13, line 51 =C2=B6 = skipping to change at page 15, line 6 =C2=B6
Map-Requests = MUST be rate-limited. It is RECOMMENDED that a Map- Map-Requests MUST be rate-limited. It is RECOMMENDED = that a Map-
Request for = the same EID-Prefix be sent no more than once per second. = Request for the same EID-Prefix be sent no = more than once per second.
However, = recommendations from [RFC8085] SHOULD be considered. However, recommendations from [RFC8085] SHOULD be = considered.
=
An ITR that is = configured with mapping database information (i.e., it An ITR that is configured with mapping database = information (i.e., it
is also an = ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings = in a Map-
Request. When = an ETR configured to accept and verify such Request. When an ETR configured to accept and verify = such
"piggybacked" = mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a = Map-Request and it does
not have this = mapping in the Map-Cache, it MAY originate a "verifying = not have this mapping in the Map-Cache, it = MAY originate a "verifying
Map-Request", = addressed to the map-requesting ITR and the ETR MAY add = Map-Request", addressed to the = map-requesting ITR and the ETR MAY add
a Map-Cache = entry. If the ETR has a Map-Cache entry that matches the = a Map-Cache entry. If the ETR (when it is an xTR co-located as an
= "piggybacked" EID and the RLOC is in the Locator-Set for the = entry, = ITR) has a Map-Cache entry that matches the "piggybacked" EID and = the
then it MAY = send the "verifying Map-Request" directly to the RLOC is in the Locator-Set for the entry, then it = MAY send the
originating = Map-Request source. If the RLOC is not in the Locator- = "verifying Map-Request" directly to the originating Map-Request
Set, then the ETR MUST send the "verifying = Map-Request" to the source. If = the RLOC is not in the Locator-Set, then = the ETR MUST
= "piggybacked" EID. Doing this forces the "verifying Map-Request" = to send the "verifying = Map-Request" to the "piggybacked" EID. Doing
go through = the mapping database system to reach the authoritative this forces the "verifying Map-Request" to go = through the mapping
source of = information about that EID, guarding against RLOC-spoofing = database system to reach the authoritative = source of information
in the = "piggybacked" mapping data. about = that EID, guarding against RLOC-spoofing in the "piggybacked"
= mapping data.
=
5.4. Map-Reply = Message Format 5.4. Map-Reply Message = Format
=
0 = 1 2 3 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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3D2 = |P|E|S| Reserved | Record Count | = |Type=3D2 |P|E|S| Reserved = | Record Count |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Nonce . . . | | Nonce . . . = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
skipping to = change at = page 16, line 19 =C2=B6 = skipping to change at page 17, line = 19 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Reserved: = This field MUST be set to 0 on transmit and MUST be Reserved: This field MUST be set to 0 on transmit = and MUST be
ignored on = receipt. ignored on = receipt.
=
Record Count: = This is the number of records in this reply message. Record Count: This is the number of records in this = reply message.
A record is = comprised of that portion of the packet labeled A record is comprised of that portion of the = packet labeled
'Record' = above and occurs the number of times equal to Record 'Record' above and occurs the number of times = equal to Record
= Count. Count.
=
Nonce: This = is a 24-bit value set in a = Data-Probe Nonce: This = 64-bit value from the Map-Request is echoed in this
[I-D.ietf-lisp-rfc6830bis] or a 64-bit = value from the Map-Request = 'Nonce' field of the Map-Reply.
is echoed = in this 'Nonce' field of the Map-Reply. When a = 24-bit
value is supplied, it resides in the low-order 64 = bits of the
'Nonce' field.
=
Record TTL: = This is the time in minutes the recipient of the Map- Record TTL: This is the time in minutes the = recipient of the Map-
Reply will = store the mapping. If the TTL is 0, the entry MUST be Reply will store the mapping. If the TTL is 0, = the entry MUST be
removed = from the cache immediately. If the value is 0xffffffff, = removed from the cache immediately. If = the value is 0xffffffff,
the = recipient can decide locally how long to store the mapping. = the recipient can decide locally how long = to store the mapping.
=
Locator Count: = This is the number of Locator entries. A Locator Locator Count: This is the number of Locator = entries. A Locator
entry = comprises what is labeled above as 'Loc'. The Locator count = entry comprises what is labeled above as = 'Loc'. The Locator count
can be 0, = indicating that there are no Locators for the EID- can be 0, indicating that there are no Locators = for the EID-
= Prefix. Prefix.
=
skipping to = change at = page 17, line 23 =C2=B6 = skipping to change at page 18, line = 19 =C2=B6
(4) = Drop/Policy-Denied: A packet that matches this Map-Cache = (4) Drop/Policy-Denied: A packet that = matches this Map-Cache
entry = is dropped. The reason for the Drop action is that a entry is dropped. The reason for the Drop = action is that a
= Map-Request for the target-EID is being policy denied by = Map-Request for the target-EID is = being policy denied by
either = an xTR or the mapping system. = either an xTR or the mapping system.
=
(5) = Drop/Authentication-Failure: A packet that matches this Map- = (5) Drop/Authentication-Failure: A = packet that matches this Map-
Cache = entry is dropped. The reason for the Drop action is Cache entry is dropped. The reason for the = Drop action is
that a = Map-Request for the target-EID fails an authentication that a Map-Request for the target-EID fails an = authentication
= verification-check by either an xTR or the mapping system. = verification-check by either an xTR = or the mapping system.
=
A: The = Authoritative bit, when sent, is always = set to 1 by an ETR. A: The = Authoritative bit, when set to 1, is = always set to 1 by an
When a = Map-Server is proxy Map-Replying for a LISP site, the ETR. When a Map-Server is proxy Map-Replying for = a LISP site, the
= Authoritative bit is set to 0. This indicates to requesting = ITRs Authoritative bit is set to = 0. This indicates to requesting ITRs
that the = Map-Reply was not originated by a LISP node managed at that the Map-Reply was not originated by a LISP = node managed at
the site = that owns the EID-Prefix. the = site that owns the EID-Prefix.
=
Map-Version = Number: When this 12-bit value is non-zero, the Map- Map-Version Number: When this 12-bit value is = non-zero, the Map-
Reply = sender is informing the ITR what the version number is for = Reply sender is informing the ITR what = the version number is for
the EID = record contained in the Map-Reply. The ETR can allocate = the EID record contained in the = Map-Reply. The ETR can allocate
this number = internally but MUST coordinate this value with other this number internally but MUST coordinate this = value with other
ETRs for = the site. When this value is 0, there is no versioning = ETRs for the site. When this value is 0, = there is no versioning
information = conveyed. The Map-Version Number can be included in information conveyed. The Map-Version Number can = be included in
=
skipping = to change at page 18, line = 44 =C2=B6 = skipping to change at page 19, line = 40 =C2=B6
Locators in = this Locator-Set. Locators in = this Locator-Set.
=
p: When this = bit is set, an ETR informs the RLOC-Probing ITR that the = p: When this bit is set, an ETR informs the = RLOC-Probing ITR that the
locator = address for which this bit is set is the one being RLOC- = locator address for which this bit is set = is the one being RLOC-
probed and = may be different from the source address of the Map- probed and may be different from the source = address of the Map-
Reply. An = ITR that RLOC-probes a particular Locator MUST use this = Reply. An ITR that RLOC-probes a = particular Locator MUST use this
Locator for = retrieving the data structure used to store the fact Locator for retrieving the data structure used to = store the fact
that the = Locator is reachable. The p-bit is set for a single that the Locator is reachable. The p-bit is set = for a single
Locator in = the same Locator-Set. If an implementation sets more Locator in the same Locator-Set. If an = implementation sets more
than one = p-bit erroneously, the receiver of the Map-Reply MUST than one p-bit erroneously, the receiver of the = Map-Reply MUST
select = the first Locator. The p-bit MUST NOT be set for Locator- = select the first set p-bit Locator. The = p-bit MUST NOT be set for
Set records sent in Map-Request and = Map-Register messages. Locator-Set records sent in Map-Request and = Map-Register messages.
=
R: This is set = when the sender of a Map-Reply has a route to the R: This is set when the sender of a Map-Reply has a = route to the
Locator in = the Locator data record. This receiver may find this Locator in the Locator data record. This receiver = may find this
useful to = know if the Locator is up but not necessarily reachable = useful to know if the Locator is up but = not necessarily reachable
from the = receiver's point of view. See also EID-Reachability from the receiver's point of view. See also = EID-Reachability
Section 7.1 = for another way the R-bit may be used. = Section 7.1 for another way the R-bit may be used.
=
Locator: This = is an IPv4 or IPv6 address (as encoded by the 'Loc- Locator: This is an IPv4 or IPv6 address (as encoded = by the 'Loc-
AFI' = field) assigned to an ETR. Note that the = destination RLOC AFI' field) = assigned to an ETR and used by an ITR as a = destination
address = MAY be an anycast address. A source RLOC can be an RLOC address in the outer = header of a LISP encapsualted packet.
anycast = address as well. The source or destination RLOC MUST NOT = =
be the = broadcast address (255.255.255.255 or any subnet broadcast = Note that the destination RLOC address = of a LISP encapsulated
address = known to the router) and MUST NOT be a link-local packet MAY be an = anycast address. A source RLOC of a = LISP
multicast = address. The source RLOC MUST NOT be a multicast encapsulated packet = can be an anycast address as well. The source
address. = The destination RLOC SHOULD be a multicast address if it = or destination RLOC MUST NOT be the = broadcast address
is being = mapped from a multicast destination EID. (255.255.255.255 or any subnet broadcast address = known to the
= router) and MUST NOT be a link-local = multicast address. The
= source RLOC MUST NOT be a multicast = address. The destination RLOC
= SHOULD be a multicast address if it is = being mapped from a
= multicast destination EID.
=
5.5. EID-to-RLOC = UDP Map-Reply Message 5.5. = EID-to-RLOC UDP Map-Reply Message
=
A Map-Reply = returns an EID-Prefix with a prefix length that is less = A Map-Reply returns an EID-Prefix with a = prefix length that is less
than or equal = to the EID being requested. The EID being requested is = than or equal to the EID being requested. = The EID being requested is
either from = the destination field of an IP header of a Data-Probe or = either from the destination field of an IP = header of a Data-Probe or
the EID record = of a Map-Request. The RLOCs in the Map-Reply are the EID record of a Map-Request. The RLOCs in the = Map-Reply are
routable IP = addresses of all ETRs for the LISP site. Each RLOC routable IP addresses of all ETRs for the LISP site. = Each RLOC
conveys status = reachability but does not convey path reachability conveys status reachability but does not convey path = reachability
from a = requester's perspective. Separate testing of path from a requester's perspective. Separate testing of = path
=
skipping = to change at page 20, line = 11 =C2=B6 = skipping to change at page 21, line = 11 =C2=B6
= 2001:db8:1::/24 = 2001:db8:1::/24
= 2001:db8:1:1::/32 = 2001:db8:1:1::/32
= 2001:db8:1:2::/32 = 2001:db8:1:2::/32
=
A Map-Request = for EID 2001:db8:1:1::1 would cause a Map-Reply with a A Map-Request for EID 2001:db8:1:1::1 would cause a = Map-Reply with a
record count = of 1 to be returned with a mapping record EID-Prefix of = record count of 1 to be returned with a = mapping record EID-Prefix of
= 2001:db8:1:1::/32. = 2001:db8:1:1::/32.
=
A Map-Request = for EID 2001:db8:1:5::5 would cause a Map-Reply with a A Map-Request for EID 2001:db8:1:5::5 would cause a = Map-Reply with a
record count = of 3 to be returned with mapping records for EID- record count of 3 to be returned with mapping records = for EID-
Prefixes = 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32. Note = Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32,
filling out = the /24 with more-specifics that exist in the mapping filling out the /24 with more-specifics that exist in = the mapping
= system. system.
=
Note that not = all overlapping EID-Prefixes need to be returned but Note that not all overlapping EID-Prefixes need to be = returned but
only the = more-specific entries (note that in the second example above = only the more-specific entries (note that in = the second example above
2001:db8::/16 = was not returned for requesting EID 2001:db8:1:5::5) 2001:db8::/16 was not returned for requesting EID = 2001:db8:1:5::5)
for the = matching EID-Prefix of the requesting EID. When more than = for the matching EID-Prefix of the = requesting EID. When more than
one EID-Prefix = is returned, all SHOULD use the same Time to Live one EID-Prefix is returned, all SHOULD use the same = Time to Live
value so they = can all time out at the same time. When a more- value so they can all time out at the same time. = When a more-
specific = EID-Prefix is received later, its Time to Live value in the = specific EID-Prefix is received later, its = Time to Live value in the
=
skipping = to change at page 21, line = 8 =C2=B6 = skipping to change at page 22, line = 8 =C2=B6
message. The = Locator-Set MUST be sorted in order of ascending IP message. The Locator-Set MUST be sorted in order of = ascending IP
address where = an IPv4 locator address is considered numerically 'less = address where an IPv4 locator address is = considered numerically 'less
than' an IPv6 = locator address. than' an IPv6 = locator address.
=
When sending a = Map-Reply message, the destination address is copied When sending a Map-Reply message, the destination = address is copied
from one of = the 'ITR-RLOC' fields from the Map-Request. The ETR can = from one of the 'ITR-RLOC' fields from the = Map-Request. The ETR can
choose a = locator address from one of the address families it choose a locator address from one of the address = families it
supports. For = Data-Probes, the destination address of the Map-Reply supports. For Data-Probes, the destination address = of the Map-Reply
is copied from = the source address of the Data-Probe message that is is copied from the source address of the Data-Probe = message that is
invoking the = reply. The source address of the Map-Reply is one of invoking the reply. The source address of the = Map-Reply is one of
the local IP = addresses chosen to allow Unicast Reverse Path the local IP addresses chosen, to allow Unicast Reverse Path
Forwarding = (uRPF) checks to succeed in the upstream service provider. = Forwarding (uRPF) checks to succeed in the = upstream service provider.
The = destination port of a Map-Reply message is copied from the = source The destination port of a = Map-Reply message is copied from the source
port of the = Map-Request or Data-Probe, and the source port of the port of the Map-Request or Data-Probe, and the source = port of the
Map-Reply = message is set to the well-known UDP port 4342. Map-Reply message is set to the well-known UDP port = 4342.
=
5.6. = Map-Register Message Format 5.6. = Map-Register Message Format
=
This section = specifies the encoding format for the Map-Register This section specifies the encoding format for the = Map-Register
message. The = message is sent in UDP with a destination UDP port of message. The message is sent in UDP with a = destination UDP port of
4342 and a = randomly selected UDP source port number. 4342 and a randomly selected UDP source port = number.
=
skipping = to change at page 23, line = 7 =C2=B6 = skipping to change at page 24, line = 7 =C2=B6
P: This is the = proxy Map-Reply bit. When set to 1, an ETR sends a P: This is the proxy Map-Reply bit. When set to 1, = an ETR sends a
= Map-Register message requesting the Map-Server to proxy a Map- = Map-Register message requesting the = Map-Server to proxy a Map-
Reply. The = Map-Server will send non-authoritative Map-Replies on Reply. The Map-Server will send non-authoritative = Map-Replies on
behalf of = the ETR. behalf of the = ETR.
=
S: This is the = security-capable bit. When set, the procedures from S: This is the security-capable bit. When set, the = procedures from
= [I-D.ietf-lisp-sec] are supported. = [I-D.ietf-lisp-sec] are supported.
=
I: This is the = xTR-ID bit. When this bit is set, what is appended to I: This is the xTR-ID bit. When this bit is set, = what is appended to
the = Map-Register is a 128-bit xTR router-ID and then a 64-bit = the Map-Register is a 128-bit xTR = router-ID and then a 64-bit
site-ID. = See LISP NAT-Traversal procedures = in site-ID.
[I-D.ermagan-lisp-nat-traversal] for = details.
=
Reserved: = This field MUST be set to 0 on transmit and MUST be Reserved: This field MUST be set to 0 on transmit = and MUST be
ignored on = receipt. ignored on = receipt.
=
E: This is the = Map-Register EID-notify bit. This is used by a First- E: This is the Map-Register EID-notify bit. This is = used by a First-
Hop-Router = (FHR) which discovers a dynamic-EID. This EID-notify Hop-Router (FHR) which discovers a dynamic-EID. = This EID-notify
based = Map-Register is sent by the FHR to the same site xTR that = based Map-Register is sent by the FHR to = the same site xTR that
propogates = the Map-Register to the mapping system. The site xTR propogates the Map-Register to the mapping system. = The site xTR
keeps state = to later Map-Notify the FHR after the EID has moves keeps state to later Map-Notify the FHR after the = EID has moves
away. See = [I-D.ietf-lisp-eid-mobility] for a detailed use-case. away. See [I-D.ietf-lisp-eid-mobility] for a = detailed use-case.
=
T: This is the = use-TTL for timeout bit. When set to 1, the xTR wants T: This is the use-TTL for timeout bit. When set to = 1, the xTR wants
the = Map-Server to time out registrations based on the value in the = the Map-Server to time out registrations = based on the value in the
"Record = TTL" field of this message. = "Record TTL" field of this message. Otherwise, = the default
= timeout described = in Section 8.2 is used.
=
a: This is the = merge-request bit. When set to 1, the xTR requests to a: This is the merge-request bit. When set to 1, the = xTR requests to
merge = RLOC-records from different xTRs registering the same EID- = merge RLOC-records from different xTRs = registering the same EID-
record. = See signal-free multicast [RFC8378] for one use case record. See signal-free multicast [RFC8378] for = one use case
= example. example.
=
m: This is the = mobile-node bit. When set to 1, the registering xTR m: This is the mobile-node bit. When set to 1, the = registering xTR
supports = the procedures in [I-D.ietf-lisp-mn]. This bit can be supports the procedures in [I-D.ietf-lisp-mn]. = This bit can be
ignored if = an implementation does not support [I-D.ietf-lisp-mn] ignored if an implementation does not support = [I-D.ietf-lisp-mn]
=
=
skipping = to change at page 24, line = 19 =C2=B6 = skipping to change at page 25, line = 19 =C2=B6
(MAC) = algorithm value used for the authentication function. See = (MAC) algorithm value used for the = authentication function. See
Algorithm = ID Numbers in the Section 11.5 for codepoint Algorithm ID Numbers in the Section 11.5 for = codepoint
= assignments. = assignments.
=
Authentication = Data Length: This is the length in octets of the Authentication Data Length: This is the length in = octets of the
= 'Authentication Data' field that follows this field. The = length 'Authentication Data' = field that follows this field. The length
of the = 'Authentication Data' field is dependent on the MAC of the 'Authentication Data' field is dependent on = the MAC
algorithm = used. The length field allows a device that doesn't algorithm used. The length field allows a device = that doesn't
know the = MAC algorithm to correctly parse the packet. know the MAC algorithm to correctly parse the = packet.
=
= Authentication Data: This is the message digest = used from the output = Authentication Data: This is the output of the MAC algorithm. = The
of the = MAC algorithm. The entire Map-Register payload is entire Map-Register payload (from and including the LISP message
= type field = through the end of the last RLOC record) is
= authenticated with this field preset to 0. After the MAC is = authenticated with this field preset to = 0. After the MAC is
computed, = it is placed in this field. Implementations of this computed, it is placed in this field. = Implementations of this
= specification MUST include support for HMAC-SHA-1-96 [RFC2404], = specification MUST include support for either HMAC-SHA-1-96
and support for HMAC-SHA-256-128 [RFC4868] is = RECOMMENDED. [RFC2404] and HMAC-SHA-256-128 [RFC4868] where the latter is
= RECOMMENDED.
=
The definition = of the rest of the Map-Register can be found in EID- The definition of the rest of the Map-Register can be = found in EID-
record = description in Section 5.4. record = description in Section 5.4.
=
5.7. = Map-Notify/Map-Notify-Ack Message Format 5.7. Map-Notify/Map-Notify-Ack Message Format
=
This section = specifies the encoding format for the Map-Notify and This section specifies the encoding format for the = Map-Notify and
Map-Notify-Ack = messages. The messages are sent inside a UDP packet Map-Notify-Ack messages. The messages are sent = inside a UDP packet
with source = and destination UDP ports equal to 4342. with source and destination UDP ports equal to = 4342.
=
=
skipping = to change at page 28, line = 38 =C2=B6 = skipping to change at page 29, line = 38 =C2=B6
UDP: The = inner UDP header, where the port assignments depend on the = UDP: The inner UDP header, where the port = assignments depend on the
control = packet being encapsulated. When the control packet is control packet being encapsulated. When the = control packet is
a = Map-Request or Map-Register, the source port is selected by = a Map-Request or Map-Register, the = source port is selected by
the = ITR/PITR and the destination port is 4342. When the the ITR/PITR and the destination port is 4342. = When the
control = packet is a Map-Reply, the source port is 4342 and the control packet is a Map-Reply, the source port = is 4342 and the
= destination port is assigned from the source port of the = destination port is assigned from the = source port of the
invoking = Map-Request. Port number 4341 MUST NOT be assigned to invoking Map-Request. Port number 4341 MUST = NOT be assigned to
either = port. The checksum field MUST be non-zero. either port. The checksum field MUST be = non-zero.
=
LCM: The = format is one of the control message formats described in = LCM: The format is one of the control = message formats described in
this = section. At this time, only Map-Request = messages are this section. = Map-Request messages are allowed to be Control-
= allowed to be Control-Plane (ECM) = encapsulated. In the future, = Plane = (ECM) encapsulated. When Map-Requests are sent for RLOC-
PIM Join/Prune messages [RFC6831] might be = allowed. = Probing purposes (i.e. the = probe-bit is set), they MUST NOT be
Encapsulating other types of LISP control = messages is for sent = inside Encapsulated Control Messages. PIM = Join/Prune
further study. When Map-Requests are = sent for RLOC-Probing messages [RFC6831] are = also allowed to be Control-Plane (ECM)
= purposes (i.e., the probe-bit is set), = they MUST NOT be sent encapsulated.
inside = Encapsulated Control Messages.
=
6. Changing the = Contents of EID-to-RLOC Mappings 6. = Changing the Contents of EID-to-RLOC Mappings
=
In the LISP = architecture ITRs/PITRs use a local Map-Cache to store In the LISP architecture ITRs/PITRs use a local = Map-Cache to store
EID-to-RLOC = mappings for forwarding. When an ETR updates a mapping a = EID-to-RLOC mappings for forwarding. When = an ETR updates a mapping a
mechanism is = required to inform ITRs/PITRs that are using such mechanism is required to inform ITRs/PITRs that are = using such
= mappings. mappings.
=
The LISP = Data-Plane defines several mechanism to update mappings = The LISP Data-Plane defines several = mechanism to update mappings
= [I-D.ietf-lisp-rfc6830bis]. This document specifies the = Solicit-Map = [I-D.ietf-lisp-rfc6830bis]. This document specifies the = Solicit-Map
=
skipping = to change at page 29, line = 25 =C2=B6 = skipping to change at page 30, line = 25 =C2=B6
Control-Plane = mechanism based on the Publish/subscribe paradigm is Control-Plane mechanism based on the = Publish/subscribe paradigm is
specified in = [I-D.ietf-lisp-pubsub]. specified = in [I-D.ietf-lisp-pubsub].
=
6.1. = Solicit-Map-Request (SMR) 6.1. = Solicit-Map-Request (SMR)
=
Soliciting a = Map-Request is a selective way for ETRs, at the site Soliciting a Map-Request is a selective way for ETRs, = at the site
where mappings = change, to control the rate they receive requests for where mappings change, to control the rate they = receive requests for
Map-Reply = messages. SMRs are also used to tell remote ITRs to update = Map-Reply messages. SMRs are also used to = tell remote ITRs to update
the mappings = they have cached. the mappings they = have cached.
=
Since the ETRs don't = keep track of remote ITRs that have cached their Since ETRs are not required = to keep track of remote ITRs that have
mappings, = they do not know which ITRs need to have their mappings = cached their mappings, they do not know = which ITRs need to have their
updated. As = a result, an ETR will solicit Map-Requests (called an mappings updated. As a result, an ETR will solicit = Map-Requests
SMR message) = to those sites to which it has been sending encapsulated = (called an SMR message) to those sites to = which it has been sending
data for the = last minute. In particular, an ETR will send an SMR to = LISP = encapsulated data packets for the last = minute. In particular,
an ITR to = which it has recently sent encapsulated data. This can = an ETR will send an SMR to an ITR to which = it has recently sent
only occur = when both ITR and ETR functionality reside in the same encapsulated data. This can only occur when both = ITR and ETR
= router. functionality reside in = the same router.
=
An SMR message = is simply a bit set in a Map-Request message. An ITR An SMR message is simply a bit set in a Map-Request = message. An ITR
or PITR will = send a Map-Request when they receive an SMR message. or PITR will send a Map-Request when they receive an = SMR message.
Both the SMR = sender and the Map-Request responder MUST rate-limit Both the SMR sender and the Map-Request responder = MUST rate-limit
these = messages. Rate-limiting can be implemented as a global rate- = these messages. Rate-limiting can be = implemented as a global rate-
limiter or one = rate-limiter per SMR destination. = limiter or one rate-limiter per SMR destination.
=
The following = procedure shows how an SMR exchange occurs when a site The following procedure shows how an SMR exchange = occurs when a site
is doing = Locator-Set compaction for an EID-to-RLOC mapping: is doing Locator-Set compaction for an EID-to-RLOC = mapping:
=
1. When the = database mappings in an ETR change, the ETRs at the site = 1. When the database mappings in an ETR = change, the ETRs at the site
begin to = send Map-Requests with the SMR bit set for each Locator = begin to send Map-Requests with the SMR = bit set for each Locator
in each = Map-Cache entry the ETR caches. = in each Map-Cache entry the ETR (when it is an = xTR co-located as
= an ITR) = caches.
=
2. A remote = ITR that receives the SMR message will schedule sending = 2. A remote ITR that receives the SMR = message will schedule sending
a = Map-Request message to the source locator address of the SMR = a Map-Request message to the source = locator address of the SMR
message or = to the mapping database system. A newly allocated message or to the mapping database system. A = newly allocated
random = nonce is selected, and the EID-Prefix used is the one random nonce is selected, and the EID-Prefix used = is the one
copied = from the SMR message. If the source Locator is the only = copied from the SMR message. If the = source Locator is the only
Locator in = the cached Locator-Set, the remote ITR SHOULD send a Locator in the cached Locator-Set, the remote ITR = SHOULD send a
= Map-Request to the database mapping system just in case the = Map-Request to the database mapping = system just in case the
single = Locator has changed and may no longer be reachable to single Locator has changed and may no longer be = reachable to
accept the = Map-Request. accept the = Map-Request.
=
3. The remote = ITR MUST rate-limit the Map-Request until it gets a 3. The remote ITR MUST rate-limit the Map-Request = until it gets a
Map-Reply = while continuing to use the cached mapping. When Map-Reply while continuing to use the cached = mapping. When
= Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, = Map-Versioning as described in = [I-D.ietf-lisp-6834bis] is used,
an SMR = sender can detect if an ITR is using the most up-to-date = an SMR sender can detect if an ITR is = using the most up-to-date
database = mapping. database = mapping.
=
4. The = ETRs at the site with= the changed mapping will reply to the 4. The site sending SMR = messages will reply to the Map-Request with
= Map-Request with a Map-Reply message that has a nonce from the = a Map-Reply message that has a nonce = from the SMR-invoked Map-
= SMR-invoked Map-Request. The Map-Reply = messages MUST be rate- Request. The = Map-Reply messages MUST be rate-limited = according
limited according to procedures in = [RFC8085]. This is important = to procedures in [RFC8085]. This is important to avoid = Map-Reply
to avoid = Map-Reply implosion. = implosion.
=
5. The ETRs = at the site with the changed mapping record the fact 5. The ETRs at the site with the changed mapping = record the fact
that the = site that sent the Map-Request has received the new that the site that sent the Map-Request has = received the new
mapping = data in the Map-Cache entry for the remote site so the mapping data in the Map-Cache entry for the = remote site so the
= Locator-Status-Bits are reflective of the new mapping for = packets Locator-Status-Bits are = reflective of the new mapping for packets
going to = the remote site. The ETR then stops sending SMR going to the remote site. The ETR then stops = sending SMR
= messages. messages.
=
For security = reasons, an ITR MUST NOT process unsolicited Map- For security reasons, an ITR MUST NOT process = unsolicited Map-
Replies. To = avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a = third party, a
=
skipping = to change at page 32, line = 39 =C2=B6 = skipping to change at page 33, line = 43 =C2=B6
an RLOC-probe = is NOT encapsulated and NOT sent to a Map-Server or to an RLOC-probe is NOT encapsulated and NOT sent to a = Map-Server or to
the mapping = database system as one would when soliciting mapping the mapping database system as one would when = soliciting mapping
data. The EID = record encoded in the Map-Request is the EID-Prefix of data. The EID record encoded in the Map-Request is = the EID-Prefix of
the Map-Cache = entry cached by the ITR or PITR. The ITR MAY include a = the Map-Cache entry cached by the ITR or = PITR. The ITR MAY include a
mapping data = record for its own database mapping information that mapping data record for its own database mapping = information that
contains the = local EID-Prefixes and RLOCs for its site. RLOC-probes = contains the local EID-Prefixes and RLOCs = for its site. RLOC-probes
are sent = periodically using a jittered timer interval. are sent periodically using a jittered timer = interval.
=
When an ETR = receives a Map-Request message with the probe-bit set, it = When an ETR receives a Map-Request message = with the probe-bit set, it
returns a = Map-Reply with the probe-bit set. The source address of = returns a Map-Reply with the probe-bit set. = The source address of
the = Map-Reply is set according to the procedure described in the Map-Reply is set to the IP = address of the outgoing interface the
[I-D.ietf-lisp-rfc6830bis]. The Map-Reply = SHOULD contain mapping Map-Reply destination address routes to. The = Map-Reply SHOULD
data for the = EID-Prefix contained in the Map-Request. This provides = contain mapping data for the EID-Prefix = contained in the Map-Request.
the = opportunity for the ITR or PITR that sent the RLOC-probe to get This provides the opportunity for the ITR or PITR = that sent the RLOC-
mapping = updates if there were changes to the ETR's database mapping = probe to get = mapping updates if there were changes to the ETR's
= entries. database mapping = entries.
=
There are = advantages and disadvantages of RLOC-Probing. The greatest = There are advantages and disadvantages of RLOC-Probing. The main
benefit of = RLOC-Probing is that it can handle many failure scenarios = benefit of RLOC-Probing is that it can = handle many failure scenarios
allowing the = ITR to determine when the path to a specific Locator is = allowing the ITR to determine when the path = to a specific Locator is
reachable or = has become unreachable, thus providing a robust reachable or has become unreachable, thus providing a = robust
mechanism for = switching to using another Locator from the cached mechanism for switching to using another Locator from = the cached
Locator. = RLOC-Probing can also provide rough Round-Trip Time (RTT) = Locator. RLOC-Probing can also provide = rough Round-Trip Time (RTT)
estimates = between a pair of Locators, which can be useful for network = estimates between a pair of Locators, which = can be useful for network
management = purposes as well as for selecting low delay paths. The = management purposes as well as for selecting = low delay paths. The
major = disadvantage of RLOC-Probing is in the number of control = major disadvantage of RLOC-Probing is in the = number of control
messages = required and the amount of bandwidth used to obtain those = messages required and the amount of = bandwidth used to obtain those
benefits, = especially if the requirement for failure detection times = benefits, especially if the requirement for = failure detection times
=
skipping = to change at page 38, line = 29 =C2=B6 = skipping to change at page 39, line = 35 =C2=B6
overclaiming' = attacks on the Map-Request/Map-Reply exchange. In overclaiming' attacks on the Map-Request/Map-Reply = exchange. In
addition and = while beyond the scope of securing an individual Map- addition and while beyond the scope of securing an = individual Map-
Server or = Map-Resolver, it should be noted that LISP-SEC can be Server or Map-Resolver, it should be noted that = LISP-SEC can be
complemented = by additional security mechanisms defined by the Mapping = complemented by additional security = mechanisms defined by the Mapping
System = Infrastructure. For instance, BGP-based LISP-ALT [RFC6836] = System Infrastructure. For instance, = BGP-based LISP-ALT [RFC6836]
can take = advantage of standards work on adding security to BGP while = can take advantage of standards work on = adding security to BGP while
LISP-DDT = [RFC8111] defines its own additional security mechanisms. = LISP-DDT [RFC8111] defines its own = additional security mechanisms.
=
To publish an = authoritative EID-to-RLOC mapping with a Map-Server To publish an authoritative EID-to-RLOC mapping with = a Map-Server
using the = Map-Register message, an ETR includes authentication data = using the Map-Register message, an ETR = includes authentication data
that is a = hash of the entire message using a = pair-wise shared key. that is a = MAC of the entire message using a = pair-wise shared key. An
An = implementation MUST support use of HMAC-SHA-1-96 [RFC2104] and = implementation MUST support use of = HMAC-SHA-1-96 [RFC2104] and SHOULD
SHOULD = support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated = support use of HMAC-SHA-256-128 [RFC6234] = (SHA-256 truncated to 128
to 128 = bits). The Map-Register message is vulnerable to replay = bits). The Map-Register message is = vulnerable to replay attacks by a
attacks by a = man-in-the-middle. Deployments that are concerned with = man-in-the-middle. Deployments that are = concerned with active man-
active man-in-the-middle attacks to the Map-Register = message SHOULD = in-the-middle attacks to the Map-Register message SHOULD use = a
use a = transport-level integrity and anti-reply protection mechanism = transport-level integrity and anti-reply = protection mechanism such as
such as = IPSEC [RFC6071]. In addition, a compromised ETR can IPSEC [RFC6071]. In addition, a compromised ETR can = overclaim the
overclaim = the prefix it owns and successfully register it on its prefix it owns and successfully register it on its = corresponding Map-
= corresponding Map-Server. To mitigate = this and as noted in Server. To mitigate this and as noted in = Section 8.2, a Map-Server
Section 8.2, = a Map-Server SHOULD verify that all EID-Prefixes SHOULD verify that all EID-Prefixes registered by an = ETR match the
registered = by an ETR match the configuration stored on the Map- = configuration stored on the Map-Server.
Server.
=
A complete = LISP threat analysis has been published in [RFC7835]. A complete LISP threat analysis has been published in = [RFC7835].
Please refer = to it for more detailed security related details. Please refer to it for more detailed security related = details.
=
10. Changes = since RFC 6833 10. Changes since RFC = 6833
=
For = implementation considerations, the following changes have been = For implementation considerations, the = following changes have been
made to this = document since RFC 6833 was published: = made to this document since RFC 6833 was published:
=
o A = Map-Notify-Ack message is added in this document to provide = o A Map-Notify-Ack message is added in this = document to provide
=
skipping = to change at page 41, line = 18 =C2=B6 = skipping to change at page 42, line = 31 =C2=B6
or IESG = approval, but these need not be managed by IANA. or IESG approval, but these need not be managed by = IANA.
=
11.4. LISP = Address Type Codes 11.4. LISP Address = Type Codes
=
LISP Canonical = Address Format (LCAF) [RFC8060] is an 8-bit field that LISP Canonical Address Format (LCAF) [RFC8060] is an = 8-bit field that
defines = LISP-specific encodings for AFI value 16387. LCAF encodings = defines LISP-specific encodings for AFI = value 16387. LCAF encodings
are used for = specific use-cases where different address types for are used for specific use-cases where different = address types for
EID-records = and RLOC-records are required. = EID-records and RLOC-records are required.
=
The IANA = registry "LISP Canonical Address Format (LCAF) Types" is = The IANA registry "LISP Canonical Address = Format (LCAF) Types" is
used for = LCAF types, the registry for LCAF types = use the used for LCAF types. The registry for LCAF types use the
Specification = Required policy [RFC8126]. Initial values for the Specification Required policy [RFC8126]. Initial = values for the
registry as = well as further information can be found in [RFC8060]. registry as well as further information can be found = in [RFC8060].
=
Therefore, = there is no longer a need for the "LISP Address Type Therefore, there is no longer a need for the "LISP = Address Type
Codes" = registry requested by [RFC6830]. This document requests to = Codes" registry requested by [RFC6830]. = This document requests to
remove = it. remove it.
=
11.5. LISP = Algorithm ID Numbers 11.5. LISP = Algorithm ID Numbers
=
In [RFC6830], = a request for a "LISP Key ID Numbers" registry was In [RFC6830], a request for a "LISP Key ID Numbers" = registry was
=
skipping = to change at page 42, line = 8 =C2=B6 = skipping to change at page 43, line = 20 =C2=B6
12.1. Normative = References 12.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-19 = (work in progress), = (LISP)", draft-ietf-lisp-rfc6830bis-21 = (work in progress),
= September 2018. = September 2018.
=
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
skipping = to change at page 42, line = 47 =C2=B6 = skipping to change at page 44, line = 12 =C2=B6
= NUMBERS http://www.iana.org/assignments/address-family- = NUMBERS = http://www.iana.org/assignments/address-family-
= numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, = Febuary 2007.
=
= [GTP-3GPP] [GTP-3GPP]
= 3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) = Tunnelling
= Protocol User Plane (GTPv1-U)", TS.29.281 Protocol User Plane (GTPv1-U)", = TS.29.281
= https://portal.3gpp.org/desktopmodules/Specifications/ = https://portal.3gpp.org/desktopmodules/Specifications/
= SpecificationDetails.aspx?specificationId=3D1699, January = = SpecificationDetails.aspx?specificationId=3D1699, January
= 2015. 2015.
=
[I-D.ermagan-lisp-nat-traversal] =
Ermagan, V., Farinacci, D., Lewis, D., = Skriver, J., Maino,
F., and C. White, "NAT traversal for = LISP", draft-ermagan-
lisp-nat-traversal-14 (work in progress), = April 2018.
= =
= [I-D.herbert-intarea-ila] = [I-D.herbert-intarea-ila]
= Herbert, T. and P. Lapukhov, "Identifier-locator Herbert, T. and P. Lapukhov, = "Identifier-locator
= addressing for IPv6", draft-herbert-intarea-ila-01 (work = addressing for IPv6", = draft-herbert-intarea-ila-01 (work
in = progress), March 2018. = in progress), March 2018.
=
= [I-D.ietf-lisp-eid-mobility] = [I-D.ietf-lisp-eid-mobility]
= Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, = Portoles-Comeras, M., Ashtaputre, = V., Moreno, V., Maino,
F., = and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID = Mobility Using a
= Unified Control Plane", draft-ietf-lisp-eid-mobility-02 = Unified Control Plane", = draft-ietf-lisp-eid-mobility-02
= (work in progress), May 2018. = (work in progress), May 2018.
=
skipping = to change at page 47, line = 19 =C2=B6 = skipping to change at page 48, line = 19 =C2=B6
Fabio Maino, = and members of the lisp@ietf.org mailing list for their = Fabio Maino, and members of the = lisp@ietf.org mailing list for their
feedback and = helpful suggestions. feedback and = helpful suggestions.
=
Special thanks = are due to Noel Chiappa for his extensive work and Special thanks are due to Noel Chiappa for his = extensive work and
thought about = caching in Map-Resolvers. thought = about caching in Map-Resolvers.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6833bis-16 B.1. = Changes to draft-ietf-lisp-rfc6833bis-17
=
= o Posted = Late-September 2018.
=
= o Changes to = reflect comments from Sep 27th Telechat.
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-16
=
o Posted = Late-September 2018. o Posted = Late-September 2018.
=
o Re-wrote = Security Considerations section. Thanks Albert. o Re-wrote Security Considerations section. Thanks = Albert.
=
o Added = Alvaro text to be more clear about IANA actions. o Added Alvaro text to be more clear about IANA = actions.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-15 B.3. Changes to = draft-ietf-lisp-rfc6833bis-15
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Colin and Mirja. = o Changes to reflect comments from Colin and Mirja.
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-14 B.4. Changes to = draft-ietf-lisp-rfc6833bis-14
=
o Posted = September 2018. o Posted September = 2018.
=
o Changes to = reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, = and Secdir
= reviews. reviews.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-13 B.5. Changes to = draft-ietf-lisp-rfc6833bis-13
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-12 B.6. Changes to = draft-ietf-lisp-rfc6833bis-12
=
o Posted late = July 2018. o Posted late July = 2018.
=
o Moved = RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative = References.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-11 B.7. Changes to = draft-ietf-lisp-rfc6833bis-11
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for = RFC status and
ran through = IDNITs again. ran through IDNITs = again.
=
B.7. Changes to = draft-ietf-lisp-rfc6833bis-10 B.8. Changes to = draft-ietf-lisp-rfc6833bis-10
=
o Posted = after LISP WG at IETF week March. o = Posted after LISP WG at IETF week March.
=
o Move AD = field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM = packet format
description = section. description = section.
=
o Say more = about when the new Drop actions should be sent. o Say more about when the new Drop actions should be = sent.
=
B.8. Changes to = draft-ietf-lisp-rfc6833bis-09 B.9. Changes to = draft-ietf-lisp-rfc6833bis-09
=
o Posted = March IETF week 2018. o Posted = March IETF week 2018.
=
o Fixed = editorial comments submitted by document shepherd Luigi = o Fixed editorial comments submitted by = document shepherd Luigi
= Iannone. Iannone.
=
B.9. Changes to = draft-ietf-lisp-rfc6833bis-08 B.10. Changes to = draft-ietf-lisp-rfc6833bis-08
=
o Posted = March 2018. o Posted March = 2018.
=
o Added = RLOC-probing algorithm. o Added = RLOC-probing algorithm.
=
o Added = Solicit-Map Request algorithm. o = Added Solicit-Map Request algorithm.
=
o Added = several mechanisms (from 6830bis) regarding Routing Locator = o Added several mechanisms (from 6830bis) = regarding Routing Locator
= Reachability. = Reachability.
=
o Added port = 4342 to IANA Considerations section. = o Added port 4342 to IANA Considerations section.
=
B.10. Changes to = draft-ietf-lisp-rfc6833bis-07 B.11. Changes to = draft-ietf-lisp-rfc6833bis-07
=
o Posted = December 2017. o Posted December = 2017.
=
o Make it = more clear in a couple of places that RLOCs are used to = o Make it more clear in a couple of places = that RLOCs are used to
locate ETRs = more so than for Map-Server Map-Request forwarding. locate ETRs more so than for Map-Server = Map-Request forwarding.
=
o Make it = clear that "encapsualted" for a control message is an ECM = o Make it clear that "encapsualted" for a = control message is an ECM
based = message. based message.
=
o Make it = more clear what messages use source-port 4342 and which = o Make it more clear what messages use = source-port 4342 and which
=
skipping = to change at page 49, line = 25 =C2=B6 = skipping to change at page 50, line = 32 =C2=B6
Can use = othe AFIs then IPv4 and IPv6. = Can use othe AFIs then IPv4 and IPv6.
=
o Many = editorial changes to clarify text. = o Many editorial changes to clarify text.
=
o Changed = some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to = capitalized.
=
o Added = definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply = messages.
=
o Ran = document through IDNITs. o Ran = document through IDNITs.
=
B.11. Changes to = draft-ietf-lisp-rfc6833bis-06 B.12. Changes to = draft-ietf-lisp-rfc6833bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Spec the = I-bit to include the xTR-ID in a Map-Request message to = o Spec the I-bit to include the xTR-ID in a = Map-Request message to
be = consistent with the Map-Register message and to anticipate the = be consistent with the Map-Register = message and to anticipate the
= introduction of pubsub functionality to allow Map-Requests to = introduction of pubsub functionality to = allow Map-Requests to
subscribe = to RLOC-set changes. subscribe = to RLOC-set changes.
=
o Updated = references for individual submissions that became working = o Updated references for individual = submissions that became working
group = documents. group = documents.
=
o Updated = references for working group documents that became RFCs. = o Updated references for working group = documents that became RFCs.
=
B.12. Changes to = draft-ietf-lisp-rfc6833bis-05 B.13. Changes to = draft-ietf-lisp-rfc6833bis-05
=
o Posted May = 2017. o Posted May 2017.
=
o Update IANA = Considerations section based on new requests from this o Update IANA Considerations section based on new = requests from this
document = and changes from what was requested in [RFC6830]. document and changes from what was requested in = [RFC6830].
=
B.13. Changes to = draft-ietf-lisp-rfc6833bis-04 B.14. Changes to = draft-ietf-lisp-rfc6833bis-04
=
o Posted May = 2017. o Posted May 2017.
=
o Clarify how = the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in = Map-Register and Map-
Notify = messages. Break the 16-bit field into a 8-bit Key-ID field = Notify messages. Break the 16-bit field = into a 8-bit Key-ID field
and a 8-bit = Algorithm-ID field. and a 8-bit = Algorithm-ID field.
=
o Move the = Control-Plane codepoints from the IANA Considerations o Move the Control-Plane codepoints from the IANA = Considerations
section of = RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations = section of this
= document. document.
=
o In the = "LISP Control Packet Type Allocations" section, indicate = o In the "LISP Control Packet Type = Allocations" section, indicate
how message = Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how = experimental RFC8113
sub-types = should be requested. sub-types = should be requested.
=
B.14. Changes to = draft-ietf-lisp-rfc6833bis-03 B.15. Changes to = draft-ietf-lisp-rfc6833bis-03
=
o Posted = April 2017. o Posted April = 2017.
=
o Add types = 9-14 and specify they are not assigned. = o Add types 9-14 and specify they are not assigned.
=
o Add the = "LISP Shared Extension Message" type and point to RFC8113. = o Add the "LISP Shared Extension Message" = type and point to RFC8113.
=
B.15. Changes to = draft-ietf-lisp-rfc6833bis-02 B.16. Changes to = draft-ietf-lisp-rfc6833bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Clarify = that the LISP Control-Plane document defines how the LISP = o Clarify that the LISP Control-Plane = document defines how the LISP
Data-Plane = uses Map-Requests with either the SMR-bit set or the Data-Plane uses Map-Requests with either the = SMR-bit set or the
P-bit set = supporting mapping updates and RLOC-probing. Indicating = P-bit set supporting mapping updates and = RLOC-probing. Indicating
that other = Data-Planes can use the same mechanisms or their own that other Data-Planes can use the same mechanisms = or their own
defined = mechanisms to achieve the same functionality. defined mechanisms to achieve the same = functionality.
=
B.16. Changes to = draft-ietf-lisp-rfc6833bis-01 B.17. Changes to = draft-ietf-lisp-rfc6833bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Remove = references to self. o Remove = references to self.
=
o Change = references from RFC6830 to RFC6830bis. = o Change references from RFC6830 to RFC6830bis.
=
o Add two new = action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has = posted to the LISP
WG mailing = list. WG mailing list.
=
o In intro = section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to = I-D.ietf-lisp-introduction.
=
o Removed = Open Issues section and references to "experimental". o Removed Open Issues section and references to = "experimental".
=
B.17. Changes to = draft-ietf-lisp-rfc6833bis-00 B.18. Changes to = draft-ietf-lisp-rfc6833bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6833-00 = individual submission. No other changes made. -rfc6833-00 individual submission. No other = changes made.
=
B.18. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.19. Changes to = draft-farinacci-lisp-rfc6833bis-00
=
o Posted = November 2016. o Posted November = 2016.
=
o This is the = initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into = RFC 6833bis.
=
o The = document name has changed from the "Locator/ID Separation = o The document name has changed from the = "Locator/ID Separation
Protocol = (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the = "Locator/ID
Separation = Protocol (LISP) Control-Plane". = Separation Protocol (LISP) Control-Plane".
=
o The = fundamental change was to move the Control-Plane messages from = o The fundamental change was to move the = Control-Plane messages from
 End of changes. 52 change blocks. 
172 lines changed or = deleted 179 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_7BF7407E-EF83-4B8E-8D3D-3368F8E09350 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_7BF7407E-EF83-4B8E-8D3D-3368F8E09350--