From nobody Thu Aug 9 09:06: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 CEF94130E5B; Thu, 9 Aug 2018 09:05:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adrian Farrel To: Cc: lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153383075580.28970.16196543565444262922@ietfa.amsl.com> Date: Thu, 09 Aug 2018 09:05:55 -0700 Archived-At: Subject: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04 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: Thu, 09 Aug 2018 16:05:56 -0000 Reviewer: Adrian Farrel Review result: Has Issues Hello, I have been selected as the Routing Directorate reviewer for this draft. 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 ?http://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 as normal review comments. I believe that this review comes between WG publication and the start of IETF last call - you may wish to discuss with your AD whether to treat these comments separately or as part of IETF last call. Document: draft-ietf-lisp-gpe-04.txt Reviewer: Adrian Farrel Review Date: 9-August-2018 IETF LC End Date: No known Intended Status: Standards Track Summary I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. The issues are not substantially technical in nature, but do indicate the need for significant reworking of the text. I have tried to make suggestions for new text. Comments: This document specifies an alternate LISP header format that can be used to allow LISP to carry payloads other than IP. A new capabilities flag is defined so that routers know whether this new format is supported, and a new flag in the header itself indicates when the new format is in use. The document is clear and readable, but has some issues of presentation that could close a few potential misunderstandings and thus improve implmentation prospects. No attempt is made in the document to explain how/why the reduction in size of some standard LISP header fields is acceptable. For example, if implementations of this spec can safely operate with a 16 bit Nonce or 8 bit Map-Versions, why does 6830/6830bis feel the need for 24 and 12 bit fields rspectively? ===Major Issues=== Section 3 has a mix of minor and leess minor issues... OLD This document defines the following changes to the LISP header in order to support multi-protocol encapsulation: P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit MUST be set to 1 to indicate the presence of the 8 bit next protocol field. P = 0 indicates that the payload MUST conform to LISP as defined in [I-D.ietf-lisp-rfc6830bis]. Flag bit 5 was chosen as the P bit because this flag bit is currently unallocated. Next Protocol: The lower 8 bits of the first 32-bit word are used to carry a Next Protocol. This Next Protocol field contains the protocol of the encapsulated payload packet. LISP uses the lower 24 bits of the first word for either a nonce, an echo-nonce, or to support map-versioning [I-D.ietf-lisp-6834bis]. These are all optional capabilities that are indicated in the LISP header by setting the N, E, and the V bit respectively. When the P-bit and the N-bit are set to 1, the Nonce field is the middle 16 bits. When the P-bit and the V-bit are set to 1, the Version field is the middle 16 bits. When the P-bit is set to 1 and the N-bit and the V-bit are both 0, the middle 16-bits are set to 0. This document defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4 : Network Service Header [RFC8300] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|P|K|K| Nonce/Map-Version | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LISP-GPE Header NOTES - It would be helpful to put the figure higher up - The use of "MUST" for the P-bit is attenuated wrongly - Need to be consistent on "P Bit" or "P-bit" or "P bit" - There looks to be a problem in the case of map version. The base spec has 12 bits each for source and dest map-version, so this doc needs to describe how the reeduced 16 bits is split (presumably not 12 and 4). - You need a pointer to the IANA registry for next protocol NEW This document defines two changes to the LISP header in order to support multi-protocol encapsulation: the introduction of the P-bit and the definition of a Next Protocol field. This is shown in Figure 1 and described below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|P|K|K| Nonce/Map-Version | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 : The LISP-GPE Header P-Bit: Flag bit 5 is defined as the Next Protocol bit. If the P-bit is clear (0) the LISP header conforms to the definition in [I-D.ietf-lisp-rfc6830bis]. The P-bit is set to 1 to indicate the presence of the 8 bit Next Protocol field. Next Protocol: The lower 8 bits of the first 32-bit word are used to carry a Next Protocol. This Next Protocol field contains the protocol of the encapsulated payload packet. In [I-D.ietf-lisp-6834bis], LISP uses the lower 24 bits of the first word for a nonce, an echo-nonce, or to support map- versioning. These are all optional capabilities that are indicated in the LISP header by setting the N, E, and V bits respectively. When the P-bit and the N-bit are set to 1, the Nonce field is the middle 16 bits (i.e., encoded in 16 bits, not 24 bits). Note that the E-bit only has meaning when the N-bit is set. When the P-bit and the V-bit are set to 1, the Version fields use the middle 16 bits: the Source Map-Version uses the high-order 8 bits, and the Dest Map-Version uses the low-order 8 bits. When the P-bit is set to 1 and the N-bit and the V-bit are both 0, the middle 16-bits MUST be set to 0 on transmission and ignored on receipt. This document defines the following Next Protocol values: 0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0x4 : Network Service Header [RFC8300] The values are tracked in an IANA registry as described in Section 5. --- Section 4 must describe the error case when a LISP-GPE capable router sets the P-bit on a packet to a non LISP-GPE capable router. So... OLD When encapsulating IP packets to a non LISP-GPE capable router the P bit MUST be set to 0. NEW When encapsulating IP packets to a non LISP-GPE capable router the P- bit MUST be set to 0. That is, the encapsulation format defined in this document MUST NOT be sent to a router that has not indicated that it supports this specification because such a router would ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so would misinterpret the other LISP header fields possibly causing significant errors. END --- 4.1 Not your fault that RFC 8060 doesn't have a registry for bits in the LCAF, but now you really need one or else future orthogonal specs risk colliding with the g-bit. A bit odd to add this in this document, but not worth a bis on 8060. ===Minor Issues === Section 2 OLD The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of flags (some defined, some reserved), a Nonce/Map-version field and an instance ID/Locator-status-bit field. The flags provide flexibility to define how the various fields are encoded. Notably, Flag bit 5 is the last reserved bit in the LISP header. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LISP Header NOTES We need to be careful not to risk any confusion. At least, "some reserved" is an over-statement. But also we should not show a repeat of the Lisp header as that causes a duplicate definition. NEW The LISP header is defined in [I-D.ietf-lisp-rfc6830bis] and contains a series of flags of which one (bit 5) is shown in that document as "reserved for future use". The setting of the flag fields defined how the subsequent header fields are interpretted. END --- 4.1 I don't think you should reproduce the Multiple Data-Planes LCAF Type figue from 8060 here as it creates a duplicate definition. The text explanation of which bit is the g-bit shold be enough. ===Nits=== Abstract OLD This document describes extending the Locator/ID Separation Protocol (LISP) Data-Plane, via changes to the LISP header, to support multi- protocol encapsulation. NEW This document describes extentions to the Locator/ID Separation Protocol (LISP) Data-Plane, via changes to the LISP header, to support multi-protocol encapsulation. END --- 1. OLD LISP Data-Plane, as defined in in [I-D.ietf-lisp-rfc6830bis], defines an encapsulation format that carries IPv4 or IPv6 (henceforth referred to as IP) packets in a LISP header and outer UDP/IP transport. NEW The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It specifies an encapsulation format that carries IPv4 or IPv6 packets (henceforth jointly referred to as IP) in a LISP header and outer UDP/IP transport. --- 1.1 Please use the new boilerplate... The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. --- 1.2 Nothwithstanding the text in this section, abbreviations need to be expanded either on first use or in this section. I see: - LCAF - ETR - ITR - RLOC - xTR --- 2. s/As described in the introduction/As described in Section 1/ s/LISP is limited to carry IP payloads/LISP is limited to carrying IP payloads/ --- 4.1 s/field as g bit/field as the g-bit/ --- 8.1 Please add RFC 8174 From nobody Thu Aug 9 09:15: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 27374130E5C; Thu, 9 Aug 2018 09:15: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 c63DylPzbez0; Thu, 9 Aug 2018 09:15:45 -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 A56F7130E63; Thu, 9 Aug 2018 09:15:42 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id f1-v6so2955885pgq.12; Thu, 09 Aug 2018 09:15: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=P93/LgHPGjrrLIxy4iMQk++ZD4YlhbFcfjCNevFYCEM=; b=lv2zED4Eg9erPwGgzEWPcuWaS/fsPRbqE60UOllDTM0p7O1+8YQRsPmhxnRXtbB/zN UOLv4r45K0XljdP4mZWxknQAJuHd9a7N9ChRTVyjxm8UpAzNTQ84ZvaI3tZa1M3FfoKl C96SSCdTiCHO4RBJGX1EQckkZ9mPj9jU9J4BHjL8GHnMSKsBW0N04jDJkm/vFx5uDvil VQClCP0ULHlvhAmB/8JPidzBH+xvkRz6C7LCc34qTWiNaTeQpp1UjEx3gX742ZZDuhMW r8/cwOg0i81+0FS3l4n51Yi7A4zJypeTLGLhkTF56JgxxQ53qxIWYkNTCOJONfUPhW1y pvfg== 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=P93/LgHPGjrrLIxy4iMQk++ZD4YlhbFcfjCNevFYCEM=; b=UCHGHwYS1griepdKe5e3bDfZvJcBPsoYt3PnPO0xxn4rSeV+ZLwmWt/nj9hgLQ7h+4 UxCN7D8YnnnucxvBHhCGHM5svEdQOJMKKqj7Ckt/zEPuxCA/Ag0mSS/Ka1vnGGvGj7Fg thkvSNCUYRT2SeFHYf4uzhDcMkrQv39MKRRytJLhnrVIKLDj2NDbm3Ups0Pwuoyl+ZqS Iqm6WtDRrfcT1ABMM+aFRlTa3xQCi5dYf53bjybyeIWguE8NfbQObl3A32FVs4XNIz++ //t5F0zpslgaS3wfHkAIKaBt1rMH5AEoSyKh6k/HYstcKmnjRt808QzbZWNgnjJXhU9F qErA== X-Gm-Message-State: AOUpUlG2FC/d/WwJQnrFackEguzrl+BSw+I52n5psuJoHgYpCWhL8Flw FbMOBpCgWXWCr7myO/YGxBULrSeA X-Google-Smtp-Source: AA+uWPyg+JRwHFsSVQ1YfGPneRRw5np1gkzFnsHSnzG1imEEQ1stsompW8nUTiglo/Deq3YpClHVdw== X-Received: by 2002:a63:ca09:: with SMTP id n9-v6mr2719980pgi.287.1533831342325; Thu, 09 Aug 2018 09:15:42 -0700 (PDT) Received: from [10.31.79.47] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id n12-v6sm19122996pfh.146.2018.08.09.09.15.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 09:15:41 -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: <153383075580.28970.16196543565444262922@ietfa.amsl.com> Date: Thu, 9 Aug 2018 09:15:40 -0700 Cc: rtg-dir@ietf.org, draft-ietf-lisp-gpe.all@ietf.org, lisp@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153383075580.28970.16196543565444262922@ietfa.amsl.com> To: Adrian Farrel X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04 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: Thu, 09 Aug 2018 16:15:48 -0000 > No attempt is made in the document to explain how/why the reduction in = size of > some standard LISP header fields is acceptable. For example, if = implementations > of this spec can safely operate with a 16 bit Nonce or 8 bit = Map-Versions, why > does 6830/6830bis feel the need for 24 and 12 bit fields rspectively? Note, you misread RFC6830. The Map-Version field is 24-bits when the V = bit is set. And is divided up like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dino From nobody Thu Aug 9 09:39: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 95D5E130E64; Thu, 9 Aug 2018 09:39:12 -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] 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 tAhD4SmsU8PX; Thu, 9 Aug 2018 09:39:10 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 C56F6127598; Thu, 9 Aug 2018 09:39:09 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id w79Gd7ol005959; Thu, 9 Aug 2018 17:39:07 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 01A632203A; Thu, 9 Aug 2018 17:39:07 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id E0ECA22032; Thu, 9 Aug 2018 17:39:06 +0100 (BST) Received: from 950129200 (229.91.112.87.dyn.plus.net [87.112.91.229]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id w79Gd5X9001128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2018 17:39:06 +0100 Reply-To: From: "Adrian Farrel" To: "'Dino Farinacci'" Cc: , , , References: <153383075580.28970.16196543565444262922@ietfa.amsl.com> In-Reply-To: Date: Thu, 9 Aug 2018 17:39:01 +0100 Message-ID: <0a6701d42fff$7b1819d0$71484d70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGrV/OofqTlg1gMRiMR5UDgCNFOBgKaYb9upPR3VnA= Content-Language: en-gb X-Originating-IP: 87.112.91.229 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24022.001 X-TM-AS-Result: No--13.817-10.0-31-10 X-imss-scan-details: No--13.817-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24022.001 X-TMASE-Result: 10--13.816900-10.000000 X-TMASE-MatchedRID: pBwXUM+nCwsn2WEbWzq9rXBRIrj8R47Fh+w9Wz/xXDrb6Y+fnTZUL63c dtfiowZa5FL6T9P7KVCJfU10X8ghjUHWbmeNr66REPf7TDUOGorbW9tZdSdI3GecrqZc3vabLOx C6suyQ8YIS5UXqe5IMZGTpe1iiCJqtD9qpBlNF8oLbigRnpKlKSPzRlrdFGDwbEN5AhKpD2tXM5 9BwgdtZ98l5yvkaUcGLG9HNZsM44MObh0XtZFlZg== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04 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: Thu, 09 Aug 2018 16:39:14 -0000 Hello Dino, > > No attempt is made in the document to explain how/why the reduction in size > > of some standard LISP header fields is acceptable. For example, if > > implementations of this spec can safely operate with a 16 bit Nonce or 8 bit > > Map-Versions, why does 6830/6830bis feel the need for 24 and 12 bit fields > > rspectively? > > Note, you misread RFC6830. The Map-Version field is 24-bits when the V bit is > set. And is divided up like this: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|L|E|V|I|flags| Source Map-Version | Dest Map-Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID/Locator-Status-Bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I don't think I missed that even slightly. The Map-Version field is 24 bits and split into two 12 bit Map-Versions (source and dest). When the P-bit is set, the Map-Version is reduced to 16 bits and is (presumably) split at 8 bits each for source and dest (see my new text). So my question could be seen as: Why does this document only need 8 bits for Source Map-Version when 6830 needed 12 bits? Cheers, Adrian From nobody Thu Aug 9 10:52: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 64B50130E78; Thu, 9 Aug 2018 10:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 g2AU6saq4QaB; Thu, 9 Aug 2018 10:52:13 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC26130E90; Thu, 9 Aug 2018 10:52:11 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id x6-v6so2850035plv.10; Thu, 09 Aug 2018 10:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g2XiJquM3i72nr/i2YUOj36u2M2gaICY98PlZSX1Wqc=; b=I4LCglGpP4alioDadZ0mGZtMeMN6GVa5BpeqGQs1mT4fXJrvHRcjBCvyQBM8l2zxz6 E30YCNF9iWpqsuLgxZdjBsDLs9tp/BHCnpkT1m9zB9cjRGG14xw1KBQLDcK7e7r2JSQv y/VLwK8H7qGQskYhB2n8gVB40qoCZSYI/Kvx7j0qK2CRLFdqvGO08nUEsdVRa8QFQntd b6m2r6tNZlnm+KG0BxZ/LCOLWStTx7kTNdigdK9f17ADleCp7DADfIogUFWKuu67ecGO d6Ax9JW1qmjj0umKx7zNIeQ8AdPAydy97dSzqyOwz39N7oWLuHVmTCrald3uZYo9bgP6 DqZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g2XiJquM3i72nr/i2YUOj36u2M2gaICY98PlZSX1Wqc=; b=WPXfUGI2dc81UymbjtY+KMXY0Jom/W9GqJhv0dr/WYHSR1AslDX8l12zCfdvWZZHuo i23pieykcaWuEjLr6zkdXyVDon84UJLESuIC8Zbk8FflDZ+Y0/uOct0fOk6WKYiSu+64 bYlDdbEm2ufpryypAu+DAYFLyDFfb5+372qh9TfSMjEn5LTk4l2csXqgKiTZUCYmjbqM SID4BSggmVLaQEqQSdfZrCR4ZTPe5dSnTCZXVqgPD37WstlBP//WqqloyXJyVnu98Ls9 HdKloqNL6+C4dACnZgLpHQZFeECwOZcT3LkEPQqtQ5dj7N2aatn+uzkdcF9X0D7t+cxY 1tzg== X-Gm-Message-State: AOUpUlHMXalD0Bza38uyi2T6JzIL15BwAhLHHEAxlr2jYPWK4tFZO5Ev a6IBAxfGHeBC1M+4lu6lEACLpKCV X-Google-Smtp-Source: AA+uWPxSt7ONm6QyTv17t9LwpORy5lCi2TMLiYOES7t6kBUoA9Sgj7AHHAuPYur6a9To/RBLqrYLcQ== X-Received: by 2002:a17:902:864b:: with SMTP id y11-v6mr2956638plt.335.1533837131221; Thu, 09 Aug 2018 10:52:11 -0700 (PDT) Received: from [10.31.79.47] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id 70-v6sm12220041pfz.27.2018.08.09.10.52.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 10:52:10 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Content-Type: text/html; charset=utf-8 X-Apple-Auto-Saved: 1 X-Apple-Mail-Plain-Text-Draft: yes From: Dino Farinacci X-Apple-Mail-Remote-Attachments: YES X-Apple-Base-Url: x-msg://29/ In-Reply-To: <0a6701d42fff$7b1819d0$71484d70$@olddog.co.uk> X-Apple-Windows-Friendly: 1 Date: Thu, 9 Aug 2018 09:49:33 -0700 Cc: rtg-dir@ietf.org, draft-ietf-lisp-gpe.all@ietf.org, lisp@ietf.org, ietf@ietf.org X-Apple-Mail-Signature: SKIP_SIGNATURE Content-Transfer-Encoding: quoted-printable Message-Id: <82681BD8-FC3A-4D96-A801-A91B6219D0B8@gmail.com> References: <153383075580.28970.16196543565444262922@ietfa.amsl.com> <0a6701d42fff$7b1819d0$71484d70$@olddog.co.uk> X-Uniform-Type-Identifier: com.apple.mail-draft To: Adrian Farrel X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04 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: Thu, 09 Aug 2018 17:52:15 -0000
I missed = =E2=80=9Cfields=E2=80=9D versus =E2=80=9Cfield=E2=80=9D. = Sorry.

Your question still stands. I do believe shortening the = nonce IS NOT a good think. But I believe if the version needs to change, = rollover is not an issue. The fact that it is different to the receiver = is what is important.

In RFC6830, we used the entire field = because it was available and we didn=E2=80=99t want to store both = version and nonce at the same time when V and N bits were set. But if = one favors a smaller nonce, we could use the
idea in GPE to the same = field for both purposes. But that is yet another variant.

The = Map-Versioning has been underutilized and it is a shame. Because it is a = lighter weight than using SMRs. In fact, this email thread is motivating = me to go off and implement Map-Versioning and is particularly useful for = fast moving LISP mobile-nodes.

I am a bit off topic, but this is = a decent discussion to have. Here are the tradeoffs between = map-versioning and SMRs:

(1) SMRs send a Map-Request that has the = new RLOC-set info. The receiver can use the information on blind faith = or verify its integrity by doing a mapping system lookup. That is how it = is spec=E2=80=99ed in RFC6830. Unverified version takes 1/2 = RTT.

(2) Map-Versioning always requires 3/2s RTT but the = trigger/signal comes in a data-packet. The receiver only knows there is = a change but doesn=E2=80=99t have the new RLOC-set info, so it must do a = mapping system lookup. That means Map-Versioning, by nature, is required = to verification.

Now with have draft-ietf-lisp-pubsub come to = fruition, there is less need for (1) but believe (2) is very useful = because it doesn=E2=80=99t require the state in the map-server for = subscribers. That is, good job Luigi/Damien for the Map-Versioning = idea!

Dino


rspectively?

Note, you misread = RFC6830. The Map-Version field is 24-bits when the V bit is
set. And = is divided up like this:

=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  |N|L|E|V|I|flags|  Source Map-Version =   |   Dest Map-Version    |
=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  | =             &n= bsp;   Instance ID/Locator-Status-Bits =             &n= bsp; |
=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+

I don't think I missed that even = slightly.
The Map-Version field is 24 bits and split into two 12 bit = Map-Versions (source
and dest).
When the P-bit is set, the = Map-Version is reduced to 16 bits and is (presumably)
split at 8 bits = each for source and dest (see my new text).

So my question could = be seen as:
Why does this document only need 8 bits for Source = Map-Version when 6830 needed
12 = bits?

Cheers,
Adrian



= From nobody Fri Aug 10 06:36: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 8B1FB129C6A; Fri, 10 Aug 2018 06:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.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 dm_ZUtCLOLhj; Fri, 10 Aug 2018 06:36:18 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 451EC128CB7; Fri, 10 Aug 2018 06:36:15 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7ADXUFY006463; Fri, 10 Aug 2018 06:36:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=WbVwPUDSyVV9cKW3A2Mz8o0VSSiQ1hasHB4LDJ4MNrk=; b=oUiTVljvS1LLtdU71W7J69rHRUqZyUkEZgnujWMm7MIPgDy6vt/rgAALU/Y9sCm1y6Hp 6RkkPPRRBxLMiccEkkHOicQvRjCYWtsO/eDKQBN6Lj6+Yq3L1gsnR+3V6kbqV3kMb/bC CbSSAZcb6+YBena+PRch03uRKAUxbDm6wPM70Cne9wWdH5+NXmhAhw9VM24Qrnj8ZfCl J0laTp7Af/jjfIDLhNwbggcPvAb1LqvancUmK3inQbE68kBvxT5tMnsa4ByatFpJEcOI +y6brgKMdlgrkCF/KgF05+hJIYd+Tvch4l9gtGhsTYkCbbTWVhL+7bS0NSMo/Vb3JKuU rA== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0112.outbound.protection.outlook.com [207.46.163.112]) by mx0a-00273201.pphosted.com with ESMTP id 2ks8qj08sy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 10 Aug 2018 06:36:14 -0700 Received: from BN7PR05MB4354.namprd05.prod.outlook.com (52.133.223.33) by BN7PR05MB4529.namprd05.prod.outlook.com (52.135.248.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.15; Fri, 10 Aug 2018 13:36:12 +0000 Received: from BN7PR05MB4354.namprd05.prod.outlook.com ([fe80::7dd5:8313:e414:4e74]) by BN7PR05MB4354.namprd05.prod.outlook.com ([fe80::7dd5:8313:e414:4e74%2]) with mapi id 15.20.1038.019; Fri, 10 Aug 2018 13:36:12 +0000 From: John E Drake To: "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "draft-ietf-lisp-rfc6830bis.all@ietf.org" , "lisp@ietf.org" , IETF discussion list Thread-Topic: RtgDir review: draft-ietf-lisp-rfc6830bis-14.txt Thread-Index: AdQwrPj4vmV7Ei3rSGiTrgqu/EQbdA== Date: Fri, 10 Aug 2018 13:36:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR05MB4529; 6:B1cPtSQEkVeHuEaZhZ6mQ/xNEbswIt38819rbQfXMKJcH2s8XXnW7GkEqGqmm76c4q7QgXeMmYrlPXyFIfE5fSSFxKRu8urGtiMlqemPv6F9fcYtoQ8OhJeTYPK1r0ZvWb2SG805ZK5xH2U1YGul9lMCisgsmkdBZffbF8xNxsjEsb/DzWl9lLUo9U//Bv17B12NK6q9/6K+gJESOCr2GeZ2zOMjyxW9UYsw7DbMUjm359kw71837pH++zLCpHtr4U7sFvM3T5/ZzjQKxTwD0ghR+tlNj6+O12GqE6cm8gNWU6fNLiotrH0MJ5yMe2talc94TZE0GQ8P+PPagYzXdjufTnsijltp8GSPoQvhxh93hiFaOLIHzIu5SjqsjOHaBeWTsqCwlimBKY6uv6za2+QGUxDAEjXU63+2+N0ulCMkaV2cT/wP9FqEQLVFmnHzs9BOb3HXIQPH/bBFZgixFQ==; 5:UZgm2tlUgoPYawiiVdiRPBvWUDGLBE7kZhP7zMe4LL2I+RcqhnwNGS+ywHrPFsiPWBBleaDOHJHqqaIFD4GJKXDNlY+q7j2/dAi1mwdtuGXO604EfMAaNaeJAVmuB78gIPWm1u+oLiBAsj+ARRCmDmGldd91lU4VlwNVhJ/J9Rg=; 7:LTkPEc3ICKWJSuuCtoMps70uFJa1iIFiWCCejv2QTuyagBMQsxpgw2Zvmo7G8F+9jAHVK/7DY0ERdoCyhJI7pDgszfi0aUUNFbNqHW4TObF8kBG3pV1flF940PiUFcaHPRjWZdMlQpUw3s0h2w+X7QFyzvJmMWg1N5e6mX6oGR42oLG3YFgCb/p0snKKrmrPLu9y66Ceo/owU2tW6KxYrkAUCZytpifnMpzlkm80ixLVLNroQqwHvlM6hQZOYNLe x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0a449d84-69e2-4f84-2dcd-08d5fec63cf4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN7PR05MB4529; x-ms-traffictypediagnostic: BN7PR05MB4529: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BN7PR05MB4529; BCL:0; PCL:0; RULEID:; SRVR:BN7PR05MB4529; x-forefront-prvs: 07607ED19A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(346002)(396003)(376002)(366004)(189003)(199004)(25786009)(102836004)(66066001)(7696005)(54906003)(68736007)(305945005)(14454004)(99286004)(4326008)(26005)(9686003)(316002)(55016002)(478600001)(97736004)(86362001)(186003)(6436002)(450100002)(5640700003)(7736002)(53936002)(6506007)(6116002)(2906002)(2501003)(106356001)(105586002)(8676002)(2351001)(3846002)(6916009)(81156014)(2900100001)(476003)(5660300001)(5250100002)(256004)(81166006)(14444005)(74316002)(33656002)(8936002)(486006)(1720100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4529; H:BN7PR05MB4354.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: vFI9wx9hyGEU4CMszldhMGbo71nCL9/C7d6YRYiGRQ1WPO8LQ3rWEtIfrdCOMj3PKBOlSjzsqiD5A+XN7DQzM+SUBJsMccZHX6cj/ZD4DynsLTcfVYAQCvacjiulz3DbIq/ixyrOrDoChLhIYFfCvAXFKqzozSK97E4C1IqnbHY7Z1KoWsSqks+ya5ndLqJNWIELsWxAWH1/o+s5lQqKZqqqcVxqg/l1Ij/UNJs9Ap5euo0PoCNLTtqLrx/+8eVerjCUnOYznAZTguck0l+GoEk5I/m02pSD5WmMBbE4MH4nqCfiNJH72A9DyIO3Qw9w306pUFly0QFvHVh7M+G/0AmiE+vnAgENXwoUKmiPw+8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 0a449d84-69e2-4f84-2dcd-08d5fec63cf4 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2018 13:36:12.1437 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4529 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-10_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=935 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808100149 Archived-At: Subject: [lisp] RtgDir review: draft-ietf-lisp-rfc6830bis-14.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: Fri, 10 Aug 2018 13:36:21 -0000 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2Ug Y29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0 IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0 cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRo ZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMwYmlzLTE0LnR4dA0K UmV2aWV3ZXI6IHlvdXItbmFtZQ0KUmV2aWV3IERhdGU6IA0KSUVURiBMQyBFbmQgRGF0ZTogMTct QXVnLTIwMTgNCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQoNClN1bW1hcnk6DQoN CiAgICBObyBpc3N1ZXMgZm91bmQuIFRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0 aW9uLg0KICAgIA0KQ29tbWVudHM6DQoNCiAgICBUaGUgZG9jdW1lbnQgaXMgY2xlYXIsIGNvbmNp c2UsIGFuZCBjb21wcmVoZW5zaXZlLg0KDQogTWFqb3IgSXNzdWVzOg0KDQogIE5vIG1ham9yIGlz c3VlcyBmb3VuZC4NCg0KTWlub3IgSXNzdWVzOg0KDQogIE5vIG1pbm9yIGlzc3VlcyBmb3VuZC4g DQoNCllvdXJzIElycmVzcGVjdGl2ZWx5LA0KDQpKb2huDQoNCg== From nobody Wed Aug 15 10:30: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 3AF1C13101B; Wed, 15 Aug 2018 10:29:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk CC: lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, db3546@att.com, Luigi Iannone , ggx@gigix.net, lisp@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153435419816.14388.8449951694289375416.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 10:29:58 -0700 Archived-At: Subject: [lisp] Last Call: (The Locator/ID Separation Protocol (LISP)) to Proposed Standard 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: Wed, 15 Aug 2018 17:29:58 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'The Locator/ID Separation Protocol (LISP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-08-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-lisp-6834bis: Locator/ID Separation Protocol (LISP) Map-Versioning (None - IETF stream) From nobody Wed Aug 15 11:15: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 7D029130DC2; Wed, 15 Aug 2018 11:15:22 -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 YrvX4awYHI_M; Wed, 15 Aug 2018 11:15:20 -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 BD3FF12D949; Wed, 15 Aug 2018 11:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13470; q=dns/txt; s=iport; t=1534356919; x=1535566519; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=oF29BqskOcVJ6IJ3di9gSm9SISGq5Y5KyCMUwK7bYew=; b=liPhiCKzAJIeJfxxPwStK4oVL5Ppe95uyr26SbOvPgjqEukJrBqfxVMQ GBaAGWj+guryaxtJmew07xO+ONEVR8XfeNHSeH7ozVYwkJYWd7l2E+wis J22ojavXj9srwPm3RyKKQU2dF/3cajRvc1ZBuwNyVFkyFgCW35vu7heBn o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAAAObXRb/5pdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMgL2N/KINtiAqMM4FgLZYTgXoLI4EzAYMVAoM0ITQYAQI?= =?us-ascii?q?BAQIBAQJtHAyFNwEBAQMBIw8BBS8SBQsLFAQCAiYCAlcGAQwIAQGDHgGBeQg?= =?us-ascii?q?PqzqBLoRohXqBC4gJF4FBP4ESJ4JrgxALAoE6J4MBglUCjXKMeQmGJXWBfoY?= =?us-ascii?q?9BhWBOkiDZoJRhXOIK4JdiBmBQTiBUjMaCBsVgyUIghwXiFmFXh8xi1+CSQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.53,244,1531785600"; d="scan'208";a="441754412" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Aug 2018 18:15:18 +0000 Received: from [10.24.94.185] ([10.24.94.185]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w7FIFHJh012095; Wed, 15 Aug 2018 18:15:17 GMT To: Adrian Farrel , rtg-dir@ietf.org Cc: lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org References: <153383075580.28970.16196543565444262922@ietfa.amsl.com> From: Fabio Maino Message-ID: <1c15b23d-abe7-16c5-d7d8-88279b061441@cisco.com> Date: Wed, 15 Aug 2018 11:15:17 -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: <153383075580.28970.16196543565444262922@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.24.94.185, [10.24.94.185] X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04 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: Wed, 15 Aug 2018 18:15:22 -0000 Hi Adrian, thanks for such a detailed review. I went through your comments and I can incorporate all of them into a new version of the draft. Wrt the reduction in size of the Map-Versioning and Nonce fields, I could add in Section 3, right after the definition of the encoding of those fields, the following: > The encoding of the Nonce field in LISP-GPE, compared with the one > used in RFC6830bis for the LISP data plane encapsulation, reduces the > length of the nonce from 24 to 16 bits. As per RFC6830bis, ITRs are > required to generate different nonces when sending to different RLOCs, > but the same nonce can be used for a period of time when encapsulating > to the same 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. > > Similarly, the encoding of the Source and Dest Map-Version fields, > compared with RFC6830bis, is reduced from 12 to 8 bits. This still > allows to associate 256 different versions to each EID-to-RLOC mapping > to inform commmunicating ITRs and ETRs about modifications of the > mapping. > Either Deborah, Joel, or Luigi: if you could please confirm that it is ok to publish a new version of the draft at this point, I'll update it right away. Thanks, Fabio On 8/9/18 9:05 AM, Adrian Farrel wrote: > Reviewer: Adrian Farrel > Review result: Has Issues > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. 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 > ?http://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 as normal review comments. I believe that > this review comes between WG publication and the start of IETF last call - you > may wish to discuss with your AD whether to treat these comments separately or > as part of IETF last call. > > Document: draft-ietf-lisp-gpe-04.txt > Reviewer: Adrian Farrel > Review Date: 9-August-2018 > IETF LC End Date: No known > Intended Status: Standards Track > > Summary > I have significant concerns about this document and recommend that the Routing > ADs discuss these issues further with the authors. The issues are not > substantially technical in nature, but do indicate the need for significant > reworking of the text. I have tried to make suggestions for new text. > > Comments: > > This document specifies an alternate LISP header format that can be used to > allow LISP to carry payloads other than IP. A new capabilities flag is defined > so that routers know whether this new format is supported, and a new flag in > the header itself indicates when the new format is in use. > > The document is clear and readable, but has some issues of presentation that > could close a few potential misunderstandings and thus improve implmentation > prospects. > > No attempt is made in the document to explain how/why the reduction in size of > some standard LISP header fields is acceptable. For example, if implementations > of this spec can safely operate with a 16 bit Nonce or 8 bit Map-Versions, why > does 6830/6830bis feel the need for 24 and 12 bit fields rspectively? > > ===Major Issues=== > > Section 3 has a mix of minor and leess minor issues... > > OLD > This document defines the following changes to the LISP header in > order to support multi-protocol encapsulation: > > P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit > MUST be set to 1 to indicate the presence of the 8 bit next > protocol field. > > P = 0 indicates that the payload MUST conform to LISP as defined > in [I-D.ietf-lisp-rfc6830bis]. Flag bit 5 was chosen as the P bit > because this flag bit is currently unallocated. > > Next Protocol: The lower 8 bits of the first 32-bit word are used to > carry a Next Protocol. This Next Protocol field contains the > protocol of the encapsulated payload packet. > > LISP uses the lower 24 bits of the first word for either a nonce, > an echo-nonce, or to support map-versioning > [I-D.ietf-lisp-6834bis]. These are all optional capabilities that > are indicated in the LISP header by setting the N, E, and the V > bit respectively. > > When the P-bit and the N-bit are set to 1, the Nonce field is the > middle 16 bits. > > When the P-bit and the V-bit are set to 1, the Version field is > the middle 16 bits. > > When the P-bit is set to 1 and the N-bit and the V-bit are both 0, > the middle 16-bits are set to 0. > > This document defines the following Next Protocol values: > > 0x1 : IPv4 > > 0x2 : IPv6 > > 0x3 : Ethernet > > 0x4 : Network Service Header [RFC8300] > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|L|E|V|I|P|K|K| Nonce/Map-Version | Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID/Locator-Status-Bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > LISP-GPE Header > > NOTES > - It would be helpful to put the figure higher up > - The use of "MUST" for the P-bit is attenuated wrongly > - Need to be consistent on "P Bit" or "P-bit" or "P bit" > - There looks to be a problem in the case of map version. The base > spec has 12 bits each for source and dest map-version, so this doc > needs to describe how the reeduced 16 bits is split (presumably not > 12 and 4). > - You need a pointer to the IANA registry for next protocol > NEW > This document defines two changes to the LISP header in order to > support multi-protocol encapsulation: the introduction of the P-bit > and the definition of a Next Protocol field. This is shown in > Figure 1 and described below. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|L|E|V|I|P|K|K| Nonce/Map-Version | Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID/Locator-Status-Bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1 : The LISP-GPE Header > > P-Bit: Flag bit 5 is defined as the Next Protocol bit. > > If the P-bit is clear (0) the LISP header conforms to the > definition in [I-D.ietf-lisp-rfc6830bis]. > > The P-bit is set to 1 to indicate the presence of the 8 bit Next > Protocol field. > > Next Protocol: The lower 8 bits of the first 32-bit word are used to > carry a Next Protocol. This Next Protocol field contains the > protocol of the encapsulated payload packet. > > In [I-D.ietf-lisp-6834bis], LISP uses the lower 24 bits of the > first word for a nonce, an echo-nonce, or to support map- > versioning. These are all optional capabilities that are > indicated in the LISP header by setting the N, E, and V bits > respectively. > > When the P-bit and the N-bit are set to 1, the Nonce field is the > middle 16 bits (i.e., encoded in 16 bits, not 24 bits). Note that > the E-bit only has meaning when the N-bit is set. > > When the P-bit and the V-bit are set to 1, the Version fields use > the middle 16 bits: the Source Map-Version uses the high-order 8 > bits, and the Dest Map-Version uses the low-order 8 bits. > > When the P-bit is set to 1 and the N-bit and the V-bit are both 0, > the middle 16-bits MUST be set to 0 on transmission and ignored on > receipt. > > This document defines the following Next Protocol values: > > 0x1 : IPv4 > > 0x2 : IPv6 > > 0x3 : Ethernet > > 0x4 : Network Service Header [RFC8300] > > The values are tracked in an IANA registry as described in Section > 5. > > --- > > Section 4 must describe the error case when a LISP-GPE capable router > sets the P-bit on a packet to a non LISP-GPE capable router. So... > > OLD > When encapsulating IP packets to a non LISP-GPE capable router the P > bit MUST be set to 0. > NEW > When encapsulating IP packets to a non LISP-GPE capable router the P- > bit MUST be set to 0. That is, the encapsulation format defined in > this document MUST NOT be sent to a router that has not indicated > that it supports this specification because such a router would > ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so > would misinterpret the other LISP header fields possibly causing > significant errors. > END > > --- > > 4.1 > > Not your fault that RFC 8060 doesn't have a registry for bits in the > LCAF, but now you really need one or else future orthogonal specs risk > colliding with the g-bit. A bit odd to add this in this document, but > not worth a bis on 8060. > > ===Minor Issues === > > Section 2 > > OLD > The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of flags > (some defined, some reserved), a Nonce/Map-version field and an > instance ID/Locator-status-bit field. The flags provide flexibility > to define how the various fields are encoded. Notably, Flag bit 5 is > the last reserved bit in the LISP header. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|L|E|V|I|R|K|K| Nonce/Map-Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID/Locator-Status-Bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > LISP Header > NOTES > We need to be careful not to risk any confusion. At least, "some > reserved" is an over-statement. But also we should not show a repeat > of the Lisp header as that causes a duplicate definition. > NEW > The LISP header is defined in [I-D.ietf-lisp-rfc6830bis] and contains > a series of flags of which one (bit 5) is shown in that document as > "reserved for future use". The setting of the flag fields defined > how the subsequent header fields are interpretted. > END > > --- > > 4.1 > I don't think you should reproduce the Multiple Data-Planes LCAF Type > figue from 8060 here as it creates a duplicate definition. The text > explanation of which bit is the g-bit shold be enough. > > ===Nits=== > > Abstract > OLD > This document describes extending the Locator/ID Separation Protocol > (LISP) Data-Plane, via changes to the LISP header, to support multi- > protocol encapsulation. > NEW > This document describes extentions to the Locator/ID Separation > Protocol (LISP) Data-Plane, via changes to the LISP header, to > support multi-protocol encapsulation. > END > > --- > > 1. > OLD > LISP Data-Plane, as defined in in [I-D.ietf-lisp-rfc6830bis], defines > an encapsulation format that carries IPv4 or IPv6 (henceforth > referred to as IP) packets in a LISP header and outer UDP/IP > transport. > NEW > The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It > specifies an encapsulation format that carries IPv4 or IPv6 packets > (henceforth jointly referred to as IP) in a LISP header and outer > UDP/IP transport. > > --- > > 1.1 > Please use the new boilerplate... > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. > > --- > > 1.2 > Nothwithstanding the text in this section, abbreviations need to be > expanded either on first use or in this section. > I see: > - LCAF > - ETR > - ITR > - RLOC > - xTR > > --- > > 2. > s/As described in the introduction/As described in Section 1/ > s/LISP is limited to carry IP payloads/LISP is limited to carrying IP payloads/ > > --- > > 4.1 > s/field as g bit/field as the g-bit/ > > --- > > 8.1 > Please add RFC 8174 > From nobody Wed Aug 15 11:30: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 6EA7613108C; Wed, 15 Aug 2018 11:30:30 -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, 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 Q9-R3GHYus25; Wed, 15 Aug 2018 11:30:27 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 B65F9130DF6; Wed, 15 Aug 2018 11:30:26 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id w7FIULUV017726; Wed, 15 Aug 2018 19:30:21 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 593F222042; Wed, 15 Aug 2018 19:30:21 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 400C92204A; Wed, 15 Aug 2018 19:30:21 +0100 (BST) Received: from 950129200 (229.91.112.87.dyn.plus.net [87.112.91.229]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id w7FIUIdj006521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2018 19:30:19 +0100 Reply-To: From: "Adrian Farrel" To: "'Fabio Maino'" , Cc: , , References: <153383075580.28970.16196543565444262922@ietfa.amsl.com> <1c15b23d-abe7-16c5-d7d8-88279b061441@cisco.com> In-Reply-To: <1c15b23d-abe7-16c5-d7d8-88279b061441@cisco.com> Date: Wed, 15 Aug 2018 19:30:18 +0100 Message-ID: <015201d434c6$05902a10$10b07e30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGrV/OofqTlg1gMRiMR5UDgCNFOBgHrrPAlpQN9NOA= Content-Language: en-gb X-Originating-IP: 87.112.91.229 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24034.002 X-TM-AS-Result: No--35.829-10.0-31-10 X-imss-scan-details: No--35.829-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24034.002 X-TMASE-Result: 10--35.828700-10.000000 X-TMASE-MatchedRID: yebcs53SkkAZax9TsUmzyeYAh37ZsBDCt3aeg7g/usAutoY2UtFqGFdV hcU0C7v4RV3Jvwv5IomxJZlbR4Xa9lrzSUKT6RlXma6DzXaohvPDHSNFHFxB883WsuqkgrPjyms yD5ZDYiKkzut+vhJOLUz/oFwO7+N+W/Dpe0fsrIpCnGIuUMP0VVAI6wCVrE3vDzHdHAreOMVlmv qsqaAYaxfEMA1zsy4OJUrYO+8+T/CrzuBPuFwqQk0jzafXv7tTYQXxsZnRwoJrKNt7ipQiYxEag Ylxo94PVgVZDJENjzI5pv/p79MF1dXXXs1Z8vkC8OsWh3diggrUZrYvzuo9ArrfxlRjqBJ3FhMg ncTYqyRkcD2Pk3/H3tl/84vVNSajq0LcAkhU1lF8Uw4r8ep8Bn+vzHfC29pfpMEnsw8ssa6kQu0 /M/TLDkIiCGakGnQ9x5ikrsSuxdbLIr1irshnclVCBNP48QP9NACnndLvXwfb6Y+fnTZUL33398 wxgdEB/esbbEiRiTnb3DJ2e4GMIpnPexZXV5z5kRs1fAcYNHGhfX5oAjRY3pTx+2LIqNmtjNETH H9N9TZeCaDw/ofFOyyMYZ1O/+1WsbrrpvzFsu8SS5pQAyYxiu4dka7CjortMKZRiezcUtNZc6Pc 0imoinyFbrfLM824xOwqJ2xqFVHEFB+Bmr71qu78M8+rjHgCviRliDV2nywCB9odk/ZD8DjsVNj k91jAj4P46izEGRMskUg+WjIazOF7Pq0ToovmlUgQqGVMqmyP/EshoNKyEUK7eJQWtfQOxURYSO EGU3tp0u+4Heb9WT63/DOLFD0VYY3ozW+EngeeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04 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: Wed, 15 Aug 2018 18:30:38 -0000 Hi Fabio, That additional text is helpful, thanks. Adrian > -----Original Message----- > From: Fabio Maino [mailto:fmaino@cisco.com] > Sent: 15 August 2018 19:15 > To: Adrian Farrel; rtg-dir@ietf.org > Cc: lisp@ietf.org; ietf@ietf.org; draft-ietf-lisp-gpe.all@ietf.org > Subject: Re: Rtgdir last call review of draft-ietf-lisp-gpe-04 >=20 > Hi Adrian, > thanks for such a detailed review. >=20 > I went through your comments and I can incorporate all of them into a > new version of the draft. >=20 > Wrt the reduction in size of the Map-Versioning and Nonce fields, I > could add in Section 3, right after the definition of the encoding of > those fields, the following: >=20 > > The encoding of the Nonce field in LISP-GPE, compared with the one > > used in RFC6830bis for the LISP data plane encapsulation, reduces = the > > length of the nonce from 24 to 16 bits. As per RFC6830bis, ITRs are > > required to generate different nonces when sending to different = RLOCs, > > but the same nonce can be used for a period of time when = encapsulating > > to the same 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. > > > > Similarly, the encoding of the Source and Dest Map-Version fields, > > compared with RFC6830bis, is reduced from 12 to 8 bits. This still > > allows to associate 256 different versions to each EID-to-RLOC = mapping > > to inform commmunicating ITRs and ETRs about modifications of the > > mapping. > > >=20 >=20 > Either Deborah, Joel, or Luigi: if you could please confirm that it is > ok to publish a new version of the draft at this point, I'll update it > right away. >=20 > Thanks, > Fabio >=20 >=20 >=20 >=20 > On 8/9/18 9:05 AM, Adrian Farrel wrote: > > Reviewer: Adrian Farrel > > Review result: Has Issues > > > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this = draft. 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 > > ?http://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 as normal review comments. I = believe > that > > this review comes between WG publication and the start of IETF last = call - you > > may wish to discuss with your AD whether to treat these comments = separately > or > > as part of IETF last call. > > > > Document: draft-ietf-lisp-gpe-04.txt > > Reviewer: Adrian Farrel > > Review Date: 9-August-2018 > > IETF LC End Date: No known > > Intended Status: Standards Track > > > > Summary > > I have significant concerns about this document and recommend that = the > Routing > > ADs discuss these issues further with the authors. The issues are = not > > substantially technical in nature, but do indicate the need for = significant > > reworking of the text. I have tried to make suggestions for new = text. > > > > Comments: > > > > This document specifies an alternate LISP header format that can be = used to > > allow LISP to carry payloads other than IP. A new capabilities flag = is defined > > so that routers know whether this new format is supported, and a new = flag in > > the header itself indicates when the new format is in use. > > > > The document is clear and readable, but has some issues of = presentation that > > could close a few potential misunderstandings and thus improve = implmentation > > prospects. > > > > No attempt is made in the document to explain how/why the reduction = in size > of > > some standard LISP header fields is acceptable. For example, if > implementations > > of this spec can safely operate with a 16 bit Nonce or 8 bit = Map-Versions, why > > does 6830/6830bis feel the need for 24 and 12 bit fields = rspectively? > > > > =3D=3D=3DMajor Issues=3D=3D=3D > > > > Section 3 has a mix of minor and leess minor issues... > > > > OLD > > This document defines the following changes to the LISP header = in > > order to support multi-protocol encapsulation: > > > > P Bit: Flag bit 5 is defined as the Next Protocol bit. The P = bit > > MUST be set to 1 to indicate the presence of the 8 bit next > > protocol field. > > > > P =3D 0 indicates that the payload MUST conform to LISP as = defined > > in [I-D.ietf-lisp-rfc6830bis]. Flag bit 5 was chosen as the = P bit > > because this flag bit is currently unallocated. > > > > Next Protocol: The lower 8 bits of the first 32-bit word are = used to > > carry a Next Protocol. This Next Protocol field contains the > > protocol of the encapsulated payload packet. > > > > LISP uses the lower 24 bits of the first word for either a = nonce, > > an echo-nonce, or to support map-versioning > > [I-D.ietf-lisp-6834bis]. These are all optional capabilities = that > > are indicated in the LISP header by setting the N, E, and the = V > > bit respectively. > > > > When the P-bit and the N-bit are set to 1, the Nonce field is = the > > middle 16 bits. > > > > When the P-bit and the V-bit are set to 1, the Version field = is > > the middle 16 bits. > > > > When the P-bit is set to 1 and the N-bit and the V-bit are = both 0, > > the middle 16-bits are set to 0. > > > > This document defines the following Next Protocol values: > > > > 0x1 : IPv4 > > > > 0x2 : IPv6 > > > > 0x3 : Ethernet > > > > 0x4 : Network Service Header [RFC8300] > > > > 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 > > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |N|L|E|V|I|P|K|K| Nonce/Map-Version | Next = Protocol | > > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Instance ID/Locator-Status-Bits = | > > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > LISP-GPE Header > > > > NOTES > > - It would be helpful to put the figure higher up > > - The use of "MUST" for the P-bit is attenuated wrongly > > - Need to be consistent on "P Bit" or "P-bit" or "P bit" > > - There looks to be a problem in the case of map version. The = base > > spec has 12 bits each for source and dest map-version, so this = doc > > needs to describe how the reeduced 16 bits is split = (presumably not > > 12 and 4). > > - You need a pointer to the IANA registry for next protocol > > NEW > > This document defines two changes to the LISP header in order to > > support multi-protocol encapsulation: the introduction of the = P-bit > > and the definition of a Next Protocol field. This is shown in > > Figure 1 and described below. > > > > 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 > > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |N|L|E|V|I|P|K|K| Nonce/Map-Version | Next = Protocol | > > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Instance ID/Locator-Status-Bits = | > > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 1 : The LISP-GPE Header > > > > P-Bit: Flag bit 5 is defined as the Next Protocol bit. > > > > If the P-bit is clear (0) the LISP header conforms to the > > definition in [I-D.ietf-lisp-rfc6830bis]. > > > > The P-bit is set to 1 to indicate the presence of the 8 bit = Next > > Protocol field. > > > > Next Protocol: The lower 8 bits of the first 32-bit word are = used to > > carry a Next Protocol. This Next Protocol field contains the > > protocol of the encapsulated payload packet. > > > > In [I-D.ietf-lisp-6834bis], LISP uses the lower 24 bits of = the > > first word for a nonce, an echo-nonce, or to support map- > > versioning. These are all optional capabilities that are > > indicated in the LISP header by setting the N, E, and V bits > > respectively. > > > > When the P-bit and the N-bit are set to 1, the Nonce field is = the > > middle 16 bits (i.e., encoded in 16 bits, not 24 bits). Note = that > > the E-bit only has meaning when the N-bit is set. > > > > When the P-bit and the V-bit are set to 1, the Version fields = use > > the middle 16 bits: the Source Map-Version uses the = high-order 8 > > bits, and the Dest Map-Version uses the low-order 8 bits. > > > > When the P-bit is set to 1 and the N-bit and the V-bit are = both 0, > > the middle 16-bits MUST be set to 0 on transmission and = ignored on > > receipt. > > > > This document defines the following Next Protocol values: > > > > 0x1 : IPv4 > > > > 0x2 : IPv6 > > > > 0x3 : Ethernet > > > > 0x4 : Network Service Header [RFC8300] > > > > The values are tracked in an IANA registry as described in = Section > > 5. > > > > --- > > > > Section 4 must describe the error case when a LISP-GPE capable = router > > sets the P-bit on a packet to a non LISP-GPE capable router. So... > > > > OLD > > When encapsulating IP packets to a non LISP-GPE capable router = the P > > bit MUST be set to 0. > > NEW > > When encapsulating IP packets to a non LISP-GPE capable router = the P- > > bit MUST be set to 0. That is, the encapsulation format defined = in > > this document MUST NOT be sent to a router that has not = indicated > > that it supports this specification because such a router would > > ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) = and so > > would misinterpret the other LISP header fields possibly causing > > significant errors. > > END > > > > --- > > > > 4.1 > > > > Not your fault that RFC 8060 doesn't have a registry for bits in the > > LCAF, but now you really need one or else future orthogonal specs = risk > > colliding with the g-bit. A bit odd to add this in this document, = but > > not worth a bis on 8060. > > > > =3D=3D=3DMinor Issues =3D=3D=3D > > > > Section 2 > > > > OLD > > The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of = flags > > (some defined, some reserved), a Nonce/Map-version field and an > > instance ID/Locator-status-bit field. The flags provide = flexibility > > to define how the various fields are encoded. Notably, Flag bit = 5 is > > the last reserved bit in the LISP header. > > > > 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 > > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |N|L|E|V|I|R|K|K| Nonce/Map-Version = | > > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Instance ID/Locator-Status-Bits = | > > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > LISP Header > > NOTES > > We need to be careful not to risk any confusion. At least, "some > > reserved" is an over-statement. But also we should not show a = repeat > > of the Lisp header as that causes a duplicate definition. > > NEW > > The LISP header is defined in [I-D.ietf-lisp-rfc6830bis] and = contains > > a series of flags of which one (bit 5) is shown in that document = as > > "reserved for future use". The setting of the flag fields = defined > > how the subsequent header fields are interpretted. > > END > > > > --- > > > > 4.1 > > I don't think you should reproduce the Multiple Data-Planes LCAF = Type > > figue from 8060 here as it creates a duplicate definition. The text > > explanation of which bit is the g-bit shold be enough. > > > > =3D=3D=3DNits=3D=3D=3D > > > > Abstract > > OLD > > This document describes extending the Locator/ID Separation = Protocol > > (LISP) Data-Plane, via changes to the LISP header, to support = multi- > > protocol encapsulation. > > NEW > > This document describes extentions to the Locator/ID Separation > > Protocol (LISP) Data-Plane, via changes to the LISP header, to > > support multi-protocol encapsulation. > > END > > > > --- > > > > 1. > > OLD > > LISP Data-Plane, as defined in in [I-D.ietf-lisp-rfc6830bis], = defines > > an encapsulation format that carries IPv4 or IPv6 (henceforth > > referred to as IP) packets in a LISP header and outer UDP/IP > > transport. > > NEW > > The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. = It > > specifies an encapsulation format that carries IPv4 or IPv6 = packets > > (henceforth jointly referred to as IP) in a LISP header and = outer > > UDP/IP transport. > > > > --- > > > > 1.1 > > Please use the new boilerplate... > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", > "MAY", and > > "OPTIONAL" in this document are to be interpreted as described = in BCP > > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > > capitals, as shown here. > > > > --- > > > > 1.2 > > Nothwithstanding the text in this section, abbreviations need to be > > expanded either on first use or in this section. > > I see: > > - LCAF > > - ETR > > - ITR > > - RLOC > > - xTR > > > > --- > > > > 2. > > s/As described in the introduction/As described in Section 1/ > > s/LISP is limited to carry IP payloads/LISP is limited to carrying = IP payloads/ > > > > --- > > > > 4.1 > > s/field as g bit/field as the g-bit/ > > > > --- > > > > 8.1 > > Please add RFC 8174 > > From nobody Wed Aug 15 11:30: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 63BBF131093; Wed, 15 Aug 2018 11:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 25r8sBG7LL74; Wed, 15 Aug 2018 11:30: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 18AB8130E89; Wed, 15 Aug 2018 11:30:30 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7FIFUOL037208; Wed, 15 Aug 2018 14:24:58 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 2kvrya17me-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Aug 2018 14:24:58 -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 w7FIOuuj019725; Wed, 15 Aug 2018 14:24:57 -0400 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [135.66.87.42]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w7FIOsJ0019707; Wed, 15 Aug 2018 14:24:54 -0400 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [127.0.0.1]) by zlp27129.vci.att.com (Service) with ESMTP id 3F6DA40397D4; Wed, 15 Aug 2018 18:24:54 +0000 (GMT) Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (unknown [130.9.129.151]) by zlp27129.vci.att.com (Service) with ESMTPS id 1BE63400041E; Wed, 15 Aug 2018 18:24:54 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.41]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0408.000; Wed, 15 Aug 2018 14:24:53 -0400 From: "BRUNGARD, DEBORAH A" To: Fabio Maino , Adrian Farrel CC: "lisp@ietf.org" , "draft-ietf-lisp-gpe.all@ietf.org" Thread-Topic: Rtgdir last call review of draft-ietf-lisp-gpe-04 Thread-Index: AQHUL/rptGnvayTge0qYxHM0x66st6TBau6A//++k2A= Date: Wed, 15 Aug 2018 18:24:53 +0000 Message-ID: References: <153383075580.28970.16196543565444262922@ietfa.amsl.com> <1c15b23d-abe7-16c5-d7d8-88279b061441@cisco.com> In-Reply-To: <1c15b23d-abe7-16c5-d7d8-88279b061441@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.232] 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-08-15_07:, , 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-1808150189 Archived-At: Subject: Re: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04 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: Wed, 15 Aug 2018 18:30:40 -0000 SGkgRmFiaW8sDQoNClllcywgcGxlYXNlIHVwZGF0ZS0NCkRlYm9yYWgNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRmFiaW8gTWFpbm8gPGZtYWlub0BjaXNjby5jb20+IA0K U2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTUsIDIwMTggMjoxNSBQTQ0KVG86IEFkcmlhbiBGYXJy ZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+OyBydGctZGlyQGlldGYub3JnDQpDYzogbGlzcEBpZXRm Lm9yZzsgaWV0ZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1saXNwLWdwZS5hbGxAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBSdGdkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWxpc3AtZ3Bl LTA0DQoNCkhpIEFkcmlhbiwNCnRoYW5rcyBmb3Igc3VjaCBhIGRldGFpbGVkIHJldmlldy4NCg0K SSB3ZW50IHRocm91Z2ggeW91ciBjb21tZW50cyBhbmQgSSBjYW4gaW5jb3Jwb3JhdGUgYWxsIG9m IHRoZW0gaW50byBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KV3J0IHRoZSByZWR1Y3Rp b24gaW4gc2l6ZSBvZiB0aGUgTWFwLVZlcnNpb25pbmcgYW5kIE5vbmNlIGZpZWxkcywgSSBjb3Vs ZCBhZGQgaW4gU2VjdGlvbiAzLCByaWdodCBhZnRlciB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgZW5j b2Rpbmcgb2YgdGhvc2UgZmllbGRzLCB0aGUgZm9sbG93aW5nOg0KDQo+IFRoZSBlbmNvZGluZyBv ZiB0aGUgTm9uY2UgZmllbGQgaW4gTElTUC1HUEUsIGNvbXBhcmVkIHdpdGggdGhlIG9uZSANCj4g dXNlZCBpbiBSRkM2ODMwYmlzIGZvciB0aGUgTElTUCBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24s IHJlZHVjZXMgdGhlIA0KPiBsZW5ndGggb2YgdGhlIG5vbmNlIGZyb20gMjQgdG8gMTYgYml0cy4g QXMgcGVyIFJGQzY4MzBiaXMsIElUUnMgYXJlIA0KPiByZXF1aXJlZCB0byBnZW5lcmF0ZSBkaWZm ZXJlbnQgbm9uY2VzIHdoZW4gc2VuZGluZyB0byBkaWZmZXJlbnQgUkxPQ3MsIA0KPiBidXQgdGhl IHNhbWUgbm9uY2UgY2FuIGJlIHVzZWQgZm9yIGEgcGVyaW9kIG9mIHRpbWUgd2hlbiBlbmNhcHN1 bGF0aW5nIA0KPiB0byB0aGUgc2FtZSBFVFIuIFRoZSB1c2Ugb2YgMTYgYml0cyBub25jZXMgc3Rp bGwgYWxsb3dzwqAgYW4gSVRSIHRvIA0KPiBkZXRlcm1pbmUgdG8gYW5kIGZyb20gcmVhY2hhYmls aXR5IGZvciB1cCB0byA2NGsgUkxPQ3MgYXQgdGhlIHNhbWUgdGltZS4NCj4NCj4gU2ltaWxhcmx5 LCB0aGUgZW5jb2Rpbmcgb2YgdGhlIFNvdXJjZSBhbmQgRGVzdCBNYXAtVmVyc2lvbiBmaWVsZHMs IA0KPiBjb21wYXJlZCB3aXRoIFJGQzY4MzBiaXMsIGlzIHJlZHVjZWQgZnJvbSAxMiB0byA4IGJp dHMuIFRoaXMgc3RpbGwgDQo+IGFsbG93cyB0byBhc3NvY2lhdGUgMjU2IGRpZmZlcmVudCB2ZXJz aW9ucyB0byBlYWNoIEVJRC10by1STE9DIG1hcHBpbmcgDQo+IHRvIGluZm9ybSBjb21tbXVuaWNh dGluZyBJVFJzIGFuZCBFVFJzIGFib3V0IG1vZGlmaWNhdGlvbnMgb2YgdGhlIA0KPiBtYXBwaW5n Lg0KPg0KDQoNCkVpdGhlciBEZWJvcmFoLCBKb2VsLCBvciBMdWlnaTogaWYgeW91IGNvdWxkIHBs ZWFzZSBjb25maXJtIHRoYXQgaXQgaXMgb2sgdG8gcHVibGlzaCBhIG5ldyB2ZXJzaW9uIG9mIHRo ZSBkcmFmdCBhdCB0aGlzIHBvaW50LCBJJ2xsIHVwZGF0ZSBpdCByaWdodCBhd2F5Lg0KDQpUaGFu a3MsDQpGYWJpbw0KDQoNCg0KDQpPbiA4LzkvMTggOTowNSBBTSwgQWRyaWFuIEZhcnJlbCB3cm90 ZToNCj4gUmV2aWV3ZXI6IEFkcmlhbiBGYXJyZWwNCj4gUmV2aWV3IHJlc3VsdDogSGFzIElzc3Vl cw0KPg0KPiBIZWxsbywNCj4NCj4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcg RGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgDQo+IGRyYWZ0LiBUaGUgUm91dGluZyBEaXJl Y3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3IgDQo+IHJvdXRpbmctcmVsYXRl ZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgDQo+ IHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9m IHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4N Cj4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBs ZWFzZSBzZWUgDQo+ID9odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cC0zQV9fdHJhYy50b29scy5pZXRmLm8NCj4gcmdfYXJlYV9ydGdfdHJhY193aWtpX1J0Z0Rp ciZkPUR3SURhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj02VWhHcA0KPiBXOWx3aTlkTTdq WWx4WEQ4dyZtPVBrV2RlNnp1LWtFOWd6R1FzYy05cFlMd2RjUnJqSWEyNDI1UTRBSkEtZmcmcz1f OEFuDQo+IFNCZzBaQk5VLW4ydXo5a0xqVDZWd1NUWEh5cy1oXzU0YXl2ejlQQSZlPQ0KPg0KPiBB bHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBS b3V0aW5nIEFEcywgDQo+IGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVy IHRoZW0gYXMgbm9ybWFsIHJldmlldyANCj4gY29tbWVudHMuIEkgYmVsaWV2ZSB0aGF0IHRoaXMg cmV2aWV3IGNvbWVzIGJldHdlZW4gV0cgcHVibGljYXRpb24gYW5kIA0KPiB0aGUgc3RhcnQgb2Yg SUVURiBsYXN0IGNhbGwgLSB5b3UgbWF5IHdpc2ggdG8gZGlzY3VzcyB3aXRoIHlvdXIgQUQgDQo+ IHdoZXRoZXIgdG8gdHJlYXQgdGhlc2UgY29tbWVudHMgc2VwYXJhdGVseSBvciBhcyBwYXJ0IG9m IElFVEYgbGFzdCBjYWxsLg0KPg0KPiBEb2N1bWVudDogZHJhZnQtaWV0Zi1saXNwLWdwZS0wNC50 eHQNCj4gICBSZXZpZXdlcjogQWRyaWFuIEZhcnJlbA0KPiAgIFJldmlldyBEYXRlOiA5LUF1Z3Vz dC0yMDE4DQo+ICAgSUVURiBMQyBFbmQgRGF0ZTogTm8ga25vd24NCj4gICBJbnRlbmRlZCBTdGF0 dXM6IFN0YW5kYXJkcyBUcmFjaw0KPg0KPiBTdW1tYXJ5DQo+IEkgaGF2ZSBzaWduaWZpY2FudCBj b25jZXJucyBhYm91dCB0aGlzIGRvY3VtZW50IGFuZCByZWNvbW1lbmQgdGhhdCB0aGUgDQo+IFJv dXRpbmcgQURzIGRpc2N1c3MgdGhlc2UgaXNzdWVzIGZ1cnRoZXIgd2l0aCB0aGUgYXV0aG9ycy4g VGhlIGlzc3VlcyANCj4gYXJlIG5vdCBzdWJzdGFudGlhbGx5IHRlY2huaWNhbCBpbiBuYXR1cmUs IGJ1dCBkbyBpbmRpY2F0ZSB0aGUgbmVlZCANCj4gZm9yIHNpZ25pZmljYW50IHJld29ya2luZyBv ZiB0aGUgdGV4dC4gSSBoYXZlIHRyaWVkIHRvIG1ha2Ugc3VnZ2VzdGlvbnMgZm9yIG5ldyB0ZXh0 Lg0KPg0KPiBDb21tZW50czoNCj4NCj4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gYWx0ZXJu YXRlIExJU1AgaGVhZGVyIGZvcm1hdCB0aGF0IGNhbiBiZSANCj4gdXNlZCB0byBhbGxvdyBMSVNQ IHRvIGNhcnJ5IHBheWxvYWRzIG90aGVyIHRoYW4gSVAuIEEgbmV3IGNhcGFiaWxpdGllcyANCj4g ZmxhZyBpcyBkZWZpbmVkIHNvIHRoYXQgcm91dGVycyBrbm93IHdoZXRoZXIgdGhpcyBuZXcgZm9y bWF0IGlzIA0KPiBzdXBwb3J0ZWQsIGFuZCBhIG5ldyBmbGFnIGluIHRoZSBoZWFkZXIgaXRzZWxm IGluZGljYXRlcyB3aGVuIHRoZSBuZXcgZm9ybWF0IGlzIGluIHVzZS4NCj4NCj4gVGhlIGRvY3Vt ZW50IGlzIGNsZWFyIGFuZCByZWFkYWJsZSwgYnV0IGhhcyBzb21lIGlzc3VlcyBvZiANCj4gcHJl c2VudGF0aW9uIHRoYXQgY291bGQgY2xvc2UgYSBmZXcgcG90ZW50aWFsIG1pc3VuZGVyc3RhbmRp bmdzIGFuZCANCj4gdGh1cyBpbXByb3ZlIGltcGxtZW50YXRpb24gcHJvc3BlY3RzLg0KPg0KPiBO byBhdHRlbXB0IGlzIG1hZGUgaW4gdGhlIGRvY3VtZW50IHRvIGV4cGxhaW4gaG93L3doeSB0aGUg cmVkdWN0aW9uIGluIA0KPiBzaXplIG9mIHNvbWUgc3RhbmRhcmQgTElTUCBoZWFkZXIgZmllbGRz IGlzIGFjY2VwdGFibGUuIEZvciBleGFtcGxlLCANCj4gaWYgaW1wbGVtZW50YXRpb25zIG9mIHRo aXMgc3BlYyBjYW4gc2FmZWx5IG9wZXJhdGUgd2l0aCBhIDE2IGJpdCBOb25jZSANCj4gb3IgOCBi aXQgTWFwLVZlcnNpb25zLCB3aHkgZG9lcyA2ODMwLzY4MzBiaXMgZmVlbCB0aGUgbmVlZCBmb3Ig MjQgYW5kIDEyIGJpdCBmaWVsZHMgcnNwZWN0aXZlbHk/DQo+DQo+ID09PU1ham9yIElzc3Vlcz09 PQ0KPg0KPiBTZWN0aW9uIDMgaGFzIGEgbWl4IG9mIG1pbm9yIGFuZCBsZWVzcyBtaW5vciBpc3N1 ZXMuLi4NCj4NCj4gT0xEDQo+ICAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGZvbGxvd2lu ZyBjaGFuZ2VzIHRvIHRoZSBMSVNQIGhlYWRlciBpbg0KPiAgICAgb3JkZXIgdG8gc3VwcG9ydCBt dWx0aS1wcm90b2NvbCBlbmNhcHN1bGF0aW9uOg0KPg0KPiAgICAgUCBCaXQ6ICBGbGFnIGJpdCA1 IGlzIGRlZmluZWQgYXMgdGhlIE5leHQgUHJvdG9jb2wgYml0LiAgVGhlIFAgYml0DQo+ICAgICAg ICBNVVNUIGJlIHNldCB0byAxIHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiB0aGUgOCBiaXQg bmV4dA0KPiAgICAgICAgcHJvdG9jb2wgZmllbGQuDQo+DQo+ICAgICAgICBQID0gMCBpbmRpY2F0 ZXMgdGhhdCB0aGUgcGF5bG9hZCBNVVNUIGNvbmZvcm0gdG8gTElTUCBhcyBkZWZpbmVkDQo+ICAg ICAgICBpbiBbSS1ELmlldGYtbGlzcC1yZmM2ODMwYmlzXS4gIEZsYWcgYml0IDUgd2FzIGNob3Nl biBhcyB0aGUgUCBiaXQNCj4gICAgICAgIGJlY2F1c2UgdGhpcyBmbGFnIGJpdCBpcyBjdXJyZW50 bHkgdW5hbGxvY2F0ZWQuDQo+DQo+ICAgICBOZXh0IFByb3RvY29sOiAgVGhlIGxvd2VyIDggYml0 cyBvZiB0aGUgZmlyc3QgMzItYml0IHdvcmQgYXJlIHVzZWQgdG8NCj4gICAgICAgIGNhcnJ5IGEg TmV4dCBQcm90b2NvbC4gIFRoaXMgTmV4dCBQcm90b2NvbCBmaWVsZCBjb250YWlucyB0aGUNCj4g ICAgICAgIHByb3RvY29sIG9mIHRoZSBlbmNhcHN1bGF0ZWQgcGF5bG9hZCBwYWNrZXQuDQo+DQo+ ICAgICAgICBMSVNQIHVzZXMgdGhlIGxvd2VyIDI0IGJpdHMgb2YgdGhlIGZpcnN0IHdvcmQgZm9y IGVpdGhlciBhIG5vbmNlLA0KPiAgICAgICAgYW4gZWNoby1ub25jZSwgb3IgdG8gc3VwcG9ydCBt YXAtdmVyc2lvbmluZw0KPiAgICAgICAgW0ktRC5pZXRmLWxpc3AtNjgzNGJpc10uICBUaGVzZSBh cmUgYWxsIG9wdGlvbmFsIGNhcGFiaWxpdGllcyB0aGF0DQo+ICAgICAgICBhcmUgaW5kaWNhdGVk IGluIHRoZSBMSVNQIGhlYWRlciBieSBzZXR0aW5nIHRoZSBOLCBFLCBhbmQgdGhlIFYNCj4gICAg ICAgIGJpdCByZXNwZWN0aXZlbHkuDQo+DQo+ICAgICAgICBXaGVuIHRoZSBQLWJpdCBhbmQgdGhl IE4tYml0IGFyZSBzZXQgdG8gMSwgdGhlIE5vbmNlIGZpZWxkIGlzIHRoZQ0KPiAgICAgICAgbWlk ZGxlIDE2IGJpdHMuDQo+DQo+ICAgICAgICBXaGVuIHRoZSBQLWJpdCBhbmQgdGhlIFYtYml0IGFy ZSBzZXQgdG8gMSwgdGhlIFZlcnNpb24gZmllbGQgaXMNCj4gICAgICAgIHRoZSBtaWRkbGUgMTYg Yml0cy4NCj4NCj4gICAgICAgIFdoZW4gdGhlIFAtYml0IGlzIHNldCB0byAxIGFuZCB0aGUgTi1i aXQgYW5kIHRoZSBWLWJpdCBhcmUgYm90aCAwLA0KPiAgICAgICAgdGhlIG1pZGRsZSAxNi1iaXRz IGFyZSBzZXQgdG8gMC4NCj4NCj4gICAgICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgZm9s bG93aW5nIE5leHQgUHJvdG9jb2wgdmFsdWVzOg0KPg0KPiAgICAgICAgMHgxIDogIElQdjQNCj4N Cj4gICAgICAgIDB4MiA6ICBJUHY2DQo+DQo+ICAgICAgICAweDMgOiAgRXRoZXJuZXQNCj4NCj4g ICAgICAgIDB4NCA6ICBOZXR3b3JrIFNlcnZpY2UgSGVhZGVyIFtSRkM4MzAwXQ0KPg0KPiAgICAg ICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAg ICAgICAgICAzDQo+ICAgICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiAgICAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgICAg ICAgfE58THxFfFZ8SXxQfEt8S3wgICAgICAgIE5vbmNlL01hcC1WZXJzaW9uICAgICAgfCBOZXh0 IFByb3RvY29sIHwNCj4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAgIHwgICAgICAgICAgICAg ICAgIEluc3RhbmNlIElEL0xvY2F0b3ItU3RhdHVzLUJpdHMgICAgICAgICAgICAgICB8DQo+ICAg ICAgICAgDQo+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBM SVNQLUdQRSBIZWFkZXINCj4NCj4gTk9URVMNCj4gICAgIC0gSXQgd291bGQgYmUgaGVscGZ1bCB0 byBwdXQgdGhlIGZpZ3VyZSBoaWdoZXIgdXANCj4gICAgIC0gVGhlIHVzZSBvZiAiTVVTVCIgZm9y IHRoZSBQLWJpdCBpcyBhdHRlbnVhdGVkIHdyb25nbHkNCj4gICAgIC0gTmVlZCB0byBiZSBjb25z aXN0ZW50IG9uICJQIEJpdCIgb3IgIlAtYml0IiBvciAiUCBiaXQiDQo+ICAgICAtIFRoZXJlIGxv b2tzIHRvIGJlIGEgcHJvYmxlbSBpbiB0aGUgY2FzZSBvZiBtYXAgdmVyc2lvbi4gVGhlIGJhc2UN Cj4gICAgICAgc3BlYyBoYXMgMTIgYml0cyBlYWNoIGZvciBzb3VyY2UgYW5kIGRlc3QgbWFwLXZl cnNpb24sIHNvIHRoaXMgZG9jDQo+ICAgICAgIG5lZWRzIHRvIGRlc2NyaWJlIGhvdyB0aGUgcmVl ZHVjZWQgMTYgYml0cyBpcyBzcGxpdCAocHJlc3VtYWJseSBub3QNCj4gICAgICAgMTIgYW5kIDQp Lg0KPiAgICAgLSBZb3UgbmVlZCBhIHBvaW50ZXIgdG8gdGhlIElBTkEgcmVnaXN0cnkgZm9yIG5l eHQgcHJvdG9jb2wgTkVXDQo+ICAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdHdvIGNoYW5nZXMg dG8gdGhlIExJU1AgaGVhZGVyIGluIG9yZGVyIHRvDQo+ICAgICBzdXBwb3J0IG11bHRpLXByb3Rv Y29sIGVuY2Fwc3VsYXRpb246IHRoZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIFAtYml0DQo+ICAgICBh bmQgdGhlIGRlZmluaXRpb24gb2YgYSBOZXh0IFByb3RvY29sIGZpZWxkLiAgVGhpcyBpcyBzaG93 biBpbg0KPiAgICAgRmlndXJlIDEgYW5kIGRlc2NyaWJlZCBiZWxvdy4NCj4NCj4gICAgICAgICAg MCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAg ICAgMw0KPiAgICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAgIHxO fEx8RXxWfEl8UHxLfEt8ICAgICAgICBOb25jZS9NYXAtVmVyc2lvbiAgICAgIHwgTmV4dCBQcm90 b2NvbCB8DQo+ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgICAgICB8ICAgICAgICAgICAgICAgICBJ bnN0YW5jZSBJRC9Mb2NhdG9yLVN0YXR1cy1CaXRzICAgICAgICAgICAgICAgfA0KPiAgICAgICAg IA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxIDog VGhlIExJU1AtR1BFIEhlYWRlcg0KPg0KPiAgICAgUC1CaXQ6ICBGbGFnIGJpdCA1IGlzIGRlZmlu ZWQgYXMgdGhlIE5leHQgUHJvdG9jb2wgYml0Lg0KPg0KPiAgICAgICAgSWYgdGhlIFAtYml0IGlz IGNsZWFyICgwKSB0aGUgTElTUCBoZWFkZXIgY29uZm9ybXMgdG8gdGhlDQo+ICAgICAgICBkZWZp bml0aW9uIGluIFtJLUQuaWV0Zi1saXNwLXJmYzY4MzBiaXNdLg0KPg0KPiAgICAgICAgVGhlIFAt Yml0IGlzIHNldCB0byAxIHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiB0aGUgOCBiaXQgTmV4 dA0KPiAgICAgICAgUHJvdG9jb2wgZmllbGQuDQo+DQo+ICAgICBOZXh0IFByb3RvY29sOiAgVGhl IGxvd2VyIDggYml0cyBvZiB0aGUgZmlyc3QgMzItYml0IHdvcmQgYXJlIHVzZWQgdG8NCj4gICAg ICAgIGNhcnJ5IGEgTmV4dCBQcm90b2NvbC4gIFRoaXMgTmV4dCBQcm90b2NvbCBmaWVsZCBjb250 YWlucyB0aGUNCj4gICAgICAgIHByb3RvY29sIG9mIHRoZSBlbmNhcHN1bGF0ZWQgcGF5bG9hZCBw YWNrZXQuDQo+DQo+ICAgICAgICBJbiBbSS1ELmlldGYtbGlzcC02ODM0YmlzXSwgTElTUCB1c2Vz IHRoZSBsb3dlciAyNCBiaXRzIG9mIHRoZQ0KPiAgICAgICAgZmlyc3Qgd29yZCBmb3IgYSBub25j ZSwgYW4gZWNoby1ub25jZSwgb3IgdG8gc3VwcG9ydCBtYXAtDQo+ICAgICAgICB2ZXJzaW9uaW5n LiAgVGhlc2UgYXJlIGFsbCBvcHRpb25hbCBjYXBhYmlsaXRpZXMgdGhhdCBhcmUNCj4gICAgICAg IGluZGljYXRlZCBpbiB0aGUgTElTUCBoZWFkZXIgYnkgc2V0dGluZyB0aGUgTiwgRSwgYW5kIFYg Yml0cw0KPiAgICAgICAgcmVzcGVjdGl2ZWx5Lg0KPg0KPiAgICAgICAgV2hlbiB0aGUgUC1iaXQg YW5kIHRoZSBOLWJpdCBhcmUgc2V0IHRvIDEsIHRoZSBOb25jZSBmaWVsZCBpcyB0aGUNCj4gICAg ICAgIG1pZGRsZSAxNiBiaXRzIChpLmUuLCBlbmNvZGVkIGluIDE2IGJpdHMsIG5vdCAyNCBiaXRz KS4gIE5vdGUgdGhhdA0KPiAgICAgICAgdGhlIEUtYml0IG9ubHkgaGFzIG1lYW5pbmcgd2hlbiB0 aGUgTi1iaXQgaXMgc2V0Lg0KPg0KPiAgICAgICAgV2hlbiB0aGUgUC1iaXQgYW5kIHRoZSBWLWJp dCBhcmUgc2V0IHRvIDEsIHRoZSBWZXJzaW9uIGZpZWxkcyB1c2UNCj4gICAgICAgIHRoZSBtaWRk bGUgMTYgYml0czogdGhlIFNvdXJjZSBNYXAtVmVyc2lvbiB1c2VzIHRoZSBoaWdoLW9yZGVyIDgN Cj4gICAgICAgIGJpdHMsIGFuZCB0aGUgRGVzdCBNYXAtVmVyc2lvbiB1c2VzIHRoZSBsb3ctb3Jk ZXIgOCBiaXRzLg0KPg0KPiAgICAgICAgV2hlbiB0aGUgUC1iaXQgaXMgc2V0IHRvIDEgYW5kIHRo ZSBOLWJpdCBhbmQgdGhlIFYtYml0IGFyZSBib3RoIDAsDQo+ICAgICAgICB0aGUgbWlkZGxlIDE2 LWJpdHMgTVVTVCBiZSBzZXQgdG8gMCBvbiB0cmFuc21pc3Npb24gYW5kIGlnbm9yZWQgb24NCj4g ICAgICAgIHJlY2VpcHQuDQo+DQo+ICAgICAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGZv bGxvd2luZyBOZXh0IFByb3RvY29sIHZhbHVlczoNCj4NCj4gICAgICAgIDB4MSA6ICBJUHY0DQo+ DQo+ICAgICAgICAweDIgOiAgSVB2Ng0KPg0KPiAgICAgICAgMHgzIDogIEV0aGVybmV0DQo+DQo+ ICAgICAgICAweDQgOiAgTmV0d29yayBTZXJ2aWNlIEhlYWRlciBbUkZDODMwMF0NCj4NCj4gICAg ICAgIFRoZSB2YWx1ZXMgYXJlIHRyYWNrZWQgaW4gYW4gSUFOQSByZWdpc3RyeSBhcyBkZXNjcmli ZWQgaW4gU2VjdGlvbg0KPiAgICAgICAgNS4NCj4NCj4gLS0tDQo+DQo+IFNlY3Rpb24gNCBtdXN0 IGRlc2NyaWJlIHRoZSBlcnJvciBjYXNlIHdoZW4gYSBMSVNQLUdQRSBjYXBhYmxlIHJvdXRlciAN Cj4gc2V0cyB0aGUgUC1iaXQgb24gYSBwYWNrZXQgdG8gYSBub24gTElTUC1HUEUgY2FwYWJsZSBy b3V0ZXIuIFNvLi4uDQo+DQo+IE9MRA0KPiAgICAgV2hlbiBlbmNhcHN1bGF0aW5nIElQIHBhY2tl dHMgdG8gYSBub24gTElTUC1HUEUgY2FwYWJsZSByb3V0ZXIgdGhlIFANCj4gICAgIGJpdCBNVVNU IGJlIHNldCB0byAwLg0KPiBORVcNCj4gICAgIFdoZW4gZW5jYXBzdWxhdGluZyBJUCBwYWNrZXRz IHRvIGEgbm9uIExJU1AtR1BFIGNhcGFibGUgcm91dGVyIHRoZSBQLQ0KPiAgICAgYml0IE1VU1Qg YmUgc2V0IHRvIDAuICBUaGF0IGlzLCB0aGUgZW5jYXBzdWxhdGlvbiBmb3JtYXQgZGVmaW5lZCBp bg0KPiAgICAgdGhpcyBkb2N1bWVudCBNVVNUIE5PVCBiZSBzZW50IHRvIGEgcm91dGVyIHRoYXQg aGFzIG5vdCBpbmRpY2F0ZWQNCj4gICAgIHRoYXQgaXQgc3VwcG9ydHMgdGhpcyBzcGVjaWZpY2F0 aW9uIGJlY2F1c2Ugc3VjaCBhIHJvdXRlciB3b3VsZA0KPiAgICAgaWdub3JlIHRoZSBQLWJpdCAo YXMgZGVzY3JpYmVkIGluIFtJLUQuaWV0Zi1saXNwLXJmYzY4MzBiaXNdKSBhbmQgc28NCj4gICAg IHdvdWxkIG1pc2ludGVycHJldCB0aGUgb3RoZXIgTElTUCBoZWFkZXIgZmllbGRzIHBvc3NpYmx5 IGNhdXNpbmcNCj4gICAgIHNpZ25pZmljYW50IGVycm9ycy4NCj4gRU5EDQo+DQo+IC0tLQ0KPg0K PiA0LjENCj4NCj4gTm90IHlvdXIgZmF1bHQgdGhhdCBSRkMgODA2MCBkb2Vzbid0IGhhdmUgYSBy ZWdpc3RyeSBmb3IgYml0cyBpbiB0aGUgDQo+IExDQUYsIGJ1dCBub3cgeW91IHJlYWxseSBuZWVk IG9uZSBvciBlbHNlIGZ1dHVyZSBvcnRob2dvbmFsIHNwZWNzIHJpc2sgDQo+IGNvbGxpZGluZyB3 aXRoIHRoZSBnLWJpdC4gIEEgYml0IG9kZCB0byBhZGQgdGhpcyBpbiB0aGlzIGRvY3VtZW50LCBi dXQgDQo+IG5vdCB3b3J0aCBhIGJpcyBvbiA4MDYwLg0KPg0KPiA9PT1NaW5vciBJc3N1ZXMgPT09 DQo+DQo+IFNlY3Rpb24gMg0KPg0KPiBPTEQNCj4gICAgIFRoZSBMSVNQIGhlYWRlciBbSS1ELmll dGYtbGlzcC1yZmM2ODMwYmlzXSBjb250YWlucyBhIHNlcmllcyBvZiBmbGFncw0KPiAgICAgKHNv bWUgZGVmaW5lZCwgc29tZSByZXNlcnZlZCksIGEgTm9uY2UvTWFwLXZlcnNpb24gZmllbGQgYW5k IGFuDQo+ICAgICBpbnN0YW5jZSBJRC9Mb2NhdG9yLXN0YXR1cy1iaXQgZmllbGQuICBUaGUgZmxh Z3MgcHJvdmlkZSBmbGV4aWJpbGl0eQ0KPiAgICAgdG8gZGVmaW5lIGhvdyB0aGUgdmFyaW91cyBm aWVsZHMgYXJlIGVuY29kZWQuICBOb3RhYmx5LCBGbGFnIGJpdCA1IGlzDQo+ICAgICB0aGUgbGFz dCByZXNlcnZlZCBiaXQgaW4gdGhlIExJU1AgaGVhZGVyLg0KPg0KPiAgICAgICAgICAwICAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+ ICAgICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMQ0KPiAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgICAgICAgfE58THxFfFZ8 SXxSfEt8S3wgICAgICAgICAgICBOb25jZS9NYXAtVmVyc2lvbiAgICAgICAgICAgICAgICAgIHwN Cj4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAgIHwgICAgICAgICAgICAgICAgIEluc3RhbmNl IElEL0xvY2F0b3ItU3RhdHVzLUJpdHMgICAgICAgICAgICAgICB8DQo+ICAgICAgICAgDQo+ICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExJU1AgSGVhZGVy IE5PVEVTDQo+ICAgICBXZSBuZWVkIHRvIGJlIGNhcmVmdWwgbm90IHRvIHJpc2sgYW55IGNvbmZ1 c2lvbi4gQXQgbGVhc3QsICJzb21lDQo+ICAgICByZXNlcnZlZCIgaXMgYW4gb3Zlci1zdGF0ZW1l bnQuIEJ1dCBhbHNvIHdlIHNob3VsZCBub3Qgc2hvdyBhIHJlcGVhdA0KPiAgICAgb2YgdGhlIExp c3AgaGVhZGVyIGFzIHRoYXQgY2F1c2VzIGEgZHVwbGljYXRlIGRlZmluaXRpb24uDQo+IE5FVw0K PiAgICAgVGhlIExJU1AgaGVhZGVyIGlzIGRlZmluZWQgaW4gW0ktRC5pZXRmLWxpc3AtcmZjNjgz MGJpc10gYW5kIGNvbnRhaW5zDQo+ICAgICBhIHNlcmllcyBvZiBmbGFncyBvZiB3aGljaCBvbmUg KGJpdCA1KSBpcyBzaG93biBpbiB0aGF0IGRvY3VtZW50IGFzDQo+ICAgICAicmVzZXJ2ZWQgZm9y IGZ1dHVyZSB1c2UiLiAgVGhlIHNldHRpbmcgb2YgdGhlIGZsYWcgZmllbGRzIGRlZmluZWQNCj4g ICAgIGhvdyB0aGUgc3Vic2VxdWVudCBoZWFkZXIgZmllbGRzIGFyZSBpbnRlcnByZXR0ZWQuDQo+ IEVORA0KPg0KPiAtLS0NCj4NCj4gNC4xDQo+IEkgZG9uJ3QgdGhpbmsgeW91IHNob3VsZCByZXBy b2R1Y2UgdGhlIE11bHRpcGxlIERhdGEtUGxhbmVzIExDQUYgVHlwZSANCj4gZmlndWUgZnJvbSA4 MDYwIGhlcmUgYXMgaXQgY3JlYXRlcyBhIGR1cGxpY2F0ZSBkZWZpbml0aW9uLiAgVGhlIHRleHQg DQo+IGV4cGxhbmF0aW9uIG9mIHdoaWNoIGJpdCBpcyB0aGUgZy1iaXQgc2hvbGQgYmUgZW5vdWdo Lg0KPg0KPiA9PT1OaXRzPT09DQo+DQo+IEFic3RyYWN0DQo+IE9MRA0KPiAgICAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgZXh0ZW5kaW5nIHRoZSBMb2NhdG9yL0lEIFNlcGFyYXRpb24gUHJvdG9j b2wNCj4gICAgIChMSVNQKSBEYXRhLVBsYW5lLCB2aWEgY2hhbmdlcyB0byB0aGUgTElTUCBoZWFk ZXIsIHRvIHN1cHBvcnQgbXVsdGktDQo+ICAgICBwcm90b2NvbCBlbmNhcHN1bGF0aW9uLg0KPiBO RVcNCj4gICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGV4dGVudGlvbnMgdG8gdGhlIExvY2F0 b3IvSUQgU2VwYXJhdGlvbg0KPiAgICAgUHJvdG9jb2wgKExJU1ApIERhdGEtUGxhbmUsIHZpYSBj aGFuZ2VzIHRvIHRoZSBMSVNQIGhlYWRlciwgdG8NCj4gICAgIHN1cHBvcnQgbXVsdGktcHJvdG9j b2wgZW5jYXBzdWxhdGlvbi4NCj4gRU5EDQo+DQo+IC0tLQ0KPg0KPiAxLg0KPiBPTEQNCj4gICAg IExJU1AgRGF0YS1QbGFuZSwgYXMgZGVmaW5lZCBpbiBpbiBbSS1ELmlldGYtbGlzcC1yZmM2ODMw YmlzXSwgZGVmaW5lcw0KPiAgICAgYW4gZW5jYXBzdWxhdGlvbiBmb3JtYXQgdGhhdCBjYXJyaWVz IElQdjQgb3IgSVB2NiAoaGVuY2Vmb3J0aA0KPiAgICAgcmVmZXJyZWQgdG8gYXMgSVApIHBhY2tl dHMgaW4gYSBMSVNQIGhlYWRlciBhbmQgb3V0ZXIgVURQL0lQDQo+ICAgICB0cmFuc3BvcnQuDQo+ IE5FVw0KPiAgICAgVGhlIExJU1AgRGF0YS1QbGFuZSBpcyBkZWZpbmVkIGluIFtJLUQuaWV0Zi1s aXNwLXJmYzY4MzBiaXNdLiAgSXQNCj4gICAgIHNwZWNpZmllcyBhbiBlbmNhcHN1bGF0aW9uIGZv cm1hdCB0aGF0IGNhcnJpZXMgSVB2NCBvciBJUHY2IHBhY2tldHMNCj4gICAgIChoZW5jZWZvcnRo IGpvaW50bHkgcmVmZXJyZWQgdG8gYXMgSVApIGluIGEgTElTUCBoZWFkZXIgYW5kIG91dGVyDQo+ ICAgICBVRFAvSVAgdHJhbnNwb3J0Lg0KPg0KPiAtLS0NCj4NCj4gMS4xDQo+IFBsZWFzZSB1c2Ug dGhlIG5ldyBib2lsZXJwbGF0ZS4uLg0KPiAgICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNU IE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KPiAgICAgIlNIT1VMRCIs ICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk5PVCBSRUNPTU1FTkRFRCIsICJNQVkiLCBh bmQNCj4gICAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0 ZWQgYXMgZGVzY3JpYmVkIGluIEJDUA0KPiAgICAgMTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVu LCBhbmQgb25seSB3aGVuLCB0aGV5IGFwcGVhciBpbiBhbGwNCj4gICAgIGNhcGl0YWxzLCBhcyBz aG93biBoZXJlLg0KPg0KPiAtLS0NCj4NCj4gMS4yDQo+IE5vdGh3aXRoc3RhbmRpbmcgdGhlIHRl eHQgaW4gdGhpcyBzZWN0aW9uLCBhYmJyZXZpYXRpb25zIG5lZWQgdG8gYmUgDQo+IGV4cGFuZGVk IGVpdGhlciBvbiBmaXJzdCB1c2Ugb3IgaW4gdGhpcyBzZWN0aW9uLg0KPiBJIHNlZToNCj4gLSBM Q0FGDQo+IC0gRVRSDQo+IC0gSVRSDQo+IC0gUkxPQw0KPiAtIHhUUg0KPg0KPiAtLS0NCj4NCj4g Mi4NCj4gcy9BcyBkZXNjcmliZWQgaW4gdGhlIGludHJvZHVjdGlvbi9BcyBkZXNjcmliZWQgaW4g U2VjdGlvbiAxLyBzL0xJU1AgDQo+IGlzIGxpbWl0ZWQgdG8gY2FycnkgSVAgcGF5bG9hZHMvTElT UCBpcyBsaW1pdGVkIHRvIGNhcnJ5aW5nIElQIA0KPiBwYXlsb2Fkcy8NCj4NCj4gLS0tDQo+DQo+ IDQuMQ0KPiBzL2ZpZWxkIGFzIGcgYml0L2ZpZWxkIGFzIHRoZSBnLWJpdC8NCj4NCj4gLS0tDQo+ DQo+IDguMQ0KPiBQbGVhc2UgYWRkIFJGQyA4MTc0DQo+DQoNCg== From nobody Wed Aug 15 22: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 02477130DC8; Wed, 15 Aug 2018 22:13:53 -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: <153439643296.3170.11475292725627185967@ietfa.amsl.com> Date: Wed, 15 Aug 2018 22:13:53 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-gpe-05.txt 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: Thu, 16 Aug 2018 05:13:53 -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-05.txt Pages : 10 Date : 2018-08-15 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-gpe-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-gpe-05 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 Aug 15 22:29: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 6D4BE131092; Wed, 15 Aug 2018 22:29:12 -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 SVanIP8GZW9e; Wed, 15 Aug 2018 22:29:08 -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 E581513108C; Wed, 15 Aug 2018 22:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14962; q=dns/txt; s=iport; t=1534397348; x=1535606948; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3Z1kB2TmbzRSWp4zN0E4vLYWfkiLHLv0ZSEf46mEcQw=; b=INgl2QMW0iCSbj08mnEeb3Jq9WnLyiK2At4NzpP49DzOdT7kix+lZrRp FxVBAXmlDm7Uf8xOGj87KX32cYrUpvctQ2+vLCv05YTOIHM1+/H9BmG/I oTBkKhSK+UUJhdzz5DSHx01AS8CQguYxi9NyfkWljoIJIWdDmxElkoc5x k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAADOCnVb/4QNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMgL2N/KINuiAqMNIFgLZYTgXoLI4EzAYMVAoM0ITQYAQI?= =?us-ascii?q?BAQIBAQJtHAyFNwEBAQQjFS8SDAQLEQMBAQEBAgIjAwICRgkIBwwGAgEBgx4?= =?us-ascii?q?BggEPqhyBLoQqAT2FeIELiAkXgUE/gRIngmuDEAsBAQOBNyeDAYJVAo1CMIx?= =?us-ascii?q?5CYYldYF+hj0GFYE6SINmglGFc4grgl2IGYFBOIFSMxoIGxWDJAkWggYXhS2?= =?us-ascii?q?DLIVeHzABFwEBi2GCSQEB?= X-IronPort-AV: E=Sophos;i="5.53,246,1531785600"; d="scan'208";a="436743100" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Aug 2018 05:29:06 +0000 Received: from [10.24.94.185] ([10.24.94.185]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTP id w7G5T4vS002116; Thu, 16 Aug 2018 05:29:05 GMT To: adrian@olddog.co.uk, rtg-dir@ietf.org Cc: lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org References: <153383075580.28970.16196543565444262922@ietfa.amsl.com> <1c15b23d-abe7-16c5-d7d8-88279b061441@cisco.com> <015201d434c6$05902a10$10b07e30$@olddog.co.uk> From: Fabio Maino Message-ID: <28017ff3-05e1-a59a-1f66-106d070b6856@cisco.com> Date: Wed, 15 Aug 2018 22:29:04 -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: <015201d434c6$05902a10$10b07e30$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Outbound-SMTP-Client: 10.24.94.185, [10.24.94.185] X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04 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: Thu, 16 Aug 2018 05:29:17 -0000 Hi Adrian, here is the updated draft that should address all your comments: https://tools.ietf.org/html/draft-ietf-lisp-gpe-05. Rfcdiff pointer: https://goo.gl/bMbRvC Please let me know if you have any other suggestion. Thanks again, Fabio On 8/15/18 11:30 AM, Adrian Farrel wrote: > Hi Fabio, > > That additional text is helpful, thanks. > > Adrian > >> -----Original Message----- >> From: Fabio Maino [mailto:fmaino@cisco.com] >> Sent: 15 August 2018 19:15 >> To: Adrian Farrel; rtg-dir@ietf.org >> Cc: lisp@ietf.org; ietf@ietf.org; draft-ietf-lisp-gpe.all@ietf.org >> Subject: Re: Rtgdir last call review of draft-ietf-lisp-gpe-04 >> >> Hi Adrian, >> thanks for such a detailed review. >> >> I went through your comments and I can incorporate all of them into a >> new version of the draft. >> >> Wrt the reduction in size of the Map-Versioning and Nonce fields, I >> could add in Section 3, right after the definition of the encoding of >> those fields, the following: >> >>> The encoding of the Nonce field in LISP-GPE, compared with the one >>> used in RFC6830bis for the LISP data plane encapsulation, reduces the >>> length of the nonce from 24 to 16 bits. As per RFC6830bis, ITRs are >>> required to generate different nonces when sending to different RLOCs, >>> but the same nonce can be used for a period of time when encapsulating >>> to the same 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. >>> >>> Similarly, the encoding of the Source and Dest Map-Version fields, >>> compared with RFC6830bis, is reduced from 12 to 8 bits. This still >>> allows to associate 256 different versions to each EID-to-RLOC mapping >>> to inform commmunicating ITRs and ETRs about modifications of the >>> mapping. >>> >> >> Either Deborah, Joel, or Luigi: if you could please confirm that it is >> ok to publish a new version of the draft at this point, I'll update it >> right away. >> >> Thanks, >> Fabio >> >> >> >> >> On 8/9/18 9:05 AM, Adrian Farrel wrote: >>> Reviewer: Adrian Farrel >>> Review result: Has Issues >>> >>> Hello, >>> >>> I have been selected as the Routing Directorate reviewer for this draft. 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 >>> ?http://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 as normal review comments. I believe >> that >>> this review comes between WG publication and the start of IETF last call - you >>> may wish to discuss with your AD whether to treat these comments separately >> or >>> as part of IETF last call. >>> >>> Document: draft-ietf-lisp-gpe-04.txt >>> Reviewer: Adrian Farrel >>> Review Date: 9-August-2018 >>> IETF LC End Date: No known >>> Intended Status: Standards Track >>> >>> Summary >>> I have significant concerns about this document and recommend that the >> Routing >>> ADs discuss these issues further with the authors. The issues are not >>> substantially technical in nature, but do indicate the need for significant >>> reworking of the text. I have tried to make suggestions for new text. >>> >>> Comments: >>> >>> This document specifies an alternate LISP header format that can be used to >>> allow LISP to carry payloads other than IP. A new capabilities flag is defined >>> so that routers know whether this new format is supported, and a new flag in >>> the header itself indicates when the new format is in use. >>> >>> The document is clear and readable, but has some issues of presentation that >>> could close a few potential misunderstandings and thus improve implmentation >>> prospects. >>> >>> No attempt is made in the document to explain how/why the reduction in size >> of >>> some standard LISP header fields is acceptable. For example, if >> implementations >>> of this spec can safely operate with a 16 bit Nonce or 8 bit Map-Versions, why >>> does 6830/6830bis feel the need for 24 and 12 bit fields rspectively? >>> >>> ===Major Issues=== >>> >>> Section 3 has a mix of minor and leess minor issues... >>> >>> OLD >>> This document defines the following changes to the LISP header in >>> order to support multi-protocol encapsulation: >>> >>> P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit >>> MUST be set to 1 to indicate the presence of the 8 bit next >>> protocol field. >>> >>> P = 0 indicates that the payload MUST conform to LISP as defined >>> in [I-D.ietf-lisp-rfc6830bis]. Flag bit 5 was chosen as the P bit >>> because this flag bit is currently unallocated. >>> >>> Next Protocol: The lower 8 bits of the first 32-bit word are used to >>> carry a Next Protocol. This Next Protocol field contains the >>> protocol of the encapsulated payload packet. >>> >>> LISP uses the lower 24 bits of the first word for either a nonce, >>> an echo-nonce, or to support map-versioning >>> [I-D.ietf-lisp-6834bis]. These are all optional capabilities that >>> are indicated in the LISP header by setting the N, E, and the V >>> bit respectively. >>> >>> When the P-bit and the N-bit are set to 1, the Nonce field is the >>> middle 16 bits. >>> >>> When the P-bit and the V-bit are set to 1, the Version field is >>> the middle 16 bits. >>> >>> When the P-bit is set to 1 and the N-bit and the V-bit are both 0, >>> the middle 16-bits are set to 0. >>> >>> This document defines the following Next Protocol values: >>> >>> 0x1 : IPv4 >>> >>> 0x2 : IPv6 >>> >>> 0x3 : Ethernet >>> >>> 0x4 : Network Service Header [RFC8300] >>> >>> 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 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |N|L|E|V|I|P|K|K| Nonce/Map-Version | Next Protocol | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Instance ID/Locator-Status-Bits | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> LISP-GPE Header >>> >>> NOTES >>> - It would be helpful to put the figure higher up >>> - The use of "MUST" for the P-bit is attenuated wrongly >>> - Need to be consistent on "P Bit" or "P-bit" or "P bit" >>> - There looks to be a problem in the case of map version. The base >>> spec has 12 bits each for source and dest map-version, so this doc >>> needs to describe how the reeduced 16 bits is split (presumably not >>> 12 and 4). >>> - You need a pointer to the IANA registry for next protocol >>> NEW >>> This document defines two changes to the LISP header in order to >>> support multi-protocol encapsulation: the introduction of the P-bit >>> and the definition of a Next Protocol field. This is shown in >>> Figure 1 and described below. >>> >>> 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 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |N|L|E|V|I|P|K|K| Nonce/Map-Version | Next Protocol | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Instance ID/Locator-Status-Bits | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Figure 1 : The LISP-GPE Header >>> >>> P-Bit: Flag bit 5 is defined as the Next Protocol bit. >>> >>> If the P-bit is clear (0) the LISP header conforms to the >>> definition in [I-D.ietf-lisp-rfc6830bis]. >>> >>> The P-bit is set to 1 to indicate the presence of the 8 bit Next >>> Protocol field. >>> >>> Next Protocol: The lower 8 bits of the first 32-bit word are used to >>> carry a Next Protocol. This Next Protocol field contains the >>> protocol of the encapsulated payload packet. >>> >>> In [I-D.ietf-lisp-6834bis], LISP uses the lower 24 bits of the >>> first word for a nonce, an echo-nonce, or to support map- >>> versioning. These are all optional capabilities that are >>> indicated in the LISP header by setting the N, E, and V bits >>> respectively. >>> >>> When the P-bit and the N-bit are set to 1, the Nonce field is the >>> middle 16 bits (i.e., encoded in 16 bits, not 24 bits). Note that >>> the E-bit only has meaning when the N-bit is set. >>> >>> When the P-bit and the V-bit are set to 1, the Version fields use >>> the middle 16 bits: the Source Map-Version uses the high-order 8 >>> bits, and the Dest Map-Version uses the low-order 8 bits. >>> >>> When the P-bit is set to 1 and the N-bit and the V-bit are both 0, >>> the middle 16-bits MUST be set to 0 on transmission and ignored on >>> receipt. >>> >>> This document defines the following Next Protocol values: >>> >>> 0x1 : IPv4 >>> >>> 0x2 : IPv6 >>> >>> 0x3 : Ethernet >>> >>> 0x4 : Network Service Header [RFC8300] >>> >>> The values are tracked in an IANA registry as described in Section >>> 5. >>> >>> --- >>> >>> Section 4 must describe the error case when a LISP-GPE capable router >>> sets the P-bit on a packet to a non LISP-GPE capable router. So... >>> >>> OLD >>> When encapsulating IP packets to a non LISP-GPE capable router the P >>> bit MUST be set to 0. >>> NEW >>> When encapsulating IP packets to a non LISP-GPE capable router the P- >>> bit MUST be set to 0. That is, the encapsulation format defined in >>> this document MUST NOT be sent to a router that has not indicated >>> that it supports this specification because such a router would >>> ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so >>> would misinterpret the other LISP header fields possibly causing >>> significant errors. >>> END >>> >>> --- >>> >>> 4.1 >>> >>> Not your fault that RFC 8060 doesn't have a registry for bits in the >>> LCAF, but now you really need one or else future orthogonal specs risk >>> colliding with the g-bit. A bit odd to add this in this document, but >>> not worth a bis on 8060. >>> >>> ===Minor Issues === >>> >>> Section 2 >>> >>> OLD >>> The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of flags >>> (some defined, some reserved), a Nonce/Map-version field and an >>> instance ID/Locator-status-bit field. The flags provide flexibility >>> to define how the various fields are encoded. Notably, Flag bit 5 is >>> the last reserved bit in the LISP header. >>> >>> 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 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |N|L|E|V|I|R|K|K| Nonce/Map-Version | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Instance ID/Locator-Status-Bits | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> LISP Header >>> NOTES >>> We need to be careful not to risk any confusion. At least, "some >>> reserved" is an over-statement. But also we should not show a repeat >>> of the Lisp header as that causes a duplicate definition. >>> NEW >>> The LISP header is defined in [I-D.ietf-lisp-rfc6830bis] and contains >>> a series of flags of which one (bit 5) is shown in that document as >>> "reserved for future use". The setting of the flag fields defined >>> how the subsequent header fields are interpretted. >>> END >>> >>> --- >>> >>> 4.1 >>> I don't think you should reproduce the Multiple Data-Planes LCAF Type >>> figue from 8060 here as it creates a duplicate definition. The text >>> explanation of which bit is the g-bit shold be enough. >>> >>> ===Nits=== >>> >>> Abstract >>> OLD >>> This document describes extending the Locator/ID Separation Protocol >>> (LISP) Data-Plane, via changes to the LISP header, to support multi- >>> protocol encapsulation. >>> NEW >>> This document describes extentions to the Locator/ID Separation >>> Protocol (LISP) Data-Plane, via changes to the LISP header, to >>> support multi-protocol encapsulation. >>> END >>> >>> --- >>> >>> 1. >>> OLD >>> LISP Data-Plane, as defined in in [I-D.ietf-lisp-rfc6830bis], defines >>> an encapsulation format that carries IPv4 or IPv6 (henceforth >>> referred to as IP) packets in a LISP header and outer UDP/IP >>> transport. >>> NEW >>> The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It >>> specifies an encapsulation format that carries IPv4 or IPv6 packets >>> (henceforth jointly referred to as IP) in a LISP header and outer >>> UDP/IP transport. >>> >>> --- >>> >>> 1.1 >>> Please use the new boilerplate... >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", >> "MAY", and >>> "OPTIONAL" in this document are to be interpreted as described in BCP >>> 14 [RFC2119] [RFC8174] when, and only when, they appear in all >>> capitals, as shown here. >>> >>> --- >>> >>> 1.2 >>> Nothwithstanding the text in this section, abbreviations need to be >>> expanded either on first use or in this section. >>> I see: >>> - LCAF >>> - ETR >>> - ITR >>> - RLOC >>> - xTR >>> >>> --- >>> >>> 2. >>> s/As described in the introduction/As described in Section 1/ >>> s/LISP is limited to carry IP payloads/LISP is limited to carrying IP payloads/ >>> >>> --- >>> >>> 4.1 >>> s/field as g bit/field as the g-bit/ >>> >>> --- >>> >>> 8.1 >>> Please add RFC 8174 >>> From nobody Fri Aug 17 05:37: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 1C93B128CB7; Fri, 17 Aug 2018 05:37:00 -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 4N8mt_08BZSc; Fri, 17 Aug 2018 05:36:58 -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 5965A127598; Fri, 17 Aug 2018 05:36:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4948C5E1240; Fri, 17 Aug 2018 05:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1534509418; bh=S9mxNpMZPd3lpASfRtPEBRQeekB86Hbcis5Ljytg2wA=; h=Subject:References:To:From:Date:In-Reply-To:From; b=n0F3T2CjELFAK9b+OywfsoMQ4otBerN8hBeWm2XpBBf7FsE3iC53c/7qWfUsYrOe6 WZt9ictRfVtyNIcSS6LtHcFpMOwSarT6+x+fph79VDJSYWxUEyXbso0aMlBlqXmd5u jnbvlus9KSCfaPuHhLjAkyqk7XsgRZzhNR8tSd+I= X-Virus-Scanned: Debian amavisd-new at maila2.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 maila2.tigertech.net (Postfix) with ESMTPSA id BB2F65E0EBF; Fri, 17 Aug 2018 05:36:57 -0700 (PDT) References: <153443912996.12204.13310672598806696421.idtracker@ietfa.amsl.com> To: "lisp@ietf.org" , "sfc@ietf.org" From: Joel Halpern X-Forwarded-Message-Id: <153443912996.12204.13310672598806696421.idtracker@ietfa.amsl.com> Message-ID: <9e17b073-ddc8-202e-193a-7b0d77c54699@joelhalpern.com> Date: Fri, 17 Aug 2018 08:36:56 -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: <153443912996.12204.13310672598806696421.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [lisp] Fwd: NomCom 2018: Call for nominations 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: Fri, 17 Aug 2018 12:37:00 -0000 The IETF nomcom is looking for nominees. Please consider running, and / or nominating suitable individuals. Thank you, Joel -------- Forwarded Message -------- Subject: NomCom 2018: Call for nominations Date: Thu, 16 Aug 2018 10:05:29 -0700 From: NomCom Chair 2018 Reply-To: ietf@ietf.org To: IETF Announcement List CC: ietf@ietf.org The 2018-19 Nominating Committee (NomCom) is seeking nominations from now until September 30, 2018. The open positions being considered by this year's NomCom can be found at the end of this email and also on this year's NomCom website: https://datatracker.ietf.org/nomcom/2018/ Nominations may be made by selecting the Nominate link at the top of the NomCom 2018 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2018/nominate/ Note: Nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ If you are unable to use the web form, nominations may instead be made by email to nomcom-18 at ietf dot org. If using email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you are nominating someone other than yourself, please tell us if we may tell the nominee that you were the one who made the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self-nomination is welcome! Willing nominees will be asked to fill out a questionnaire specific to the position for which they are nominated. The questionnaires will be available on August 31, 2018 and have a submission deadline of October 5, 2018. NomCom 2018-19 will follow the policy for "Open Disclosure of Willing Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way, e.g., anyone with a datatracker account may access the lists. Additionally, the nomination form asks if we may share your own name with the nominee. In all other ways, the confidentiality requirements of BCP 10 remain in effect. All feedback and all NomCom deliberations will remain confidential and will not be disclosed. There is a field on the form you can mark in order to allow the NomCom to tell the nominee that you were the one who made the nomination. This defaults to “no” - so if you don't mark the field we won’t tell. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the NomCom on or before September 30, 2018. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for management permission, as it is easier to decline the nomination than put one in late. The NomCom appoints individuals to fill the IETF Chair (IESG General AD) and the open slots on the IAB and the IESG. The IAOC position is not being filled this year, and the call for nominations related to the IETF LLC will be coming in the next few weeks. The list of people and posts whose terms end with the March 2019 IETF meeting, and thus the positions for which this NomCom is responsible, follows: IAB - Jari Arkko - Gabriel Montenegro - Mark Nottingham - Robert Sparks - Jeff Tantsura - Suzanne Woolf IESG Chair - Alissa Cooper, GEN (IETF Chair) IESG - Ben Campbell, ART - Terry Manderson, INT * - Warren Kumari, OPS - Deborah Brungard, RTG - Alvaro Retana, RTG - Eric Rescorla, SEC - Spencer Dawkins, TSV * *- have indicated that they do not intend to accept a renomination. This information is always up to date on https://datatracker.ietf.org/nomcom/2018/ Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, developed by the IAB and IESG under individual tabs at: https://datatracker.ietf.org/nomcom/2018/requirements/ In addition to nominations, the NomCom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom-18 at ietf dot org. Thank you for your help in identifying qualified nominees! regards, -scott. Scott Mansfield scott dot mansfield at ericsson dot com nomcom-chair-2018 at ietf dot org From nobody Fri Aug 17 08:17:53 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 C68B9130DD2; Fri, 17 Aug 2018 08:17:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk CC: lisp-chairs@ietf.org, lisp@ietf.org, db3546@att.com, Luigi Iannone , ggx@gigix.net, draft-ietf-lisp-rfc6833bis@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153451906473.18078.3298934607001431350.idtracker@ietfa.amsl.com> Date: Fri, 17 Aug 2018 08:17:44 -0700 Archived-At: Subject: [lisp] Last Call: (Locator/ID Separation Protocol (LISP) Control-Plane) to Proposed Standard 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: Fri, 17 Aug 2018 15:17:45 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'Locator/ID Separation Protocol (LISP) Control-Plane' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-08-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 6833. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-lisp-6834bis: Locator/ID Separation Protocol (LISP) Map-Versioning (None - IETF stream) From nobody Mon Aug 20 11:42: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 E1CEE12F295; Mon, 20 Aug 2018 11:42:19 -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 FXxBeY05QA2U; Mon, 20 Aug 2018 11:42:16 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 E928812F1A5; Mon, 20 Aug 2018 11:42:15 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id y10-v6so10352405uao.4; Mon, 20 Aug 2018 11:42:15 -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=VZ0eLZ3dWgNBMskRvd8IsaYArpCqKSw+6CiLDowNCuA=; b=Lxji4dDdyHNXPe8YOw2E3OQsuSA9autwIqIVJ5wmR+7JFFTnkgyDUST4li8dLIHvoQ u0TYvF8zVU3A1AnDIgdPR/nyVSQbO74qumEkpn9v9WER+wLBM41qqKDzeovSRmwYUs/C jCsc21iA2T3G5CqvH0N/2CjaAJ1UKOJ/Vurt2kGmfe+k8r/OF3Q2Ak7iBtxFwCMlDa8s QUN/PZvqsjYEHOvZEq8j8XV5DxPArTlqWE61FwwMHXk5QX+rJv+eav+ALbK77UJgHUEn I4L+BNnpqhy/poUL6uiAF+FYNwRljtQWWQUOHYY5VUKQ3/Zyrx/xy92EEbFyg9ZllNct eK8Q== 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=VZ0eLZ3dWgNBMskRvd8IsaYArpCqKSw+6CiLDowNCuA=; b=enLgEELoW1nlWZ2r1cNtBfY25mSo/IREU3E8OqEMtVk8XGoObbknjEzvEk8Sr1xJGL onfsERp17/1mA3rGF9rGLBfTInwW+Dng8Uf8Xu6hY7Nnz03yrgxyWfW9cYbIJVGvNgp1 hkAix1Y15H3JnWuGQMp++iFbYG3K3szuA3R2Bn+Hz/xhNn6GGNYQYzLN5iFW8ByvrjzU a53/Yi5eW2F6dXF6zH/7m6SDNi9GZoBHCh14+sXPfqku8JOFejD1jguCsL+p8HHppJVq Dl/0iYvYR0vvWx/BKbMTe/tSW5fbYEJ++c2IOSJTFdH46QS14kljpxywVFtZ2NM1YIfb kqGg== X-Gm-Message-State: APzg51CxMXZzau0opnzEZrDvAikKIh4Rm4rSP7LWCQolwtUqiZUmrPoe KHddHrWX0eyv0E7IqJkOD+afo/Z+ X-Google-Smtp-Source: ANB0Vdbi2VtPhSJO9O5jtmNsKiDBgWyEpixE7ZmfwoDV/EJZluPpEo/t4ZXZBml/yHqs6fH3I7vvgA== X-Received: by 2002:ab0:3242:: with SMTP id r2-v6mr279930uan.92.1534790534978; Mon, 20 Aug 2018 11:42:14 -0700 (PDT) Received: from [10.10.0.236] ([45.73.155.132]) by smtp.gmail.com with ESMTPSA id 13-v6sm4950059vkf.34.2018.08.20.11.42.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Aug 2018 11:42:14 -0700 (PDT) From: Dino Farinacci Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_0AFF2B4E-C53A-4BED-A7B5-07915000BA6C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 20 Aug 2018 14:42:12 -0400 In-Reply-To: Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" To: "Scott O. Bradner" References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com> <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com> <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14 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, 20 Aug 2018 18:42:20 -0000 --Apple-Mail=_0AFF2B4E-C53A-4BED-A7B5-07915000BA6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 WG, here is a diff with changes to reflect Scott=E2=80=99s comment. I = wanted the list of implementator to-be-aware changes to get working = group quick review. I=E2=80=99m about to add a =E2=80=9CChanges since RFC 6833=E2=80=9D = section to RFC 6833bis as well. Thanks, Dino --Apple-Mail=_0AFF2B4E-C53A-4BED-A7B5-07915000BA6C Content-Disposition: attachment; filename=rfcdiff-rfc6830bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-rfc6830bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6830bis-13.txt - = draft-ietf-lisp-rfc6830bis-14.txt=20 =20 =20 =20 =20 =20 =20
< draft-ietf-lisp-rfc6830bis-13.txt  =  draft-ietf-lisp-rfc6830bis-14.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: January 16, 2019 = Cisco Systems Expires: February 21, 2019 = Cisco Systems
= A. Cabellos (Ed.) = A. Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= July = 15, 2018 = August = 20, 2018
=
= The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol = (LISP)
= draft-ietf-lisp-rfc6830bis-13 = = draft-ietf-lisp-rfc6830bis-14
=
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 January 16, = 2019. This Internet-Draft will = expire on February 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 47 =C2=B6 = skipping to change at page 2, line 47 =C2=B6
10. Routing = Locator Reachability . . . . . . . . . . . . . . . . 24 = 10. Routing Locator Reachability . . . . . = . . . . . . . . . . . 24
10.1. Echo = Nonce Algorithm . . . . . . . . . . . . . . . . . . 25 = 10.1. Echo Nonce Algorithm . . . . . . . = . . . . . . . . . . . 25
11. EID = Reachability within a LISP Site . . . . . . . . . . . . . 26 = 11. EID Reachability within a LISP Site . . = . . . . . . . . . . . 26
12. Routing = Locator Hashing . . . . . . . . . . . . . . . . . . . 27 = 12. Routing Locator Hashing . . . . . . . . = . . . . . . . . . . . 27
13. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 28 = 13. Changing the Contents of EID-to-RLOC = Mappings . . . . . . . . 28
13.1. = Database Map-Versioning . . . . . . . . . . . . . . . . 29 = 13.1. Database Map-Versioning . . . . . = . . . . . . . . . . . 29
14. Multicast = Considerations . . . . . . . . . . . . . . . . . . 29 = 14. Multicast Considerations . . . . . . . = . . . . . . . . . . . 29
15. Router = Performance Considerations . . . . . . . . . . . . . . 30 = 15. Router Performance Considerations . . . = . . . . . . . . . . . 30
16. Security = Considerations . . . . . . . . . . . . . . . . . . . 31 = 16. Security Considerations . . . . . . . . = . . . . . . . . . . . 31
17. Network = Management Considerations . . . . . . . . . . . . . . 32 = 17. Network Management Considerations . . . = . . . . . . . . . . . 32
18. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 32 = 18. Changes since = RFC 6830 . . . . . . . . . . . . . . . . . . . 32
18.1. LISP UDP Port Numbers . . . . . . . . . = . . . . . . . . 32 19. IANA Considerations . . . . . . . . . . . = . . . . . . . . . . 32
19. References . . . . . . . . . . . . . . . . = . . . . . . . . . 32 19.1. LISP UDP Port = Numbers . . . . . . . . . . . . . . . . . 32
19.1. Normative References . . . . . . . . = . . . . . . . . . . 32 20. References . . . = . . . . . . . . . . . . . . . . . . . . . . 33
19.2. Informative References . . . . . . . = . . . . . . . . . . 33 20.1. Normative References . . . . . . . . = . . . . . . . . . . 33
= 20.2. = Informative References . . . . . . . . . . . . . . . . . 33
= =
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 37 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 37
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 37 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 37
B.1. = Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 38 B.1. = Changes to draft-ietf-lisp-rfc6830bis-14 = . . . . . . . . 38
B.2. = Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 38 B.2. = Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 38
B.3. = Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 38 B.3. = Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 38
B.4. = Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 38 B.4. = Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 38
B.5. = Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 38 B.5. = Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 38
B.6. = Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 39 B.6. = Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 39
B.7. = Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 39 B.7. = Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 39
B.8. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 39 B.8. = Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 39
B.9. = Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 40 = B.9. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . = 39
B.10. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 40 B.10. Changes to = draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 40
B.11. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 40 B.11. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 40
B.12. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 40 B.12. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 40
B.13. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 40 B.13. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 40
B.14. Changes to draft-ietf-lisp-rfc6830bis-00 = . . . . . . . . 41 B.14. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 40
= B.15. = Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 41
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 41
=
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 20 =C2=B6 = skipping to change at page 4, line 20 =C2=B6
LISP = forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] = LISP forwarding node functionality while = [I-D.ietf-lisp-rfc6833bis]
specifies the = LISP control plane. LISP deployment guidelines can be specifies the LISP control plane. LISP deployment = guidelines can be
found in = [RFC7215] and [RFC6835] describes considerations for network = found in [RFC7215] and [RFC6835] describes = considerations for network
operational = management. Finally, [I-D.ietf-lisp-introduction] operational management. Finally, = [I-D.ietf-lisp-introduction]
describes the = LISP architecture. describes the = LISP architecture.
=
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]. = document are to be interpreted as described in [RFC2119] and
= = [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 = the Data-Plane. See [AFN] and [RFC3232] = for details. An AFI
value of 0 = used in this specification indicates an unspecified value of 0 used in this specification indicates an = unspecified
encoded = address where the length of the address is 0 octets encoded address where the length of the address is = 0 octets
following = the 16-bit AFI value of 0. = following the 16-bit AFI value of 0.
=
=
skipping to = change at = page 29, line 5 =C2=B6 = skipping to change at page 29, line 5 =C2=B6
well as = setting the corresponding Locator-Status-Bit to 0. This = well as setting the corresponding = Locator-Status-Bit to 0. This
forces ITRs = with old or new mappings to avoid using the removed forces ITRs with old or new mappings to avoid using = the removed
= Locator. Locator.
=
If many = changes occur to a mapping over a long period of time, one = If many changes occur to a mapping over a = long period of time, one
will find = empty record slots in the middle of the Locator-Set and new = will find empty record slots in the middle = of the Locator-Set and new
records = appended to the Locator-Set. At some point, it would be = records appended to the Locator-Set. At some = point, it would be
useful to = compact the Locator-Set so the Locator-Status-Bit settings = useful to compact the Locator-Set so the = Locator-Status-Bit settings
can be = efficiently packed. can be = efficiently packed.
=
We propose = here a Data-Plane mechanism (Map-Versioning)= to update the We propose here a = Data-Plane mechanism (Map-Versioning specified = in
contents of = EID-to-RLOC mappings. Please note that in addition the = = [I-D.ietf-lisp-6834bis])) to update the contents of = EID-to-RLOC
Solicit-Map = Request (specified in [I-D.ietf-lisp-rfc6833bis]) is a mappings. Please note that in addition the = Solicit-Map Request
= Control-Plane mechanisms that can be used to update EID-to-RLOC = (specified in [I-D.ietf-lisp-rfc6833bis]) = is a Control-Plane
= mappings. mechanisms that can be = used to update EID-to-RLOC mappings.
=
13.1. Database = Map-Versioning 13.1. Database = Map-Versioning
=
When there is = unidirectional packet flow between an ITR and ETR, and When there is unidirectional packet flow between an = ITR and ETR, and
the = EID-to-RLOC mappings change on the ETR, it needs to inform the = the EID-to-RLOC mappings change on the ETR, = it needs to inform the
ITR so = encapsulation to a removed Locator can stop and can instead be = ITR so encapsulation to a removed Locator = can stop and can instead be
started to a = new Locator in the Locator-Set. = started to a new Locator in the Locator-Set.
=
An ETR, when = it sends Map-Reply messages, conveys its own Map-Version = An ETR, when it sends Map-Reply messages, = conveys its own Map-Version
Number. This = is known as the Destination Map-Version Number. ITRs Number. This is known as the Destination Map-Version = Number. ITRs
=
skipping to = change at = page 32, line 14 =C2=B6 = skipping to change at page 32, line = 14 =C2=B6
or gleaning) = SHOULD be verified with other reachability mechanisms. or gleaning) SHOULD be verified with other = reachability mechanisms.
In addition, = systematic rate-limitation and filtering is an effective = In addition, systematic rate-limitation and = filtering is an effective
technique to = mitigate attacks that aim to overload the Control-Plane. = technique to mitigate attacks that aim to = overload the Control-Plane.
=
17. Network = Management Considerations 17. Network = Management Considerations
=
Considerations = for network management tools exist so the LISP Considerations for network management tools exist so = the LISP
protocol suite = can be operationally managed. These mechanisms can be protocol suite can be operationally managed. These = mechanisms can be
found in = [RFC7052] and [RFC6835]. found in = [RFC7052] and [RFC6835].
=
18. IANA = Considerations 18. Changes since RFC 6830
=
= For implementation = considerations, the following changes have been
= made to this = document since RFC 6830 was published:
=
= o It is no longer = mandated that a maximum number of 2 LISP headers
= be prepended to a = packet. If there is a application need for more
= than 2 LISP = headers, an implementation can support more. However,
= this document = recommends a maximum of 2 LISP headers.
=
= o The 3 reserved = flag bits in the LISP header have been allocated
= for [RFC8060]. = The low-order 2 bits of the 3-bit field (now named
= the KK bits) are = used as a key identifier. The is 1 remaining bit
= is still = documented as reserved.
=
= o Data-plane = gleaning for creating map-cache entries has been made
= optional in this = draft. If any ITR implementations depend or
= assume the remote = ETR is gleaning should not do so. This does not
= create any = interoperability problems since the control-plane map-
= cache population = procedures are unilateral and are the typical
= method for = map-cache population.
=
= 19. 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
Data-Plane = LISP specification, in accordance with BCP 26 [RFC8126]. = Data-Plane LISP specification, in accordance = with BCP 26 [RFC8126].
=
18.1. LISP UDP Port Numbers 19.1. LISP UDP Port = Numbers
=
The IANA = registry has allocated UDP port number 4341 for the LISP = The IANA registry has allocated UDP port = number 4341 for the LISP
Data-Plane. = IANA has updated the description for UDP port 4341 as Data-Plane. IANA has updated the description for UDP = port 4341 as
= follows: follows:
=
lisp-data = 4341 udp LISP Data Packets = lisp-data 4341 udp LISP Data Packets
=
19. References 20. References
=
19.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-00 (work in progress), July 2018. lisp-6834bis-00 (work in progress), July = 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-12 (work in progress), = July
= 2018. 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 33, line 21 =C2=B6 = skipping to change at page 33, line = 44 =C2=B6
[RFC3168] = Ramakrishnan, K., Floyd, S., and D. Black, "The Addition = [RFC3168] Ramakrishnan, K., Floyd, S., and = D. Black, "The Addition
of = Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) = to IP",
RFC = 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September = 2001,
= <https://www.rfc-editor.org/info/rfc3168>. = <https://www.rfc-editor.org/info/rfc3168>.
=
[RFC8200] = Deering, S. and R. Hinden, "Internet Protocol, Version 6 = [RFC8200] Deering, S. and R. Hinden, = "Internet Protocol, Version 6
= (IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC = 8200,
DOI = 10.17487/RFC8200, July 2017, = DOI 10.17487/RFC8200, July 2017,
= <https://www.rfc-editor.org/info/rfc8200>. = <https://www.rfc-editor.org/info/rfc8200>.
=
19.2. Informative References 20.2. Informative = References
=
[AFN] = IANA, "Address Family Numbers", August 2016, [AFN] IANA, "Address Family Numbers", August = 2016,
= <http://www.iana.org/assignments/address-family-numbers>. = = <http://www.iana.org/assignments/address-family-numbers>.
=
[CHIAPPA] = Chiappa, J., "Endpoints and Endpoint names: A Proposed", = [CHIAPPA] Chiappa, J., "Endpoints and = Endpoint names: A Proposed",
= 1999, 1999,
= <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. = = <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
=
= [I-D.ietf-lisp-introduction] = [I-D.ietf-lisp-introduction]
= Cabellos-Aparicio, A. and D. Saucez, "An Architectural Cabellos-Aparicio, A. and D. Saucez, "An = Architectural
=
skipping to = change at = page 36, line 15 =C2=B6 = skipping to change at page 36, line = 36 =C2=B6
[RFC8111] = Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, = A., and A.
= Smirnov, "Locator/ID Separation Protocol Delegated Smirnov, "Locator/ID Separation Protocol = Delegated
= Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, = Database Tree (LISP-DDT)", RFC = 8111, DOI 10.17487/RFC8111,
May = 2017, <https://www.rfc-editor.org/info/rfc8111>. May 2017, = <https://www.rfc-editor.org/info/rfc8111>.
=
[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
= 2119 Key = Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
= May 2017, = <https://www.rfc-editor.org/info/rfc8174>.
= =
[RFC8378] = Moreno, V. and D. Farinacci, "Signal-Free Locator/ID [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free = Locator/ID
= Separation Protocol (LISP) Multicast", RFC 8378, Separation Protocol (LISP) Multicast", RFC = 8378,
DOI = 10.17487/RFC8378, May 2018, = DOI 10.17487/RFC8378, May 2018,
= <https://www.rfc-editor.org/info/rfc8378>. = <https://www.rfc-editor.org/info/rfc8378>.
=
Appendix A. = Acknowledgments Appendix A. = Acknowledgments
=
An initial = thank you goes to Dave Oran for planting the seeds for the = An initial thank you goes to Dave Oran for = planting the seeds for the
initial ideas = for LISP. His consultation continues to provide value initial ideas for LISP. His consultation continues = to provide value
to the LISP = authors. to the LISP = authors.
=
skipping to = change at = page 38, line 5 =C2=B6 = skipping to change at page 38, 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-13 B.1. = Changes to draft-ietf-lisp-rfc6830bis-14
=
= o Posted August = 2018.
=
= o Final editorial = changes before RFC submission for Proposed
= = Standard.
=
= o Added section = "Changes since RFC 6830" so implementators are
= informed of any = changes since the last RFC publication.
=
= B.2. 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.2. Changes to = draft-ietf-lisp-rfc6830bis-12 B.3. 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.3. Changes to = draft-ietf-lisp-rfc6830bis-11 B.4. 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.4. Changes to = draft-ietf-lisp-rfc6830bis-10 B.5. 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.5. Changes to = draft-ietf-lisp-rfc6830bis-09 B.6. 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.6. Changes to = draft-ietf-lisp-rfc6830bis-08 B.7. 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.7. Changes to = draft-ietf-lisp-rfc6830bis-07 B.8. 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.8. Changes to = draft-ietf-lisp-rfc6830bis-06 B.9. 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 40, line = 9 =C2=B6 = skipping to change at page 40, line = 17 =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.9. Changes to = draft-ietf-lisp-rfc6830bis-05 B.10. 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.10. Changes to = draft-ietf-lisp-rfc6830bis-04 B.11. 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.11. Changes to = draft-ietf-lisp-rfc6830bis-03 B.12. 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.12. Changes to = draft-ietf-lisp-rfc6830bis-02 B.13. 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.13. Changes to = draft-ietf-lisp-rfc6830bis-01 B.14. 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.14. Changes to = draft-ietf-lisp-rfc6830bis-00 B.15. 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. 29 change blocks. 
49 lines changed or = deleted 89 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=_0AFF2B4E-C53A-4BED-A7B5-07915000BA6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 20, 2018, at 9:03 AM, Scott O. Bradner wrote: >=20 > a specific section only dealing with the changes since the RFC is best >=20 > there is too much noise in the per iteration log (which as you already = note should be removed) >=20 > Scott >=20 >> On Aug 20, 2018, at 8:57 AM, Dino Farinacci = wrote: >>=20 >> Note we do have a Document Change Log in Appendix B detailing the = changes put in each version starting with RFC6830. Would that suffice? = Or you still think a specific section is required? >>=20 >> Dino >>=20 >> >>=20 >>> On Aug 20, 2018, at 8:44 AM, Scott O. Bradner wrote: >>>=20 >>> it would be best to have a section called =E2=80=9Cchanges since RFC = 6830=E2=80=9D so there is no ambiguity that the section covers the = changes >>>=20 >>> it would be fine to have that section just say =E2=80=9CSee = =E2=80=9CImplementation Considerations.=E2=80=9D >>>=20 >>> Scott >>>=20 >>>=20 >>>> On Aug 20, 2018, at 8:26 AM, Dino Farinacci = wrote: >>>>=20 >>>>=20 >>>>> Hi Dino >>>>>> On Aug 20, 2018, at 8:18 AM, Dino Farinacci = wrote: >>>>>>=20 >>>>>> There were little changes that an implementor would need to know = about for the data-plane. But there were for the control-plane (i.e. = RFC6833bis). But in either case, we=E2=80=99ll add a section in each bis = document. >>>>>=20 >>>>> thanks - even if the section says =E2=80=9Cnothing to worry = about=E2=80=9D it will be useful >>>>=20 >>>> I=E2=80=99ll title it =E2=80=9CImplementation Considerations=E2=80=9D= and place it between 17 and 18? >>>>=20 >>>> 14. Multicast Considerations . . . . . . . . . . . . . . . . . . = 29 >>>> 15. Router Performance Considerations . . . . . . . . . . . . . . = 30 >>>> 16. Security Considerations . . . . . . . . . . . . . . . . . . . = 31 >>>> 17. Network Management Considerations . . . . . . . . . . . . . . = 32 >>>> 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 32 >>>>=20 >>>>=20 >>>>>>=20 >>>>>> Are you going to be reviewer for 6833bis as well? >>>>>=20 >>>>> not assigned that yet but I will take a look >>>>=20 >>>> I will try to get the sections done in the next day or so. I=E2=80=99= m at the 3GPP meetings this week. >>>>=20 >>>> Dino >>>>=20 >>>>>=20 >>>>> Scott >>>>>>=20 >>>>>> Dino >>>>>>=20 >>>>>>> On Aug 20, 2018, at 6:14 AM, Scott O. Bradner = wrote: >>>>>>>=20 >>>>>>> I was just assigned to do a ops-dir review of = draft-ietf-lisp-rfc6830bis-14 >>>>>>>=20 >>>>>>> this is not the review - that will come soon >>>>>>>=20 >>>>>>> but since this is a =E2=80=9Cbis=E2=80=9D document that is to = replace an existing RFC it needs to have a=20 >>>>>>> =E2=80=9Cchanges since RFC 6830=E2=80=9D section so that = implementors of the earlier RFC will be able to tell >>>>>>> what they need to change to bring their code up to date without = having to compare the=20 >>>>>>> RFCs line by line (and likely miss something) >>>>>>>=20 >>>>>>> Scott >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_0AFF2B4E-C53A-4BED-A7B5-07915000BA6C-- From nobody Mon Aug 20 11:49: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 8AD82130DC6; Mon, 20 Aug 2018 11:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 qv5dlV68Y6YI; Mon, 20 Aug 2018 11:49:05 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510D412F295; Mon, 20 Aug 2018 11:49:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 6034270E18DF; Mon, 20 Aug 2018 14:49:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrvtZF-4oKXN; Mon, 20 Aug 2018 14:48:42 -0400 (EDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 374F570E18CD; Mon, 20 Aug 2018 14:48:41 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Scott O. Bradner" In-Reply-To: Date: Mon, 20 Aug 2018 14:48:39 -0400 Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com> <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com> <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14 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, 20 Aug 2018 18:49:06 -0000 looks good to me - thanks Scott > On Aug 20, 2018, at 2:42 PM, Dino Farinacci = wrote: >=20 > WG, here is a diff with changes to reflect Scott=E2=80=99s comment. I = wanted the list of implementator to-be-aware changes to get working = group quick review. >=20 > I=E2=80=99m about to add a =E2=80=9CChanges since RFC 6833=E2=80=9D = section to RFC 6833bis as well. >=20 > Thanks, > Dino >=20 > >=20 >> On Aug 20, 2018, at 9:03 AM, Scott O. Bradner wrote: >>=20 >> a specific section only dealing with the changes since the RFC is = best >>=20 >> there is too much noise in the per iteration log (which as you = already note should be removed) >>=20 >> Scott >>=20 >>> On Aug 20, 2018, at 8:57 AM, Dino Farinacci = wrote: >>>=20 >>> Note we do have a Document Change Log in Appendix B detailing the = changes put in each version starting with RFC6830. Would that suffice? = Or you still think a specific section is required? >>>=20 >>> Dino >>>=20 >>> >>>=20 >>>> On Aug 20, 2018, at 8:44 AM, Scott O. Bradner = wrote: >>>>=20 >>>> it would be best to have a section called =E2=80=9Cchanges since = RFC 6830=E2=80=9D so there is no ambiguity that the section covers the = changes >>>>=20 >>>> it would be fine to have that section just say =E2=80=9CSee = =E2=80=9CImplementation Considerations.=E2=80=9D >>>>=20 >>>> Scott >>>>=20 >>>>=20 >>>>> On Aug 20, 2018, at 8:26 AM, Dino Farinacci = wrote: >>>>>=20 >>>>>=20 >>>>>> Hi Dino >>>>>>> On Aug 20, 2018, at 8:18 AM, Dino Farinacci = wrote: >>>>>>>=20 >>>>>>> There were little changes that an implementor would need to know = about for the data-plane. But there were for the control-plane (i.e. = RFC6833bis). But in either case, we=E2=80=99ll add a section in each bis = document. >>>>>>=20 >>>>>> thanks - even if the section says =E2=80=9Cnothing to worry = about=E2=80=9D it will be useful >>>>>=20 >>>>> I=E2=80=99ll title it =E2=80=9CImplementation Considerations=E2=80=9D= and place it between 17 and 18? >>>>>=20 >>>>> 14. Multicast Considerations . . . . . . . . . . . . . . . . . . = 29 >>>>> 15. Router Performance Considerations . . . . . . . . . . . . . . = 30 >>>>> 16. Security Considerations . . . . . . . . . . . . . . . . . . . = 31 >>>>> 17. Network Management Considerations . . . . . . . . . . . . . . = 32 >>>>> 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 32 >>>>>=20 >>>>>=20 >>>>>>>=20 >>>>>>> Are you going to be reviewer for 6833bis as well? >>>>>>=20 >>>>>> not assigned that yet but I will take a look >>>>>=20 >>>>> I will try to get the sections done in the next day or so. I=E2=80=99= m at the 3GPP meetings this week. >>>>>=20 >>>>> Dino >>>>>=20 >>>>>>=20 >>>>>> Scott >>>>>>>=20 >>>>>>> Dino >>>>>>>=20 >>>>>>>> On Aug 20, 2018, at 6:14 AM, Scott O. Bradner = wrote: >>>>>>>>=20 >>>>>>>> I was just assigned to do a ops-dir review of = draft-ietf-lisp-rfc6830bis-14 >>>>>>>>=20 >>>>>>>> this is not the review - that will come soon >>>>>>>>=20 >>>>>>>> but since this is a =E2=80=9Cbis=E2=80=9D document that is to = replace an existing RFC it needs to have a=20 >>>>>>>> =E2=80=9Cchanges since RFC 6830=E2=80=9D section so that = implementors of the earlier RFC will be able to tell >>>>>>>> what they need to change to bring their code up to date without = having to compare the=20 >>>>>>>> RFCs line by line (and likely miss something) >>>>>>>>=20 >>>>>>>> Scott >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Mon Aug 20 11:57: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 B159C130EE8 for ; Mon, 20 Aug 2018 11:56:53 -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 HjxcWvq-h5lQ for ; Mon, 20 Aug 2018 11:56:51 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11ACB130ED7 for ; Mon, 20 Aug 2018 11:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9793; q=dns/txt; s=iport; t=1534791411; x=1536001011; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=3aM96SvEvpGzNVRUZ6Svj1BNKXl5ZHGgftpRSU7Wf9o=; b=ck7SlHFlYw2fo4K5w1SyRVcYu7xF4l8kHkfa1leK1mqFccx7pyV56by0 2HV+m3pfZONRCQuAHuLdRYGFeTSFVNHXVaHxIpFAMlsjXTpAUpaLOWsHa g/RRKQ3Xnsuii/58W2orheMc+7Ffkvfib9Qfd45hKYTnRpfnnSiAaWuw2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BJAQDMDXtb/4YNJK1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMgBSpjfyiDcIgKjB2BYC2IUYgbhSsUgWYLGAEKhEkCg00hNBg?= =?us-ascii?q?BAgEBAgEBAm0cDIU4AQEBAwEBIQRHGwsYKgICIQYwEwYCAQGDHgGBaQMVD6d?= =?us-ascii?q?zezMfhEmCNw2DLAWJGBeBQT+BEieCa4JWRQEBgUmDGYJXAo13hEmIESsJjFC?= =?us-ascii?q?DCgYViECFeItthzuBQTiBUjMaCBsVGiGCaYM2AQiHVoVeHzCOfAEB?= X-IronPort-AV: E=Sophos;i="5.53,266,1531785600"; d="scan'208,217";a="160078680" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Aug 2018 18:56:50 +0000 Received: from [10.32.173.123] ([10.32.173.123]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTP id w7KIunLs018481 for ; Mon, 20 Aug 2018 18:56:49 GMT To: lisp@ietf.org References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com> <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com> <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com> From: Fabio Maino Message-ID: Date: Mon, 20 Aug 2018 11:56:50 -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="------------6F4EFDA164A484E7BD117341" Content-Language: en-US X-Outbound-SMTP-Client: 10.32.173.123, [10.32.173.123] X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14 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, 20 Aug 2018 18:57:01 -0000 This is a multi-part message in MIME format. --------------6F4EFDA164A484E7BD117341 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Looks good Dino. Noted one nit in section 18, not worth spinning a new version IMO: "The is 1 remaining bit" -> "The 1 remaining bit" Fabio On 8/20/18 11:42 AM, Dino Farinacci wrote: > WG, here is a diff with changes to reflect Scott’s comment. I wanted the list of implementator to-be-aware changes to get working group quick review. > > I’m about to add a “Changes since RFC 6833” section to RFC 6833bis as well. > > Thanks, > Dino > > > > >> On Aug 20, 2018, at 9:03 AM, Scott O. Bradner wrote: >> >> a specific section only dealing with the changes since the RFC is best >> >> there is too much noise in the per iteration log (which as you already note should be removed) >> >> Scott >> >>> On Aug 20, 2018, at 8:57 AM, Dino Farinacci wrote: >>> >>> Note we do have a Document Change Log in Appendix B detailing the changes put in each version starting with RFC6830. Would that suffice? Or you still think a specific section is required? >>> >>> Dino >>> >>> >>> >>>> On Aug 20, 2018, at 8:44 AM, Scott O. Bradner wrote: >>>> >>>> it would be best to have a section called “changes since RFC 6830” so there is no ambiguity that the section covers the changes >>>> >>>> it would be fine to have that section just say “See “Implementation Considerations.” >>>> >>>> Scott >>>> >>>> >>>>> On Aug 20, 2018, at 8:26 AM, Dino Farinacci wrote: >>>>> >>>>> >>>>>> Hi Dino >>>>>>> On Aug 20, 2018, at 8:18 AM, Dino Farinacci wrote: >>>>>>> >>>>>>> There were little changes that an implementor would need to know about for the data-plane. But there were for the control-plane (i.e. RFC6833bis). But in either case, we’ll add a section in each bis document. >>>>>> thanks - even if the section says “nothing to worry about” it will be useful >>>>> I’ll title it “Implementation Considerations” and place it between 17 and 18? >>>>> >>>>> 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 29 >>>>> 15. Router Performance Considerations . . . . . . . . . . . . . . 30 >>>>> 16. Security Considerations . . . . . . . . . . . . . . . . . . . 31 >>>>> 17. Network Management Considerations . . . . . . . . . . . . . . 32 >>>>> 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 >>>>> >>>>> >>>>>>> Are you going to be reviewer for 6833bis as well? >>>>>> not assigned that yet but I will take a look >>>>> I will try to get the sections done in the next day or so. I’m at the 3GPP meetings this week. >>>>> >>>>> Dino >>>>> >>>>>> Scott >>>>>>> Dino >>>>>>> >>>>>>>> On Aug 20, 2018, at 6:14 AM, Scott O. Bradner wrote: >>>>>>>> >>>>>>>> I was just assigned to do a ops-dir review of draft-ietf-lisp-rfc6830bis-14 >>>>>>>> >>>>>>>> this is not the review - that will come soon >>>>>>>> >>>>>>>> but since this is a “bis” document that is to replace an existing RFC it needs to have a >>>>>>>> “changes since RFC 6830” section so that implementors of the earlier RFC will be able to tell >>>>>>>> what they need to change to bring their code up to date without having to compare the >>>>>>>> RFCs line by line (and likely miss something) >>>>>>>> >>>>>>>> Scott > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --------------6F4EFDA164A484E7BD117341 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Looks good Dino.

Noted one nit in section 18, not worth spinning a new version IMO:

"The is 1 remaining bit" -> "The 1 remaining bit"

Fabio


On 8/20/18 11:42 AM, Dino Farinacci wrote:
WG, here is a diff with changes to reflect Scott’s comment. I wanted the list of implementator to-be-aware changes to get working group quick review.

I’m about to add a “Changes since RFC 6833” section to RFC 6833bis as well.

Thanks,
Dino






On Aug 20, 2018, at 9:03 AM, Scott O. Bradner <sob@sobco.com> wrote:

a specific section only dealing with the changes since the RFC is best

there is too much noise in the per iteration log (which as you already note should be removed)

Scott


On Aug 20, 2018, at 8:57 AM, Dino Farinacci <farinacci@gmail.com> wrote:

Note we do have a Document Change Log in Appendix B detailing the changes put in each version starting with RFC6830. Would that suffice? Or you still think a specific section is required?

Dino

<PastedGraphic-9.png>


On Aug 20, 2018, at 8:44 AM, Scott O. Bradner <sob@sobco.com> wrote:

it would be best to have a section called “changes since RFC 6830” so there is no ambiguity that the section covers the changes

it would be fine to have that section just say “See  “Implementation Considerations.”

Scott



On Aug 20, 2018, at 8:26 AM, Dino Farinacci <farinacci@gmail.com> wrote:



Hi Dino

On Aug 20, 2018, at 8:18 AM, Dino Farinacci <farinacci@gmail.com> wrote:

There were little changes that an implementor would need to know about for the data-plane. But there were for the control-plane (i.e. RFC6833bis). But in either case, we’ll add a section in each bis document.

thanks - even if the section says “nothing to worry about” it will be useful

I’ll title it “Implementation Considerations” and place it between 17 and 18?

14. Multicast Considerations  . . . . . . . . . . . . . . . . . .  29
15. Router Performance Considerations . . . . . . . . . . . . . .  30
16. Security Considerations . . . . . . . . . . . . . . . . . . .  31
17. Network Management Considerations . . . . . . . . . . . . . .  32
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  32



Are you going to be reviewer for 6833bis as well?

not assigned that yet but I will take a look

I will try to get the sections done in the next day or so. I’m at the 3GPP meetings this week.

Dino


Scott

Dino


On Aug 20, 2018, at 6:14 AM, Scott O. Bradner <sob@sobco.com> wrote:

I was just assigned to do a ops-dir review of  draft-ietf-lisp-rfc6830bis-14

this is not the review - that will come soon

but since this is a “bis” document that is to replace an existing RFC it needs to have a 
“changes since RFC 6830” section so that implementors of the earlier RFC will be able to tell
what they need to change to bring their code up to date without having to compare the 
RFCs line by line (and likely miss something)

Scott


                

                

              

              

            

            

          

          

        

        

      

      

      

      

      

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


    

    


    

  


--------------6F4EFDA164A484E7BD117341--


From nobody Mon Aug 20 12:30: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 2727B129619; Mon, 20 Aug 2018 12:30:09 -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 vTOhHxDvI35P; Mon, 20 Aug 2018 12:30:02 -0700 (PDT)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 36CD3128CF3; Mon, 20 Aug 2018 12:30:02 -0700 (PDT)
Received: by mail-vk0-x22e.google.com with SMTP id y9-v6so7080575vky.3; Mon, 20 Aug 2018 12:30:02 -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=uH7UDop1VvvU0xQ1C7jTmV6jFmUP3VYPR+JciIKOf70=; b=DsjxkKCwXPcCjTe1X/etpSeNyLaW30+PLbeL5eKohiaYDxwg+9Cz78bS8Ih20Az4B3 iQ09uUe4WPX2yualONz4FzsifvXt9JsmZSiPEp8p6v65sCqjFia4Sz4UjQSquWhgoA/Z 3XQdxO0aawPS++7Pyrsc4wtgivJHJWN0djmBQrz7f5lZlO6rj7eo1C/9sJOINghExUNY JOLlzLNxKJrWITN9u7u2D0633NUhNpmK1Q+6AEp+U7lTuWURtVPWZUVFBKAdFNBfwVIe 1MOZH7/EgdRj3GO51zUZPSazcYRVV6D8YROD52ULy1r5wfEi85RY0tJ+NKsnX78oqT7g V4tg==
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=uH7UDop1VvvU0xQ1C7jTmV6jFmUP3VYPR+JciIKOf70=; b=a5heZ3AocA0oP4fUhCBhw+UqAk8dx/bkwU77XVLdmJujiZl0EOK3PXTN2a1K8+qeje QKgUXIbd5yiGruFvBslRL6S5vlvpU/KBC75Idd/ZdFRfIOoZA4aQhe0W1B0+TZuWtsLy IiKBeB3YxA8LDJBEqjs1qrVg6mIXxgYQZbF/cTN6NjQtoryNSmGzaNtECwMC76DVLjKR UpEWErv2NQURtFGxLZFMPddQoWZYIup2a9urbkkeNT7gADtlIXzQw6OKAqaCc489G6T9 9+KywnIjVj/a7yQtOk7DFZkgN1jpCzF6mXd7rcNwcUhPGsFz+1Fe6gy4tz6ox7RgkNsm x79g==
X-Gm-Message-State: AOUpUlFdfBb1zeG3ORywpMveBapv0ZromR22h/G5RL70dJimlMWZLn+l /SYevJH7hs3XT3oBf8S3Oo3yGrmQ
X-Google-Smtp-Source: AA+uWPy8ryw9gIUASYA5CXLF/cRX4+MOdLQMwjy3Vzavy2PbO6mAs92Z+WRNnsnSG9nhfWvHQqvG2Q==
X-Received: by 2002:a1f:dd47:: with SMTP id u68-v6mr30486084vkg.137.1534793401265;  Mon, 20 Aug 2018 12:30:01 -0700 (PDT)
Received: from [10.10.0.236] ([45.73.155.132]) by smtp.gmail.com with ESMTPSA id 13-v6sm5088107vkf.34.2018.08.20.12.30.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Aug 2018 12:30:00 -0700 (PDT)
From: Dino Farinacci 
Message-Id: <9BE375D7-50E1-4FF1-B59C-93C203CFBDD0@gmail.com>
Content-Type: multipart/mixed; boundary="Apple-Mail=_89A825BA-DB37-4020-9AD1-0E28AD907930"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 20 Aug 2018 15:29:59 -0400
In-Reply-To: 
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" 
To: "Scott O. Bradner" 
References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com>  <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com>  <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com>  
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14
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, 20 Aug 2018 19:30:09 -0000

--Apple-Mail=_89A825BA-DB37-4020-9AD1-0E28AD907930
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

And here is the diff for the same type of changes for 6833bis.

Thanks,
Dino


--Apple-Mail=_89A825BA-DB37-4020-9AD1-0E28AD907930
Content-Disposition: attachment;
	filename=rfcdiff-rfc6833bis.html
Content-Type: text/html;
	x-unix-mode=0644;
	name="rfcdiff-rfc6833bis.html"
Content-Transfer-Encoding: quoted-printable



=20
  =20
  =20
  Diff: draft-ietf-lisp-rfc6833bis-12.txt - =
draft-ietf-lisp-rfc6833bis-13.txt=20
  =20
     =20
=20
=20
  =20
  =20
      =

      =

      =

      
< draft-ietf-lisp-rfc6833bis-12.txt  =
 draft-ietf-lisp-rfc6833bis-13.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: January 27, 2019                              =
UPC/BarcelonaTech Expires: February 21, 2019                             =
UPC/BarcelonaTech

      
                =
                                           July =
26, 2018                       =
                                   August =
20, 2018

      
 =


      
          =
Locator/ID Separation Protocol (LISP) Control-Plane           Locator/ID Separation Protocol (LISP) =
Control-Plane

      
                  =
   draft-ietf-lisp-rfc6833bis-12       =
               draft-ietf-lisp-rfc6833bis-12

      
 =


      
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

      
 =


      
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 January 27, =
2019.    This Internet-Draft will =
expire on February 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 25 =C2=B6 =
skipping to change at page 2, line 25 =C2=B6

      
   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  . . . . . . . . . . . . . . . . . . . . . . . .   =
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  . . . . . . . . . . . . . . . . . . . . . . .   5    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 =
. . . . . . . . . . .  26

      
   6.  Changing =
the Contents of EID-to-RLOC Mappings . . . . . . . .  28 =
   6.  Changing the Contents of EID-to-RLOC =
Mappings . . . . . . . .  28

      
     6.1.  =
Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . .  28 =
     6.1.  Solicit-Map-Request (SMR) . . . . . =
. . . . . . . . . . .  28

      
   7.  Routing =
Locator Reachability  . . . . . . . . . . . . . . . .  29 =
   7.  Routing Locator Reachability  . . . . . =
. . . . . . . . . . .  29

      
     7.1.  =
RLOC-Probing Algorithm  . . . . . . . . . . . . . . . . .  31 =
     7.1.  RLOC-Probing Algorithm  . . . . . . =
. . . . . . . . . . .  31

      
   8.  =
Interactions with Other LISP Components . . . . . . . . . . .  =
32    8.  Interactions with Other LISP =
Components . . . . . . . . . . .  32

      
     8.1.  ITR =
EID-to-RLOC Mapping Resolution  . . . . . . . . . . .  32 =
     8.1.  ITR EID-to-RLOC Mapping Resolution  =
. . . . . . . . . . .  32

      
     8.2.  =
EID-Prefix Configuration and ETR Registration . . . . . .  33 =
     8.2.  EID-Prefix Configuration and ETR =
Registration . . . . . .  33

      
     8.3.  =
Map-Server Processing . . . . . . . . . . . . . . . . . .  35 =
     8.3.  Map-Server Processing . . . . . . . =
. . . . . . . . . . .  35

      
     8.4.  =
Map-Resolver Processing . . . . . . . . . . . . . . . . .  36 =
     8.4.  Map-Resolver Processing . . . . . . =
. . . . . . . . . . .  36

      
       8.4.1.  =
Anycast Map-Resolver Operation  . . . . . . . . . . .  36 =
       8.4.1.  Anycast Map-Resolver Operation  =
. . . . . . . . . . .  36

      
   9.  Security =
Considerations . . . . . . . . . . . . . . . . . . .  36 =
   9.  Security Considerations . . . . . . . . =
. . . . . . . . . . .  36

      

      
   10. IANA =
Considerations . . . . . . . . . . . . . . . . . . . . .  37    10. =
Changes since RFC 6833  . . . . . . . . . . . . . =
. . . . . .  37

      
     10.1.  LISP UDP Port Numbers  . . . . . . . =
. . . . . . . . . .  38    11. IANA Considerations . . . . . . . . . . . =
. . . . . . . . . .  38

      
     10.2.  LISP Packet Type Codes . . . . . . . . . =
. . . . . . . .  38      11.1.  LISP UDP Port Numbers  . . . . . . . =
. . . . . . . . . .  38

      
     10.3.  LISP ACT and Flag Fields . . . . . . . . =
. . . . . . . .  38      11.2.  LISP Packet =
Type Codes . . . . . . . . . . . . . . . . .  38

      
     10.4.  LISP Address Type Codes  . . . . . . =
. . . . . . . . . .  39      11.3.  LISP ACT and Flag Fields . . . . . . . . =
. . . . . . . .  39

      
     10.5.  LISP Algorithm ID Numbers  . . . . . . . =
. . . . . . . .  39      11.4.  LISP Address =
Type Codes  . . . . . . . . . . . . . . . .  39

      
   11. References  . . . . . . . . . . . . . . . =
. . . . . . . . . .  39      11.5.  LISP =
Algorithm ID Numbers  . . . . . . . . . . . . . . .  40

      
     11.1.  Normative References . . . . . . . . =
. . . . . . . . . .  39 

      
     11.2.  Informative References . . . . . . . =
. . . . . . . . . .  40    12. References  . . . =
. . . . . . . . . . . . . . . . . . . . . .  40

      
   Appendix A.  =
Acknowledgments  . . . . . . . . . . . . . . . . . .  44      12.1.  Normative References . . . . . . . . =
. . . . . . . . . .  40

      
   Appendix B.  =
Document Change Log  . . . . . . . . . . . . . . . .  44      12.2.  Informative References . . . . . . . =
. . . . . . . . . .  41

      
     B.1.  =
Changes to draft-ietf-lisp-rfc6833bis-12  =
. . . . . . . .  44    Appendix A.  Acknowledgments  . . . . . . . . . . . =
. . . . . . .  45

      
     B.2.  =
Changes to draft-ietf-lisp-rfc6833bis-11  =
. . . . . . . .  44    Appendix B.  Document Change Log  . . . . . . . . . =
. . . . . . .  45

      
     B.3.  =
Changes to draft-ietf-lisp-rfc6833bis-10  =
. . . . . . . .  44      B.1.  Changes to draft-ietf-lisp-rfc6833bis-13  . . . . . . . .  =
45

      
     B.4.  =
Changes to draft-ietf-lisp-rfc6833bis-09  =
. . . . . . . .  44      B.2.  Changes to draft-ietf-lisp-rfc6833bis-12  . . . . . . . .  =
45

      
     B.5.  =
Changes to draft-ietf-lisp-rfc6833bis-08  =
. . . . . . . .  44      B.3.  Changes to draft-ietf-lisp-rfc6833bis-11  . . . . . . . .  =
45

      
     B.6.  =
Changes to draft-ietf-lisp-rfc6833bis-07  =
. . . . . . . .  45      B.4.  Changes to draft-ietf-lisp-rfc6833bis-10  . . . . . . . .  =
45

      
     B.7.  =
Changes to draft-ietf-lisp-rfc6833bis-06  =
. . . . . . . .  45      B.5.  Changes to draft-ietf-lisp-rfc6833bis-09  . . . . . . . .  =
46

      
     B.8.  =
Changes to draft-ietf-lisp-rfc6833bis-05  =
. . . . . . . .  46      B.6.  Changes to draft-ietf-lisp-rfc6833bis-08  . . . . . . . .  =
46

      
     B.9.  =
Changes to draft-ietf-lisp-rfc6833bis-04  =
. . . . . . . .  46      B.7.  Changes to draft-ietf-lisp-rfc6833bis-07  . . . . . . . .  =
46

      
     B.10. =
Changes to draft-ietf-lisp-rfc6833bis-03  =
. . . . . . . .  46      B.8.  Changes to draft-ietf-lisp-rfc6833bis-06  . . . . . . . .  =
47

      
     B.11. =
Changes to draft-ietf-lisp-rfc6833bis-02  =
. . . . . . . .  46      B.9.  Changes to draft-ietf-lisp-rfc6833bis-05  . . . . . . . .  =
47

      
     B.12. =
Changes to draft-ietf-lisp-rfc6833bis-01  =
. . . . . . . .  46      B.10. Changes to draft-ietf-lisp-rfc6833bis-04  . . . . . . . .  =
47

      
     B.13. =
Changes to draft-ietf-lisp-rfc6833bis-00  =
. . . . . . . .  47      B.11. Changes to draft-ietf-lisp-rfc6833bis-03  . . . . . . . .  =
47

      
     B.14. =
Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . .  47      B.12. =
Changes to draft-ietf-lisp-rfc6833bis-02  =
. . . . . . . .  48

      
   Authors' =
Addresses  . . . . . . . . . . . . . . . . . . . . . . .  48      B.13. =
Changes to draft-ietf-lisp-rfc6833bis-01  =
. . . . . . . .  48

      
 =
     B.14. Changes to draft-ietf-lisp-rfc6833bis-00  . . . . . . . .  =
48

      
 =
     B.15. Changes =
to draft-farinacci-lisp-rfc6833bis-00 . . . . . .  48

      
 =
   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

      
   achieve this =
separation, LISP defines protocol mechanisms for mapping =
   achieve this separation, LISP defines =
protocol mechanisms for mapping

      
 =


      
skipping to =
change at =
page 3, line 51 =C2=B6 =
skipping to change at page 4, line 5 =C2=B6

      
   The LISP =
Mapping Service defines two new types of LISP-speaking    The LISP Mapping Service defines two new types of =
LISP-speaking

      
   devices: the =
Map-Resolver, which accepts Map-Requests from an Ingress =
   devices: the Map-Resolver, which accepts =
Map-Requests from an Ingress

      
   Tunnel Router =
(ITR) and "resolves" the EID-to-RLOC mapping using a    Tunnel Router (ITR) and "resolves" the EID-to-RLOC =
mapping using a

      
   mapping =
database; and the Map-Server, which learns authoritative EID- =
   mapping database; and the Map-Server, which =
learns authoritative EID-

      
   to-RLOC =
mappings from an Egress Tunnel Router (ETR) and publishes =
   to-RLOC mappings from an Egress Tunnel =
Router (ETR) and publishes

      
   them in a =
database.    them in a =
database.

      
 =


      
   This LISP =
Control-Plane Mapping Service can be used by many different =
   This LISP Control-Plane Mapping Service can =
be used by many different

      
   =
encapsulation-based or translation-based Data-Planes which =
include    encapsulation-based or =
translation-based Data-Planes which include

      
   but are not =
limited to the ones defined in LISP RFC 6830bis    but are not limited to the ones defined in LISP RFC =
6830bis

      

      
   =
[I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN    [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.ietf-lisp-gpe], VXLAN

      
                =
                                                          =
   [RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], and ILA

      
   [RFC7348], =
VXLAN-GPE [I-D.quinn-vxlan-gpe], and =
ILA 

      
   =
[I-D.herbert-intarea-ila].    =
[I-D.herbert-intarea-ila].

      
 =


      
   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 that while this document assumes a =
LISP-ALT database mapping

      
 =


      
skipping to =
change at =
page 4, line 32 =C2=B6 =
skipping to change at page 4, line 33 =C2=B6

      
   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 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].    =
document are to be interpreted as described in [RFC2119] and

      
 =
   =
[RFC8174].

      
 =


      
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 11, line 17 =C2=B6 =
skipping to change at page 11, line =
17 =C2=B6

      
 =


      
   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].

      
 =


      
   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.rodrigueznatal-lisp-pubsub] for =
details.       procedures in =
[I-D.ietf-lisp-pubsub] for =
details.

      
 =


      
   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 24, line 7 =C2=B6 =
skipping to change at page 24, line 7 =C2=B6

      
      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 10.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 message digest used =
from the output

      
      of the MAC =
algorithm.  The entire Map-Register payload is       of the MAC algorithm.  The entire Map-Register =
payload is

      
 =


      
skipping to =
change at =
page 28, line 16 =C2=B6 =
skipping to change at page 28, line =
16 =C2=B6

      
 =


      
   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

      
   Request (SMR), =
a Control-Plane push-based mechanism.  An additional    Request (SMR), a Control-Plane push-based mechanism.  =
An additional

      
   Control-Plane =
mechanism based on the Publish/subscribe paradigm is    Control-Plane mechanism based on the =
Publish/subscribe paradigm is

      

      
   specified in =
[I-D.rodrigueznatal-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 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

      
 =


      
skipping to =
change at =
page 37, line 33 =C2=B6 =
skipping to change at page 37, line =
33 =C2=B6

      
   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.  IANA =
Considerations 10.  Changes since RFC 6833

      
 =


      
 =
   For implementation =
considerations, the following changes have been

      
 =
   made to this =
document since RFC 6833 was published:

      
 =


      
 =
   o  A Map-Notify-Ack =
message is added in this docuemnt to provide

      
 =
      reliability for =
Map-Notify messages.  Any receivers of a Map-

      
 =
      Notify message =
must respond with a Map-Notify-Ack message.  Map-

      
 =
      Servers who are =
senders of Map-Notify messages, must queue the

      
 =
      Map-Notify =
contents until they receive a Map-Notify-Ack with the

      
 =
      nonce used in the =
Map-Notify message.

      
 =


      
 =
   o  This document is =
incorporating the codepoint for the Map-Referral

      
 =
      message from the =
LISP-DDT specification [RFC8111] to indicate that

      
 =
      a Map-Server must =
send the final Map-Referral message when it

      
 =
      participates in =
the LISP-DDT mapping system procedures.

      
 =


      
 =
   o  The "m", "I", =
"L", and "D" bits are added to the Map-Request

      
 =
      message.  See =
Section 5.3 for details.

      
 =


      
 =
   o  The "S", "I", =
"E", "T", "a", and "m" bits are added to the Map-

      
 =
      Register message. =
 See Section 5.6 for details.

      
 =


      
 =
   o  The 16-bit Key-ID =
field of the Map-Register message has been split

      
 =
      into a 8-bit =
Key-ID field and a 8-bit Algorithm-ID field.

      
 =


      
 =
   o  This document =
adds two new Action values that are in an EID-record

      
 =
      that appear in =
Map-Reply, Map-Register, Map-Notify, and Map-

      
 =
      Notify-Ack =
messages.  The Drop/Policy-Denied and Drop/Auth-Failure

      
 =
      are the =
descriptions for the two new action values.  See

      
 =
      Section 5.4 for =
details.

      
 =


      
 =
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".

      
 =


      

      
10.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

      
   =
follows:    follows:

      
 =


      
        Keyword   =
        Port    Transport Layer   Description         Keyword           Port    Transport Layer   =
Description

      
        -------   =
        ----    ---------------   -----------         -------           ----    ---------------   =
-----------

      
        =
lisp-control      4342    udp               LISP Control =
Packets         lisp-control      4342 =
   udp               LISP Control Packets

      
 =


      

      
10.2.  LISP Packet Type Codes 11.2.  LISP Packet Type =
Codes

      
 =


      
   It is being =
requested that the IANA be authoritative for LISP Packet =
   It is being requested that the IANA be =
authoritative for LISP Packet

      
   Type =
definitions and that it refers to this document as well as =
   Type definitions and that it refers to this =
document as well as

      
   [RFC8113] as =
references.    [RFC8113] as =
references.

      
 =


      
   Based on =
deployment experience of [RFC6830], the Map-Notify-Ack    Based on deployment experience of [RFC6830], the =
Map-Notify-Ack

      
   message, =
message type 5, was added to this document.  This document =
   message, message type 5, was added to this =
document.  This document

      
   requests IANA =
to add it to the LISP Packet Type Registry.    requests IANA to add it to the LISP Packet Type =
Registry.

      
 =


      
         Name     =
            Number          Defined in  =
        Name                 Number          Defined in

      
         ----     =
            ------          ----------- =
         ----                 ------          -----------

      
         LISP =
Map-Notify-Ack  5               RFC6833bis          LISP Map-Notify-Ack  5               =
RFC6833bis

      
 =


      

      
10.3.  LISP ACT and Flag Fields 11.3.  LISP ACT and Flag =
Fields

      
 =


      
   New ACT values =
can be allocated through IETF review or IESG approval.    New ACT values can be allocated through IETF review =
or IESG approval.

      
   Four values =
have already been allocated by [RFC6830].  This    Four values have already been allocated by [RFC6830]. =
 This

      
   specification =
changes the name of ACT type 3 value from "Drop" to    specification changes the name of ACT type 3 value =
from "Drop" to

      
   =
"Drop/No-Reason" as well as adding two new ACT values, the =
"Drop/    "Drop/No-Reason" as well as =
adding two new ACT values, the "Drop/

      
   Policy-Denied" =
(type 4) and "Drop/Authentication-Failure" (type 5).    Policy-Denied" (type 4) and =
"Drop/Authentication-Failure" (type 5).

      
 =


      
   Value  Action  =
       Description                          Reference    Value  Action         Description                     =
     Reference

      
   -----  ------  =
       -----------                          ---------    -----  ------         -----------                     =
     ---------

      
   4      Drop/   =
       A Packet matching this Map-Cache     RFC6833bis    4      Drop/          A Packet matching this =
Map-Cache     RFC6833bis

      
 =


      
skipping =
to change at page 39, line =
7 =C2=B6 =
skipping to change at page 39, line =
35 =C2=B6

      
          =
Auth-Failure   entry is dropped because the           Auth-Failure   entry is dropped because =
the

      
                  =
       Map-Request for target EID fails an                          Map-Request for target EID =
fails an

      
                  =
       authentication check by the xTR or                          authentication check by the xTR =
or

      
                  =
       the mapping system.             =
             the mapping system.

      
 =


      
   In addition, =
LISP has a number of flag fields and reserved fields,    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 =
   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    bits for flags in these fields can be implemented =
after IETF review

      
   or IESG =
approval, but these need not be managed by IANA.    or IESG approval, but these need not be managed by =
IANA.

      
 =


      

      
10.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.

      
 =


      

      
10.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

      
   submitted.  =
This document renames the registry to "LISP Algorithm ID =
   submitted.  This document renames the =
registry to "LISP Algorithm ID

      
   Numbers" and =
requests the IANA to make the name change.    Numbers" and requests the IANA to make the name =
change.

      
 =


      
   The following =
Algorithm ID values are defined by this specification    The following Algorithm ID values are defined by this =
specification

      
   as used in any =
packet type that references a 'Algorithm ID' field:    as used in any packet type that references a =
'Algorithm ID' field:

      
 =


      
         Name     =
            Number          Defined in  =
        Name                 Number          Defined in

      
         =
-----------------------------------------------          =
-----------------------------------------------

      
         None     =
            0               RFC6833bis  =
        None                 0               RFC6833bis

      
         =
HMAC-SHA-1-96        1               [RFC2404]          HMAC-SHA-1-96        1               =
[RFC2404]

      
         =
HMAC-SHA-256-128     2               [RFC4868]          HMAC-SHA-256-128     2               =
[RFC4868]

      
 =


      
   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.

      
 =


      

      
11.  References 12.  References

      
 =


      

      
11.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-00 (work in progress), July =
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-14 (work in progress),

      
 =


      
skipping =
to change at page 40, line =
25 =C2=B6 =
skipping to change at page 41, line =
5 =C2=B6

      
   [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>.

      
 =


      

      
11.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.

      
 =


      
   =
[I-D.ermagan-lisp-nat-traversal]    =
[I-D.ermagan-lisp-nat-traversal]

      
              =
Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, =
              Ermagan, V., Farinacci, D., =
Lewis, D., Skriver, J., Maino,

      
              F., =
and C. White, "NAT traversal for LISP", draft-ermagan-               F., and C. White, "NAT traversal for =
LISP", draft-ermagan-

      
              =
lisp-nat-traversal-14 (work in progress), April 2018.               lisp-nat-traversal-14 (work in progress), =
April 2018.

      
 =


      
 =


      
skipping =
to change at page 40, line =
47 =C2=B6 =
skipping to change at page 41, line =
27 =C2=B6

      
              =
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.

      
 =


      

      
 =
   [I-D.ietf-lisp-gpe]

      
 =
              Maino, =
F., Lemon, J., Agarwal, P., Lewis, D., and M.

      
 =
              Smith, =
"LISP Generic Protocol Extension", draft-ietf-lisp-

      
 =
              gpe-05 =
(work in progress), August 2018.

      
 =
                                               =
                          

      
   =
[I-D.ietf-lisp-introduction]    =
[I-D.ietf-lisp-introduction]

      
              =
Cabellos-Aparicio, A. and D. Saucez, "An Architectural               Cabellos-Aparicio, A. and D. Saucez, "An =
Architectural

      
              =
Introduction to the Locator/ID Separation Protocol               Introduction to the Locator/ID Separation =
Protocol

      
              =
(LISP)", draft-ietf-lisp-introduction-13 (work in               (LISP)", draft-ietf-lisp-introduction-13 =
(work in

      
              =
progress), April 2015.               =
progress), April 2015.

      
 =


      
   =
[I-D.ietf-lisp-mn]    =
[I-D.ietf-lisp-mn]

      
              =
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP =
              Farinacci, D., Lewis, D., Meyer, =
D., and C. White, "LISP

      
              =
Mobile Node", draft-ietf-lisp-mn-02 (work in progress), =
              Mobile Node", =
draft-ietf-lisp-mn-02 (work in progress),

      
              =
April 2018.               April =
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-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.
 =


      

      
 =
   [I-D.ietf-nvo3-vxlan-gpe]

      
 =
              Maino, =
F., Kreeger, L., and U. Elzur, "Generic Protocol

      
 =
              Extension =
for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work

      
 =
              in =
progress), April 2018.

      
 =
                                               =
                          

      
   =
[I-D.ietf-opsec-icmp-filtering]    =
[I-D.ietf-opsec-icmp-filtering]

      
              =
Gont, F., Gont, G., and C. Pignataro, "Recommendations for =
              Gont, F., Gont, G., and C. =
Pignataro, "Recommendations for

      
              =
filtering ICMP messages", draft-ietf-opsec-icmp-               filtering ICMP messages", =
draft-ietf-opsec-icmp-

      
              =
filtering-04 (work in progress), July 2013.               filtering-04 (work in progress), July =
2013.

      
 =


      

      
   [I-D.lewis-lisp-gpe] 

      
              Lewis, D., Lemon, J., Agarwal, P., =
Kreeger, L., Quinn, P., 

      
              Smith, M., Yadav, N., and F. Maino, "LISP =
Generic Protocol 

      
              Extension", draft-lewis-lisp-gpe-04 (work =
in progress), 

      
              December 2017. 

      
                =
                                                          =


      
   =
[I-D.meyer-loc-id-implications]    =
[I-D.meyer-loc-id-implications]

      
              =
Meyer, D. and D. Lewis, "Architectural Implications of               Meyer, D. and D. Lewis, "Architectural =
Implications of

      
              =
Locator/ID Separation", draft-meyer-loc-id-implications-01 =
              Locator/ID Separation", =
draft-meyer-loc-id-implications-01

      
              =
(work in progress), January 2009.      =
         (work in progress), January 2009.

      
 =


      

      
   [I-D.quinn-vxlan-gpe] 

      
              Quinn, P., Manur, R., Kreeger, L., Lewis, =
D., Maino, F., 

      
              Smith, M., Agarwal, P., Yong, L., Xu, X., =
Elzur, U., Garg, 

      
              P., and D. Melman, "Generic Protocol =
Extension for VXLAN", 

      
              draft-quinn-vxlan-gpe-04 (work in =
progress), February 

      
              2015. 

      
                =
                                                          =


      
   =
[I-D.rodrigueznatal-lisp-oam]    =
[I-D.rodrigueznatal-lisp-oam]

      
              =
Rodriguez-Natal, A., Cabellos-Aparicio, A., Portoles-               Rodriguez-Natal, A., Cabellos-Aparicio, =
A., Portoles-

      
              =
Comeras, M., Kowal, M., Lewis, D., and F. Maino, "LISP-OAM =
              Comeras, M., Kowal, M., Lewis, =
D., and F. Maino, "LISP-OAM

      
              =
(Operations, Administration and Management): Use cases and =
              (Operations, Administration and =
Management): Use cases and

      
              =
requirements", draft-rodrigueznatal-lisp-oam-08 (work in =
              requirements", =
draft-rodrigueznatal-lisp-oam-08 (work in

      
              =
progress), June 2018.               =
progress), June 2018.

      
 =


      

      
   [I-D.rodrigueznatal-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-rodrigueznatal- 

      
              lisp-pubsub-02 (work in progress), March =
2018. 

      
                =
                                                          =


      
   [RFC1035]  =
Mockapetris, P., "Domain names - implementation and    [RFC1035]  Mockapetris, P., "Domain names - =
implementation and

      
              =
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, =
              specification", STD 13, RFC 1035, =
DOI 10.17487/RFC1035,

      
              =
November 1987, <https://www.rfc-editor.org/info/rfc1035>. =
              November 1987, =
<https://www.rfc-editor.org/info/rfc1035>.

      
 =


      
   [RFC1071]  =
Braden, R., Borman, D., and C. Partridge, "Computing the =
   [RFC1071]  Braden, R., Borman, D., and C. =
Partridge, "Computing the

      
              =
Internet checksum", RFC 1071, DOI 10.17487/RFC1071,               Internet checksum", RFC 1071, DOI =
10.17487/RFC1071,

      
              =
September 1988, =
<https://www.rfc-editor.org/info/rfc1071>.               September 1988, =
<https://www.rfc-editor.org/info/rfc1071>.

      
 =


      
   [RFC2104]  =
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- =
   [RFC2104]  Krawczyk, H., Bellare, M., and R. =
Canetti, "HMAC: Keyed-

      
              =
Hashing for Message Authentication", RFC 2104,               Hashing for Message Authentication", RFC =
2104,

      
 =


      
skipping =
to change at page 43, line =
43 =C2=B6 =
skipping to change at page 44, line =
25 =C2=B6

      
              =
Protocol (LISP): Shared Extension Message & IANA Registry =
              Protocol (LISP): Shared Extension =
Message & IANA Registry

      
              for =
Packet Type Allocations", RFC 8113,    =
           for Packet Type Allocations", RFC 8113,

      
              DOI =
10.17487/RFC8113, March 2017,          =
     DOI 10.17487/RFC8113, March 2017,
              =
<https://www.rfc-editor.org/info/rfc8113>.               =
<https://www.rfc-editor.org/info/rfc8113>.

      
 =


      
   [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

      
 =
              2119 Key =
Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,

      
 =
              May 2017, =
<https://www.rfc-editor.org/info/rfc8174>.

      
 =
                                               =
                          

      
   [RFC8378]  =
Moreno, V. and D. Farinacci, "Signal-Free Locator/ID    [RFC8378]  Moreno, V. and D. Farinacci, "Signal-Free =
Locator/ID

      
              =
Separation Protocol (LISP) Multicast", RFC 8378,               Separation Protocol (LISP) Multicast", RFC =
8378,

      
              DOI =
10.17487/RFC8378, May 2018,            =
   DOI 10.17487/RFC8378, May 2018,

      
              =
<https://www.rfc-editor.org/info/rfc8378>.               =
<https://www.rfc-editor.org/info/rfc8378>.

      
 =


      
Appendix A.  =
Acknowledgments Appendix A.  =
Acknowledgments

      
 =


      
   The authors =
would like to thank Greg Schudel, Darrel Lewis, John    The authors would like to thank Greg Schudel, Darrel =
Lewis, John

      
   Zwiebel, =
Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, =
   Zwiebel, Andrew Partan, Dave Meyer, Isidor =
Kouvelas, Jesper Skriver,

      
   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-12 B.1. =
 Changes to draft-ietf-lisp-rfc6833bis-13

      
 =


      
 =
   o  Posted August =
2018.

      
 =


      
 =
   o  Final editorial =
changes before RFC submission for Proposed

      
 =
      =
Standard.

      
 =


      
 =
   o  Added section =
"Changes since RFC 6833" so implementators are

      
 =
      informed of any =
changes since the last RFC publication.

      
 =


      
 =
B.2.  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.2.  Changes to =
draft-ietf-lisp-rfc6833bis-11 B.3.  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.3.  Changes to =
draft-ietf-lisp-rfc6833bis-10 B.4.  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.4.  Changes to =
draft-ietf-lisp-rfc6833bis-09 B.5.  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.5.  Changes to =
draft-ietf-lisp-rfc6833bis-08 B.6.  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.6.  Changes to =
draft-ietf-lisp-rfc6833bis-07 B.7.  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 45, line =
39 =C2=B6 =
skipping to change at page 47, line =
5 =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.7.  Changes to =
draft-ietf-lisp-rfc6833bis-06 B.8.  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.8.  Changes to =
draft-ietf-lisp-rfc6833bis-05 B.9.  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.9.  Changes to =
draft-ietf-lisp-rfc6833bis-04 B.10.  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.10.  Changes to =
draft-ietf-lisp-rfc6833bis-03 B.11.  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.11.  Changes to =
draft-ietf-lisp-rfc6833bis-02 B.12.  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.12.  Changes to =
draft-ietf-lisp-rfc6833bis-01 B.13.  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.13.  Changes to =
draft-ietf-lisp-rfc6833bis-00 B.14.  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.14.  Changes to =
draft-farinacci-lisp-rfc6833bis-00 B.15.  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. 

     
80 lines changed or =
deleted 126 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=_89A825BA-DB37-4020-9AD1-0E28AD907930
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Aug 20, 2018, at 2:42 PM, Dino Farinacci  =
wrote:
>=20
> WG, here is a diff with changes to reflect Scott=E2=80=99s comment. I =
wanted the list of implementator to-be-aware changes to get working =
group quick review.
>=20
> I=E2=80=99m about to add a =E2=80=9CChanges since RFC 6833=E2=80=9D =
section to RFC 6833bis as well.
>=20
> Thanks,
> Dino
>=20
> 
>=20
>> On Aug 20, 2018, at 9:03 AM, Scott O. Bradner  wrote:
>>=20
>> a specific section only dealing with the changes since the RFC is =
best
>>=20
>> there is too much noise in the per iteration log (which as you =
already note should be removed)
>>=20
>> Scott
>>=20
>>> On Aug 20, 2018, at 8:57 AM, Dino Farinacci  =
wrote:
>>>=20
>>> Note we do have a Document Change Log in Appendix B detailing the =
changes put in each version starting with RFC6830. Would that suffice? =
Or you still think a specific section is required?
>>>=20
>>> Dino
>>>=20
>>> 
>>>=20
>>>> On Aug 20, 2018, at 8:44 AM, Scott O. Bradner  =
wrote:
>>>>=20
>>>> it would be best to have a section called =E2=80=9Cchanges since =
RFC 6830=E2=80=9D so there is no ambiguity that the section covers the =
changes
>>>>=20
>>>> it would be fine to have that section just say =E2=80=9CSee  =
=E2=80=9CImplementation Considerations.=E2=80=9D
>>>>=20
>>>> Scott
>>>>=20
>>>>=20
>>>>> On Aug 20, 2018, at 8:26 AM, Dino Farinacci  =
wrote:
>>>>>=20
>>>>>=20
>>>>>> Hi Dino
>>>>>>> On Aug 20, 2018, at 8:18 AM, Dino Farinacci =
 wrote:
>>>>>>>=20
>>>>>>> There were little changes that an implementor would need to know =
about for the data-plane. But there were for the control-plane (i.e. =
RFC6833bis). But in either case, we=E2=80=99ll add a section in each bis =
document.
>>>>>>=20
>>>>>> thanks - even if the section says =E2=80=9Cnothing to worry =
about=E2=80=9D it will be useful
>>>>>=20
>>>>> I=E2=80=99ll title it =E2=80=9CImplementation Considerations=E2=80=9D=
 and place it between 17 and 18?
>>>>>=20
>>>>> 14. Multicast Considerations  . . . . . . . . . . . . . . . . . .  =
29
>>>>> 15. Router Performance Considerations . . . . . . . . . . . . . .  =
30
>>>>> 16. Security Considerations . . . . . . . . . . . . . . . . . . .  =
31
>>>>> 17. Network Management Considerations . . . . . . . . . . . . . .  =
32
>>>>> 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  =
32
>>>>>=20
>>>>>=20
>>>>>>>=20
>>>>>>> Are you going to be reviewer for 6833bis as well?
>>>>>>=20
>>>>>> not assigned that yet but I will take a look
>>>>>=20
>>>>> I will try to get the sections done in the next day or so. I=E2=80=99=
m at the 3GPP meetings this week.
>>>>>=20
>>>>> Dino
>>>>>=20
>>>>>>=20
>>>>>> Scott
>>>>>>>=20
>>>>>>> Dino
>>>>>>>=20
>>>>>>>> On Aug 20, 2018, at 6:14 AM, Scott O. Bradner  =
wrote:
>>>>>>>>=20
>>>>>>>> I was just assigned to do a ops-dir review of  =
draft-ietf-lisp-rfc6830bis-14
>>>>>>>>=20
>>>>>>>> this is not the review - that will come soon
>>>>>>>>=20
>>>>>>>> but since this is a =E2=80=9Cbis=E2=80=9D document that is to =
replace an existing RFC it needs to have a=20
>>>>>>>> =E2=80=9Cchanges since RFC 6830=E2=80=9D section so that =
implementors of the earlier RFC will be able to tell
>>>>>>>> what they need to change to bring their code up to date without =
having to compare the=20
>>>>>>>> RFCs line by line (and likely miss something)
>>>>>>>>=20
>>>>>>>> Scott
>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_89A825BA-DB37-4020-9AD1-0E28AD907930--


From nobody Mon Aug 20 12:32: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 E98C812F1A5 for ; Mon, 20 Aug 2018 12:32:42 -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 GxdSdMd5TIDZ for ; Mon, 20 Aug 2018 12:32:41 -0700 (PDT)
Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 D489E129619 for ; Mon, 20 Aug 2018 12:32:40 -0700 (PDT)
Received: by mail-ua1-x92b.google.com with SMTP id h1-v6so10417228uao.8 for ; Mon, 20 Aug 2018 12:32: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=TMtTic6I1P+apNHeXUb1k9zCQpByC4n2MV0iJ6EQ8QU=; b=X9Um1Qyq5hk0qlSMRcs9rKzILMAaXE18+Lh6w3/MMuqGrYb2Ok0TjX5EVCmTNZr0Zm 9suVLbQqGhSORFKG5eQj9oglqR38SmQQ01n7R3ai/NOVSe5wecrVhmSM6+9Gx7MRpPHt xto4WXii+8VX7K8pu+Fw+yb/l4ZsXBp7JPeldoTfNxQwrHCr3NEjTgfDkE+WxEV30YWA fqcZb3qxBDAjkokDx/YMHZomDF6iGuNJg+JSE02WMXL3TCNtub6Tc3aW1UEQBax4FoW/ Q9b+sJkkd0Ni6/IHn2U6iW1fGTz6ZSIZHUbOEJpWNaY4DTPTwaXtweBd4CT9IIaC4S14 BQbQ==
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=TMtTic6I1P+apNHeXUb1k9zCQpByC4n2MV0iJ6EQ8QU=; b=XNpySUUcXp+LvEPy4lI07MO6M9tSbkAZ460gsxvNeHD2l/guNmJgKxCNgUN57jxYrZ p+99HkAVP+fi8UGSrcmsUsbWY61ijrzP4JqGXtLmsCmqWFbo8Y8i4bCWWrhiWyooLQzq e6H7hBcL40HeQs0tsFPNaq1KPX+mwPyn21HosyyxkhY7h0K2uYV5Mkv8Ovf6+4cDCZM3 113HySxdiTdKvCnOS0F/04pAK98a0HqoxXUE4tRnEjszy/1Y/GCwnbB2idrCwa3VuQL7 fxPacOXnlmhPlUH7IymkY2SdmFpOgZJT1Yc8B3Xs9+sq4WtLD9cN5ccU/vbLpZdd/vQN Od5g==
X-Gm-Message-State: AOUpUlHTGaxADp40NM/3D5wDEGJdwVIR4XeWSxAdyAiOj6HKHzHGkFgt XaT4ie3WDpJgdF+Dw4M1rHOjq2gR
X-Google-Smtp-Source: AA+uWPwOp7QC9R9rahi/iS0NHpjKl1oAVBTsLkHyHmCNHGnBLgWdEFKrhGx/JS42lGhrPGnM2/J9Jw==
X-Received: by 2002:ab0:2687:: with SMTP id t7-v6mr31334740uao.195.1534793558860;  Mon, 20 Aug 2018 12:32:38 -0700 (PDT)
Received: from [10.10.0.236] ([45.73.155.132]) by smtp.gmail.com with ESMTPSA id d71-v6sm2898228vka.47.2018.08.20.12.32.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Aug 2018 12:32: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: 
Date: Mon, 20 Aug 2018 15:32:37 -0400
Cc: lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com>  <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com>  <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com>   
To: Fabio Maino 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14
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, 20 Aug 2018 19:32:43 -0000

Will fix. Thanks for the catch Fabio.

Dino

> On Aug 20, 2018, at 2:56 PM, Fabio Maino =
 wrote:
>=20
> Looks good Dino.=20
>=20
> Noted one nit in section 18, not worth spinning a new version IMO:=20
>=20
> "The is 1 remaining bit" -> "The 1 remaining bit"
>=20
> Fabio
>=20
>=20
> On 8/20/18 11:42 AM, Dino Farinacci wrote:
>> WG, here is a diff with changes to reflect Scott=E2=80=99s comment. I =
wanted the list of implementator to-be-aware changes to get working =
group quick review.
>>=20
>> I=E2=80=99m about to add a =E2=80=9CChanges since RFC 6833=E2=80=9D =
section to RFC 6833bis as well.
>>=20
>> Thanks,
>> Dino
>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Aug 20, 2018, at 9:03 AM, Scott O. Bradner 
>>>  wrote:
>>>=20
>>> a specific section only dealing with the changes since the RFC is =
best
>>>=20
>>> there is too much noise in the per iteration log (which as you =
already note should be removed)
>>>=20
>>> Scott
>>>=20
>>>=20
>>>> On Aug 20, 2018, at 8:57 AM, Dino Farinacci 
>>>>  wrote:
>>>>=20
>>>> Note we do have a Document Change Log in Appendix B detailing the =
changes put in each version starting with RFC6830. Would that suffice? =
Or you still think a specific section is required?
>>>>=20
>>>> Dino
>>>>=20
>>>> 
>>>>=20
>>>>=20
>>>>> On Aug 20, 2018, at 8:44 AM, Scott O. Bradner 
>>>>>  wrote:
>>>>>=20
>>>>> it would be best to have a section called =E2=80=9Cchanges since =
RFC 6830=E2=80=9D so there is no ambiguity that the section covers the =
changes
>>>>>=20
>>>>> it would be fine to have that section just say =E2=80=9CSee  =
=E2=80=9CImplementation Considerations.=E2=80=9D
>>>>>=20
>>>>> Scott
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On Aug 20, 2018, at 8:26 AM, Dino Farinacci 
>>>>>>  wrote:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> Hi Dino
>>>>>>>=20
>>>>>>>> On Aug 20, 2018, at 8:18 AM, Dino Farinacci =

>>>>>>>>  wrote:
>>>>>>>>=20
>>>>>>>> There were little changes that an implementor would need to =
know about for the data-plane. But there were for the control-plane =
(i.e. RFC6833bis). But in either case, we=E2=80=99ll add a section in =
each bis document.
>>>>>>>>=20
>>>>>>> thanks - even if the section says =E2=80=9Cnothing to worry =
about=E2=80=9D it will be useful
>>>>>>>=20
>>>>>> I=E2=80=99ll title it =E2=80=9CImplementation Considerations=E2=80=9D=
 and place it between 17 and 18?
>>>>>>=20
>>>>>> 14. Multicast Considerations  . . . . . . . . . . . . . . . . . . =
 29
>>>>>> 15. Router Performance Considerations . . . . . . . . . . . . . . =
 30
>>>>>> 16. Security Considerations . . . . . . . . . . . . . . . . . . . =
 31
>>>>>> 17. Network Management Considerations . . . . . . . . . . . . . . =
 32
>>>>>> 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . =
 32
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>>> Are you going to be reviewer for 6833bis as well?
>>>>>>>>=20
>>>>>>> not assigned that yet but I will take a look
>>>>>>>=20
>>>>>> I will try to get the sections done in the next day or so. I=E2=80=99=
m at the 3GPP meetings this week.
>>>>>>=20
>>>>>> Dino
>>>>>>=20
>>>>>>=20
>>>>>>> Scott
>>>>>>>=20
>>>>>>>> Dino
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On Aug 20, 2018, at 6:14 AM, Scott O. Bradner 
>>>>>>>>>  wrote:
>>>>>>>>>=20
>>>>>>>>> I was just assigned to do a ops-dir review of  =
draft-ietf-lisp-rfc6830bis-14
>>>>>>>>>=20
>>>>>>>>> this is not the review - that will come soon
>>>>>>>>>=20
>>>>>>>>> but since this is a =E2=80=9Cbis=E2=80=9D document that is to =
replace an existing RFC it needs to have a=20
>>>>>>>>> =E2=80=9Cchanges since RFC 6830=E2=80=9D section so that =
implementors of the earlier RFC will be able to tell
>>>>>>>>> what they need to change to bring their code up to date =
without having to compare the=20
>>>>>>>>> RFCs line by line (and likely miss something)
>>>>>>>>>=20
>>>>>>>>> Scott
>>>>>>>>>=20
>>=20
>>=20
>> _______________________________________________
>> lisp mailing list
>>=20
>> 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 Aug 20 12:35: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 1D2D6130DC6; Mon, 20 Aug 2018 12:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level: 
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 dkgrz-E_bRmv; Mon, 20 Aug 2018 12:35:04 -0700 (PDT)
Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F33212F18C; Mon, 20 Aug 2018 12:35:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id CFFAF70E245A; Mon, 20 Aug 2018 15:34:59 -0400 (EDT)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiP0pZLjlGnb; Mon, 20 Aug 2018 15:34:52 -0400 (EDT)
Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 466E970E244B; Mon, 20 Aug 2018 15:34:50 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Scott O. Bradner" 
In-Reply-To: <9BE375D7-50E1-4FF1-B59C-93C203CFBDD0@gmail.com>
Date: Mon, 20 Aug 2018 15:34:49 -0400
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E88630B-404F-4E0D-8CE5-5DD602A59D25@sobco.com>
References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com>  <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com>  <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com>   <9BE375D7-50E1-4FF1-B59C-93C203CFBDD0@gmail.com>
To: Dino Farinacci 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14
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, 20 Aug 2018 19:35:05 -0000

looks just right=20

thanks

Scott

> On Aug 20, 2018, at 3:29 PM, Dino Farinacci  =
wrote:
>=20
> And here is the diff for the same type of changes for 6833bis.
>=20
> Thanks,
> Dino
>=20
> 
>=20
>> On Aug 20, 2018, at 2:42 PM, Dino Farinacci  =
wrote:
>>=20
>> WG, here is a diff with changes to reflect Scott=E2=80=99s comment. I =
wanted the list of implementator to-be-aware changes to get working =
group quick review.
>>=20
>> I=E2=80=99m about to add a =E2=80=9CChanges since RFC 6833=E2=80=9D =
section to RFC 6833bis as well.
>>=20
>> Thanks,
>> Dino
>>=20
>> 
>>=20
>>> On Aug 20, 2018, at 9:03 AM, Scott O. Bradner  wrote:
>>>=20
>>> a specific section only dealing with the changes since the RFC is =
best
>>>=20
>>> there is too much noise in the per iteration log (which as you =
already note should be removed)
>>>=20
>>> Scott
>>>=20
>>>> On Aug 20, 2018, at 8:57 AM, Dino Farinacci  =
wrote:
>>>>=20
>>>> Note we do have a Document Change Log in Appendix B detailing the =
changes put in each version starting with RFC6830. Would that suffice? =
Or you still think a specific section is required?
>>>>=20
>>>> Dino
>>>>=20
>>>> 
>>>>=20
>>>>> On Aug 20, 2018, at 8:44 AM, Scott O. Bradner  =
wrote:
>>>>>=20
>>>>> it would be best to have a section called =E2=80=9Cchanges since =
RFC 6830=E2=80=9D so there is no ambiguity that the section covers the =
changes
>>>>>=20
>>>>> it would be fine to have that section just say =E2=80=9CSee  =
=E2=80=9CImplementation Considerations.=E2=80=9D
>>>>>=20
>>>>> Scott
>>>>>=20
>>>>>=20
>>>>>> On Aug 20, 2018, at 8:26 AM, Dino Farinacci  =
wrote:
>>>>>>=20
>>>>>>=20
>>>>>>> Hi Dino
>>>>>>>> On Aug 20, 2018, at 8:18 AM, Dino Farinacci =
 wrote:
>>>>>>>>=20
>>>>>>>> There were little changes that an implementor would need to =
know about for the data-plane. But there were for the control-plane =
(i.e. RFC6833bis). But in either case, we=E2=80=99ll add a section in =
each bis document.
>>>>>>>=20
>>>>>>> thanks - even if the section says =E2=80=9Cnothing to worry =
about=E2=80=9D it will be useful
>>>>>>=20
>>>>>> I=E2=80=99ll title it =E2=80=9CImplementation Considerations=E2=80=9D=
 and place it between 17 and 18?
>>>>>>=20
>>>>>> 14. Multicast Considerations  . . . . . . . . . . . . . . . . . . =
 29
>>>>>> 15. Router Performance Considerations . . . . . . . . . . . . . . =
 30
>>>>>> 16. Security Considerations . . . . . . . . . . . . . . . . . . . =
 31
>>>>>> 17. Network Management Considerations . . . . . . . . . . . . . . =
 32
>>>>>> 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . =
 32
>>>>>>=20
>>>>>>=20
>>>>>>>>=20
>>>>>>>> Are you going to be reviewer for 6833bis as well?
>>>>>>>=20
>>>>>>> not assigned that yet but I will take a look
>>>>>>=20
>>>>>> I will try to get the sections done in the next day or so. I=E2=80=99=
m at the 3GPP meetings this week.
>>>>>>=20
>>>>>> Dino
>>>>>>=20
>>>>>>>=20
>>>>>>> Scott
>>>>>>>>=20
>>>>>>>> Dino
>>>>>>>>=20
>>>>>>>>> On Aug 20, 2018, at 6:14 AM, Scott O. Bradner  =
wrote:
>>>>>>>>>=20
>>>>>>>>> I was just assigned to do a ops-dir review of  =
draft-ietf-lisp-rfc6830bis-14
>>>>>>>>>=20
>>>>>>>>> this is not the review - that will come soon
>>>>>>>>>=20
>>>>>>>>> but since this is a =E2=80=9Cbis=E2=80=9D document that is to =
replace an existing RFC it needs to have a=20
>>>>>>>>> =E2=80=9Cchanges since RFC 6830=E2=80=9D section so that =
implementors of the earlier RFC will be able to tell
>>>>>>>>> what they need to change to bring their code up to date =
without having to compare the=20
>>>>>>>>> RFCs line by line (and likely miss something)
>>>>>>>>>=20
>>>>>>>>> Scott
>>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


From nobody Mon Aug 20 12:42: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 81460130E30; Mon, 20 Aug 2018 12:42: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 I3HubF4BPfJl; Mon, 20 Aug 2018 12:42:57 -0700 (PDT)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 CF81C130DD8; Mon, 20 Aug 2018 12:42:56 -0700 (PDT)
Received: by mail-vk0-x22d.google.com with SMTP id w187-v6so2110118vkw.0; Mon, 20 Aug 2018 12:42: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=FDfQ17iHR7WUggDtCoxLXPbpgSZuyx+zrYn4TiganLM=; b=M7zohtG3E5qzabbQWxSVOe1RxWAe4uY1OR39do0DEafe7Ubk03mpBq+wEpPOVWE9PQ culsPqdu41beuf5XUYmQuxjyFOLF145pR2ykkLuy1IchOiU5FEQ5ttJ4Y/7yaH5OQnho 5hCs2Anlwrd2C96FE3qjbyuGv/poy3mILvpQmDlDNSAulbNGxUEKWY1vAH4IrVvoCt+Y O7MXmpLslvgxzRJeken7zbqNOvbugRfgWH9DJcgRPHS2AbgfaRxOII6UobJaEzkY6475 0/DP92Scgxp7uc7JDmiyh1r/v7QuD/SRigsST1a7JRV+UH5MJHHm2suhjcGbCLBN/eU1 JOFA==
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=FDfQ17iHR7WUggDtCoxLXPbpgSZuyx+zrYn4TiganLM=; b=hGCanrGENYrYmmdu9fWpdyyrYh5BynV5XcRQvLA/BPv8KveCuaDqnBEXVdfsSFYkYK 530SrYAuzMZG9zbjCH4D1Aj1XGt7lo4dgY3djMSCme9Xw6QiMznjSPIHo585mxrGMnHh CS+06/16lrcreChUKHaefNxuCDLbGncwgSyHqD0dpvuiD/gNMmrL2PcJfRP8U0iHbQx/ C8/j9gC7p2IhzdlWeBrp8givPIj748fK3TRVd7RV/w9AYWFN5CEnxfoHaWFmHPk/LWyb ZDMrBWthQEZi3Boq+ogOwIvUoaLEmR4WVV+EXGUK3ygVpV9udKEd/qo5YZrpLXNxOTMm ctyw==
X-Gm-Message-State: AOUpUlFDfg2sqp8jHum6LewRaxCf2RlHzwQYmtEUI7YezhxMreBV2/UR vAa74o1TJf6jzAyayfPLr1M=
X-Google-Smtp-Source: AA+uWPxNsH+9Thj9KtBELyCJjGu3UWWlnselN4ZYj/3ViJHwY6MrB6/fdqtv2Q96UDmaMCcl1dmtlA==
X-Received: by 2002:a1f:2bd8:: with SMTP id r207-v6mr32083900vkr.104.1534794175861;  Mon, 20 Aug 2018 12:42:55 -0700 (PDT)
Received: from [10.10.0.236] ([45.73.155.132]) by smtp.gmail.com with ESMTPSA id b15-v6sm2855665uak.40.2018.08.20.12.42.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Aug 2018 12:42:55 -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: <9E88630B-404F-4E0D-8CE5-5DD602A59D25@sobco.com>
Date: Mon, 20 Aug 2018 15:42:54 -0400
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F27055C-152D-432B-B372-B79739561D92@gmail.com>
References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com>  <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com>  <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com>   <9BE375D7-50E1-4FF1-B59C-93C203CFBDD0@gmail.com> <9E88630B-404F-4E0D-8CE5-5DD602A59D25@sobco.com>
To: "Scott O. Bradner" 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14
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, 20 Aug 2018 19:42:58 -0000

I=E2=80=99ll post both in a few days giving WG some time.

Dino

> On Aug 20, 2018, at 3:34 PM, Scott O. Bradner  wrote:
>=20
> looks just right=20
>=20
> thanks
>=20
> Scott
>=20
>> On Aug 20, 2018, at 3:29 PM, Dino Farinacci  =
wrote:
>>=20
>> And here is the diff for the same type of changes for 6833bis.
>>=20
>> Thanks,
>> Dino
>>=20
>> 
>>=20
>>> On Aug 20, 2018, at 2:42 PM, Dino Farinacci  =
wrote:
>>>=20
>>> WG, here is a diff with changes to reflect Scott=E2=80=99s comment. =
I wanted the list of implementator to-be-aware changes to get working =
group quick review.
>>>=20
>>> I=E2=80=99m about to add a =E2=80=9CChanges since RFC 6833=E2=80=9D =
section to RFC 6833bis as well.
>>>=20
>>> Thanks,
>>> Dino
>>>=20
>>> 
>>>=20
>>>> On Aug 20, 2018, at 9:03 AM, Scott O. Bradner  =
wrote:
>>>>=20
>>>> a specific section only dealing with the changes since the RFC is =
best
>>>>=20
>>>> there is too much noise in the per iteration log (which as you =
already note should be removed)
>>>>=20
>>>> Scott
>>>>=20
>>>>> On Aug 20, 2018, at 8:57 AM, Dino Farinacci  =
wrote:
>>>>>=20
>>>>> Note we do have a Document Change Log in Appendix B detailing the =
changes put in each version starting with RFC6830. Would that suffice? =
Or you still think a specific section is required?
>>>>>=20
>>>>> Dino
>>>>>=20
>>>>> 
>>>>>=20
>>>>>> On Aug 20, 2018, at 8:44 AM, Scott O. Bradner  =
wrote:
>>>>>>=20
>>>>>> it would be best to have a section called =E2=80=9Cchanges since =
RFC 6830=E2=80=9D so there is no ambiguity that the section covers the =
changes
>>>>>>=20
>>>>>> it would be fine to have that section just say =E2=80=9CSee  =
=E2=80=9CImplementation Considerations.=E2=80=9D
>>>>>>=20
>>>>>> Scott
>>>>>>=20
>>>>>>=20
>>>>>>> On Aug 20, 2018, at 8:26 AM, Dino Farinacci =
 wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>> Hi Dino
>>>>>>>>> On Aug 20, 2018, at 8:18 AM, Dino Farinacci =
 wrote:
>>>>>>>>>=20
>>>>>>>>> There were little changes that an implementor would need to =
know about for the data-plane. But there were for the control-plane =
(i.e. RFC6833bis). But in either case, we=E2=80=99ll add a section in =
each bis document.
>>>>>>>>=20
>>>>>>>> thanks - even if the section says =E2=80=9Cnothing to worry =
about=E2=80=9D it will be useful
>>>>>>>=20
>>>>>>> I=E2=80=99ll title it =E2=80=9CImplementation Considerations=E2=80=
=9D and place it between 17 and 18?
>>>>>>>=20
>>>>>>> 14. Multicast Considerations  . . . . . . . . . . . . . . . . . =
.  29
>>>>>>> 15. Router Performance Considerations . . . . . . . . . . . . . =
.  30
>>>>>>> 16. Security Considerations . . . . . . . . . . . . . . . . . . =
.  31
>>>>>>> 17. Network Management Considerations . . . . . . . . . . . . . =
.  32
>>>>>>> 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . =
.  32
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Are you going to be reviewer for 6833bis as well?
>>>>>>>>=20
>>>>>>>> not assigned that yet but I will take a look
>>>>>>>=20
>>>>>>> I will try to get the sections done in the next day or so. I=E2=80=
=99m at the 3GPP meetings this week.
>>>>>>>=20
>>>>>>> Dino
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Scott
>>>>>>>>>=20
>>>>>>>>> Dino
>>>>>>>>>=20
>>>>>>>>>> On Aug 20, 2018, at 6:14 AM, Scott O. Bradner  =
wrote:
>>>>>>>>>>=20
>>>>>>>>>> I was just assigned to do a ops-dir review of  =
draft-ietf-lisp-rfc6830bis-14
>>>>>>>>>>=20
>>>>>>>>>> this is not the review - that will come soon
>>>>>>>>>>=20
>>>>>>>>>> but since this is a =E2=80=9Cbis=E2=80=9D document that is to =
replace an existing RFC it needs to have a=20
>>>>>>>>>> =E2=80=9Cchanges since RFC 6830=E2=80=9D section so that =
implementors of the earlier RFC will be able to tell
>>>>>>>>>> what they need to change to bring their code up to date =
without having to compare the=20
>>>>>>>>>> RFCs line by line (and likely miss something)
>>>>>>>>>>=20
>>>>>>>>>> Scott
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


From nobody Wed Aug 22 00:51: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 C3192120049 for ; Wed, 22 Aug 2018 00:51:12 -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 nlCVom0HMBtY for ; Wed, 22 Aug 2018 00:51:09 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 9FA7A130E1F for ; Wed, 22 Aug 2018 00:51:08 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id c14-v6so1113145wmb.4 for ; Wed, 22 Aug 2018 00:51:08 -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=3XdrcidYurlQd0fAS7BFUfnqbYVP+0JuyIh+cwAa4xQ=; b=M9r4+bLp2i6SYQ8rwnB96pK5Hw9ubpWiiVUJyDR3ammiwTZYAvgVUTpDY1zScq/VS2 rqLyOBQSXWQvFfKojRGGZyIQwb0yv3Tv62ImQ0qaSAEysGxeK7KPYw3YmfBoVGGOrsEi 1dJhykGLAxT18pefDCrFMtJmD7jwEHKdfT/6CTDuNxC/XGk7XCxaiYVOoTnCZvb83TBq 1MYA/B4j8N4PDNBZW2wybbqqlXavgceygJE7ExyU7ZbiPxfAyzT2J79WfjKDVHaTckKr mznm+R5vtmWycQA9917X8cMpAZqqUCEveeb84ZqzNtvotvN6PuwB0g7Zuuh1tXPn/U1O 0f0A==
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=3XdrcidYurlQd0fAS7BFUfnqbYVP+0JuyIh+cwAa4xQ=; b=PXDFFOgvFYoXGOOREElbgnDnGkQ6qHoP6FAZ/kUUzBfWpAzYCHQ2usGmxm5GTqmTKd cpE7L04BUkZodmONxfQlhvnpzeg1EvyyjV7sOZAvDgdLe+s3uO8RxA24a9RJVlGgcXFW Mm1KOT/Yi7hFkpamvsu/JH+t8k38Jl15dVYJYgeW0VuDAIPzBdUB4DY0qOOVl19kqME7 qd5ahH7ihclRzTqKUfThmA94FMdi/GAJoYodfCdVj/Z17U9gfa+JGG4j3pScof6fSgyz 1ioIE6n8EW+Ry9RH5K3PAbuGiUVrZGZ3+tDs6pXFCBkeD+xiRxMckFnX2Mk9xdPx+tm9 74eA==
X-Gm-Message-State: APzg51Cly7TlHk1xeHDNkmmgmwPGgLFLPkIIakQHiB1q9ZfLz/HBlklD r1v1BZsf3Uj5ECPY2AJtCFHV2w==
X-Google-Smtp-Source: ANB0VdYyeW8hDSCZOBiX1It2nFd/QGyJOU3MdbHs8OcNEpf9DB2x+rLoNHUnJp3CDmZCpV69XN1cAA==
X-Received: by 2002:a1c:f913:: with SMTP id x19-v6mr1633443wmh.63.1534924267082;  Wed, 22 Aug 2018 00:51:07 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:edfb:cd69:b75b:2a84? ([2001:660:330f:a4:edfb:cd69:b75b:2a84]) by smtp.gmail.com with ESMTPSA id f18-v6sm980935wru.51.2018.08.22.00.51.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 00:51:05 -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, 22 Aug 2018 09:51:10 +0200
Cc: "Scott O. Bradner" , draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7ED27E5F-14EC-4900-99A9-D6D4C8737710@gigix.net>
References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com>  <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com>  <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com>  
To: Dino Farinacci 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14
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: Wed, 22 Aug 2018 07:51:13 -0000

Hi Dino,

the new section looks good to me. Just one comment: I would avoid use =
the word =E2=80=9Cdraft=E2=80=9D in the first sentence of the last =
bullet of the section.
So instead of=20

"Data-plane gleaning for creating map-cache entries has been made =
optional in this draft.=E2=80=9D

I would simply put:

"Data-plane gleaning for creating map-cache entries has been made =
optional.=E2=80=9D

Just trimming the last part.

Ciao

L.



> On 20 Aug 2018, at 20:42, Dino Farinacci  wrote:
>=20
> 


From nobody Wed Aug 22 01:00: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 7EE6D130EB3 for ; Wed, 22 Aug 2018 01:00:08 -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 4E4gDk3AIGKH for ; Wed, 22 Aug 2018 01:00:07 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450: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 967C2126CC7 for ; Wed, 22 Aug 2018 01:00:06 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id o37-v6so811682wrf.6 for ; Wed, 22 Aug 2018 01:00:06 -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=jTsdIUGvaqWAEes01qNQbJl2XyRYjKeublQ3fdS7ITc=; b=e69N94wgw1QZ1EwznWjjXGOmWpyjz6dZtYuHPz9TXCFPZBopjBObaCeL1ZoVz0U4vq EI/6Q9lhHF5vkH1HjGI6w+2iS0i9G8sRoadpGxhj02mKHq0RdIpcBfCuS8MZtWbOTPDJ SM8YTQGFhxDGz3EFsVxADNPSaZApdFpzK6SXVKvyHjcZyvilrUyfsgBm3QBr3wVv6Ri2 aqQgyDVfQD+eqclh+PYKpLezmGVfaGED+F3Fo8oR5OpP9mHLETY5KM+MGsEmBnY2MZlt uPIe7sNb/tRQR25NQve2M8iVCcyiCo32iIp1NCgD0E7YNegX0gE9bxtRzv/4+WrFmjWw H8xA==
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=jTsdIUGvaqWAEes01qNQbJl2XyRYjKeublQ3fdS7ITc=; b=kNh+KlACwhA7VRfbPgw1Jd3E6vrLcjIUXVgZTXL0Hr7UmnU9oaMP6snnIyiZtIaCfr sfXSP4UJZAai3H1Rfaw3Luq/NyAQHjDPDfAimEjAh1PR+1x/X8e6wKLeV+S0jMjPuf6d 4Z8SoWVRFVm/08lRmX3/ks+EOnTEuYPxK2rh3IA9LW2E3CkEcUmghzojcZthYKC66kvc acoEgkOCpUfguAMC8RVWNUHYWzrA3gsE9qplslwjM636/DJZp3adHzfy/5M6J14I5LbW Nasowosoyp7sqN7h4nJcHk+qziFA5f8yEqAfPfyS8ujwuUPLNtdvRNr+V9EzVQ3xFpqx JscQ==
X-Gm-Message-State: AOUpUlF9eGtvWbbDvWA4aX/jLIHuPI8mDWqZIA8Eu1QxKLpYIK0aUyhg E4jzRYQ8uMO6wce8b9XTzOKJ1g==
X-Google-Smtp-Source: AA+uWPwGcko2XqDUsxjUVO0i990SNTiI1hnernfCQMnM7JLYAWJY2Y9LSUo1Q/2TWk8msg+3N8fmqg==
X-Received: by 2002:a5d:434c:: with SMTP id u12-v6mr33677665wrr.189.1534924805104;  Wed, 22 Aug 2018 01:00:05 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:edfb:cd69:b75b:2a84? ([2001:660:330f:a4:edfb:cd69:b75b:2a84]) by smtp.gmail.com with ESMTPSA id v2-v6sm1154925wme.36.2018.08.22.01.00.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 01:00:03 -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: <9BE375D7-50E1-4FF1-B59C-93C203CFBDD0@gmail.com>
Date: Wed, 22 Aug 2018 10:00:07 +0200
Cc: "Scott O. Bradner" , draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FBE6404-B637-4E03-AF2C-C784A359447D@gigix.net>
References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com>  <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com>  <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com>   <9BE375D7-50E1-4FF1-B59C-93C203CFBDD0@gmail.com>
To: Dino Farinacci 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14
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: Wed, 22 Aug 2018 08:00:09 -0000

Hi Dino,

the new section in 6833bis looks good to me. Just two nits:
In the first line of the first bullet the word =E2=80=9Cdocument=E2=80=9D =
is misspelled: docuemnt -> document
In the second sentence of the same bullet: "Any receivers" -> "Any =
receiver"

Ciao

L.


> On 20 Aug 2018, at 21:29, Dino Farinacci  wrote:
>=20
> 


From nobody Wed Aug 22 02:55:17 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 17F9B130DEF; Wed, 22 Aug 2018 02:55:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: ggx@gigix.net, lisp-chairs@ietf.org, lisp@ietf.org, db3546@att.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153493171502.15890.8490260040205970057.idtracker@ietfa.amsl.com>
Date: Wed, 22 Aug 2018 02:55:15 -0700
Archived-At: 
Subject: [lisp] lisp - New Meeting Session Request for IETF 103
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: Wed, 22 Aug 2018 09:55:15 -0000

A new meeting session request has just been submitted by Luigi Iannone, a Chair of the lisp working group.


---------------------------------------------------------
Working Group Name: Locator/ID Separation Protocol
Area Name: Routing Area
Session Requester: Luigi Iannone

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 30
Conflicts to Avoid: 
 First Priority: rtgwg nvo3 i2rs sidr grow sfc nfvrg pim intarea lsr lsvr detnet maprg 
 Second Priority: mboned icnrg irtfopen idr spring bier tsvwg
 Third Priority: bess


People who must be present:
  Joel M. Halpern
  Wassim Haddad
  Deborah Brungard
  Luigi Iannone
  Padma Pillay-Esnault

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Wed Aug 22 06:52: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 93B56130EF7; Wed, 22 Aug 2018 06:52:21 -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 taByE2LUwCW9; Wed, 22 Aug 2018 06:52:13 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 9DB67128CFD; Wed, 22 Aug 2018 06:52:12 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id h200-v6so904190vke.5; Wed, 22 Aug 2018 06:52:12 -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=vGHy3m3pZlFOTTskO72iuIgmyGynpIFsJ4iVkYKud5Q=; b=AHkrsH3tex6Sw5AdX+yl0K82F+nLL9VY7t8/gOtawsaldZYVdxRlNdl0ZQ+XfTGyLY 40c5HSO5aWH/l9uekHccshCac46v7LVBpUF5vAqgz2q5EQToFk7wDLv0VCBP+xilQoUe 9Et8FpAJjVyj+FzJOdQqmi9trqxHC+dZxJd0BVylSjUoTAzjMDZ9oMY9m4OaCarKE9ho s6tOiXxDR97W3GdFCsBHcBmIwk9OVY1Ttf+w7fA93I1YPe6VHzYSv/Wh4rKoHkYA18KE 41Ti/BBZ7nzXEYspTCdkY/Mabbne6rsAzgyXlkgijCAjR30DQoMRcFPF7+aK7sKn2k4l i/dQ==
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=vGHy3m3pZlFOTTskO72iuIgmyGynpIFsJ4iVkYKud5Q=; b=rUzXYLbbyNG81663URbdPSLgZ7FItkndeLYpVOpfDYBFgNxnYd2KCigc1LcJaEWAD2 9cVL1gfLx8r7gFFKZFZCMI48qrQKNpAyQaHL3mBYYHkPIYNKiyUCw1UHZJhsCmxBHtYA X5Wuu3wKqwMmz93weD0/H3zMCAb+0fJG32Xw8Lax8lA5OKPtIb7IfgUvSp5lvZMYlCb3 aQ1wcofV30ftcY4uEtpQOi1LW+dBu2S02i2D5k1o1itXl1yDKb39Ah98S0amUgYiQF3z IvPSzSRomVXwMb0XeTZM50BJ0rbYATxu2fyNz7SDYGb3Foj1M3pLi8amfpa7kzPzOJar RyGg==
X-Gm-Message-State: AOUpUlFUTuCNhC8SWxUW77CDlLzvar00MnaKtdbUOlezRObWavUt2CB/ k6ubc/J8UshfY5cp00V7VN8=
X-Google-Smtp-Source: AA+uWPyF7vOdOQ8BWQECpZEP3WiKIx66ed2g56pE+51nGag1LR24cWouG20vbIz24PFeGFCUphDb5Q==
X-Received: by 2002:a1f:a803:: with SMTP id r3-v6mr35383976vke.8.1534945931688;  Wed, 22 Aug 2018 06:52:11 -0700 (PDT)
Received: from [10.10.0.236] ([45.73.155.132]) by smtp.gmail.com with ESMTPSA id j2-v6sm295922uag.48.2018.08.22.06.52.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 06:52:10 -0700 (PDT)
From: Dino Farinacci 
Message-Id: <9092127F-7990-4A12-A97F-37B97E6AA181@gmail.com>
Content-Type: multipart/mixed; boundary="Apple-Mail=_E0BACCC1-D960-4F49-B3FF-34CD23B791A9"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 22 Aug 2018 09:52:09 -0400
In-Reply-To: <7ED27E5F-14EC-4900-99A9-D6D4C8737710@gigix.net>
Cc: Scott Bradner , draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" 
To: Luigi Iannone 
References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com>  <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com>  <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com>   <7ED27E5F-14EC-4900-99A9-D6D4C8737710@gigix.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14
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: Wed, 22 Aug 2018 13:52:29 -0000

--Apple-Mail=_E0BACCC1-D960-4F49-B3FF-34CD23B791A9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Updated. I also received requests to add other data planes that may be =
applicable. So references to SRv6 GRE, and GTP were added.

Diffs enclosed. I will submit both drafts on Friday.

Dino


--Apple-Mail=_E0BACCC1-D960-4F49-B3FF-34CD23B791A9
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-13.txt - =
draft-ietf-lisp-rfc6830bis-14.txt=20
  =20
     =20
=20
=20
  =20
  =20
      
< draft-ietf-lisp-rfc6830bis-13.txt  =
 draft-ietf-lisp-rfc6830bis-14.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: January 16, 2019                                 =
 Cisco Systems Expires: February 23, 2019                                =
 Cisco Systems

      
                  =
                                     A. Cabellos (Ed.)                                                        =
A. Cabellos (Ed.)

      
                  =
                                     UPC/BarcelonaTech                                                        =
UPC/BarcelonaTech

      

      
                =
                                           July =
15, 2018                       =
                                   August =
22, 2018

      
 =


      
               =
The Locator/ID Separation Protocol (LISP)                The Locator/ID Separation Protocol =
(LISP)

      

      
                =
     draft-ietf-lisp-rfc6830bis-13 =
                     =
draft-ietf-lisp-rfc6830bis-14

      
 =


      
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 January 16, =
2019.    This Internet-Draft will =
expire on February 23, 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 47 =C2=B6 =
skipping to change at page 2, line 47 =C2=B6

      
   10. Routing =
Locator Reachability  . . . . . . . . . . . . . . . .  24 =
   10. Routing Locator Reachability  . . . . . =
. . . . . . . . . . .  24

      
     10.1.  Echo =
Nonce Algorithm . . . . . . . . . . . . . . . . . .  25 =
     10.1.  Echo Nonce Algorithm . . . . . . . =
. . . . . . . . . . .  25

      
   11. EID =
Reachability within a LISP Site . . . . . . . . . . . . .  26 =
   11. EID Reachability within a LISP Site . . =
. . . . . . . . . . .  26

      
   12. Routing =
Locator Hashing . . . . . . . . . . . . . . . . . . .  27 =
   12. Routing Locator Hashing . . . . . . . . =
. . . . . . . . . . .  27

      
   13. Changing =
the Contents of EID-to-RLOC Mappings . . . . . . . .  28 =
   13. Changing the Contents of EID-to-RLOC =
Mappings . . . . . . . .  28

      
     13.1.  =
Database Map-Versioning  . . . . . . . . . . . . . . . .  29 =
     13.1.  Database Map-Versioning  . . . . . =
. . . . . . . . . . .  29

      
   14. Multicast =
Considerations  . . . . . . . . . . . . . . . . . .  29 =
   14. Multicast Considerations  . . . . . . . =
. . . . . . . . . . .  29

      
   15. Router =
Performance Considerations . . . . . . . . . . . . . .  30 =
   15. Router Performance Considerations . . . =
. . . . . . . . . . .  30

      
   16. Security =
Considerations . . . . . . . . . . . . . . . . . . .  31 =
   16. Security Considerations . . . . . . . . =
. . . . . . . . . . .  31

      
   17. Network =
Management Considerations . . . . . . . . . . . . . .  32 =
   17. Network Management Considerations . . . =
. . . . . . . . . . .  32

      

      
   18. IANA =
Considerations . . . . . . . . . . . . . . . . . . . . .  32 =
   18. Changes since =
RFC 6830  . . . . . . . . . . . . . . . . . . .  32

      
     18.1.  LISP UDP Port Numbers  . . . . . . . . . =
. . . . . . . .  32    19. IANA Considerations . . . . . . . . . . . =
. . . . . . . . . .  32

      
   19. References  . . . . . . . . . . . . . . . . =
. . . . . . . . .  32      19.1.  LISP UDP Port =
Numbers  . . . . . . . . . . . . . . . . .  32

      
     19.1.  Normative References . . . . . . . . =
. . . . . . . . . .  32    20. References  . . . =
. . . . . . . . . . . . . . . . . . . . . .  33

      
     19.2.  Informative References . . . . . . . =
. . . . . . . . . .  33      20.1.  Normative References . . . . . . . . =
. . . . . . . . . .  33

      
 =
     20.2.  =
Informative References . . . . . . . . . . . . . . . . .  33

      
 =
                                               =
                          

      
   Appendix A.  =
Acknowledgments  . . . . . . . . . . . . . . . . . .  37 =
   Appendix A.  Acknowledgments  . . . . . . . =
. . . . . . . . . . .  37

      
   Appendix B.  =
Document Change Log  . . . . . . . . . . . . . . . .  37 =
   Appendix B.  Document Change Log  . . . . . =
. . . . . . . . . . .  37

      

      
     B.1.  =
Changes to draft-ietf-lisp-rfc6830bis-13  =
. . . . . . . .  38      B.1.  =
Changes to draft-ietf-lisp-rfc6830bis-14  =
. . . . . . . .  38

      
     B.2.  =
Changes to draft-ietf-lisp-rfc6830bis-12  =
. . . . . . . .  38      B.2.  =
Changes to draft-ietf-lisp-rfc6830bis-13  =
. . . . . . . .  38

      
     B.3.  =
Changes to draft-ietf-lisp-rfc6830bis-11  =
. . . . . . . .  38      B.3.  =
Changes to draft-ietf-lisp-rfc6830bis-12  =
. . . . . . . .  38

      
     B.4.  =
Changes to draft-ietf-lisp-rfc6830bis-10  =
. . . . . . . .  38      B.4.  =
Changes to draft-ietf-lisp-rfc6830bis-11  =
. . . . . . . .  38

      
     B.5.  =
Changes to draft-ietf-lisp-rfc6830bis-09  =
. . . . . . . .  38      B.5.  =
Changes to draft-ietf-lisp-rfc6830bis-10  =
. . . . . . . .  38

      
     B.6.  =
Changes to draft-ietf-lisp-rfc6830bis-08  =
. . . . . . . .  39      B.6.  =
Changes to draft-ietf-lisp-rfc6830bis-09  =
. . . . . . . .  39

      
     B.7.  =
Changes to draft-ietf-lisp-rfc6830bis-07  =
. . . . . . . .  39      B.7.  =
Changes to draft-ietf-lisp-rfc6830bis-08  =
. . . . . . . .  39

      
     B.8.  =
Changes to draft-ietf-lisp-rfc6830bis-06  =
. . . . . . . .  39      B.8.  =
Changes to draft-ietf-lisp-rfc6830bis-07  =
. . . . . . . .  39

      
     B.9.  =
Changes to draft-ietf-lisp-rfc6830bis-05  . . . . . . . .  40 =
     B.9.  Changes to draft-ietf-lisp-rfc6830bis-06  . . . . . . . .  =
39

      
     B.10. Changes to draft-ietf-lisp-rfc6830bis-04  =
. . . . . . . .  40      B.10. Changes to =
draft-ietf-lisp-rfc6830bis-05  . . . . . . . .  40

      
     B.11. Changes to draft-ietf-lisp-rfc6830bis-03  =
. . . . . . . .  40      B.11. Changes to draft-ietf-lisp-rfc6830bis-04  =
. . . . . . . .  40

      
     B.12. Changes to draft-ietf-lisp-rfc6830bis-02  =
. . . . . . . .  40      B.12. Changes to draft-ietf-lisp-rfc6830bis-03  =
. . . . . . . .  40

      
     B.13. Changes to draft-ietf-lisp-rfc6830bis-01  =
. . . . . . . .  40      B.13. Changes to draft-ietf-lisp-rfc6830bis-02  =
. . . . . . . .  40

      
     B.14. Changes to draft-ietf-lisp-rfc6830bis-00  =
. . . . . . . .  41      B.14. Changes to draft-ietf-lisp-rfc6830bis-01  =
. . . . . . . .  40

      
 =
     B.15. =
Changes to draft-ietf-lisp-rfc6830bis-00  . . . . . . . .  41

      
   Authors' =
Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41 =
   Authors' Addresses  . . . . . . . . . . . . =
. . . . . . . . . . .  41

      
 =


      
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 20 =C2=B6 =
skipping to change at page 4, line 20 =C2=B6

      
   LISP =
forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] =
   LISP forwarding node functionality while =
[I-D.ietf-lisp-rfc6833bis]

      
   specifies the =
LISP control plane.  LISP deployment guidelines can be    specifies the LISP control plane.  LISP deployment =
guidelines can be

      
   found in =
[RFC7215] and [RFC6835] describes considerations for network =
   found in [RFC7215] and [RFC6835] describes =
considerations for network

      
   operational =
management.  Finally, [I-D.ietf-lisp-introduction]    operational management.  Finally, =
[I-D.ietf-lisp-introduction]

      
   describes the =
LISP architecture.    describes the =
LISP architecture.

      
 =


      
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].    =
document are to be interpreted as described in [RFC2119] and

      
 =
   =
[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 =
      the Data-Plane.  See [AFN] and [RFC3232] =
for details.  An AFI

      
      value of 0 =
used in this specification indicates an unspecified       value of 0 used in this specification indicates an =
unspecified

      
      encoded =
address where the length of the address is 0 octets       encoded address where the length of the address is =
0 octets

      
      following =
the 16-bit AFI value of 0.       =
following the 16-bit AFI value of 0.

      
 =


      
 =


      
skipping to =
change at =
page 29, line 5 =C2=B6 =
skipping to change at page 29, line 5 =C2=B6

      
   well as =
setting the corresponding Locator-Status-Bit to 0.  This =
   well as setting the corresponding =
Locator-Status-Bit to 0.  This

      
   forces ITRs =
with old or new mappings to avoid using the removed    forces ITRs with old or new mappings to avoid using =
the removed

      
   =
Locator.    Locator.

      
 =


      
   If many =
changes occur to a mapping over a long period of time, one =
   If many changes occur to a mapping over a =
long period of time, one

      
   will find =
empty record slots in the middle of the Locator-Set and new =
   will find empty record slots in the middle =
of the Locator-Set and new

      
   records =
appended to the Locator-Set. At some point, it would be =
   records appended to the Locator-Set. At some =
point, it would be

      
   useful to =
compact the Locator-Set so the Locator-Status-Bit settings =
   useful to compact the Locator-Set so the =
Locator-Status-Bit settings

      
   can be =
efficiently packed.    can be =
efficiently packed.

      
 =


      

      
   We propose =
here a Data-Plane mechanism (Map-Versioning)=
 to update the    We propose here a =
Data-Plane mechanism (Map-Versioning specified =
in

      
   contents of =
EID-to-RLOC mappings.  Please note that in addition the =
   =
[I-D.ietf-lisp-6834bis]) to update the contents of =
EID-to-RLOC

      
   Solicit-Map =
Request (specified in [I-D.ietf-lisp-rfc6833bis]) is a    mappings.  Please note that in addition the =
Solicit-Map Request

      
   =
Control-Plane mechanisms that can be used to update EID-to-RLOC =
   (specified in [I-D.ietf-lisp-rfc6833bis]) =
is a Control-Plane

      
   =
mappings.    mechanisms that can be =
used to update EID-to-RLOC mappings.

      
 =


      
13.1.  Database =
Map-Versioning 13.1.  Database =
Map-Versioning

      
 =


      
   When there is =
unidirectional packet flow between an ITR and ETR, and    When there is unidirectional packet flow between an =
ITR and ETR, and

      
   the =
EID-to-RLOC mappings change on the ETR, it needs to inform the =
   the EID-to-RLOC mappings change on the ETR, =
it needs to inform the

      
   ITR so =
encapsulation to a removed Locator can stop and can instead be =
   ITR so encapsulation to a removed Locator =
can stop and can instead be

      
   started to a =
new Locator in the Locator-Set.    =
started to a new Locator in the Locator-Set.

      
 =


      
   An ETR, when =
it sends Map-Reply messages, conveys its own Map-Version =
   An ETR, when it sends Map-Reply messages, =
conveys its own Map-Version

      
   Number.  This =
is known as the Destination Map-Version Number.  ITRs    Number.  This is known as the Destination Map-Version =
Number.  ITRs

      
 =


      
skipping to =
change at =
page 32, line 14 =C2=B6 =
skipping to change at page 32, line =
14 =C2=B6

      
   or gleaning) =
SHOULD be verified with other reachability mechanisms.    or gleaning) SHOULD be verified with other =
reachability mechanisms.

      
   In addition, =
systematic rate-limitation and filtering is an effective =
   In addition, systematic rate-limitation and =
filtering is an effective

      
   technique to =
mitigate attacks that aim to overload the Control-Plane. =
   technique to mitigate attacks that aim to =
overload the Control-Plane.

      
 =


      
17.  Network =
Management Considerations 17.  Network =
Management Considerations

      
 =


      
   Considerations =
for network management tools exist so the LISP    Considerations for network management tools exist so =
the LISP

      
   protocol suite =
can be operationally managed.  These mechanisms can be    protocol suite can be operationally managed.  These =
mechanisms can be

      
   found in =
[RFC7052] and [RFC6835].    found in =
[RFC7052] and [RFC6835].

      
 =


      

      
18.  IANA =
Considerations 18.  Changes since RFC 6830

      
 =


      
 =
   For implementation =
considerations, the following changes have been

      
 =
   made to this =
document since RFC 6830 was published:

      
 =


      
 =
   o  It is no longer =
mandated that a maximum number of 2 LISP headers

      
 =
      be prepended to a =
packet.  If there is a application need for more

      
 =
      than 2 LISP =
headers, an implementation can support more.  However,

      
 =
      this document =
recommends a maximum of 2 LISP headers.

      
 =


      
 =
   o  The 3 reserved =
flag bits in the LISP header have been allocated

      
 =
      for [RFC8060].  =
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

      
 =
      still documented =
as reserved.

      
 =


      
 =
   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.  This does not create any

      
 =
      interoperability =
problems since the control-plane map-cache

      
 =
      population =
procedures are unilateral and are the typical method

      
 =
      for map-cache =
population.

      
 =


      
 =
19.  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

      
   Data-Plane =
LISP specification, in accordance with BCP 26 [RFC8126]. =
   Data-Plane LISP specification, in accordance =
with BCP 26 [RFC8126].

      
 =


      

      
18.1.  LISP UDP Port Numbers 19.1.  LISP UDP Port =
Numbers

      
 =


      
   The IANA =
registry has allocated UDP port number 4341 for the LISP =
   The IANA registry has allocated UDP port =
number 4341 for the LISP

      
   Data-Plane.  =
IANA has updated the description for UDP port 4341 as    Data-Plane.  IANA has updated the description for UDP =
port 4341 as

      
   =
follows:    follows:

      
 =


      
       lisp-data  =
    4341 udp    LISP Data Packets      =
  lisp-data      4341 udp    LISP Data Packets

      
 =


      

      
19.  References 20.  References

      
 =


      

      
19.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-00 (work in progress), July 2018.               lisp-6834bis-00 (work in progress), July =
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-12 (work in progress), =
July

      
              =
2018.               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 33, line 21 =C2=B6 =
skipping to change at page 33, line =
44 =C2=B6

      
   [RFC3168]  =
Ramakrishnan, K., Floyd, S., and D. Black, "The Addition =
   [RFC3168]  Ramakrishnan, K., Floyd, S., and =
D. Black, "The Addition

      
              of =
Explicit Congestion Notification (ECN) to IP",               of Explicit Congestion Notification (ECN) =
to IP",

      
              RFC =
3168, DOI 10.17487/RFC3168, September 2001,               RFC 3168, DOI 10.17487/RFC3168, September =
2001,

      
              =
<https://www.rfc-editor.org/info/rfc3168>.               =
<https://www.rfc-editor.org/info/rfc3168>.

      
 =


      
   [RFC8200]  =
Deering, S. and R. Hinden, "Internet Protocol, Version 6 =
   [RFC8200]  Deering, S. and R. Hinden, =
"Internet Protocol, Version 6

      
              =
(IPv6) Specification", STD 86, RFC 8200,               (IPv6) Specification", STD 86, RFC =
8200,

      
              DOI =
10.17487/RFC8200, July 2017,           =
    DOI 10.17487/RFC8200, July 2017,

      
              =
<https://www.rfc-editor.org/info/rfc8200>.               =
<https://www.rfc-editor.org/info/rfc8200>.

      
 =


      

      
19.2.  Informative References 20.2.  Informative =
References

      
 =


      
   [AFN]      =
IANA, "Address Family Numbers", August 2016,    [AFN]      IANA, "Address Family Numbers", August =
2016,

      
              =
<http://www.iana.org/assignments/address-family-numbers>. =
              =
<http://www.iana.org/assignments/address-family-numbers>.

      
 =


      
   [CHIAPPA]  =
Chiappa, J., "Endpoints and Endpoint names: A Proposed", =
   [CHIAPPA]  Chiappa, J., "Endpoints and =
Endpoint names: A Proposed",

      
              =
1999,               1999,

      
              =
<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. =
              =
<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.

      
 =


      
   =
[I-D.ietf-lisp-introduction]    =
[I-D.ietf-lisp-introduction]

      
              =
Cabellos-Aparicio, A. and D. Saucez, "An Architectural               Cabellos-Aparicio, A. and D. Saucez, "An =
Architectural

      
 =


      
skipping to =
change at =
page 36, line 15 =C2=B6 =
skipping to change at page 36, line =
36 =C2=B6

      
   [RFC8111]  =
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.    [RFC8111]  Fuller, V., Lewis, D., Ermagan, V., Jain, =
A., and A.

      
              =
Smirnov, "Locator/ID Separation Protocol Delegated               Smirnov, "Locator/ID Separation Protocol =
Delegated

      
              =
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, =
              Database Tree (LISP-DDT)", RFC =
8111, DOI 10.17487/RFC8111,

      
              May =
2017, <https://www.rfc-editor.org/info/rfc8111>.               May 2017, =
<https://www.rfc-editor.org/info/rfc8111>.

      
 =


      
   [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

      
 =
              2119 Key =
Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,

      
 =
              May 2017, =
<https://www.rfc-editor.org/info/rfc8174>.

      
 =
                                               =
                          

      
   [RFC8378]  =
Moreno, V. and D. Farinacci, "Signal-Free Locator/ID    [RFC8378]  Moreno, V. and D. Farinacci, "Signal-Free =
Locator/ID

      
              =
Separation Protocol (LISP) Multicast", RFC 8378,               Separation Protocol (LISP) Multicast", RFC =
8378,

      
              DOI =
10.17487/RFC8378, May 2018,            =
   DOI 10.17487/RFC8378, May 2018,

      
              =
<https://www.rfc-editor.org/info/rfc8378>.               =
<https://www.rfc-editor.org/info/rfc8378>.

      
 =


      
Appendix A.  =
Acknowledgments Appendix A.  =
Acknowledgments

      
 =


      
   An initial =
thank you goes to Dave Oran for planting the seeds for the =
   An initial thank you goes to Dave Oran for =
planting the seeds for the

      
   initial ideas =
for LISP.  His consultation continues to provide value    initial ideas for LISP.  His consultation continues =
to provide value

      
   to the LISP =
authors.    to the LISP =
authors.

      
 =


      
skipping to =
change at =
page 38, line 5 =C2=B6 =
skipping to change at page 38, 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-13 B.1. =
 Changes to draft-ietf-lisp-rfc6830bis-14

      
 =


      
 =
   o  Posted August =
2018.

      
 =


      
 =
   o  Final editorial =
changes before RFC submission for Proposed

      
 =
      =
Standard.

      
 =


      
 =
   o  Added section =
"Changes since RFC 6830" so implementators are

      
 =
      informed of any =
changes since the last RFC publication.

      
 =


      
 =
B.2.  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.2.  Changes to =
draft-ietf-lisp-rfc6830bis-12 B.3.  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.3.  Changes to =
draft-ietf-lisp-rfc6830bis-11 B.4.  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.4.  Changes to =
draft-ietf-lisp-rfc6830bis-10 B.5.  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.5.  Changes to =
draft-ietf-lisp-rfc6830bis-09 B.6.  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.6.  Changes to =
draft-ietf-lisp-rfc6830bis-08 B.7.  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.7.  Changes to =
draft-ietf-lisp-rfc6830bis-07 B.8.  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.8.  Changes to =
draft-ietf-lisp-rfc6830bis-06 B.9.  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 40, line =
9 =C2=B6 =
skipping to change at page 40, line =
17 =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.9.  Changes to =
draft-ietf-lisp-rfc6830bis-05 B.10.  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.10.  Changes to =
draft-ietf-lisp-rfc6830bis-04 B.11.  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.11.  Changes to =
draft-ietf-lisp-rfc6830bis-03 B.12.  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.12.  Changes to =
draft-ietf-lisp-rfc6830bis-02 B.13.  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.13.  Changes to =
draft-ietf-lisp-rfc6830bis-01 B.14.  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.14.  Changes to =
draft-ietf-lisp-rfc6830bis-00 B.15.  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. 29 change blocks. 

     
49 lines changed or =
deleted 89 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=_E0BACCC1-D960-4F49-B3FF-34CD23B791A9
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii



--Apple-Mail=_E0BACCC1-D960-4F49-B3FF-34CD23B791A9
Content-Disposition: attachment;
	filename=rfddiff-6833bis.html
Content-Type: text/html;
	x-unix-mode=0644;
	name="rfddiff-6833bis.html"
Content-Transfer-Encoding: quoted-printable



=20
  =20
  =20
  Diff: draft-ietf-lisp-rfc6833bis-12.txt - =
draft-ietf-lisp-rfc6833bis-13.txt=20
  =20
     =20
=20
=20
  =20
  =20
      =

      =

      =

      =

      
< draft-ietf-lisp-rfc6833bis-12.txt  =
 draft-ietf-lisp-rfc6833bis-13.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: January 27, 2019                              =
UPC/BarcelonaTech Expires: February 23, 2019                             =
UPC/BarcelonaTech

      
                =
                                           July =
26, 2018                       =
                                   August =
22, 2018

      
 =


      
          =
Locator/ID Separation Protocol (LISP) Control-Plane           Locator/ID Separation Protocol (LISP) =
Control-Plane

      
                  =
   draft-ietf-lisp-rfc6833bis-12       =
               draft-ietf-lisp-rfc6833bis-12

      
 =


      
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

      
 =


      
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 January 27, =
2019.    This Internet-Draft will =
expire on February 23, 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 25 =C2=B6 =
skipping to change at page 2, line 25 =C2=B6

      
   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  . . . . . . . . . . . . . . . . . . . . . . . .   =
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  . . . . . . . . . . . . . . . . . . . . . . .   5    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 =
. . . . . . . . . . .  26

      
   6.  Changing =
the Contents of EID-to-RLOC Mappings . . . . . . . .  28 =
   6.  Changing the Contents of EID-to-RLOC =
Mappings . . . . . . . .  28

      
     6.1.  =
Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . .  28 =
     6.1.  Solicit-Map-Request (SMR) . . . . . =
. . . . . . . . . . .  28

      
   7.  Routing =
Locator Reachability  . . . . . . . . . . . . . . . .  29 =
   7.  Routing Locator Reachability  . . . . . =
. . . . . . . . . . .  29

      
     7.1.  =
RLOC-Probing Algorithm  . . . . . . . . . . . . . . . . .  31 =
     7.1.  RLOC-Probing Algorithm  . . . . . . =
. . . . . . . . . . .  31

      
   8.  =
Interactions with Other LISP Components . . . . . . . . . . .  =
32    8.  Interactions with Other LISP =
Components . . . . . . . . . . .  32

      
     8.1.  ITR =
EID-to-RLOC Mapping Resolution  . . . . . . . . . . .  32 =
     8.1.  ITR EID-to-RLOC Mapping Resolution  =
. . . . . . . . . . .  32

      
     8.2.  =
EID-Prefix Configuration and ETR Registration . . . . . .  33 =
     8.2.  EID-Prefix Configuration and ETR =
Registration . . . . . .  33

      
     8.3.  =
Map-Server Processing . . . . . . . . . . . . . . . . . .  35 =
     8.3.  Map-Server Processing . . . . . . . =
. . . . . . . . . . .  35

      
     8.4.  =
Map-Resolver Processing . . . . . . . . . . . . . . . . .  36 =
     8.4.  Map-Resolver Processing . . . . . . =
. . . . . . . . . . .  36

      
       8.4.1.  =
Anycast Map-Resolver Operation  . . . . . . . . . . .  36 =
       8.4.1.  Anycast Map-Resolver Operation  =
. . . . . . . . . . .  36

      
   9.  Security =
Considerations . . . . . . . . . . . . . . . . . . .  36 =
   9.  Security Considerations . . . . . . . . =
. . . . . . . . . . .  36

      

      
   10. IANA =
Considerations . . . . . . . . . . . . . . . . . . . . .  37    10. =
Changes since RFC 6833  . . . . . . . . . . . . . =
. . . . . .  37

      
     10.1.  LISP UDP Port Numbers  . . . . . . . =
. . . . . . . . . .  38    11. IANA Considerations . . . . . . . . . . . =
. . . . . . . . . .  38

      
     10.2.  LISP Packet Type Codes . . . . . . . . . =
. . . . . . . .  38      11.1.  LISP UDP Port Numbers  . . . . . . . =
. . . . . . . . . .  38

      
     10.3.  LISP ACT and Flag Fields . . . . . . . . =
. . . . . . . .  38      11.2.  LISP Packet =
Type Codes . . . . . . . . . . . . . . . . .  38

      
     10.4.  LISP Address Type Codes  . . . . . . =
. . . . . . . . . .  39      11.3.  LISP ACT and Flag Fields . . . . . . . . =
. . . . . . . .  39

      
     10.5.  LISP Algorithm ID Numbers  . . . . . . . =
. . . . . . . .  39      11.4.  LISP Address =
Type Codes  . . . . . . . . . . . . . . . .  39

      
   11. References  . . . . . . . . . . . . . . . =
. . . . . . . . . .  39      11.5.  LISP =
Algorithm ID Numbers  . . . . . . . . . . . . . . .  40

      
     11.1.  Normative References . . . . . . . . =
. . . . . . . . . .  39 

      
     11.2.  Informative References . . . . . . . =
. . . . . . . . . .  40    12. References  . . . =
. . . . . . . . . . . . . . . . . . . . . .  40

      
   Appendix A.  =
Acknowledgments  . . . . . . . . . . . . . . . . . .  44      12.1.  Normative References . . . . . . . . =
. . . . . . . . . .  40

      
   Appendix B.  =
Document Change Log  . . . . . . . . . . . . . . . .  44      12.2.  Informative References . . . . . . . =
. . . . . . . . . .  41

      
     B.1.  =
Changes to draft-ietf-lisp-rfc6833bis-12  =
. . . . . . . .  44    Appendix A.  Acknowledgments  . . . . . . . . . . . =
. . . . . . .  45

      
     B.2.  =
Changes to draft-ietf-lisp-rfc6833bis-11  =
. . . . . . . .  44    Appendix B.  Document Change Log  . . . . . . . . . =
. . . . . . .  45

      
     B.3.  =
Changes to draft-ietf-lisp-rfc6833bis-10  =
. . . . . . . .  44      B.1.  Changes to draft-ietf-lisp-rfc6833bis-13  . . . . . . . .  =
45

      
     B.4.  =
Changes to draft-ietf-lisp-rfc6833bis-09  =
. . . . . . . .  44      B.2.  Changes to draft-ietf-lisp-rfc6833bis-12  . . . . . . . .  =
45

      
     B.5.  =
Changes to draft-ietf-lisp-rfc6833bis-08  =
. . . . . . . .  44      B.3.  Changes to draft-ietf-lisp-rfc6833bis-11  . . . . . . . .  =
45

      
     B.6.  =
Changes to draft-ietf-lisp-rfc6833bis-07  =
. . . . . . . .  45      B.4.  Changes to draft-ietf-lisp-rfc6833bis-10  . . . . . . . .  =
45

      
     B.7.  =
Changes to draft-ietf-lisp-rfc6833bis-06  =
. . . . . . . .  45      B.5.  Changes to draft-ietf-lisp-rfc6833bis-09  . . . . . . . .  =
46

      
     B.8.  =
Changes to draft-ietf-lisp-rfc6833bis-05  =
. . . . . . . .  46      B.6.  Changes to draft-ietf-lisp-rfc6833bis-08  . . . . . . . .  =
46

      
     B.9.  =
Changes to draft-ietf-lisp-rfc6833bis-04  =
. . . . . . . .  46      B.7.  Changes to draft-ietf-lisp-rfc6833bis-07  . . . . . . . .  =
46

      
     B.10. =
Changes to draft-ietf-lisp-rfc6833bis-03  =
. . . . . . . .  46      B.8.  Changes to draft-ietf-lisp-rfc6833bis-06  . . . . . . . .  =
47

      
     B.11. =
Changes to draft-ietf-lisp-rfc6833bis-02  =
. . . . . . . .  46      B.9.  Changes to draft-ietf-lisp-rfc6833bis-05  . . . . . . . .  =
47

      
     B.12. =
Changes to draft-ietf-lisp-rfc6833bis-01  =
. . . . . . . .  46      B.10. Changes to draft-ietf-lisp-rfc6833bis-04  . . . . . . . .  =
47

      
     B.13. =
Changes to draft-ietf-lisp-rfc6833bis-00  =
. . . . . . . .  47      B.11. Changes to draft-ietf-lisp-rfc6833bis-03  . . . . . . . .  =
47

      
     B.14. =
Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . .  47      B.12. =
Changes to draft-ietf-lisp-rfc6833bis-02  =
. . . . . . . .  48

      
   Authors' =
Addresses  . . . . . . . . . . . . . . . . . . . . . . .  48      B.13. =
Changes to draft-ietf-lisp-rfc6833bis-01  =
. . . . . . . .  48

      
 =
     B.14. Changes to draft-ietf-lisp-rfc6833bis-00  . . . . . . . .  =
48

      
 =
     B.15. Changes =
to draft-farinacci-lisp-rfc6833bis-00 . . . . . .  48

      
 =
   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

      
   achieve this =
separation, LISP defines protocol mechanisms for mapping =
   achieve this separation, LISP defines =
protocol mechanisms for mapping

      
 =


      
skipping to =
change at =
page 3, line 51 =C2=B6 =
skipping to change at page 4, line 5 =C2=B6

      
   The LISP =
Mapping Service defines two new types of LISP-speaking    The LISP Mapping Service defines two new types of =
LISP-speaking

      
   devices: the =
Map-Resolver, which accepts Map-Requests from an Ingress =
   devices: the Map-Resolver, which accepts =
Map-Requests from an Ingress

      
   Tunnel Router =
(ITR) and "resolves" the EID-to-RLOC mapping using a    Tunnel Router (ITR) and "resolves" the EID-to-RLOC =
mapping using a

      
   mapping =
database; and the Map-Server, which learns authoritative EID- =
   mapping database; and the Map-Server, which =
learns authoritative EID-

      
   to-RLOC =
mappings from an Egress Tunnel Router (ETR) and publishes =
   to-RLOC mappings from an Egress Tunnel =
Router (ETR) and publishes

      
   them in a =
database.    them in a =
database.

      
 =


      
   This LISP =
Control-Plane Mapping Service can be used by many different =
   This LISP Control-Plane Mapping Service can =
be used by many different

      
   =
encapsulation-based or translation-based Data-Planes which =
include    encapsulation-based or =
translation-based Data-Planes which include

      
   but are not =
limited to the ones defined in LISP RFC 6830bis    but are not limited to the ones defined in LISP RFC =
6830bis

      

      
   =
[I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN    [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.ietf-lisp-gpe], VXLAN

      
                =
                                                          =
   [RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], GRE [RFC2890], =
GTP

      
   [RFC7348], =
VXLAN-GPE [I-D.quinn-vxlan-gpe], and =
ILA    =
[GTP-3GPP], ILA [I-D.herbert-intarea-ila], =
and Segment Routing (SRv6)

      
   [I-D.herbert-intarea-ila].    [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 that while this document assumes a =
LISP-ALT database mapping

      
   infrastructure =
to illustrate certain aspects of Map-Server and Map-    infrastructure to illustrate certain aspects of =
Map-Server and Map-

      
 =


      
skipping to =
change at =
page 4, line 32 =C2=B6 =
skipping to change at page 4, line 34 =C2=B6

      
   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 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].    =
document are to be interpreted as described in [RFC2119] and

      
 =
   =
[RFC8174].

      
 =


      
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 11, line 17 =C2=B6 =
skipping to change at page 11, line =
17 =C2=B6

      
 =


      
   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].

      
 =


      
   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.rodrigueznatal-lisp-pubsub] for =
details.       procedures in =
[I-D.ietf-lisp-pubsub] for =
details.

      
 =


      
   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 24, line 7 =C2=B6 =
skipping to change at page 24, line 7 =C2=B6

      
      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 10.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 message digest used =
from the output

      
      of the MAC =
algorithm.  The entire Map-Register payload is       of the MAC algorithm.  The entire Map-Register =
payload is

      
 =


      
skipping to =
change at =
page 28, line 16 =C2=B6 =
skipping to change at page 28, line =
16 =C2=B6

      
 =


      
   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

      
   Request (SMR), =
a Control-Plane push-based mechanism.  An additional    Request (SMR), a Control-Plane push-based mechanism.  =
An additional

      
   Control-Plane =
mechanism based on the Publish/subscribe paradigm is    Control-Plane mechanism based on the =
Publish/subscribe paradigm is

      

      
   specified in =
[I-D.rodrigueznatal-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 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

      
 =


      
skipping to =
change at =
page 37, line 33 =C2=B6 =
skipping to change at page 37, line =
33 =C2=B6

      
   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.  IANA =
Considerations 10.  Changes since RFC 6833

      
 =


      
 =
   For implementation =
considerations, the following changes have been

      
 =
   made to this =
document since RFC 6833 was published:

      
 =


      
 =
   o  A Map-Notify-Ack =
message is added in this document to provide

      
 =
      reliability for =
Map-Notify messages.  Any receiver of a Map-Notify

      
 =
      message must =
respond with a Map-Notify-Ack message.  Map-Servers

      
 =
      who are senders =
of Map-Notify messages, must queue the Map-Notify

      
 =
      contents until =
they receive a Map-Notify-Ack with the nonce used

      
 =
      in the Map-Notify =
message.

      
 =


      
 =
   o  This document is =
incorporating the codepoint for the Map-Referral

      
 =
      message from the =
LISP-DDT specification [RFC8111] to indicate that

      
 =
      a Map-Server must =
send the final Map-Referral message when it

      
 =
      participates in =
the LISP-DDT mapping system procedures.

      
 =


      
 =
   o  The "m", "I", =
"L", and "D" bits are added to the Map-Request

      
 =
      message.  See =
Section 5.3 for details.

      
 =


      
 =
   o  The "S", "I", =
"E", "T", "a", and "m" bits are added to the Map-

      
 =
      Register message. =
 See Section 5.6 for details.

      
 =


      
 =
   o  The 16-bit Key-ID =
field of the Map-Register message has been split

      
 =
      into a 8-bit =
Key-ID field and a 8-bit Algorithm-ID field.

      
 =


      
 =
   o  This document =
adds two new Action values that are in an EID-record

      
 =
      that appear in =
Map-Reply, Map-Register, Map-Notify, and Map-

      
 =
      Notify-Ack =
messages.  The Drop/Policy-Denied and Drop/Auth-Failure

      
 =
      are the =
descriptions for the two new action values.  See

      
 =
      Section 5.4 for =
details.

      
 =


      
 =
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".

      
 =


      

      
10.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

      
   =
follows:    follows:

      
 =


      
        Keyword   =
        Port    Transport Layer   Description         Keyword           Port    Transport Layer   =
Description

      
        -------   =
        ----    ---------------   -----------         -------           ----    ---------------   =
-----------

      
        =
lisp-control      4342    udp               LISP Control =
Packets         lisp-control      4342 =
   udp               LISP Control Packets

      
 =


      

      
10.2.  LISP Packet Type Codes 11.2.  LISP Packet Type =
Codes

      
 =


      
   It is being =
requested that the IANA be authoritative for LISP Packet =
   It is being requested that the IANA be =
authoritative for LISP Packet

      
   Type =
definitions and that it refers to this document as well as =
   Type definitions and that it refers to this =
document as well as

      
   [RFC8113] as =
references.    [RFC8113] as =
references.

      
 =


      
   Based on =
deployment experience of [RFC6830], the Map-Notify-Ack    Based on deployment experience of [RFC6830], the =
Map-Notify-Ack

      
   message, =
message type 5, was added to this document.  This document =
   message, message type 5, was added to this =
document.  This document

      
   requests IANA =
to add it to the LISP Packet Type Registry.    requests IANA to add it to the LISP Packet Type =
Registry.

      
 =


      
         Name     =
            Number          Defined in  =
        Name                 Number          Defined in

      
         ----     =
            ------          ----------- =
         ----                 ------          -----------

      
         LISP =
Map-Notify-Ack  5               RFC6833bis          LISP Map-Notify-Ack  5               =
RFC6833bis

      
 =


      

      
10.3.  LISP ACT and Flag Fields 11.3.  LISP ACT and Flag =
Fields

      
 =


      
   New ACT values =
can be allocated through IETF review or IESG approval.    New ACT values can be allocated through IETF review =
or IESG approval.

      
   Four values =
have already been allocated by [RFC6830].  This    Four values have already been allocated by [RFC6830]. =
 This

      
   specification =
changes the name of ACT type 3 value from "Drop" to    specification changes the name of ACT type 3 value =
from "Drop" to

      
   =
"Drop/No-Reason" as well as adding two new ACT values, the =
"Drop/    "Drop/No-Reason" as well as =
adding two new ACT values, the "Drop/

      
   Policy-Denied" =
(type 4) and "Drop/Authentication-Failure" (type 5).    Policy-Denied" (type 4) and =
"Drop/Authentication-Failure" (type 5).

      
 =


      
   Value  Action  =
       Description                          Reference    Value  Action         Description                     =
     Reference

      
   -----  ------  =
       -----------                          ---------    -----  ------         -----------                     =
     ---------

      
   4      Drop/   =
       A Packet matching this Map-Cache     RFC6833bis    4      Drop/          A Packet matching this =
Map-Cache     RFC6833bis

      
 =


      
skipping =
to change at page 39, line =
7 =C2=B6 =
skipping to change at page 39, line =
35 =C2=B6

      
          =
Auth-Failure   entry is dropped because the           Auth-Failure   entry is dropped because =
the

      
                  =
       Map-Request for target EID fails an                          Map-Request for target EID =
fails an

      
                  =
       authentication check by the xTR or                          authentication check by the xTR =
or

      
                  =
       the mapping system.             =
             the mapping system.

      
 =


      
   In addition, =
LISP has a number of flag fields and reserved fields,    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 =
   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    bits for flags in these fields can be implemented =
after IETF review

      
   or IESG =
approval, but these need not be managed by IANA.    or IESG approval, but these need not be managed by =
IANA.

      
 =


      

      
10.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.

      
 =


      

      
10.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

      
   submitted.  =
This document renames the registry to "LISP Algorithm ID =
   submitted.  This document renames the =
registry to "LISP Algorithm ID

      
   Numbers" and =
requests the IANA to make the name change.    Numbers" and requests the IANA to make the name =
change.

      
 =


      
   The following =
Algorithm ID values are defined by this specification    The following Algorithm ID values are defined by this =
specification

      
   as used in any =
packet type that references a 'Algorithm ID' field:    as used in any packet type that references a =
'Algorithm ID' field:

      
 =


      
         Name     =
            Number          Defined in  =
        Name                 Number          Defined in

      
         =
-----------------------------------------------          =
-----------------------------------------------

      
         None     =
            0               RFC6833bis  =
        None                 0               RFC6833bis

      
         =
HMAC-SHA-1-96        1               [RFC2404]          HMAC-SHA-1-96        1               =
[RFC2404]

      
         =
HMAC-SHA-256-128     2               [RFC4868]          HMAC-SHA-256-128     2               =
[RFC4868]

      
 =


      
   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.

      
 =


      

      
11.  References 12.  References

      
 =


      

      
11.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-00 (work in progress), July =
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-14 (work in progress),

      
 =


      
skipping =
to change at page 40, line =
25 =C2=B6 =
skipping to change at page 41, line =
5 =C2=B6

      
   [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>.

      
 =


      

      
11.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]

      
 =
              3GPP, =
"General Packet Radio System (GPRS) Tunnelling

      
 =
              Protocol =
User Plane (GTPv1-U)", TS.29.281

      
 =
              =
https://portal.3gpp.org/desktopmodules/Specifications/

      
 =
              =
SpecificationDetails.aspx?specificationId=3D1699, January

      
 =
              =
2015.

      
 =
                                               =
                          

      
   =
[I-D.ermagan-lisp-nat-traversal]    =
[I-D.ermagan-lisp-nat-traversal]

      
              =
Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, =
              Ermagan, V., Farinacci, D., =
Lewis, D., Skriver, J., Maino,

      
              F., =
and C. White, "NAT traversal for LISP", draft-ermagan-               F., and C. White, "NAT traversal for =
LISP", draft-ermagan-

      
              =
lisp-nat-traversal-14 (work in progress), April 2018.               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.

      
 =


      

      
 =
   [I-D.ietf-lisp-gpe]

      
 =
              Maino, =
F., Lemon, J., Agarwal, P., Lewis, D., and M.

      
 =
              Smith, =
"LISP Generic Protocol Extension", draft-ietf-lisp-

      
 =
              gpe-05 =
(work in progress), August 2018.

      
 =
                                               =
                          

      
   =
[I-D.ietf-lisp-introduction]    =
[I-D.ietf-lisp-introduction]

      
              =
Cabellos-Aparicio, A. and D. Saucez, "An Architectural               Cabellos-Aparicio, A. and D. Saucez, "An =
Architectural

      
              =
Introduction to the Locator/ID Separation Protocol               Introduction to the Locator/ID Separation =
Protocol

      
              =
(LISP)", draft-ietf-lisp-introduction-13 (work in               (LISP)", draft-ietf-lisp-introduction-13 =
(work in

      
              =
progress), April 2015.               =
progress), April 2015.

      
 =


      
   =
[I-D.ietf-lisp-mn]    =
[I-D.ietf-lisp-mn]

      
              =
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP =
              Farinacci, D., Lewis, D., Meyer, =
D., and C. White, "LISP

      
              =
Mobile Node", draft-ietf-lisp-mn-02 (work in progress), =
              Mobile Node", =
draft-ietf-lisp-mn-02 (work in progress),

      
              =
April 2018.               April =
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-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.
 =


      

      
 =
   [I-D.ietf-nvo3-vxlan-gpe]

      
 =
              Maino, =
F., Kreeger, L., and U. Elzur, "Generic Protocol

      
 =
              Extension =
for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work

      
 =
              in =
progress), April 2018.

      
 =
                                               =
                          

      
   =
[I-D.ietf-opsec-icmp-filtering]    =
[I-D.ietf-opsec-icmp-filtering]

      
              =
Gont, F., Gont, G., and C. Pignataro, "Recommendations for =
              Gont, F., Gont, G., and C. =
Pignataro, "Recommendations for

      
              =
filtering ICMP messages", draft-ietf-opsec-icmp-               filtering ICMP messages", =
draft-ietf-opsec-icmp-

      
              =
filtering-04 (work in progress), July 2013.               filtering-04 (work in progress), July =
2013.

      
 =


      

      
   [I-D.lewis-lisp-gpe] 

      
              Lewis, D., Lemon, J., Agarwal, P., =
Kreeger, L., Quinn, P., 

      
              Smith, M., Yadav, N., and F. Maino, "LISP =
Generic Protocol 

      
              Extension", draft-lewis-lisp-gpe-04 (work =
in progress), 

      
              December 2017. 

      
                =
                                                          =


      
   =
[I-D.meyer-loc-id-implications]    =
[I-D.meyer-loc-id-implications]

      
              =
Meyer, D. and D. Lewis, "Architectural Implications of               Meyer, D. and D. Lewis, "Architectural =
Implications of

      
              =
Locator/ID Separation", draft-meyer-loc-id-implications-01 =
              Locator/ID Separation", =
draft-meyer-loc-id-implications-01

      
              =
(work in progress), January 2009.      =
         (work in progress), January 2009.

      
 =


      

      
   [I-D.quinn-vxlan-gpe] 

      
              Quinn, P., Manur, R., Kreeger, L., Lewis, =
D., Maino, F., 

      
              Smith, M., Agarwal, P., Yong, L., Xu, X., =
Elzur, U., Garg, 

      
              P., and D. Melman, "Generic Protocol =
Extension for VXLAN", 

      
              draft-quinn-vxlan-gpe-04 (work in =
progress), February 

      
              2015. 

      
                =
                                                          =


      
   =
[I-D.rodrigueznatal-lisp-oam]    =
[I-D.rodrigueznatal-lisp-oam]

      
              =
Rodriguez-Natal, A., Cabellos-Aparicio, A., Portoles-               Rodriguez-Natal, A., Cabellos-Aparicio, =
A., Portoles-

      
              =
Comeras, M., Kowal, M., Lewis, D., and F. Maino, "LISP-OAM =
              Comeras, M., Kowal, M., Lewis, =
D., and F. Maino, "LISP-OAM

      
              =
(Operations, Administration and Management): Use cases and =
              (Operations, Administration and =
Management): Use cases and

      
              =
requirements", draft-rodrigueznatal-lisp-oam-08 (work in =
              requirements", =
draft-rodrigueznatal-lisp-oam-08 (work in

      
              =
progress), June 2018.               =
progress), June 2018.

      
 =


      

      
   [I-D.rodrigueznatal-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-rodrigueznatal- 

      
              lisp-pubsub-02 (work in progress), March =
2018. 

      
                =
                                                          =


      
   [RFC1035]  =
Mockapetris, P., "Domain names - implementation and    [RFC1035]  Mockapetris, P., "Domain names - =
implementation and

      
              =
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, =
              specification", STD 13, RFC 1035, =
DOI 10.17487/RFC1035,

      
              =
November 1987, <https://www.rfc-editor.org/info/rfc1035>. =
              November 1987, =
<https://www.rfc-editor.org/info/rfc1035>.

      
 =


      
   [RFC1071]  =
Braden, R., Borman, D., and C. Partridge, "Computing the =
   [RFC1071]  Braden, R., Borman, D., and C. =
Partridge, "Computing the

      
              =
Internet checksum", RFC 1071, DOI 10.17487/RFC1071,               Internet checksum", RFC 1071, DOI =
10.17487/RFC1071,

      
              =
September 1988, =
<https://www.rfc-editor.org/info/rfc1071>.               September 1988, =
<https://www.rfc-editor.org/info/rfc1071>.

      
 =


      
   [RFC2104]  =
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- =
   [RFC2104]  Krawczyk, H., Bellare, M., and R. =
Canetti, "HMAC: Keyed-

      
              =
Hashing for Message Authentication", RFC 2104,               Hashing for Message Authentication", RFC =
2104,

      
              DOI =
10.17487/RFC2104, February 1997,       =
        DOI 10.17487/RFC2104, February 1997,

      
              =
<https://www.rfc-editor.org/info/rfc2104>.               =
<https://www.rfc-editor.org/info/rfc2104>.

      
 =


      
   [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>.

      
 =


      

      
 =
   [RFC2890]  Dommety, =
G., "Key and Sequence Number Extensions to GRE",

      
 =
              RFC 2890, =
DOI 10.17487/RFC2890, September 2000,

      
 =
              =
<https://www.rfc-editor.org/info/rfc2890>.

      
 =
                                               =
                          

      
   [RFC6234]  =
Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms =
   [RFC6234]  Eastlake 3rd, D. and T. Hansen, =
"US Secure Hash Algorithms

      
              =
(SHA and SHA-based HMAC and HKDF)", RFC 6234,               (SHA and SHA-based HMAC and HKDF)", RFC =
6234,

      
              DOI =
10.17487/RFC6234, May 2011,            =
   DOI 10.17487/RFC6234, May 2011,

      
              =
<https://www.rfc-editor.org/info/rfc6234>.               =
<https://www.rfc-editor.org/info/rfc6234>.

      
 =


      
   [RFC6830]  =
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The =
   [RFC6830]  Farinacci, D., Fuller, V., Meyer, =
D., and D. Lewis, "The

      
              =
Locator/ID Separation Protocol (LISP)", RFC 6830,               Locator/ID Separation Protocol (LISP)", =
RFC 6830,

      
              DOI =
10.17487/RFC6830, January 2013,        =
       DOI 10.17487/RFC6830, January 2013,

      
              =
<https://www.rfc-editor.org/info/rfc6830>.               =
<https://www.rfc-editor.org/info/rfc6830>.

      
 =


      
 =


      
skipping =
to change at page 43, line =
43 =C2=B6 =
skipping to change at page 44, line =
37 =C2=B6

      
              =
Protocol (LISP): Shared Extension Message & IANA Registry =
              Protocol (LISP): Shared Extension =
Message & IANA Registry

      
              for =
Packet Type Allocations", RFC 8113,    =
           for Packet Type Allocations", RFC 8113,

      
              DOI =
10.17487/RFC8113, March 2017,          =
     DOI 10.17487/RFC8113, March 2017,
              =
<https://www.rfc-editor.org/info/rfc8113>.               =
<https://www.rfc-editor.org/info/rfc8113>.

      
 =


      
   [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

      
 =
              2119 Key =
Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,

      
 =
              May 2017, =
<https://www.rfc-editor.org/info/rfc8174>.

      
 =
                                               =
                          

      
   [RFC8378]  =
Moreno, V. and D. Farinacci, "Signal-Free Locator/ID    [RFC8378]  Moreno, V. and D. Farinacci, "Signal-Free =
Locator/ID

      
              =
Separation Protocol (LISP) Multicast", RFC 8378,               Separation Protocol (LISP) Multicast", RFC =
8378,

      
              DOI =
10.17487/RFC8378, May 2018,            =
   DOI 10.17487/RFC8378, May 2018,

      
              =
<https://www.rfc-editor.org/info/rfc8378>.               =
<https://www.rfc-editor.org/info/rfc8378>.

      
 =


      

      
 =
   [RFC8402]  Filsfils, =
C., Ed., Previdi, S., Ed., Ginsberg, L.,

      
 =
              Decraene, =
B., Litkowski, S., and R. Shakir, "Segment

      
 =
              Routing =
Architecture", RFC 8402, DOI 10.17487/RFC8402,

      
 =
              July =
2018, <https://www.rfc-editor.org/info/rfc8402>.

      
 =
                                               =
                          

      
Appendix A.  =
Acknowledgments Appendix A.  =
Acknowledgments

      
 =


      
   The authors =
would like to thank Greg Schudel, Darrel Lewis, John    The authors would like to thank Greg Schudel, Darrel =
Lewis, John

      
   Zwiebel, =
Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, =
   Zwiebel, Andrew Partan, Dave Meyer, Isidor =
Kouvelas, Jesper Skriver,

      
   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-12 B.1. =
 Changes to draft-ietf-lisp-rfc6833bis-13

      
 =


      
 =
   o  Posted August =
2018.

      
 =


      
 =
   o  Final editorial =
changes before RFC submission for Proposed

      
 =
      =
Standard.

      
 =


      
 =
   o  Added section =
"Changes since RFC 6833" so implementators are

      
 =
      informed of any =
changes since the last RFC publication.

      
 =


      
 =
B.2.  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.2.  Changes to =
draft-ietf-lisp-rfc6833bis-11 B.3.  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.3.  Changes to =
draft-ietf-lisp-rfc6833bis-10 B.4.  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.4.  Changes to =
draft-ietf-lisp-rfc6833bis-09 B.5.  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.5.  Changes to =
draft-ietf-lisp-rfc6833bis-08 B.6.  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.6.  Changes to =
draft-ietf-lisp-rfc6833bis-07 B.7.  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 45, line =
39 =C2=B6 =
skipping to change at page 47, line =
5 =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.7.  Changes to =
draft-ietf-lisp-rfc6833bis-06 B.8.  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.8.  Changes to =
draft-ietf-lisp-rfc6833bis-05 B.9.  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.9.  Changes to =
draft-ietf-lisp-rfc6833bis-04 B.10.  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.10.  Changes to =
draft-ietf-lisp-rfc6833bis-03 B.11.  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.11.  Changes to =
draft-ietf-lisp-rfc6833bis-02 B.12.  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.12.  Changes to =
draft-ietf-lisp-rfc6833bis-01 B.13.  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.13.  Changes to =
draft-ietf-lisp-rfc6833bis-00 B.14.  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.14.  Changes to =
draft-farinacci-lisp-rfc6833bis-00 B.15.  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. 42 change blocks. 

     
81 lines changed or =
deleted 144 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=_E0BACCC1-D960-4F49-B3FF-34CD23B791A9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Aug 22, 2018, at 3:51 AM, Luigi Iannone  wrote:
>=20
> Hi Dino,
>=20
> the new section looks good to me. Just one comment: I would avoid use =
the word =E2=80=9Cdraft=E2=80=9D in the first sentence of the last =
bullet of the section.
> So instead of=20
>=20
> "Data-plane gleaning for creating map-cache entries has been made =
optional in this draft.=E2=80=9D
>=20
> I would simply put:
>=20
> "Data-plane gleaning for creating map-cache entries has been made =
optional.=E2=80=9D
>=20
> Just trimming the last part.
>=20
> Ciao
>=20
> L.
>=20
>=20
>=20
>> On 20 Aug 2018, at 20:42, Dino Farinacci  wrote:
>>=20
>> 
>=20


--Apple-Mail=_E0BACCC1-D960-4F49-B3FF-34CD23B791A9--


From nobody Thu Aug 23 11:01: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 9D9B5130E4B; Thu, 23 Aug 2018 11:01:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
CC: lisp-chairs@ietf.org, lisp@ietf.org, db3546@att.com, Luigi Iannone , draft-ietf-lisp-gpe@ietf.org, ggx@gigix.net
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Reply-To: ietf@ietf.org
Message-ID: <153504726661.12149.16060749865720630231.idtracker@ietfa.amsl.com>
Date: Thu, 23 Aug 2018 11:01:06 -0700
Archived-At: 
Subject: [lisp] Last Call:  (LISP Generic Protocol Extension) to Proposed Standard
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: Thu, 23 Aug 2018 18:01:07 -0000

The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'LISP Generic Protocol Extension'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-09-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
    draft-ietf-lisp-6834bis: Locator/ID Separation Protocol (LISP) Map-Versioning (None - IETF stream)




From nobody Fri Aug 24 03:58: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 7C791130E7D; Fri, 24 Aug 2018 03:58:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stewart Bryant 
To: 
Cc: lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153510829645.23054.14135893273393348518@ietfa.amsl.com>
Date: Fri, 24 Aug 2018 03:58:16 -0700
Archived-At: 
Subject: [lisp] Genart last call review of draft-ietf-lisp-gpe-05
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: Fri, 24 Aug 2018 10:58:17 -0000

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

.

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.

Whatever the conclusion this matter will need to be clearly written up in the
Shepherd's report.

Major issues: No technical issues, but see summary.

Minor issues: None

Nits/editorial comments: None



From nobody Fri Aug 24 11:07:55 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 AD23912D7F8; Fri, 24 Aug 2018 11:07:48 -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: <153513406867.22926.11360033848087598658@ietfa.amsl.com>
Date: Fri, 24 Aug 2018 11:07:48 -0700
Archived-At: 
Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-15.txt
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: Fri, 24 Aug 2018 18:07:49 -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-15.txt
	Pages           : 42
	Date            : 2018-08-24

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-15
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-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 Fri Aug 24 11:11: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 EE53F12D7F8; Fri, 24 Aug 2018 11:11: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: <153513429795.23063.3900637120528948509@ietfa.amsl.com>
Date: Fri, 24 Aug 2018 11:11:37 -0700
Archived-At: 
Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-13.txt
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: Fri, 24 Aug 2018 18:11:38 -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-13.txt
	Pages           : 49
	Date            : 2018-08-24

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 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-13
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-13


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 Aug 24 12:33: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 1D55E130E03; Fri, 24 Aug 2018 12:33:49 -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.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153513922907.22939.10542350679349996082@ietfa.amsl.com>
Date: Fri, 24 Aug 2018 12:33:49 -0700
Archived-At: 
Subject: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15
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: Fri, 24 Aug 2018 19:33:49 -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.

For intranet purposes, LISP (including this document) is Ready: operators
adopting this technology assume responsibility for the potentially novel
operational difficulties of a routing infrastructure having seen limited
deployment in adversarial environments. For internet deployment, readiness is
less clear.

For the internet core (DFZ RIB) use-case, LISP proposes replacing BGP sessions
and global eventually-consistent state sharing with a global control plane and
piecewise on-demand state pull. This new control plane presents novel
opportunities for attackers, and so RFC 7834 recommends authentication for all
control-plane traffic as a countermeasure for many of the threats outlined in
RFC 7835. Proper authentication will be effective for certain classes of
attacks, but does not completely address the security needs of the control
plane, nor is it clear that the proposed authentication is appropriate to the
desired scale of deployment.

One area of concern, of which I have not been able to find discussion, is that
of the implications of shared capacity for the control and data planes, and how
this can allow a volumetric data plane attack to deny a router access to the
global mapping system, slowly choking off service to uncached portions of the
EID address space. Section 6.7 of draft-ietf-lisp-sec discusses denial of
service attacks, but fails to distinguish between impersonation attacks
(properly countered by authentication using a pre-established chain of trust)
and volumetric attacks (perhaps complicated by those very authentication
mechanisms, which are often quite expensive). If discussion of this class of
issues exists elsewhere, I would appreciate a pointer as I have not yet found
it.

I would also like clarification on what defines the separation between the
control plane and data plane, and whether authentication itself is used to
distinguish, because that impacts how to precisely describe how attacks relate
to the architecture. Lack of clarity here will lead to inconsistent sets of
assumptions and security assertions.

Moreso than this particular document, draft-ietf-lisp-sec is probably where the
real action is for the security area. That document poses a multitude of
questions, only the most obvious of which is why communication between an ITR
and a Map-Resolver should be over a bespoke protocol instead of (say) DTLS.
Since there must be a pre-established trust relationship between the two, and
presumably a persistent session, this seems an obvious choice for
confidentiality and integrity protection. (Note: this is not intended as a
statement that DTLS is definitely a better choice, only that I have not been
able to find documentation of consideration of this design alternative and why
it was rejected.)

Another question it poses is: how does the Map-Resolver authenticate the
Map-Server? Symmetric authentication with the ITR-OTK demonstrates only that
the response is associated with the request: it's not immediately clear to me
what security guarantees it provides to the ITR. Limiting attacks to on-path
attackers, yes. But what about MitM? That class of attacks requires either a
pre-shared key (implying a pre-existing trust relationship between a
Map-Resolver and every Map-Server it interacts with) or asymmetric
authentication with some kind of trust anchor. I have been able to find no
mention of the latter, and it does not seem that the former scales particularly
well.

Given the difficulties in evaluating the readiness of this one piece of the
LISP ecosystem, it may be best to batch the set of documents describing the
entire protocol and to move them through IETF LC at the same time.


From nobody Sat Aug 25 14:40: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 C909D130EE8; Sat, 25 Aug 2018 14:40:21 -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 OS1EKFuoxXcS; Sat, 25 Aug 2018 14:40:19 -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 6B5DA130E44; Sat, 25 Aug 2018 14:40:19 -0700 (PDT)
Received: by mail-pl1-x634.google.com with SMTP id p4-v6so2502137pll.8; Sat, 25 Aug 2018 14:40:19 -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=rpa55aNt2PptfCWqNXmfgS4w7ISGEM14BSoh1NGJpvA=; b=DGUBhbC5CpLFrjZOkkzglonmI1mkmqKf9lE5wFOxs5+rO2oT3GuJvBpyXul7L7QdIp hEedIY3hu3R9Y9zKFGB3iKxmep0AvFJagcaDgPhC01Q56KjzwAbzBATU4dJfkwqCXHW4 5rJk5wDNL4/wRhNjAFSROKDMAXqGtHbWxM0qCu8mPguIGGD3u2C+fbsOgLf68fDSqtLz pN1htO5STDWLO0dYrvqic9XEacE+lOfmG9+F/dw3I0Y0z6dXi63HqcsDvRLmXyZrptDD ADN63UbG8vocthzCWgqVBVRH++0UlcPQO8CfFFgk83rfL3pcOYfC6wjPOqBDNPnbBgVX 1dKA==
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=rpa55aNt2PptfCWqNXmfgS4w7ISGEM14BSoh1NGJpvA=; b=aDDy7t2np9bMFAdnuxkb+Cj3VFs6T+x1ETwCTWfpn4bM47l6oSueBdcjIle8RmWzPr JILXo9kVLSZegCo3H0LE+OWL6tj+tJKIRmAXDZWRpK1hdMHeyp7WE3YgwkCSK77g3YfZ pGjxlH9YkHfHdYgmJBShoI/ukocklrbxQqXYvKYvZbpUgc0lOOwmzYuvxPgLxXrOGaQ8 QYEgiOeml+ye7n3Nwh/FSfZG0pNq/4jHHg9V9ju/YNQ9OgbEd6Hwogwl+lLqX8Vrs8iT P7ZaISpRPP0MKS5FJQ+T+qy1pnuKJV5oHyXURWwIZ1jWhV8a8MaJSqJTO+9QLbyzQ/tR IkWw==
X-Gm-Message-State: APzg51As407VMEunLlrcS+22+rpKwk/5afuMwYpdz1pjzVcxcAD8PoB2 yZtbicj9GQOwCnM72HlOZzs=
X-Google-Smtp-Source: ANB0Vda5+bgdgSOlPEhqeDrCpPqC/hJbMvhVc9ghwe8rlLoUhzgVDAxGmSTW+6MKfA01j5YJwlsGmA==
X-Received: by 2002:a17:902:528a:: with SMTP id a10-v6mr6890065pli.199.1535233218835;  Sat, 25 Aug 2018 14:40:18 -0700 (PDT)
Received: from ?IPv6:2603:3024:151c:55f0:f595:40dc:8980:444e? ([2603:3024:151c:55f0:f595:40dc:8980:444e]) by smtp.gmail.com with ESMTPSA id s73-v6sm17087002pfi.154.2018.08.25.14.40.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Aug 2018 14:40:18 -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: <153513922907.22939.10542350679349996082@ietfa.amsl.com>
Date: Sat, 25 Aug 2018 14:40:15 -0700
Cc: secdir@ietf.org, draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , Dino Farinacci , "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
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.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: Sat, 25 Aug 2018 21:40:22 -0000

> Reviewer: Kyle Rose
> Review result: Has Issues

Thanks for the review Kyle. See my responses inline.

> 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.
>=20
> For intranet purposes, LISP (including this document) is Ready: =
operators
> adopting this technology assume responsibility for the potentially =
novel
> operational difficulties of a routing infrastructure having seen =
limited
> deployment in adversarial environments. For internet deployment, =
readiness is
> less clear.

Right, agree.

> For the internet core (DFZ RIB) use-case, LISP proposes replacing BGP =
sessions
> and global eventually-consistent state sharing with a global control =
plane and

LISP *does not propse to eliminate BGP*, in fact it needs it so RLOC =
reachability across the network is available, or there would be no =
underlay for the LISP overlay.

> piecewise on-demand state pull. This new control plane presents novel
> opportunities for attackers, and so RFC 7834 recommends authentication =
for all
> control-plane traffic as a countermeasure for many of the threats =
outlined in
> RFC 7835. Proper authentication will be effective for certain classes =
of
> attacks, but does not completely address the security needs of the =
control
> plane, nor is it clear that the proposed authentication is appropriate =
to the
> desired scale of deployment.

You are missing pieces of the design and hence why you came to the =
conclusion you did. There are three documents that enhance the security =
of LISP, they are:

(1) RFC 8061 - Locator/ID Separation Protocol (LISP) Data-Plane =
Confidentiality
(2) RFC 8111 - Locator/ID Separation Protocol Delegated Database Tree =
(LISP-DDT)
(3) draft-farinacci-lisp-ecdsa-auth

You find strong asymmetric authenticaiton and authorization in (3). And =
you=E2=80=99ll find authentication of the mapping system nodes in (2). =
And note that (1) can be used and layered under the control-plane to =
give encrypted control-plane flows (or use DTLS as LISP-SEC refers to =
for the messages it requires for its functionality).

> One area of concern, of which I have not been able to find discussion, =
is that
> of the implications of shared capacity for the control and data =
planes, and how
> this can allow a volumetric data plane attack to deny a router access =
to the
> global mapping system, slowly choking off service to uncached portions =
of the

Well yes, this happens with all our IETF protocols. It is a valid =
concern and there are many operational techniques in network =
infrastructure that *help* solve (but not eliminate) these problems.

> EID address space. Section 6.7 of draft-ietf-lisp-sec discusses denial =
of
> service attacks, but fails to distinguish between impersonation =
attacks
> (properly countered by authentication using a pre-established chain of =
trust)
> and volumetric attacks (perhaps complicated by those very =
authentication
> mechanisms, which are often quite expensive). If discussion of this =
class of
> issues exists elsewhere, I would appreciate a pointer as I have not =
yet found
> it.

In draft-farinacci-lisp-ecdsa-auth, there are mechanisms to sign =
Map-Register and Map-Requests going to the mapping system. The =
map-servers, that make up the mapping system, verify signatures by =
looking up public-keys in another part of the mapping system.

> I would also like clarification on what defines the separation between =
the
> control plane and data plane, and whether authentication itself is =
used to

A control-plane obtains information to store in a table. The data-plane =
uses that table. That is the definition in the simpliest form.

> distinguish, because that impacts how to precisely describe how =
attacks relate
> to the architecture. Lack of clarity here will lead to inconsistent =
sets of
> assumptions and security assertions.

We have a lot of research and documentation identifying the threats and =
how to manage caches to minmize the impact of an attack. See the =
following documents:

(1) RFC 7835 (was draft-ietf-lisp-threats)=20
(2) draft-ietf-lisp-rfc6833bis
(3) RFC 7215 (was draft-ietf-lisp-deployment)=20

These documents also point to research papers that have done analysis on =
threat attacks.

> Moreso than this particular document, draft-ietf-lisp-sec is probably =
where the
> real action is for the security area. That document poses a multitude =
of

And the documents I cite above.

> questions, only the most obvious of which is why communication between =
an ITR
> and a Map-Resolver should be over a bespoke protocol instead of (say) =
DTLS.

LISP-SEC does suggest that DTLS can be used. And there have been =
proposals to run a reliable transport between the nodes that use the =
mapping system and the nodes that are part of the mapping system. And =
when using TCP, TLS can be acompanied as well as turning on encryption =
in QUIC. This document is:

(1) draft-kouvelas-lisp-reliable-transport

> Since there must be a pre-established trust relationship between the =
two, and
> presumably a persistent session, this seems an obvious choice for
> confidentiality and integrity protection. (Note: this is not intended =
as a
> statement that DTLS is definitely a better choice, only that I have =
not been
> able to find documentation of consideration of this design alternative =
and why
> it was rejected.)

Right, agree, and understand.

> Another question it poses is: how does the Map-Resolver authenticate =
the
> Map-Server? Symmetric authentication with the ITR-OTK demonstrates =
only that

We plane to add that in draft-farinacci-lisp-ecdsa-auth. Up until now it =
was the clients of the mapping system that first needed to be =
authenticated, but the map-servers can do the same. We plan to adding =
signing Map-Notify messages which is typically an Ack to a signed =
Map-Register sent by an xTR.

> the response is associated with the request: it's not immediately =
clear to me
> what security guarantees it provides to the ITR. Limiting attacks to =
on-path
> attackers, yes. But what about MitM? That class of attacks requires =
either a
> pre-shared key (implying a pre-existing trust relationship between a

We do use pre-shared keys for registering to the mapping system. And you =
could encrypt messages in both directions using this shared-key. This =
shared-key was intended for authorization of a particulary (IID, EID) =
pair to the mapping system, but can be easily for encryption.

> Map-Resolver and every Map-Server it interacts with) or asymmetric
> authentication with some kind of trust anchor. I have been able to =
find no
> mention of the latter, and it does not seem that the former scales =
particularly
> well.

The way draft-farinacci-lisp-ecdsa-auth specs this is out is:

(1) A controller registers hash-to-pubkey mappings in the mapping =
system. There is a shared key between the controller and map-server(s) =
so only specific, authorized controllers can register these public-keys.

(2) When Map-Register messages arrive at the Map-Server, there is a =
signature-EID in the message, that is the hash of the public-key used to =
lookup the hash-to-pubkey mapping, if mapping not found, Map-Register is =
rejected. If found, the signature is verified.=20

(3) When Map-Requerst messages arrive at the Map-Resolver, the same =
happens as in (2).

Note when LISP0-DDT is used, each level of the delegation hierarchy =
advertises the public-key of the children so when they send Map-Referral =
messages which are signed by the children, the Map-Resolver has a =
public-key to verify the Map-Referral signature.

> Given the difficulties in evaluating the readiness of this one piece =
of the
> LISP ecosystem, it may be best to batch the set of documents =
describing the
> entire protocol and to move them through IETF LC at the same time.

I hope I have helped you a bit. And if you have any more questions, =
please don=E2=80=99t hesitate to ask.

Thanks again for your review,
Dino





From nobody Sun Aug 26 09:42: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 9BFD712785F; Sun, 26 Aug 2018 09:42:44 -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 345xVEdSyqO5; Sun, 26 Aug 2018 09:42:43 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 A8111128B14; Sun, 26 Aug 2018 09:42:42 -0700 (PDT)
X-AuditID: 1209190f-2e9ff70000006e88-17-5b82d880cdc1
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 96.81.28296.188D28B5; Sun, 26 Aug 2018 12:42:41 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w7QGgZGv016191; Sun, 26 Aug 2018 12:42:37 -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 w7QGgVP1008674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Aug 2018 12:42:33 -0400
Date: Sun, 26 Aug 2018 11:42:31 -0500
From: Benjamin Kaduk 
To: Dino Farinacci 
Cc: Kyle Rose , draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" , IETF Discussion Mailing List , secdir@ietf.org
Message-ID: <20180826164230.GN59914@kduck.kaduk.org>
References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IRYrdT12280RRtsGqhokXTlxvsFu27rzFa PNs4n8Vi/YtJbBZTzqpbfFj4kMWBzWPnrLvsHkuW/GTy6Lr4nSmAOYrLJiU1J7MstUjfLoEr Y8ux1IJGnorZG7exNTDe4+xi5OSQEDCROPt5F0sXIxeHkMBiJonfW5YwQTgbGSWWrt7EBlIl JHCVSWLSvnwQm0VAVeLHy0OMIDabgIpEQ/dlZhBbREBD4u773ewgzcwC+xklpv1axQSSEBbw k5i27ydYES/QutfbjrNCDC2XuPT/JiNEXFDi5MwnLCA2s4CWxI1/L4F6OYBsaYnl/zhAwpwC thIvtzSBlYgKKEvs7TvEPoFRYBaS7llIumchdC9gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qk a6KXm1mil5pSuokRFNSckvw7GOc0eB9iFOBgVOLhbVjUGC3EmlhWXJl7iFGSg0lJlPeRVVO0 EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeM5+BynlTEiurUovyYVLSHCxK4rz3asKjhQTSE0tS s1NTC1KLYLIyHBxKErxZ14GGChalpqdWpGXmlCCkmTg4QYbzAA13B6nhLS5IzC3OTIfIn2LU 5fjzfuokZiGWvPy8VClx3pvXgIoEQIoySvPg5oCSkUT2/ppXjOJAbwnz7gEZxQNMZHCTXgEt YQJaMuNVA8iSkkSElFQDI6eIhk7V19VzKnQ+Tl9eqdqx2UIy7/RK62vPjZTZAw1CEnknNl4K e7vnzswp+qa8hwK3PGK9/WBFY+TL6zki694wPptYbSKqtorr1/4d5w86LHrwUdt+RVGehtak 23NqQ/vZAms7lKX/1C3+9iW/NjaELc9rR8kKJ84YvlyP1D+JLp/0rdSPKrEUZyQaajEXFScC AKPauwIhAwAA
Archived-At: 
Subject: Re: [lisp] [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15
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: Sun, 26 Aug 2018 16:42:45 -0000

Kyle, Dino,

Thanks for the review and discussion -- I look forward to seeing where it
ends up.  Just one note, inline...

On Sat, Aug 25, 2018 at 02:40:15PM -0700, Dino Farinacci wrote:
> > Reviewer: Kyle Rose
> > Review result: Has Issues
> 
> 
> > Another question it poses is: how does the Map-Resolver authenticate the
> > Map-Server? Symmetric authentication with the ITR-OTK demonstrates only that
> 
> We plane to add that in draft-farinacci-lisp-ecdsa-auth. Up until now it was the clients of the mapping system that first needed to be authenticated, but the map-servers can do the same. We plan to adding signing Map-Notify messages which is typically an Ack to a signed Map-Register sent by an xTR.
> 
> > the response is associated with the request: it's not immediately clear to me
> > what security guarantees it provides to the ITR. Limiting attacks to on-path
> > attackers, yes. But what about MitM? That class of attacks requires either a
> > pre-shared key (implying a pre-existing trust relationship between a
> 
> We do use pre-shared keys for registering to the mapping system. And you could encrypt messages in both directions using this shared-key. This shared-key was intended for authorization of a particulary (IID, EID) pair to the mapping system, but can be easily for encryption.

If the PSK does get additionally purposed for encryption, please make sure
to use a modern key derivation hierarchy to provide separation between the
authentication and encryption usages.

-Benjamin


From nobody Sun Aug 26 18:19: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 76C1F130DE2; Sun, 26 Aug 2018 18:19: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 zbdLVR_tS8ed; Sun, 26 Aug 2018 18:19:11 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 402EA1277C8; Sun, 26 Aug 2018 18:19:11 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id b11-v6so6928187pfo.3; Sun, 26 Aug 2018 18:19: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=f2D+zQzXcD645BJfDeDot299V9sIWuAuD4DgAKHEqyc=; b=AI4HkHuuPzt4ikYGDQUSHbsWUBnO4Kul8qbj2dXgBrNhqKMndueBWClaYd9rhwHu6M 3x3SHeaxSVYerAd0jlK4gegWg/hk0dqHSFS1doXDP2Z4ydOdd2TNjt63E1AbsrsUj4z9 h468Ljw2Ot0qBoSQl9oeHh5LsY+9H00hNtqrYmaGtyZ2giQdD5p4NmjB/d2r1yeLD6d9 27+Vbx/WGHeZGGBcZ67FVNghyOeeywbbNt4C20XThgmF+Ju/VMhgumuTOfy9wPANrile y2I7JFXV8kDkjTfzpvGRiIWxSToq0FILVRH1fgF8cqejUswd3ewWVuXYNcNCjx7k2y1L wVcQ==
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=f2D+zQzXcD645BJfDeDot299V9sIWuAuD4DgAKHEqyc=; b=SdHvq2ARCvjCCh3fzTFLRvjquGUZfY2kYeJppjAxro0ZaDFtRwBJL0ALna5QQEXn5v +yJBYa619TSzyyU7YpkNoZ+D3nU2OQ0rRUYosG1WspWlIFTwi9wdRW5g51qd6BN19FTz WdEXn2/3VdQaZ6PlobpHD3GnrE2aNEm3OsxlBTvS+R1bVGxvtjvVoSLVNRCuf3LlWLD+ zYkQ9/Qey691TgGkw/SJnPXmH5QSvrB4GwaK7bN4AMjVdVRcX8tvEJiPUyLVEYOnyNLu /9gaLHlgtwsH6/9GktUiRQTnaplbn+Yy/QVSI/gAQt7RS1tacDc4MsGhTqipDagwDJrC eMJQ==
X-Gm-Message-State: APzg51AfEsIKHFUj3kD76ZLkMrpSPaG9gn20rqpL08u53SQHc7koX9YX P0IuQVMJKDwrl4d+B1cb/yg=
X-Google-Smtp-Source: ANB0VdaLrEMNrgN3jozPajvvtpMqPRqekYkFWkF1/f0wcm83DTMINUwS9bnyDwVeFuSs0niqxST/Lg==
X-Received: by 2002:a62:fcd2:: with SMTP id e201-v6mr12057492pfh.101.1535332750774;  Sun, 26 Aug 2018 18:19:10 -0700 (PDT)
Received: from ?IPv6:2600:380:8534:1feb:3042:68f0:cdae:2918? ([2600:380:8534:1feb:3042:68f0:cdae:2918]) by smtp.gmail.com with ESMTPSA id s75-v6sm21326610pfd.108.2018.08.26.18.19.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Aug 2018 18:19:10 -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: <20180826164230.GN59914@kduck.kaduk.org>
Date: Sun, 26 Aug 2018 18:19:09 -0700
Cc: Kyle Rose , draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" , IETF Discussion Mailing List , secdir@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <196C2E5D-3DE1-46DD-9DC8-B3B0EC29DA10@gmail.com>
References: <153513922907.22939.10542350679349996082@ietfa.amsl.com>  <20180826164230.GN59914@kduck.kaduk.org>
To: Benjamin Kaduk 
Archived-At: 
Subject: Re: [lisp] [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15
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, 27 Aug 2018 01:19:13 -0000

> If the PSK does get additionally purposed for encryption, please make sure=

> to use a modern key derivation hierarchy to provide separation between the=

> authentication and encryption usages.

I would venture to say we wouldn=E2=80=99t use the PSK for that. Our options=
 are to negotiate a shared session key with the asymmetric keys already bein=
g used, use DTLS or TLS, or use lisp-crypto and have control messages encaps=
ulated I the LISP data-plane. And yes, the later has 6 cipher suites with co=
mbinations of all the latest and greatest in Crypto (but not Edward Curves).=
=20

Dino=


From nobody Mon Aug 27 00:48: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 23DD8130DF3 for ; Mon, 27 Aug 2018 00:48:36 -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 b18P4tjcW2G7 for ; Mon, 27 Aug 2018 00:48:33 -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 0B23B130E7B for ; Mon, 27 Aug 2018 00:48:33 -0700 (PDT)
Received: by mail-wr1-x444.google.com with SMTP id z96-v6so12659012wrb.8 for ; Mon, 27 Aug 2018 00:48:32 -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=REmo7U5/ipiBPFJUSg94l5PpIFZhdtIgV2eOaWNOdGA=; b=1Iqdio+myYqBOZ1l4HLtCQ9gY6I3dLypD7rJ52NtIPXCDlCuWUPRY0iJK/wFiowwmL OQ5b6aRp1EiRE7QsEg1pkkewEXxSrYSgNIUsn+hs6Vjmp3jkZ5h3oDVqODajHAi3T5D4 Bhq3CvYXBhPds2nvhuaecGIjrNDaef9HJ6a2j9/iIlSX89yWKquRhyBD3m+XJJcgRL/F CBcEBHvrNUClkAKxfRcK9M1YnaJT8YeKiMZL449PEtPYICLkZiXzYE2/DLPP1KVj8CpY mF4AvyEw+CErDbdruqGrUTEbu+vgziG0RTYnH4zvBeY60OY+HlIg2tUGkAx4JQrXXnGS ygsA==
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=REmo7U5/ipiBPFJUSg94l5PpIFZhdtIgV2eOaWNOdGA=; b=kzj8rgKcREzbo3s+OUAcVGJWFRVWjEr/joWx8RfAJoKsk0conVsOTrcmKB2RaNEaT/ Yl5ejSLrRVtApilhe0E8dWF93Y+QBertDeVmK3NNxpl+MjPaZJCvfiqXPMQ13rUNOiHF LV96DHkL3Iwi+kdkDKLDre+ajlL7oY6R8hUJ692wmqGZi+p8bki1GWq7g72siyafrIVN QJUIs0eBlaEZH/lOepNuZcFLXZR0eAizpYncjCdTcuct2nB8BJFAMSuYCn1rBFtphe1Z msmwiSvtAC5jHXj80liUuKkFCOfuj4KnjMvN4fzYId0anma2JbL6Ws3M0cx1lG6WvTVb 9w0A==
X-Gm-Message-State: APzg51Ch2vI/hep0ntYqZhF+bS7cvx7zZz43qf22PwFgktNovildncVs 8E7Vyfz6FtymXdO9XaZj7Iasw5FZCbw=
X-Google-Smtp-Source: ANB0VdZ4pV9EkeqhIH077ANgsjNlbbSk+Z6+7xrFz43t+37GoVGdjNfDlGEk4ftb1qjnSWPIkUnqxg==
X-Received: by 2002:adf:9c12:: with SMTP id f18-v6mr8015283wrc.93.1535356111396;  Mon, 27 Aug 2018 00:48:31 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:74e6:a612:f343:a6bc? ([2001:660:330f:a4:74e6:a612:f343:a6bc]) by smtp.gmail.com with ESMTPSA id l7-v6sm13616330wrt.67.2018.08.27.00.48.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 00:48:29 -0700 (PDT)
From: Luigi Iannone 
Message-Id: <0FB6579C-8C87-4BB0-91ED-B53881F54CC2@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_308F8F5D-95C5-4023-80AC-93E187EBB289"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 27 Aug 2018 09:48:33 +0200
In-Reply-To: <153510829645.23054.14135893273393348518@ietfa.amsl.com>
Cc: gen-art@ietf.org, lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org
To: Stewart Bryant 
References: <153510829645.23054.14135893273393348518@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-gpe-05
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, 27 Aug 2018 07:48:37 -0000

--Apple-Mail=_308F8F5D-95C5-4023-80AC-93E187EBB289
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Steward,

see inline=E2=80=A6.

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.

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
> 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.


>=20




> Major issues: No technical issues, but see summary.
>=20
> Minor issues: None
>=20
> Nits/editorial comments: None
>=20
>=20


--Apple-Mail=_308F8F5D-95C5-4023-80AC-93E187EBB289
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

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/shepherdwr=
iteup/

Ciao

L.







Major issues: No technical issues, but see summary.

Minor issues: None

Nits/editorial comments: None



=

--Apple-Mail=_308F8F5D-95C5-4023-80AC-93E187EBB289--


From nobody Mon Aug 27 02:55: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 0148C1271FF; Mon, 27 Aug 2018 02:55:29 -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 CLknDw9z60Bl; Mon, 27 Aug 2018 02:55:25 -0700 (PDT)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 04501130E89; Mon, 27 Aug 2018 02:55:25 -0700 (PDT)
Received: by mail-wm0-x241.google.com with SMTP id n11-v6so7688628wmc.2; Mon, 27 Aug 2018 02:55:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=StbV4YTwf32N4ORg5IpTdGmGe9GSQUWyHrnBRt2OY8E=; b=hqnUksgYAE7uJW3ROSb3lKrEMaw9WC62himtOEtfEQa34JJG5Cg8KnN0jA6iDfniNA VM7p+8kaJqR+IW38coKmr5WGaZ9im8jExwnkKQCNcrGLUV17m+cBuzr1005Btvuzlm33 3bnY+klRKQxdLYotfaj1KJNwogxiicBxoJUHXCDXVNVGr3eVxAGYm/Epw6K1r9MCMZ6R N/v021g4HrcPC80ZWiCNoMpx1i8W9SThe8s+MB+2K/Y5ZC5Pi0jReeV5fJFTRomH9R71 tpKe+/3wwTVdXba7sJoYKZ8ZilE9gDi8ryMSTbgXpmA1rCyRbDMQOUtAOQSpmvE7WITk KVwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=StbV4YTwf32N4ORg5IpTdGmGe9GSQUWyHrnBRt2OY8E=; b=Zgbo6ZPi5CxWKDdFj1yIN0WP9vvJhmn76tlrVQ94+OoJ4CnjoHVsUiooPlQ4mtqJkC rNZpUocWZEzwW0s0yjAmwIvRiXnmSM2D2fc45ajM3w3t4RUE0RhXeq9f7P/MEEVAdhQ+ 8WZ2gVQ3Bbfi/gurrR7m9c1npfb1yi+ILSTywH7J1AQuk+giCwtMWBo8o0B8dIBuyKCU VnA14u7+cPLCrM0NJ9uZWyq6VrxnxFNVog6S4PnLSEQRs07A84Hq6lrZP6Jc+C3odM+g 3oLEgxK2nWB21Qc5ZLDkqp+91x956omy2iOB1oiQn+u2kEphOtkpqPDRlE0+NFso1CQ3 OBUg==
X-Gm-Message-State: APzg51B/0xWf5iZZe5FFL8MQXLV0N85o/yp/eyq6/1oUUQvIeRNhFk7C GdKLm1RWqcOOnUStn4Y1QNDsTDym
X-Google-Smtp-Source: ANB0Vda28YmJ0W8kU4j1deX55H0YthsNYVq7Bgq9mVpgN30hwyaVjIzdhYOqElYVlSaCzuPvX3BReQ==
X-Received: by 2002:a1c:1bca:: with SMTP id b193-v6mr5056865wmb.6.1535363723253;  Mon, 27 Aug 2018 02:55:23 -0700 (PDT)
Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id g133-v6sm8815894wmf.44.2018.08.27.02.55.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 02:55:22 -0700 (PDT)
To: Luigi Iannone 
Cc: gen-art@ietf.org, lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org
References: <153510829645.23054.14135893273393348518@ietfa.amsl.com> <0FB6579C-8C87-4BB0-91ED-B53881F54CC2@gigix.net>
From: Stewart Bryant 
Message-ID: <03c0a914-4d3d-e83e-204c-e9ae30bdf2f4@gmail.com>
Date: Mon, 27 Aug 2018 10:55:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <0FB6579C-8C87-4BB0-91ED-B53881F54CC2@gigix.net>
Content-Type: multipart/alternative; boundary="------------0F4A3382C249CCD6DF6E5DB1"
Content-Language: en-GB
Archived-At: 
Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-gpe-05
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, 27 Aug 2018 09:55:29 -0000

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

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….
>
> On 24 Aug 2018, at 12:58, Stewart Bryant  > 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
>>
>> .
>>
>> 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
>>
>>
>


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


  
    
  
  
    
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….

      


      

      
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

                

                

              

            

          

        

        

      

    

    

  


--------------0F4A3382C249CCD6DF6E5DB1--


From nobody Mon Aug 27 06: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 D07451294D0; Mon, 27 Aug 2018 06:28:14 -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, HTML_MESSAGE=0.001, 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 eRo3vGkuFi0b; Mon, 27 Aug 2018 06:28:12 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 F2828124C04; Mon, 27 Aug 2018 06:28:11 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 41CCD77B72DD5; Mon, 27 Aug 2018 14:28:06 +0100 (IST)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 27 Aug 2018 14:28:07 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.188]) by SJCEML703-CHM.china.huawei.com ([169.254.5.30]) with mapi id 14.03.0415.000; Mon, 27 Aug 2018 06:27:56 -0700
From: Padmadevi Pillay Esnault 
To: "draft-ietf-lisp-6834bis@ietf.org" 
CC: "lisp@ietf.org" 
Thread-Topic: Shepherd Review Comments - draft-ietf-lisp-6834bis-00.txt
Thread-Index: AQHUPgnDhSVshIQbWEa+v1HVemfFXQ==
Date: Mon, 27 Aug 2018 13:27:55 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.245.246]
Content-Type: multipart/alternative; boundary="_000_FC1134722AFB4522B0DE7A7610514713huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [lisp] Shepherd Review Comments - draft-ietf-lisp-6834bis-00.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, 27 Aug 2018 13:28:15 -0000

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

RGVhciBBdXRob3JzDQoNCkkgYW0gYXNzaWduZWQgdG8gZG8gdGhlIHNoZXBoZXJkIHJldmlldyBv
ZiBkcmFmdC1pZXRmLWxpc3AtNjgzNGJpcy0wMC50eHQgZG9jdW1lbnQgYXMgcmVxdWVzdGVkIGJ5
IExJU1AgY2hhaXJzLg0KRmlyc3QsIEkgd291bGQgbGlrZSB0byB0aGFuayBhbGwgdGhlIGF1dGhv
cnMgb24gdGhpcyB3ZWxsIHdyaXR0ZW4gZG9jdW1lbnQuDQpJbiBvcmRlciB0byBjb21wbGV0ZSB0
aGUgcmV2aWV3LCBJIGhhdmUgYSBmZXcgbWlub3IgY29tbWVudHMgYW5kIHF1ZXN0aW9ucyBvbiB0
aGUgZG9jdW1lbnQuDQpXb3VsZCBiZSBncmVhdCBpZiB0aGUgYXV0aG9ycyBjb3VsZCByZXNwaW4g
dGhlIGRvY3VtZW50IHRvIGFkZHJlc3MgdGhlbS4NCg0KVGhhbmtzLA0KUGFkbWENCg0KQ29tbWVu
dHMgb24gZG9jdW1lbnQNCjEuIElkbml0cyBkaWQgbm90IHJ1biBjbGVhci4NCg0KaWRuaXRzIDIu
MTUuMDENCg0KdG1wL2RyYWZ0LWlldGYtbGlzcC02ODM0YmlzLTAwLnR4dDoNCg0KLSBUaGUgcmZj
NjgzMyBzdGF0ZSBmaWxlIGlzIG5vdCBmcm9tIHRvZGF5Lg0KICAgQXR0ZW1wdGluZyB0byBkb3du
bG9hZCBhIG5ld2VyIG9uZS4uLg0KLSBTdWNjZXNzIGZldGNoaW5nIHJmYzY4MzMgc3RhdGUgZmls
ZS4NCnJtOiBjYW5ub3QgcmVtb3ZlIGAvdmFyL3d3dy8vLmlkbml0cy9yZmM2ODMzLnN0YXRlLmRh
dGUnOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5DQoNCi0gVGhlIHJmYzY4MzQgc3RhdGUgZmls
ZSBpcyBub3QgZnJvbSB0b2RheS4NCiAgIEF0dGVtcHRpbmcgdG8gZG93bmxvYWQgYSBuZXdlciBv
bmUuLi4NCi0gU3VjY2VzcyBmZXRjaGluZyByZmM2ODM0IHN0YXRlIGZpbGUuDQoNCi0gVGhlIHJm
Yzc4MzUgc3RhdGUgZmlsZSBpcyBub3QgZnJvbSB0b2RheS4NCiAgIEF0dGVtcHRpbmcgdG8gZG93
bmxvYWQgYSBuZXdlciBvbmUuLi4NCi0gU3VjY2VzcyBmZXRjaGluZyByZmM3ODM1IHN0YXRlIGZp
bGUuDQoNCiAgQ2hlY2tpbmcgYm9pbGVycGxhdGUgcmVxdWlyZWQgYnkgUkZDIDUzNzggYW5kIHRo
ZSBJRVRGIFRydXN0IChzZWUNCiAgaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5m
byk6DQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICBObyBpc3N1ZXMgZm91bmQgaGVyZS4N
Cg0KICBDaGVja2luZyBuaXRzIGFjY29yZGluZyB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZC1p
bmZvLzFpZC1ndWlkZWxpbmVzLnR4dDoNCiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICAgIE5v
IGlzc3VlcyBmb3VuZCBoZXJlLg0KDQogIENoZWNraW5nIG5pdHMgYWNjb3JkaW5nIHRvIGh0dHBz
Oi8vd3d3LmlldGYub3JnL2lkLWluZm8vY2hlY2tsaXN0IDoNCiAgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KDQogICoqIFRoZSBkb2N1bWVudCBzZWVtcyB0byBsYWNrIGFuIElBTkEgQ29uc2lkZXJhdGlv
bnMgc2VjdGlvbi4gIChTZWUgU2VjdGlvbg0KICAgICAyLjIgb2YgaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvaWQtaW5mby9jaGVja2xpc3QgZm9yIGhvdyB0byBoYW5kbGUgdGhlIGNhc2UNCiAgICAgd2hl
biB0aGVyZSBhcmUgbm8gYWN0aW9ucyBmb3IgSUFOQS4pDQoNCiAgKiogVGhlIGFic3RyYWN0IHNl
ZW1zIHRvIGNvbnRhaW4gcmVmZXJlbmNlcyAoW1JGQzY4MzRdKSwgd2hpY2ggaXQNCiAgICAgc2hv
dWxkbid0LiAgUGxlYXNlIHJlcGxhY2UgdGhvc2Ugd2l0aCBzdHJhaWdodCB0ZXh0dWFsIG1lbnRp
b25zIG9mIHRoZQ0KICAgICBkb2N1bWVudHMgaW4gcXVlc3Rpb24uDQoNCg0KICBNaXNjZWxsYW5l
b3VzIHdhcm5pbmdzOg0KICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgLS0gVGhlIGRvY3VtZW50
IGRhdGUgKEp1bHkgMiwgMjAxOCkgaXMgNTUgZGF5cyBpbiB0aGUgcGFzdC4gIElzIHRoaXMNCiAg
ICAgaW50ZW50aW9uYWw/DQoNCg0KICBDaGVja2luZyByZWZlcmVuY2VzIGZvciBpbnRlbmRlZCBz
dGF0dXM6IFByb3Bvc2VkIFN0YW5kYXJkDQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICAo
U2VlIFJGQ3MgMzk2NyBhbmQgNDg5NyBmb3IgaW5mb3JtYXRpb24gYWJvdXQgdXNpbmcgbm9ybWF0
aXZlIHJlZmVyZW5jZXMNCiAgICAgdG8gbG93ZXItbWF0dXJpdHkgZG9jdW1lbnRzIGluIFJGQ3Mp
DQoNCiAgPT0gT3V0ZGF0ZWQgcmVmZXJlbmNlOiBBIGxhdGVyIHZlcnNpb24gKC0wNSkgZXhpc3Rz
IG9mDQogICAgIGRyYWZ0LWlldGYtbGlzcC1ncGUtMDMNCg0KICA9PSBPdXRkYXRlZCByZWZlcmVu
Y2U6IEEgbGF0ZXIgdmVyc2lvbiAoLTE1KSBleGlzdHMgb2YNCiAgICAgZHJhZnQtaWV0Zi1saXNw
LXJmYzY4MzBiaXMtMTINCg0KICA9PSBPdXRkYXRlZCByZWZlcmVuY2U6IEEgbGF0ZXIgdmVyc2lv
biAoLTEzKSBleGlzdHMgb2YNCiAgICAgZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzNiaXMtMTANCg0K
DQogICAgIFN1bW1hcnk6IDIgZXJyb3JzICgqKiksIDAgZmxhd3MgKH5+KSwgMyB3YXJuaW5ncyAo
PT0pLCAxIGNvbW1lbnQgKC0tKS4NCg0KMi4gVHlwb3MNCg0KVHlwb3MgbmVlZCB0byBiZSBmaXhl
ZCBpbiBhYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uIHNlY3Rpb25zOg0KVGhpcyBkb2N1bWVudCBv
YnNvbGV0ZXMgW1JGQzY4MzRdLCB3aGljaCBpcyB0aGUgaW5pdGFsIGV4cGVyaW1lbnRhbA0KICAg
c3BlY2lmaWNhdGlvbnMgb2YgdGhlIG1lY2hhbmltcyB1cGRhdGVkIGJ5IHRoaXMgZG9jdW1lbnQu
DQppbml0aWFsIC0+IGluaXRpYWwNCm1lY2hhbmltcyAtPm1lY2hhbmlzbXMNCg0KMy4gUkZDIHJl
ZmVyZW5jZXMgbWlzc2luZw0KSW4gc2VjdGlvbiAyLCB0aGVyZSBpcyBvbmx5IHJlZmVyZW5jZSB0
byBSRkMgMjExOSBhbmQgcmVmZXJlbmNlIHRvIFJGQzgxNzQgc2hvdWxkIGJlIGFkZGVkLg0KDQoN
ClNoZXBoZXJkIFF1ZXN0aW9ubmFpcmUNCjEuIElQUiBEaXNjbG9zdXJlcyBDb25maXJtYXRpb24N
Cig3KSBIYXMgZWFjaCBhdXRob3IgY29uZmlybWVkIHRoYXQgYW55IGFuZCBhbGwgYXBwcm9wcmlh
dGUgSVBSDQpkaXNjbG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRo
ZSBwcm92aXNpb25zIG9mIEJDUA0KNzggYW5kIEJDUCA3OSBoYXZlIGFscmVhZHkgYmVlbiBmaWxl
ZC4gSWYgbm90LCBleHBsYWluIHdoeT8NCg0KTG9va2VkIGludG8gbWFpbCBhcmNoaXZlcyBhbmQg
Y291bGQgbm90IGZpbmQgZXZpZGVuY2UgdGhhdCBhdXRob3JzIGNvbmZpcm1lZCBJUFIgZGlzY2xv
c3VyZXMuDQpDYW4geW91IHBsZWFzZSBjb25maXJtIG9yIHBvaW50IHRvIG1lIHdoZXJlIHRoZSBk
aXNjbG9zdXJlcyB3ZXJlIGRvbmU/DQoNCjIuIE5vcm1hdGl2ZSBhbmQgSW5mb3JtYXRpdmUgcmVm
ZXJlbmNlcw0KKDE0KSBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1lbnRz
IHRoYXQgYXJlIG5vdCByZWFkeQ0KZm9yIGFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4g
YW4gdW5jbGVhciBzdGF0ZT8gSWYgc3VjaA0Kbm9ybWF0aXZlIHJlZmVyZW5jZXMgZXhpc3QsIHdo
YXQgaXMgdGhlIHBsYW4gZm9yIHRoZWlyIGNvbXBsZXRpb24/DQoNCltJLUQuaWV0Zi1saXNwLWdw
ZV0NCiAgICAgICAgICAgICAgTWFpbm8sIEYuLCBMZW1vbiwgSi4sIEFnYXJ3YWwsIFAuLCBMZXdp
cywgRC4sIGFuZCBNLg0KICAgICAgICAgICAgICBTbWl0aCwgIkxJU1AgR2VuZXJpYyBQcm90b2Nv
bCBFeHRlbnNpb24iLCBkcmFmdC1pZXRmLWxpc3AtDQogICAgICAgICAgICAgIGdwZS0wMyAod29y
ayBpbiBwcm9ncmVzcyksIEFwcmlsIDIwMTguDQoNClNob3VsZG7igJl0IHRoaXMgZHJhZnQgYmUg
aW4gaW5mb3JtYXRpdmUgc2VjdGlvbiBpbnN0ZWFkIHRvIGFkZHJlc3MgdGhpcz8gU2VlIGJlbG93
IGRpc2N1c3Npb25zIG9uIGFsaWFzDQpkdXJpbmcgdGhlIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3
IG9mIGRyYWZ0LWlldGYtbGlzcC1ncGUtMDUuDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy
Y2hpdmUvd2ViL2xpc3AvY3VycmVudC9tc2cwNzcwMC5odG1sDQoNCjMuIFJGQyAgc3RhdHVzIGNo
YW5nZQ0KKDE2KSBXaWxsIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQgY2hhbmdlIHRoZSBz
dGF0dXMgb2YgYW55DQpleGlzdGluZyBSRkNzPyBBcmUgdGhvc2UgUkZDcyBsaXN0ZWQgb24gdGhl
IHRpdGxlIHBhZ2UgaGVhZGVyLCBsaXN0ZWQNCmluIHRoZSBhYnN0cmFjdCwgYW5kIGRpc2N1c3Nl
ZCBpbiB0aGUgaW50cm9kdWN0aW9uPyBJZiB0aGUgUkZDcyBhcmUNCm5vdCBsaXN0ZWQgaW4gdGhl
IEFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24sIGV4cGxhaW4gd2h5LCBhbmQgcG9pbnQgdG8NCnRo
ZSBwYXJ0IG9mIHRoZSBkb2N1bWVudCB3aGVyZSB0aGUgcmVsYXRpb25zaGlwIG9mIHRoaXMgZG9j
dW1lbnQgdG8NCnRoZSBvdGhlciBSRkNzIGlzIGRpc2N1c3NlZC4gSWYgdGhpcyBpbmZvcm1hdGlv
biBpcyBub3QgaW4gdGhlDQpkb2N1bWVudCwgZXhwbGFpbiB3aHkgdGhlIFdHIGNvbnNpZGVycyBp
dCB1bm5lY2Vzc2FyeS4NCg0KSXQgc2VlbXMgdGhhdCB0aGUgZHJhZnQtaWV0Zi1saXNwLWdwZS0w
NS4NCklmIGRyYWZ0LWlldGYtbGlzcC1ncGUtMDUgaXMgcHVibGlzaGVkIGZpcnN0LCBzaG91bGQg
YSByZWZlcmVuY2UgYmUgbWFkZSBmb3IgdGhpcyBkcmFmdCBzcGVjaWZpY2FsbHk/DQoNCg0KDQo=

--_000_FC1134722AFB4522B0DE7A7610514713huaweicom_
Content-Type: text/html; charset="utf-8"
Content-ID: <76D818F35AC4BB4E9E58F11E504B06FB@huawei.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t
cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0
ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z
dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K
QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTM0OTcxNTk4MjsNCgltc28tbGlzdC10eXBlOmh5YnJp
ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTgzNzI4Mjg4MiA2NzY5ODcwMyA2NzY5ODcxMyA2
NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5
ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz
dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg
bDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu
LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXtt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0
IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K
CXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXtt
YXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i
d2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2
IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgQXV0aG9yczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+SSBhbSBhc3NpZ25lZCB0byBkbyB0aGUgc2hlcGhlcmQgcmV2aWV3
IG9mJm5ic3A7ZHJhZnQtaWV0Zi1saXNwLTY4MzRiaXMtMDAudHh0IGRvY3VtZW50IGFzIHJlcXVl
c3RlZCBieSBMSVNQIGNoYWlycy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Rmlyc3QsIEkgd291
bGQgbGlrZSB0byB0aGFuayBhbGwgdGhlIGF1dGhvcnMgb24gdGhpcyB3ZWxsIHdyaXR0ZW4gZG9j
dW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkluIG9yZGVyIHRvIGNvbXBsZXRlIHRoZSByZXZpZXcs
IEkgaGF2ZSBhIGZldyBtaW5vciBjb21tZW50cyBhbmQgcXVlc3Rpb25zIG9uIHRoZSBkb2N1bWVu
dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+V291bGQgYmUgZ3JlYXQgaWYgdGhlIGF1dGhvcnMgY291bGQg
cmVzcGluIHRoZSBkb2N1bWVudCB0byBhZGRyZXNzIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBhZG1hPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Db21tZW50cyBvbiBkb2N1
bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij4xLiBJZG5pdHMgZGlkIG5vdCBydW4gY2xlYXIuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5pZG5pdHMgMi4xNS4wMSA8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPnRtcC9kcmFmdC1pZXRmLWxp
c3AtNjgzNGJpcy0wMC50eHQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij4tIFRoZSByZmM2ODMzIHN0YXRlIGZpbGUgaXMgbm90IGZyb20gdG9kYXkuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBBdHRlbXB0aW5nIHRvIGRvd25sb2FkIGEgbmV3ZXIgb25l
Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0gU3VjY2VzcyBmZXRjaGluZyByZmM2ODMzIHN0YXRlIGZp
bGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPnJtOiBjYW5ub3QgcmVtb3ZlIGAvdmFyL3d3dy8vLmlkbml0
cy9yZmM2ODMzLnN0YXRlLmRhdGUnOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tIFRoZSByZmM2ODM0IHN0YXRlIGZp
bGUgaXMgbm90IGZyb20gdG9kYXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBBdHRl
bXB0aW5nIHRvIGRvd25sb2FkIGEgbmV3ZXIgb25lLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0gU3Vj
Y2VzcyBmZXRjaGluZyByZmM2ODM0IHN0YXRlIGZpbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij4tIFRoZSByZmM3ODM1IHN0YXRlIGZpbGUgaXMgbm90IGZyb20g
dG9kYXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBBdHRlbXB0aW5nIHRvIGRvd25s
b2FkIGEgbmV3ZXIgb25lLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0gU3VjY2VzcyBmZXRjaGluZyBy
ZmM3ODM1IHN0YXRlIGZpbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij4mbmJzcDsgQ2hlY2tpbmcgYm9pbGVycGxhdGUgcmVxdWlyZWQgYnkgUkZDIDUzNzggYW5k
IHRoZSBJRVRGIFRydXN0IChzZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7IGh0dHBzOi8vdHJ1
c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vIGlzc3VlcyBmb3VuZCBoZXJlLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7IENoZWNraW5nIG5pdHMg
YWNjb3JkaW5nIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkLWluZm8vMWlkLWd1aWRlbGluZXMu
dHh0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IE5vIGlzc3VlcyBmb3VuZCBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+Jm5ic3A7IENoZWNraW5nIG5pdHMgYWNjb3JkaW5nIHRvIGh0dHBzOi8vd3d3
LmlldGYub3JnL2lkLWluZm8vY2hlY2tsaXN0IDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPiZuYnNwOyAqKiBUaGUgZG9jdW1lbnQgc2VlbXMgdG8gbGFjayBhbiBJQU5BIENvbnNpZGVy
YXRpb25zIHNlY3Rpb24uJm5ic3A7IChTZWUgU2VjdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgMi4yIG9mIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkLWluZm8v
Y2hlY2tsaXN0IGZvciBob3cgdG8gaGFuZGxlIHRoZSBjYXNlPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGVuIHRoZXJlIGFyZSBubyBhY3Rpb25zIGZvciBJQU5B
Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAqKiBU
aGUgYWJzdHJhY3Qgc2VlbXMgdG8gY29udGFpbiByZWZlcmVuY2VzIChbUkZDNjgzNF0pLCB3aGlj
aCBpdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2hvdWxkbid0
LiZuYnNwOyBQbGVhc2UgcmVwbGFjZSB0aG9zZSB3aXRoIHN0cmFpZ2h0IHRleHR1YWwgbWVudGlv
bnMgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkb2N1
bWVudHMgaW4gcXVlc3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7IE1pc2NlbGxhbmVvdXMgd2Fybmlu
Z3M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsgLS0gVGhlIGRvY3VtZW50
IGRhdGUgKEp1bHkgMiwgMjAxOCkgaXMgNTUgZGF5cyBpbiB0aGUgcGFzdC4mbmJzcDsgSXMgdGhp
czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50ZW50aW9uYWw/
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+Jm5ic3A7IENoZWNraW5nIHJlZmVyZW5jZXMgZm9yIGludGVuZGVkIHN0YXR1
czogUHJvcG9zZWQgU3RhbmRhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7IC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAoU2VlIFJGQ3MgMzk2NyBhbmQgNDg5NyBmb3IgaW5mb3JtYXRp
b24gYWJvdXQgdXNpbmcgbm9ybWF0aXZlIHJlZmVyZW5jZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGxvd2VyLW1hdHVyaXR5IGRvY3VtZW50cyBpbiBSRkNz
KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7ID09IE91
dGRhdGVkIHJlZmVyZW5jZTogQSBsYXRlciB2ZXJzaW9uICgtMDUpIGV4aXN0cyBvZjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1saXNwLWdwZS0w
MzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7ID09IE91
dGRhdGVkIHJlZmVyZW5jZTogQSBsYXRlciB2ZXJzaW9uICgtMTUpIGV4aXN0cyBvZjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1saXNwLXJmYzY4
MzBiaXMtMTI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw
OyA9PSBPdXRkYXRlZCByZWZlcmVuY2U6IEEgbGF0ZXIgdmVyc2lvbiAoLTEzKSBleGlzdHMgb2Y8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWlldGYtbGlz
cC1yZmM2ODMzYmlzLTEwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN1bW1h
cnk6IDIgZXJyb3JzICgqKiksIDAgZmxhd3MgKH5+KSwgMyB3YXJuaW5ncyAoPT0pLCAxIGNvbW1l
bnQgKC0tKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjIuIFR5
cG9zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UeXBvcyBuZWVk
IHRvIGJlIGZpeGVkIGluIGFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24gc2VjdGlvbnM6PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPlRoaXMgZG9jdW1lbnQgb2Jzb2xldGVzIFtSRkM2ODM0XSwgd2hpY2ggaXMg
dGhlIGluaXRhbCBleHBlcmltZW50YWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHNw
ZWNpZmljYXRpb25zIG9mIHRoZSBtZWNoYW5pbXMgdXBkYXRlZCBieSB0aGlzIGRvY3VtZW50Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij5pbml0aWFsIC0mZ3Q7IGluaXRpYWw8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
bWVjaGFuaW1zIC0mZ3Q7bWVjaGFuaXNtczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+My4gUkZDIHJlZmVyZW5jZXMgbWlzc2luZzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5J
biBzZWN0aW9uIDIsIHRoZXJlIGlzIG9ubHkgcmVmZXJlbmNlIHRvIFJGQyAyMTE5IGFuZCByZWZl
cmVuY2UgdG8gUkZDODE3NCBzaG91bGQgYmUgYWRkZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TaGVwaGVyZCBR
dWVzdGlvbm5haXJlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4xLiBJUFIgRGlzY2xvc3VyZXMgQ29uZmly
bWF0aW9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KDcpIEhhcyBlYWNoIGF1dGhvciBjb25maXJtZWQg
dGhhdCBhbnkgYW5kIGFsbCBhcHByb3ByaWF0ZSBJUFI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ZGlzY2xv
c3VyZXMgcmVxdWlyZWQgZm9yIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUgcHJvdmlzaW9ucyBv
ZiBCQ1A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+NzggYW5kIEJDUCA3OSBoYXZlIGFscmVhZHkgYmVlbiBm
aWxlZC4gSWYgbm90LCBleHBsYWluIHdoeT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPkxvb2tlZCBpbnRvIG1haWwgYXJjaGl2ZXMgYW5kIGNvdWxkIG5vdCBmaW5k
IGV2aWRlbmNlIHRoYXQgYXV0aG9ycyBjb25maXJtZWQgSVBSIGRpc2Nsb3N1cmVzLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij5DYW4geW91IHBsZWFzZSBjb25maXJtIG9yIHBvaW50IHRvIG1lIHdoZXJlIHRo
ZSBkaXNjbG9zdXJlcyB3ZXJlIGRvbmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij4yLiBOb3JtYXRpdmUgYW5kIEluZm9ybWF0aXZlIHJlZmVyZW5jZXM8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+KDE0KSBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1l
bnRzIHRoYXQgYXJlIG5vdCByZWFkeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5mb3IgYWR2YW5jZW1lbnQg
b3IgYXJlIG90aGVyd2lzZSBpbiBhbiB1bmNsZWFyIHN0YXRlPyBJZiBzdWNoPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPm5vcm1hdGl2ZSByZWZlcmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRoZSBwbGFuIGZvciB0
aGVpciBjb21wbGV0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+W0ktRC5pZXRmLWxpc3AtZ3BlXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7TWFpbm8sIEYuLCBMZW1vbiwgSi4sIEFnYXJ3YWwsIFAuLCBMZXdpcywgRC4sIGFuZCBN
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU21pdGgsICZxdW90O0xJ
U1AgR2VuZXJpYyBQcm90b2NvbCBFeHRlbnNpb24mcXVvdDssIGRyYWZ0LWlldGYtbGlzcC08bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdwZS0wMyAod29yayBpbiBwcm9n
cmVzcyksIEFwcmlsIDIwMTguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij5TaG91bGRu4oCZdCB0aGlzIGRyYWZ0IGJlIGluIGluZm9ybWF0aXZlIHNlY3Rpb24gaW5z
dGVhZCB0byBhZGRyZXNzIHRoaXM/IFNlZSBiZWxvdyBkaXNjdXNzaW9ucyBvbiBhbGlhcw0KPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPmR1cmluZyB0aGUgR2VuYXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJh
ZnQtaWV0Zi1saXNwLWdwZS0wNS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbC1hcmNoaXZlL3dlYi9saXNwL2N1cnJlbnQvbXNnMDc3MDAuaHRtbDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+My4gUkZDJm5ic3A7IHN0YXR1cyBjaGFu
Z2UgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPigxNikgV2lsbCBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3Vt
ZW50IGNoYW5nZSB0aGUgc3RhdHVzIG9mIGFueTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5leGlzdGluZyBS
RkNzPyBBcmUgdGhvc2UgUkZDcyBsaXN0ZWQgb24gdGhlIHRpdGxlIHBhZ2UgaGVhZGVyLCBsaXN0
ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+aW4gdGhlIGFic3RyYWN0LCBhbmQgZGlzY3Vzc2VkIGluIHRo
ZSBpbnRyb2R1Y3Rpb24/IElmIHRoZSBSRkNzIGFyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5ub3QgbGlz
dGVkIGluIHRoZSBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uLCBleHBsYWluIHdoeSwgYW5kIHBv
aW50IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPnRoZSBwYXJ0IG9mIHRoZSBkb2N1bWVudCB3aGVyZSB0
aGUgcmVsYXRpb25zaGlwIG9mIHRoaXMgZG9jdW1lbnQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+dGhl
IG90aGVyIFJGQ3MgaXMgZGlzY3Vzc2VkLiBJZiB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBpbiB0
aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+ZG9jdW1lbnQsIGV4cGxhaW4gd2h5IHRoZSBXRyBjb25zaWRl
cnMgaXQgdW5uZWNlc3NhcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij5JdCBzZWVtcyB0aGF0IHRoZSBkcmFmdC1pZXRmLWxpc3AtZ3BlLTA1LjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij5JZiBkcmFmdC1pZXRmLWxpc3AtZ3BlLTA1IGlzIHB1Ymxpc2hlZCBmaXJzdCwgc2hv
dWxkIGEgcmVmZXJlbmNlIGJlIG1hZGUgZm9yIHRoaXMgZHJhZnQgc3BlY2lmaWNhbGx5PzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_FC1134722AFB4522B0DE7A7610514713huaweicom_--


From nobody Mon Aug 27 07:36: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 52C6E130DFA; Mon, 27 Aug 2018 07:35:48 -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.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153538054829.30074.15428909912816972228@ietfa.amsl.com>
Date: Mon, 27 Aug 2018 07:35:48 -0700
Archived-At: 
Subject: [lisp] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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, 27 Aug 2018 14:35:49 -0000

Reviewer: Brian Trammell
Review result: Ready with Issues

>From a transport standpoint, this document is basically OK -- I suspect that
there are probably more transport-relevant issues to consider on 6833bis, but I
did not review it. Two issues with the dataplane:

(1) Common advice to all UDP-using encapsulation designers and implementors:
please read RFC8085, especially section 3.1.11. As LISP's dataplane is
basically an application of UDP, I was surprised to see no reference to RFC8085
here. I believe that in the most common case LISP falls into case 1 here, but
implementors of LISP ITRs should at least be made aware of the other cases.

(2) This is not transport-specific. Reading the document, it struck me that the
design of the protocol has a few inherently unsafe features related to the fact
that its wire image is neither confidentiality- nor integrity-protected. I
think that all of the potential DDoS and traffic focusing attacks I could come
up with in the hour I spent reviewing the document are indeed mentioned in the
security considerations section, but as the security considerations section
does not give any practical mitigation for dataplane overload attacks, it seems
to be saying that RLOC addresses shouldn't be Internet-accessible, which as I
understand it is not the point of LISP. I haven't seen a secdir review on this
document yet, but I'd encourage the authors to do everything it asks.

nit: Section 7.1. para 7 should note that the ICMPv6 message sent is called
Packet Too Big, not Unreachable/Frag Needed.



From nobody Mon Aug 27 10:37: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 5CF40127148; Mon, 27 Aug 2018 10:36: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 Sn8fBpdVBIfk; Mon, 27 Aug 2018 10:36:44 -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 8E79A124BE5; Mon, 27 Aug 2018 10:36:44 -0700 (PDT)
Received: by mail-pf1-x42f.google.com with SMTP id j26-v6so8061580pfi.10; Mon, 27 Aug 2018 10:36: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=29UPnE9hyUaTP4fdKCh/6rPsGsMwh6ERw7njdvZ0c5w=; b=q26R6mRdLD192JmFXPy2vyKoGGS9WpedHaCbbn92vycXiwyt0tWxsF3nHv48fyfZdx 0uSPwNuYJyAPy8Y+AlAN+te6OOTCkAtsM6dTzhscaJymOhksWJDpK0PhHVt8GcjnAfIx H8OSJKfKDF0t7c17EnycgFTuZevinkGazxFrkqsMT4UGUmIq8M+YWfaLe/VTNLgyAeTD U6pV5elzHbUXutp7zqXMqMvultzqDELz1WffZPyMW7KgKZoS6jhxabqXwhBnwRUCUD+/ GGPxNHiRo//2peqXIPWla4IJF0pj2mJQqhIIEksH7CUp1yK8XMHy+vke5r8w8DKjLX/B /lKg==
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=29UPnE9hyUaTP4fdKCh/6rPsGsMwh6ERw7njdvZ0c5w=; b=JevMTEQ2/YLPkgyX4p49aQcFwvsGhYDnSPfDLP3/+fS2+Wx8POBeUb4ZZa25V8QwFI HQBixEOhzvcEvDKnuLvTVJQZJyZBvd7uShnghO4rnSCoXv5PZevjwS1QCctIz8YH+T5N fSMftVjVVwlpAaLQkveGLhJ9kbuIH3e+N9M/M/JKJvdV+HlQ+iBy6+D3ueat3isD5moA LXLRtuxy8sLvQ8FHYJ7sfnBQnO7g5mXpERen1LqWyBhNuAntydBLm80A5dmH4OBJacYX jTfLcYZOMkuTfj8StZvkxkzKxwzW462ojPlsfeA40LcJ3QF7adcgV34TkRJXtNSMS7b+ aqoQ==
X-Gm-Message-State: APzg51Dr+wA+ChoZMBAwTzpM2YZ8k3HD9wlgimtxk010dJY/XOA6J2aB CzCoplExd9awyNkx5yYfo3yOGD4t
X-Google-Smtp-Source: ANB0Vdb/MzD5F9Ns9ppUst8eUVG/rDha/371yn0vCcOr4x0kUZ0hOjCAXaDLcSxJ2jhDICviPdsWhQ==
X-Received: by 2002:a63:3c5c:: with SMTP id i28-v6mr13108164pgn.415.1535391404171;  Mon, 27 Aug 2018 10:36:44 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id 16-v6sm26924145pfo.164.2018.08.27.10.36.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 10:36: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: <153538054829.30074.15428909912816972228@ietfa.amsl.com>
Date: Mon, 27 Aug 2018 10:36:42 -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: 
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>
To: Brian Trammell 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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, 27 Aug 2018 17:36:46 -0000

> (1) Common advice to all UDP-using encapsulation designers and =
implementors:
> please read RFC8085, especially section 3.1.11. As LISP's dataplane is
> basically an application of UDP, I was surprised to see no reference =
to RFC8085
> here. I believe that in the most common case LISP falls into case 1 =
here, but
> implementors of LISP ITRs should at least be made aware of the other =
cases.

I don=E2=80=99t see a section 3.1.11 in RFC 8085. Rather than make =
references, can you say what you think the issue is?

> (2) This is not transport-specific. Reading the document, it struck me =
that the
> design of the protocol has a few inherently unsafe features related to =
the fact
> that its wire image is neither confidentiality- nor =
integrity-protected. I
> think that all of the potential DDoS and traffic focusing attacks I =
could come
> up with in the hour I spent reviewing the document are indeed =
mentioned in the
> security considerations section, but as the security considerations =
section
> does not give any practical mitigation for dataplane overload attacks, =
it seems
> to be saying that RLOC addresses shouldn't be Internet-accessible, =
which as I
> understand it is not the point of LISP. I haven't seen a secdir review =
on this
> document yet, but I'd encourage the authors to do everything it asks.

RFC 8061 goes along with RFC6830bis. It addresses data-plane =
confidentiality.

> nit: Section 7.1. para 7 should note that the ICMPv6 message sent is =
called
> Packet Too Big, not Unreachable/Frag Needed.

We used =E2=80=9CPacket Too Big=E2=80=9D for all ICMP messages including =
IPv4 and hence we received comments about it on how it should change it =
to Network Unreachable. I will fix this for IPv6.

Dino



From nobody Mon Aug 27 10:41: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 E832F127148; Mon, 27 Aug 2018 10:41: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.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: lisp@ietf.org
Message-ID: <153539168789.30018.13079765963497536755@ietfa.amsl.com>
Date: Mon, 27 Aug 2018 10:41:27 -0700
Archived-At: 
Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-16.txt
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, 27 Aug 2018 17:41:28 -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-16.txt
	Pages           : 42
	Date            : 2018-08-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-16
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-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 Mon Aug 27 12:08: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 C2DFA130EDE; Mon, 27 Aug 2018 12:08:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level: 
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 zqA_1io3hWnG; Mon, 27 Aug 2018 12:08:12 -0700 (PDT)
Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C84712F1AB; Mon, 27 Aug 2018 12:08:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 5998F7162A63; Mon, 27 Aug 2018 15:08:08 -0400 (EDT)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1yK2Zpdh8IK; Mon, 27 Aug 2018 15:08:01 -0400 (EDT)
Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 870797162A57; Mon, 27 Aug 2018 15:08:00 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Scott O. Bradner" 
In-Reply-To: <1F27055C-152D-432B-B372-B79739561D92@gmail.com>
Date: Mon, 27 Aug 2018 15:07:59 -0400
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <91383BDF-57ED-4F7A-A868-ABF0244187CE@sobco.com>
References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com>  <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com>  <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com>   <9BE375D7-50E1-4FF1-B59C-93C203CFBDD0@gmail.com> <9E88630B-404F-4E0D-8CE5-5DD602A59D25@sobco.com> <1F27055C-152D-432B-B372-B79739561D92@gmail.com>
To: Dino Farinacci 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14
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, 27 Aug 2018 19:08:14 -0000

a quick look at the ToC of the ID & of RFC 6830 show a lot of things =
missing (the doc is a lot
shorter) - it might be useful to say something about that in the changes =
since section

Scott=


From nobody Mon Aug 27 12:33: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 AEECC130DFC; Mon, 27 Aug 2018 12:33:22 -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 pMJ4T-y2JerQ; Mon, 27 Aug 2018 12:33:21 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 EFF2E130DEA; Mon, 27 Aug 2018 12:33:20 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id x6-v6so34210plv.10; Mon, 27 Aug 2018 12:33:20 -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=Ll3cGTsTWwh1gvgk169INmfeog+0ezwX3uxIHI3757o=; b=XnN7XE3L0kqrMo3Fqn46iVk8hvgbbZQPxCQRfSoXrOQw56/BoTab1TmwvFGQ1ADqbH tzxl6/0rSDTfknzS8ka9XY+wi79iFCfgUzJ9DyvUr2dDVJMfSrZeUJ9rmXe3nPo2mTT1 OQE2tm7l9G7duq0OotysCIRCGmjB1hw3zCXSTqV9OLe4400yUgE9e7M8I+ovfORa7Y4/ 513ckM3/VYlQrAhaO5aC+BS3g5J6RhPfuGT9EugQ3w1+7Si0P1Q17ZwnfYyVKHRlxbbr q1gTWc2epYKK7LpqqhrWrdADgKyMH72frNOwK91VYkXeLJ7+pMqhxg5Dy4jBTw6x8533 GlDA==
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=Ll3cGTsTWwh1gvgk169INmfeog+0ezwX3uxIHI3757o=; b=DnipxxAHjW8tMlZXZP1ud72JyTm/O4nEmhNbx8GxMSf9/nh2sIbHcOi3hADBOmURh5 AUaG4wWwllM3Wp7sfRDrugWijD2iLwqxeaLfrO7t/wxd395GMC7CmXk/Krbetmk0caXh ikPdLZVxIKPCFZ9pPy1ZbUaiHdIpkogLieJ7jj9sM5Mhiuuc/XHyhzPQWizcjoM3QMb7 u6aV5kq88h+kJFALnjWwm0r+zbIB3zeV0pxv1N9wcFodLlnSV7uEB2fgCOjDGsEs5MOR CAQKE/T4aY8d1jI3YcShWgff7M9aTMOGmPRLtiX/vzlKPEpfGmKGmS1j00VA24p+Dwpn iF9A==
X-Gm-Message-State: APzg51D/6bz3+++1eeszGUNUNtT9wANXPx/77UliF/0FG/JlYePNSruh WwNjDIj0YJyqGQm1zG4yxDci5NS4
X-Google-Smtp-Source: ANB0VdYiHwf1ix9uMvZKBReH8bA3wDZTawmobPFSit4JxRMpbVtIuz/ke63w/Hdf3lcsz8XNyJcQZA==
X-Received: by 2002:a17:902:bd07:: with SMTP id p7-v6mr11821352pls.32.1535398400211;  Mon, 27 Aug 2018 12:33:20 -0700 (PDT)
Received: from ?IPv6:2600:380:8534:1feb:7cea:fcb:7987:97ed? ([2600:380:8534:1feb:7cea:fcb:7987:97ed]) by smtp.gmail.com with ESMTPSA id d81-v6sm56660pfj.122.2018.08.27.12.33.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 12:33:19 -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: <91383BDF-57ED-4F7A-A868-ABF0244187CE@sobco.com>
Date: Mon, 27 Aug 2018 12:33:18 -0700
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BE641EB-F095-4271-8C17-1945362526FF@gmail.com>
References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com>  <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com>  <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com>   <9BE375D7-50E1-4FF1-B59C-93C203CFBDD0@gmail.com> <9E88630B-404F-4E0D-8CE5-5DD602A59D25@sobco.com> <1F27055C-152D-432B-B372-B79739561D92@gmail.com> <91383BDF-57ED-4F7A-A868-ABF0244187CE@sobco.com>
To: "Scott O. Bradner" 
Archived-At: 
Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14
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, 27 Aug 2018 19:33:23 -0000

Right - we moved the control-plane to 6833bis. I=E2=80=99ll mention that in c=
hanges section.=20

Dino

> On Aug 27, 2018, at 12:07 PM, Scott O. Bradner  wrote:
>=20
>=20
> a quick look at the ToC of the ID & of RFC 6830 show a lot of things missi=
ng (the doc is a lot
> shorter) - it might be useful to say something about that in the changes s=
ince section
>=20
> Scott


From nobody Mon Aug 27 12:39: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 D3F0C130DFC; Mon, 27 Aug 2018 12:39:04 -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] 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 Y6OS2sJmLkSB; Mon, 27 Aug 2018 12:39:02 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA13130DC9; Mon, 27 Aug 2018 12:39:02 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5C7883406D5; Mon, 27 Aug 2018 21:39:00 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.1484);  Mon, 27 Aug 2018 21:39:00 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Mon, 27 Aug 2018 21:38:59 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.78]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 65413780; Mon, 27 Aug 2018 21:38:59 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: "Brian Trammell (IETF)" 
X-Mailer: iPhone Mail (15G77)
In-Reply-To: 
Date: Mon, 27 Aug 2018 21:38:59 +0200
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, ietf@ietf.org,  lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch>
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com> 
To: Dino Farinacci 
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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, 27 Aug 2018 19:39:05 -0000

Hi Dino, all,

Sent from my iPhone

On 27 Aug 2018, at 19:36, Dino Farinacci  wrote:

>> (1) Common advice to all UDP-using encapsulation designers and implemento=
rs:
>> please read RFC8085, especially section 3.1.11. As LISP's dataplane is
>> basically an application of UDP, I was surprised to see no reference to R=
FC8085
>> here. I believe that in the most common case LISP falls into case 1 here,=
 but
>> implementors of LISP ITRs should at least be made aware of the other case=
s.
>=20
> I don=E2=80=99t see a section 3.1.11 in RFC 8085.

Page 16, =E2=80=9CUDP tunnels=E2=80=9D.

> Rather than make references, can you say what you think the issue is?

LISP=E2=80=99s data plane is a UDP tunnel, and as such there are congestion c=
ontrol issues that must be considered. LISP inplementors and deployers using=
 LISP to carry a mix of traffic that is not predominantly=20

>> (2) This is not transport-specific. Reading the document, it struck me th=
at the
>> design of the protocol has a few inherently unsafe features related to th=
e fact
>> that its wire image is neither confidentiality- nor integrity-protected. I=

>> think that all of the potential DDoS and traffic focusing attacks I could=
 come
>> up with in the hour I spent reviewing the document are indeed mentioned i=
n the
>> security considerations section, but as the security considerations secti=
on
>> does not give any practical mitigation for dataplane overload attacks, it=
 seems
>> to be saying that RLOC addresses shouldn't be Internet-accessible, which a=
s I
>> understand it is not the point of LISP. I haven't seen a secdir review on=
 this
>> document yet, but I'd encourage the authors to do everything it asks.
>=20
> RFC 8061 goes along with RFC6830bis. It addresses data-plane confidentiali=
ty.

I haven=E2=80=99t read 8061 yet, but I probably should before continuing thi=
s thread.

I will say that I=E2=80=99m far less concerned about LISP header confidentia=
lity than I am about LISP header integrity, given the opportunities for on-p=
ath meddling and off-path spoofing. If the common solution to both is someth=
ing like sticking everything on the ITR-ETR path in IPSec then this is less o=
f a concern.

>=20
>> nit: Section 7.1. para 7 should note that the ICMPv6 message sent is call=
ed
>> Packet Too Big, not Unreachable/Frag Needed.
>=20
> We used =E2=80=9CPacket Too Big=E2=80=9D for all ICMP messages including I=
Pv4 and hence we received comments about it on how it should change it to Ne=
twork Unreachable. I will fix this for IPv6.

Yeah, this is the one place where i noticed a rough edge on supporting v4 an=
d v6. Thanks.

Cheers,

Brian

> Dino
>=20
>=20
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art


From nobody Mon Aug 27 12:40: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 1EAF5130E8E; Mon, 27 Aug 2018 12:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level: 
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 vKxnGt411XvW; Mon, 27 Aug 2018 12:40:34 -0700 (PDT)
Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC9D130E2B; Mon, 27 Aug 2018 12:40:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id F2C9F716304F; Mon, 27 Aug 2018 15:40:32 -0400 (EDT)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7Wjv9R40Lwx; Mon, 27 Aug 2018 15:40:31 -0400 (EDT)
Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 62DE77163042; Mon, 27 Aug 2018 15:40:31 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Scott O. Bradner" 
In-Reply-To: <3BE641EB-F095-4271-8C17-1945362526FF@gmail.com>
Date: Mon, 27 Aug 2018 15:40:30 -0400
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <90D8DA6D-EE44-45CE-8FCC-950C770CF568@sobco.com>
References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com>  <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com>  <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com>   <9BE375D7-50E1-4FF1-B59C-93C203CFBDD0@gmail.com> <9E88630B-404F-4E0D-8CE5-5DD602A59D25@sobco.com> <1F27055C-152D-432B-B372-B79739561D92@gmail.com> <91383BDF-57ED-4F7A-A868-ABF0244187CE@sobco.com> <3BE641EB-F095-4271-8C17-1945362526FF@gmail.com>
To: Dino Farinacci 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14
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, 27 Aug 2018 19:40:35 -0000

thanks!

Scott


> On Aug 27, 2018, at 3:33 PM, Dino Farinacci  =
wrote:
>=20
> Right - we moved the control-plane to 6833bis. I=E2=80=99ll mention =
that in changes section.=20
>=20
> Dino
>=20
>> On Aug 27, 2018, at 12:07 PM, Scott O. Bradner  wrote:
>>=20
>>=20
>> a quick look at the ToC of the ID & of RFC 6830 show a lot of things =
missing (the doc is a lot
>> shorter) - it might be useful to say something about that in the =
changes since section
>>=20
>> Scott


From nobody Mon Aug 27 13:39: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 587A9130E25; Mon, 27 Aug 2018 13: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 cbwhd1IvpGA1; Mon, 27 Aug 2018 13:39:37 -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 BF7DD12D7F8; Mon, 27 Aug 2018 13:39:37 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id h8-v6so121686pgs.4; Mon, 27 Aug 2018 13: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=iyPLyTrhnf2AyUr0Em3iTYM7SSDykqAfnXfT8eis+ZU=; b=dqi0klgnHJ6Gyb70vSz7mKrRWN9VdyIbMoCuPJSUEA11EuWxnv07TGI24gnlwjk9GB ADRcfASWGjiHQlsoPWXekdgPo5sf29JFmuSJpaG18b9Y/GN2IKfONePhFPejoCyGJuqO QfiO3qkbNWPpMntE4LHxL3ef2ZUOxhl/LoKRgaew6o26N64U8D6K+VZwfFMbTLChgFAT 9zehhVElVUMJgduB2oR2KSsmVA49QCuOxeXG5hb8pgF4ZW7GfZZyBCBl6OG/UKW638UZ lCrNSeQnpCL29fyhWNR0XHdpwxATbGJCOPeo1pMI4sJZJCuM9m/vZKUVzx+Imf0cdw2S 6m/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=iyPLyTrhnf2AyUr0Em3iTYM7SSDykqAfnXfT8eis+ZU=; b=mQ+ZcOlCuPJvuc1JujXK1Yp8XEEPH70XwvkoPZ8/Ds20YZ02C3s+xF2Mqbo/eSzomC r6wxIRM96zuOq7CzVe1KPAb3mA6YNpB3mABzSy96/qL6uaYSzU6Ju9o3qC+0QW1Yjhzg q1cMXh5OTljxogWtZeNAOBdwDTqRYsuH+r+SqUKBy/YV/VM43cMk+m3qV9gyZqreiWeM b2T6EKcbHULhl6y2Z417LsVrVOAwwErcns5aQ7w4vVGc+SKn/EQgjECZGe6uF8fpIppV DdDvgNLpBLAIFe5YFq4OPdC2SHdSFjPyFiYTeVVkVRGbrQue+40EQW2r+jVo2syDfEsx T03w==
X-Gm-Message-State: APzg51BKmnfLz0+eHqvtIgh+vuEdlFwbVSp0e9MggydQ4nildGyvRzVl +L8/+DLzjl/nih8TTp1fUbA=
X-Google-Smtp-Source: ANB0VdalP/KHD6ZeOwaiEFmsEKN6bs77FNi4/TaYAAt3DoC2OeMSiQZ0YNn4XnG1URhvM0BIg3G+SA==
X-Received: by 2002:a62:fd06:: with SMTP id p6-v6mr15800396pfh.167.1535402377316;  Mon, 27 Aug 2018 13:39:37 -0700 (PDT)
Received: from ?IPv6:2603:3024:151c:55f0:c1b3:bc4c:9028:ff3b? ([2603:3024:151c:55f0:c1b3:bc4c:9028:ff3b]) by smtp.gmail.com with ESMTPSA id 87-v6sm169811pfn.103.2018.08.27.13.39.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 13: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: <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch>
Date: Mon, 27 Aug 2018 13:39:34 -0700
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, ietf@ietf.org,  lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com>
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch>
To: "Brian Trammell (IETF)" 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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, 27 Aug 2018 20:39:40 -0000

>> Rather than make references, can you say what you think the issue is?
>=20
> LISP=E2=80=99s data plane is a UDP tunnel, and as such there are =
congestion control issues that must be considered. LISP inplementors and =
deployers using LISP to carry a mix of traffic that is not predominantly=20=


Could you finish your sentence.=20

I am not sure what more we can say. There is an depth discussion about =
DSCP fields and how to use ECN. Basically copies the inner values to the =
outer header equiv values.

>=20
>>> (2) This is not transport-specific. Reading the document, it struck =
me that the
>>> design of the protocol has a few inherently unsafe features related =
to the fact
>>> that its wire image is neither confidentiality- nor =
integrity-protected. I
>>> think that all of the potential DDoS and traffic focusing attacks I =
could come
>>> up with in the hour I spent reviewing the document are indeed =
mentioned in the
>>> security considerations section, but as the security considerations =
section
>>> does not give any practical mitigation for dataplane overload =
attacks, it seems
>>> to be saying that RLOC addresses shouldn't be Internet-accessible, =
which as I
>>> understand it is not the point of LISP. I haven't seen a secdir =
review on this
>>> document yet, but I'd encourage the authors to do everything it =
asks.
>>=20
>> RFC 8061 goes along with RFC6830bis. It addresses data-plane =
confidentiality.
>=20
> I haven=E2=80=99t read 8061 yet, but I probably should before =
continuing this thread.
>=20
> I will say that I=E2=80=99m far less concerned about LISP header =
confidentiality than I am about LISP header integrity, given the =
opportunities for on-path meddling and off-path spoofing. If the common =
solution to both is something like sticking everything on the ITR-ETR =
path in IPSec then this is less of a concern.

Well RFC8061 does AEAD on the payload. All data *after* the LISP header. =
The encryption is a more integrated model than IPsec, so we can be more =
efficient by not using extra IP headers and extra control/key exchange =
protocols.

>=20
>>=20
>>> nit: Section 7.1. para 7 should note that the ICMPv6 message sent is =
called
>>> Packet Too Big, not Unreachable/Frag Needed.
>>=20
>> We used =E2=80=9CPacket Too Big=E2=80=9D for all ICMP messages =
including IPv4 and hence we received comments about it on how it should =
change it to Network Unreachable. I will fix this for IPv6.
>=20
> Yeah, this is the one place where i noticed a rough edge on supporting =
v4 and v6. Thanks.

Fixed. Submitted a new revision a few hours ago.

Dino



From nobody Mon Aug 27 13:48:35 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 0B129124BE5; Mon, 27 Aug 2018 13:48:34 -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 eXvaNNP-hr6U; Mon, 27 Aug 2018 13:48:30 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 A2DDE12D7F8; Mon, 27 Aug 2018 13:48:30 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id w14-v6so122854plp.6; Mon, 27 Aug 2018 13:48:30 -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=1TKD5qsK502s2K7YS3n+oQbzDfbtp7D+Qmic8C3E2kA=; b=ghGTOOjDvyeSFYxSBffwO1XI8Hpgy2GUJkZAyN7CFohIwM5DJ9+S5Yilpyk7Rjzy88 BKpzqtD75ZRkxpMdnC0spdKrRHdMqXz4A1QldYRKrduQlfrPxsQh9rtrPz0FjMwKoizr oypJou8/M9pE+80sCED4mfp2S7EpdXN00n1Mzc5O7wtszfy4gRETPTCdJeW5Jm3uuU5S nZVYieM8pjzD41gk50KQxlWUS6dQvjA3gnKLEnNkwRMHW1Em7SPH3wXbgPZ4HNamYCRH /NH4e9tLhL8SH5z4v4iOW+K58FdLthUY7zQ9X6oLqkcZnZeRdZXYYCnLjtWN/OM504OO 1BwA==
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=1TKD5qsK502s2K7YS3n+oQbzDfbtp7D+Qmic8C3E2kA=; b=dDVaiVwxMYcOVugH+LQcAvhq67AUtXTMjxQzo2qZ58TVloAHOQ9I8L68mov07F7GUS px9jDTap58QP1W2f1+qZ+5Wx1fdydZu+B8t/9dAQUqF7Fni57zfUTOJq+87KYjNg3g/n BGesetSTzSRq76FCrfdLWozYIWKTid7VNq9I1NA5W7wjKilVcNEUMpO8SNn3E3++5IS4 OnwLWA31zPqgOHcnN2UsGqhVDMOaCYM9tVkkhTquyOO8nNTeQSr+FNwkdZFhtzUjEurd pk9CDyifsh3ybJNNtkKxS9UFX8/AhOEFEKqEZBPd7QCqwPM1GI7e+s73oSpl3hLo/BFH Wo6w==
X-Gm-Message-State: APzg51Aj0zYO+AHysWVfBRSxZztNHMhqLJa3keQTqIoAMDC7wcUHmacY t8x6ipwv55IGQIvoBPfWCok=
X-Google-Smtp-Source: ANB0VdZkgXrRQCVp1aaQfIgfnIrfLeXa9o5zyoDqI2EleUccZ4ohZdCM0pH+8daUiSAzq05blFtChg==
X-Received: by 2002:a17:902:b901:: with SMTP id bf1-v6mr14338832plb.226.1535402910240;  Mon, 27 Aug 2018 13:48:30 -0700 (PDT)
Received: from ?IPv6:2603:3024:151c:55f0:c1b3:bc4c:9028:ff3b? ([2603:3024:151c:55f0:c1b3:bc4c:9028:ff3b]) by smtp.gmail.com with ESMTPSA id h130-v6sm163013pgc.88.2018.08.27.13.48.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 13:48:29 -0700 (PDT)
From: Dino Farinacci 
Message-Id: <1CF46C36-C1CF-477E-95BD-21ACC4FBAE14@gmail.com>
Content-Type: multipart/mixed; boundary="Apple-Mail=_7611F17F-F885-4FD9-8D84-1585E45570AD"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 27 Aug 2018 13:48:26 -0700
In-Reply-To: <90D8DA6D-EE44-45CE-8FCC-950C770CF568@sobco.com>
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" 
To: Scott Bradner 
References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com>  <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com>  <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com>   <9BE375D7-50E1-4FF1-B59C-93C203CFBDD0@gmail.com> <9E88630B-404F-4E0D-8CE5-5DD602A59D25@sobco.com> <1F27055C-152D-432B-B372-B79739561D92@gmail.com> <91383BDF-57ED-4F7A-A868-ABF0244187CE@sobco.com> <3BE641EB-F095-4271-8C17-1945362526FF@gmail.com> <90D8DA6D-EE44-45CE-8FCC-950C770CF568@sobco.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14
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, 27 Aug 2018 20:48:34 -0000

--Apple-Mail=_7611F17F-F885-4FD9-8D84-1585E45570AD
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Diffs enclosed.

Dino


--Apple-Mail=_7611F17F-F885-4FD9-8D84-1585E45570AD
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-rfc6830bis-16.txt - =
draft-ietf-lisp-rfc6830bis-17.txt=20
  =20
     =20
=20
=20
  =20
  =20
      
< draft-ietf-lisp-rfc6830bis-16.txt  =
 draft-ietf-lisp-rfc6830bis-17.txt >
 =


      
skipping to =
change at =
page 1, line 13 =C2=B6 =
skipping to change at page 1, line 13 =C2=B6

      
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: February =
28, 2019                                 Cisco Systems Expires: February 28, 2019                               =
  Cisco Systems

      
                  =
                                     A. Cabellos (Ed.)                                                        =
A. Cabellos (Ed.)

      
                  =
                                     UPC/BarcelonaTech                                                        =
UPC/BarcelonaTech

      
                  =
                                       August 27, 2018                                                          =
August 27, 2018

      
 =


      
               =
The Locator/ID Separation Protocol (LISP)                The Locator/ID Separation Protocol =
(LISP)

      

      
                =
     draft-ietf-lisp-rfc6830bis-16 =
                     =
draft-ietf-lisp-rfc6830bis-17

      
 =


      
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 3, line 7 =C2=B6 =
skipping to change at page 3, line 7 =C2=B6

      
   17. Network =
Management Considerations . . . . . . . . . . . . . .  32 =
   17. Network Management Considerations . . . =
. . . . . . . . . . .  32

      
   18. Changes =
since RFC 6830  . . . . . . . . . . . . . . . . . . .  32 =
   18. Changes since RFC 6830  . . . . . . . . =
. . . . . . . . . . .  32

      
   19. IANA =
Considerations . . . . . . . . . . . . . . . . . . . . .  32 =
   19. IANA Considerations . . . . . . . . . . =
. . . . . . . . . . .  32

      
     19.1.  LISP =
UDP Port Numbers  . . . . . . . . . . . . . . . . .  32 =
     19.1.  LISP UDP Port Numbers  . . . . . . =
. . . . . . . . . . .  32

      
   20. References =
 . . . . . . . . . . . . . . . . . . . . . . . . .  33    20. References  . . . . . . . . . . . . . . . . . . . =
. . . . . .  33

      
     20.1.  =
Normative References . . . . . . . . . . . . . . . . . .  33 =
     20.1.  Normative References . . . . . . . =
. . . . . . . . . . .  33

      
     20.2.  =
Informative References . . . . . . . . . . . . . . . . .  33 =
     20.2.  Informative References . . . . . . =
. . . . . . . . . . .  33

      
 =


      
   Appendix A.  =
Acknowledgments  . . . . . . . . . . . . . . . . . .  37 =
   Appendix A.  Acknowledgments  . . . . . . . =
. . . . . . . . . . .  37

      
   Appendix B.  =
Document Change Log  . . . . . . . . . . . . . . . .  37 =
   Appendix B.  Document Change Log  . . . . . =
. . . . . . . . . . .  37

      

      
     B.1.  =
Changes to draft-ietf-lisp-rfc6830bis-16  =
. . . . . . . .  38      B.1.  =
Changes to draft-ietf-lisp-rfc6830bis-17  =
. . . . . . . .  38

      
     B.2.  =
Changes to draft-ietf-lisp-rfc6830bis-15  =
. . . . . . . .  38      B.2.  =
Changes to draft-ietf-lisp-rfc6830bis-16  =
. . . . . . . .  38

      
     B.3.  =
Changes to draft-ietf-lisp-rfc6830bis-14  =
. . . . . . . .  38      B.3.  =
Changes to draft-ietf-lisp-rfc6830bis-15  =
. . . . . . . .  38

      
     B.4.  =
Changes to draft-ietf-lisp-rfc6830bis-13  =
. . . . . . . .  38      B.4.  =
Changes to draft-ietf-lisp-rfc6830bis-14  =
. . . . . . . .  38

      
     B.5.  =
Changes to draft-ietf-lisp-rfc6830bis-12  =
. . . . . . . .  38      B.5.  =
Changes to draft-ietf-lisp-rfc6830bis-13  =
. . . . . . . .  38

      
     B.6.  =
Changes to draft-ietf-lisp-rfc6830bis-11  =
. . . . . . . .  38      B.6.  =
Changes to draft-ietf-lisp-rfc6830bis-12  =
. . . . . . . .  38

      
     B.7.  =
Changes to draft-ietf-lisp-rfc6830bis-10  =
. . . . . . . .  39      B.7.  =
Changes to draft-ietf-lisp-rfc6830bis-11  =
. . . . . . . .  39

      
     B.8.  =
Changes to draft-ietf-lisp-rfc6830bis-09  =
. . . . . . . .  39      B.8.  =
Changes to draft-ietf-lisp-rfc6830bis-10  =
. . . . . . . .  39

      
     B.9.  =
Changes to draft-ietf-lisp-rfc6830bis-08  =
. . . . . . . .  39      B.9.  =
Changes to draft-ietf-lisp-rfc6830bis-09  =
. . . . . . . .  39

      
     B.10. =
Changes to draft-ietf-lisp-rfc6830bis-07  . . . . . . . .  40 =
     B.10. Changes to draft-ietf-lisp-rfc6830bis-08  . . . . . . . .  =
39

      
     B.11. Changes to draft-ietf-lisp-rfc6830bis-06  =
. . . . . . . .  40      B.11. Changes to =
draft-ietf-lisp-rfc6830bis-07  . . . . . . . .  40

      
     B.12. Changes to draft-ietf-lisp-rfc6830bis-05  =
. . . . . . . .  40      B.12. Changes to draft-ietf-lisp-rfc6830bis-06  =
. . . . . . . .  40

      
     B.13. Changes to draft-ietf-lisp-rfc6830bis-04  =
. . . . . . . .  40      B.13. Changes to draft-ietf-lisp-rfc6830bis-05  =
. . . . . . . .  40

      
     B.14. Changes to draft-ietf-lisp-rfc6830bis-03  =
. . . . . . . .  41      B.14. Changes to draft-ietf-lisp-rfc6830bis-04  =
. . . . . . . .  40

      
     B.15. Changes to draft-ietf-lisp-rfc6830bis-02  =
. . . . . . . .  41      B.15. Changes to draft-ietf-lisp-rfc6830bis-03  =
. . . . . . . .  41

      
     B.16. Changes to draft-ietf-lisp-rfc6830bis-01  =
. . . . . . . .  41      B.16. Changes to draft-ietf-lisp-rfc6830bis-02  =
. . . . . . . .  41

      
     B.17. Changes to draft-ietf-lisp-rfc6830bis-00  =
. . . . . . . .  41      B.17. Changes to draft-ietf-lisp-rfc6830bis-01  =
. . . . . . . .  41

      
 =
     B.18. =
Changes to draft-ietf-lisp-rfc6830bis-00  . . . . . . . .  41

      
   Authors' =
Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41 =
   Authors' Addresses  . . . . . . . . . . . . =
. . . . . . . . . . .  41

      
 =


      
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 32, line 36 =C2=B6 =
skipping to change at page 32, line =
36 =C2=B6

      
      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.  If any ITR implementations depend or =
assume the remote

      
      ETR is =
gleaning should not do so.  This does not create any       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

      
 =
      are due to moving =
the LISP control-plane messaging and procedures

      
 =
      to =
[I-D.ietf-lisp-rfc6833bis].

      
 =
                                               =
                          

      
19.  IANA =
Considerations 19.  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

      
   Data-Plane =
LISP specification, in accordance with BCP 26 [RFC8126]. =
   Data-Plane LISP specification, in accordance =
with BCP 26 [RFC8126].

      
 =


      
19.1.  LISP UDP =
Port Numbers 19.1.  LISP UDP Port =
Numbers

      
 =


      
   The IANA =
registry has allocated UDP port number 4341 for the LISP =
   The IANA registry has allocated UDP port =
number 4341 for the LISP

      
   Data-Plane.  =
IANA has updated the description for UDP port 4341 as    Data-Plane.  IANA has updated the description for UDP =
port 4341 as

      
 =


      
skipping to =
change at =
page 38, line 5 =C2=B6 =
skipping to change at page 38, 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-16 B.1. =
 Changes to draft-ietf-lisp-rfc6830bis-17

      
 =


      
 =
   o  Posted late =
August 2018.

      
 =


      
 =
   o  Indicate in the =
"Changes since RFC 6830" section why the document

      
 =
      has been =
shortened in length.

      
 =


      
 =
B.2.  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.2.  Changes to =
draft-ietf-lisp-rfc6830bis-15 B.3.  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.3.  Changes to =
draft-ietf-lisp-rfc6830bis-14 B.4.  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.4.  Changes to =
draft-ietf-lisp-rfc6830bis-13 B.5.  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.5.  Changes to =
draft-ietf-lisp-rfc6830bis-12 B.6.  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.6.  Changes to =
draft-ietf-lisp-rfc6830bis-11 B.7.  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.7.  Changes to =
draft-ietf-lisp-rfc6830bis-10 B.8.  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.8.  Changes to =
draft-ietf-lisp-rfc6830bis-09 B.9.  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.9.  Changes to =
draft-ietf-lisp-rfc6830bis-08 B.10.  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.10.  Changes to =
draft-ietf-lisp-rfc6830bis-07 B.11.  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.11.  Changes to =
draft-ietf-lisp-rfc6830bis-06 B.12.  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 40, line 35 =C2=B6 =
skipping to change at page 40, line =
40 =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.12.  Changes to =
draft-ietf-lisp-rfc6830bis-05 B.13.  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.13.  Changes to =
draft-ietf-lisp-rfc6830bis-04 B.14.  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.14.  Changes to =
draft-ietf-lisp-rfc6830bis-03 B.15.  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.15.  Changes to =
draft-ietf-lisp-rfc6830bis-02 B.16.  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.16.  Changes to =
draft-ietf-lisp-rfc6830bis-01 B.17.  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.17.  Changes to =
draft-ietf-lisp-rfc6830bis-00 B.18.  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. 20 change blocks. 

     
35 lines changed or =
deleted 47 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=_7611F17F-F885-4FD9-8D84-1585E45570AD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Aug 27, 2018, at 12:40 PM, Scott O. Bradner  wrote:
>=20
> thanks!
>=20
> Scott
>=20
>=20
>> On Aug 27, 2018, at 3:33 PM, Dino Farinacci  =
wrote:
>>=20
>> Right - we moved the control-plane to 6833bis. I=E2=80=99ll mention =
that in changes section.=20
>>=20
>> Dino
>>=20
>>> On Aug 27, 2018, at 12:07 PM, Scott O. Bradner  =
wrote:
>>>=20
>>>=20
>>> a quick look at the ToC of the ID & of RFC 6830 show a lot of things =
missing (the doc is a lot
>>> shorter) - it might be useful to say something about that in the =
changes since section
>>>=20
>>> Scott
>=20


--Apple-Mail=_7611F17F-F885-4FD9-8D84-1585E45570AD--


From nobody Mon Aug 27 14:14: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 7CA2F130DE8; Mon, 27 Aug 2018 14:14:25 -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] 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 RJ6RyDh4z9-a; Mon, 27 Aug 2018 14:14:23 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B530130DD3; Mon, 27 Aug 2018 14:14:23 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E758A340EC0; Mon, 27 Aug 2018 23:14:20 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.20989);  Mon, 27 Aug 2018 23:14:20 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Mon, 27 Aug 2018 23:14:20 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 65417947; Mon, 27 Aug 2018 23:14:20 +0200
From: "Brian Trammell (IETF)" 
Message-Id: <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_911F9E88-3CD5-4DE1-B119-5E6A43F96417"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 27 Aug 2018 23:14:19 +0200
In-Reply-To: <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com>
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, ietf@ietf.org,  lisp@ietf.org
To: Dino Farinacci 
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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, 27 Aug 2018 21:14:25 -0000

--Apple-Mail=_911F9E88-3CD5-4DE1-B119-5E6A43F96417
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

hi Dino,

> On 27 Aug 2018, at 22:39, Dino Farinacci  wrote:
>=20
>=20
>>> Rather than make references, can you say what you think the issue =
is?
>>=20
>> LISP=E2=80=99s data plane is a UDP tunnel, and as such there are =
congestion control issues that must be considered. LISP inplementors and =
deployers using LISP to carry a mix of traffic that is not predominantly
>=20
> Could you finish your sentence.

sorry, ate an interrupt, sorry about that.

... "congestion controlled itself (i.e., carried by any IETF transport) =
need to be aware that the ITR is ultimately responsible for not causing =
undue congestion, for example, using a circuit breaker."

> I am not sure what more we can say. There is an depth discussion about =
DSCP fields and how to use ECN. Basically copies the inner values to the =
outer header equiv values.

Concretely, I'd add a pointer to RFC 8085, especially section 3.1.11.

>>=20
>>>> (2) This is not transport-specific. Reading the document, it struck =
me that the
>>>> design of the protocol has a few inherently unsafe features related =
to the fact
>>>> that its wire image is neither confidentiality- nor =
integrity-protected. I
>>>> think that all of the potential DDoS and traffic focusing attacks I =
could come
>>>> up with in the hour I spent reviewing the document are indeed =
mentioned in the
>>>> security considerations section, but as the security considerations =
section
>>>> does not give any practical mitigation for dataplane overload =
attacks, it seems
>>>> to be saying that RLOC addresses shouldn't be Internet-accessible, =
which as I
>>>> understand it is not the point of LISP. I haven't seen a secdir =
review on this
>>>> document yet, but I'd encourage the authors to do everything it =
asks.
>>>=20
>>> RFC 8061 goes along with RFC6830bis. It addresses data-plane =
confidentiality.
>>=20
>> I haven=E2=80=99t read 8061 yet, but I probably should before =
continuing this thread.
>>=20
>> I will say that I=E2=80=99m far less concerned about LISP header =
confidentiality than I am about LISP header integrity, given the =
opportunities for on-path meddling and off-path spoofing. If the common =
solution to both is something like sticking everything on the ITR-ETR =
path in IPSec then this is less of a concern.
>=20
> Well RFC8061 does AEAD on the payload. All data *after* the LISP =
header.
> The encryption is a more integrated model than IPsec, so we can be =
more efficient by not using extra IP headers and extra control/key =
exchange protocols.

Okay, that's all well and good. The LISP header itself isn't integrity =
protected, though?

Thanks, cheers,

Brian

>>>> nit: Section 7.1. para 7 should note that the ICMPv6 message sent =
is called
>>>> Packet Too Big, not Unreachable/Frag Needed.
>>>=20
>>> We used =E2=80=9CPacket Too Big=E2=80=9D for all ICMP messages =
including IPv4 and hence we received comments about it on how it should =
change it to Network Unreachable. I will fix this for IPv6.
>>=20
>> Yeah, this is the one place where i noticed a rough edge on =
supporting v4 and v6. Thanks.
>=20
> Fixed. Submitted a new revision a few hours ago.
>=20
> Dino
>=20
>=20


--Apple-Mail=_911F9E88-3CD5-4DE1-B119-5E6A43F96417
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAluEaasACgkQihK3vwvq
RqMbBhAAsaqhduIJ20IKG0owdGzG9HLVhh1liSWlIDnyrvT3yQNf4NnjGQNZ2Lj0
8e2U2b7jyYAs1typPBTUd/aAcq8hecJ1pOCvF93LDb48ssI1GKwylFfw/YRuEwgh
9pb+q2V2cEDRyUcYAUPWn7o+bAFzreGjsCVA45mXx2yGByvkrhMn20zoFTLo3uTq
27CvkXcDY9/hNDOHF5P+eDVJ5c3e8ysDB//oVoKgChmw8QcCusujRIrogxopQF5G
BEjV/KSly5ZEW9Nhg3FYfyoUrTSbAuc8NigtN13uORrHq2iMyHKCU3nM08ntC8OW
E3vbQliGc+Vzl1wHa5d78KaJL+PVRYJUQnZ4vwuknvG/YXDFvQW1e1Y4V65XxOGz
Gl/bA8W9PZ3zIimZVcVHgp/8H5EQRl6RdDJElSjn+CP25MfaYKb4euhMpbv0PPq8
sBwo5H9L/mI3dYzck7QSB8T1WsnW4DmS13qbDpQGErZdyQcC3hpRiSbbA8iKI2wn
oyAUitnjBll7IdoKmAGX3ZzrH6/DSg/R2TKeQpumApg+MC/QLIGVxwIWEyPyHK1Y
gmgWR4DQLzTpUWThoZbCdWUWG67kxMIlCdSygIhtLdms/+vNkeRSGxQRUZlA1nu1
pKmZeBmwS6UxEPtU+TlMbobMVk/VpJzRFVAxYhIf9/o7gLDSvHE=
=XCGz
-----END PGP SIGNATURE-----

--Apple-Mail=_911F9E88-3CD5-4DE1-B119-5E6A43F96417--


From nobody Mon Aug 27 14:19: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 BAEE4130DD3; Mon, 27 Aug 2018 14:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level: 
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 3ThuNTr3EDRk; Mon, 27 Aug 2018 14:19:04 -0700 (PDT)
Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E49B130E16; Mon, 27 Aug 2018 14:19:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 2ECD07164B1C; Mon, 27 Aug 2018 17:19:03 -0400 (EDT)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd_PdNleDA33; Mon, 27 Aug 2018 17:19:02 -0400 (EDT)
Received: from [10.0.1.16] (173-166-5-69-newengland.hfc.comcastbusiness.net [173.166.5.69]) by sobco.sobco.com (Postfix) with ESMTPSA id 9470B7164B0F; Mon, 27 Aug 2018 17:19:02 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Scott O. Bradner" 
In-Reply-To: <1CF46C36-C1CF-477E-95BD-21ACC4FBAE14@gmail.com>
Date: Mon, 27 Aug 2018 17:19:01 -0400
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6515577E-31A8-45DC-90DA-59C43817EAB7@sobco.com>  <600E5518-F884-42DA-80F2-4CF650C6BA60@sobco.com>  <4BAEBA48-2435-4B26-9A45-493A259E6250@sobco.com> <75299534-B274-40F4-AACB-F72105B2E248@gmail.com>   <9BE375D7-50E1-4FF1-B59C-93C203CFBDD0@gmail.com> <9E88630B-404F-4E0D-8CE5-5DD602A59D25@sobco.com> <1F27055C-152D-432B-B372-B79739561D92@gmail.com> <91383BDF-57ED-4F7A-A868-ABF0244187CE@sobco.com> <3BE641EB-F095-4271-8C17-1945362526FF@gmail.com> <90D8DA6D-EE44-45CE-8FCC-950C770CF568@sobco.com> <1CF46C36-C1CF-477E-95BD-21ACC4FBAE14@gmail.com>
To: Dino Farinacci 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] draft-ietf-lisp-rfc6830bis-14
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, 27 Aug 2018 21:19:06 -0000

wfm

Scott


> On Aug 27, 2018, at 4:48 PM, Dino Farinacci  =
wrote:
>=20
> Diffs enclosed.
>=20
> Dino
>=20
> 
>=20
>> On Aug 27, 2018, at 12:40 PM, Scott O. Bradner  wrote:
>>=20
>> thanks!
>>=20
>> Scott
>>=20
>>=20
>>> On Aug 27, 2018, at 3:33 PM, Dino Farinacci  =
wrote:
>>>=20
>>> Right - we moved the control-plane to 6833bis. I=E2=80=99ll mention =
that in changes section.=20
>>>=20
>>> Dino
>>>=20
>>>> On Aug 27, 2018, at 12:07 PM, Scott O. Bradner  =
wrote:
>>>>=20
>>>>=20
>>>> a quick look at the ToC of the ID & of RFC 6830 show a lot of =
things missing (the doc is a lot
>>>> shorter) - it might be useful to say something about that in the =
changes since section
>>>>=20
>>>> Scott
>>=20
>=20


From nobody Mon Aug 27 14:29: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 C7CBD130DE8; Mon, 27 Aug 2018 14:29: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 HPv-y0M0HZao; Mon, 27 Aug 2018 14:29:38 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0: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 55165124BE5; Mon, 27 Aug 2018 14:29:07 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id h79-v6so168746pfk.8; Mon, 27 Aug 2018 14:29: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=Oq1cJpikosjtSrJX3/wzGsbWFYtlih981KqcfcARU5E=; b=ZLCNGsZDGG1vyXRVzTPsbE1uxyjc4qYApDGjT82S7ISRLrnQVIQXxJqkPdK/nzilFe jBSA7waYXEpTBaiKugo6J4a6e+OKx4otu76DWEwBfgF9/70NTof2zGgh/Z++Afr7bq2G YrljqZRhmug+0l8dyD20i2s2m/tSxPvGNPIqiEWvpnF0h4iTfGSKURmR3K5xjdndj9r1 jXuxaUff69SexYF28tpJ1tCO6J1Mz/wkp7yj9MpuCSWDMnIClIvgslxfAw8EqWGPb8UJ 4OOqfNeFRxoc/g/ymWeCePoFYRmfPspYRdXi+EwQlw1M9dhd1ZWO4UjCgiWhM111suGc /+Tw==
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=Oq1cJpikosjtSrJX3/wzGsbWFYtlih981KqcfcARU5E=; b=YKIVFE70x0/DDLvKSCc2D8K7SXeY8Rs69wuA3mFmq35yNpPk5s/EpJWXLNeza56keJ HgAjaXq3D3J7VV4ReCneuqZ5hhdkUH4QgymtsRBxI8jTdGn7U+ivtSsFQihIEvBI/SBh paaXx+AYZlnodW/2x79ieQHtg9y/kexoCZecElbTfLVOb8cRxFP34XUG6OiFAfu30XvC lOhEiuS8IwaF4V8rLaj2T4R6Nzvho97Fu9enAES+aXR2S0GMGDux+uaPNoJmCS+6vCyV T8ryi6hp/GHYwTM7SM2yYCGazNPcEbgLD2YSBjY6sbTbxE9R6IXOlbiQgtLRj1sPKUMJ u2WQ==
X-Gm-Message-State: APzg51BwhcNTytnhosAAUa4CRnuP9oQdSZ2Bh0S1vuMKPARlQrAGTgGl Cry2xKwnF4F3mb+8a/Emqn0=
X-Google-Smtp-Source: ANB0VdbAQTOY67THMFRNu/1G6mpyBsA98/zu3Vjjh9SjuhSfMvBJ4/zqJMAexJlPPCyjiraZ3B8Y5Q==
X-Received: by 2002:a65:4384:: with SMTP id m4-v6mr13612465pgp.265.1535405346836;  Mon, 27 Aug 2018 14:29:06 -0700 (PDT)
Received: from ?IPv6:2603:3024:151c:55f0:c1b3:bc4c:9028:ff3b? ([2603:3024:151c:55f0:c1b3:bc4c:9028:ff3b]) by smtp.gmail.com with ESMTPSA id f6-v6sm257675pff.29.2018.08.27.14.29.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 14:29: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: <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>
Date: Mon, 27 Aug 2018 14:29:03 -0700
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, ietf@ietf.org,  lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>
To: "Brian Trammell (IETF)" 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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, 27 Aug 2018 21:29:42 -0000

>> LISP=E2=80=99s data plane is a UDP tunnel, and as such there are =
congestion control issues that must be considered. LISP inplementors and =
deployers using LISP to carry a mix of traffic that is not =
predominantly"
> sorry, ate an interrupt, sorry about that.
>=20
> ... "congestion controlled itself (i.e., carried by any IETF =
transport) need to be aware that the ITR is ultimately responsible for =
not causing undue congestion, for example, using a circuit breaker.=E2=80=9D=


Well I hear you, but you know there is a lot of technology developed =
that uses UDP tunneling. And in this case, it isn=E2=80=99t used like a =
traditional transport whereby a node is originating traffic. In this =
case, a LISP router is forwarding packets just like any other IP router =
forwarding IP packets.

>=20
>> I am not sure what more we can say. There is an depth discussion =
about DSCP fields and how to use ECN. Basically copies the inner values =
to the outer header equiv values.
>=20
> Concretely, I'd add a pointer to RFC 8085, especially section 3.1.11.

But I am not sure what supporting text we should put around the =
reference. Please advise.

>=20
>>>=20
>>>>> (2) This is not transport-specific. Reading the document, it =
struck me that the
>>>>> design of the protocol has a few inherently unsafe features =
related to the fact
>>>>> that its wire image is neither confidentiality- nor =
integrity-protected. I
>>>>> think that all of the potential DDoS and traffic focusing attacks =
I could come
>>>>> up with in the hour I spent reviewing the document are indeed =
mentioned in the
>>>>> security considerations section, but as the security =
considerations section
>>>>> does not give any practical mitigation for dataplane overload =
attacks, it seems
>>>>> to be saying that RLOC addresses shouldn't be Internet-accessible, =
which as I
>>>>> understand it is not the point of LISP. I haven't seen a secdir =
review on this
>>>>> document yet, but I'd encourage the authors to do everything it =
asks.
>>>>=20
>>>> RFC 8061 goes along with RFC6830bis. It addresses data-plane =
confidentiality.
>>>=20
>>> I haven=E2=80=99t read 8061 yet, but I probably should before =
continuing this thread.
>>>=20
>>> I will say that I=E2=80=99m far less concerned about LISP header =
confidentiality than I am about LISP header integrity, given the =
opportunities for on-path meddling and off-path spoofing. If the common =
solution to both is something like sticking everything on the ITR-ETR =
path in IPSec then this is less of a concern.
>>=20
>> Well RFC8061 does AEAD on the payload. All data *after* the LISP =
header.
>> The encryption is a more integrated model than IPsec, so we can be =
more efficient by not using extra IP headers and extra control/key =
exchange protocols.
>=20
> Okay, that's all well and good. The LISP header itself isn't integrity =
protected, though?

It is not, unless the outer UDP checksum is used. Which we suggest to be =
0 and when NATs make it non-zero, ETRs ignore it.

Dino


From nobody Mon Aug 27 23:42: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 41009130DDB; Mon, 27 Aug 2018 23:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 H2pGLI8V0r57; Mon, 27 Aug 2018 23:42:12 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94AC6130DEC; Mon, 27 Aug 2018 23:42:11 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7D4B23405A9; Tue, 28 Aug 2018 08:42:09 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.3568);  Tue, 28 Aug 2018 08:42:09 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Tue, 28 Aug 2018 08:42:09 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 65445939; Tue, 28 Aug 2018 08:42:08 +0200
From: "Brian Trammell (IETF)" 
Message-Id: <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_31FA4454-BFE8-4349-B92D-49E7904B1D6C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 28 Aug 2018 08:42:08 +0200
In-Reply-To: 
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, ietf@ietf.org,  lisp@ietf.org
To: Dino Farinacci 
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch> 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Tue, 28 Aug 2018 06:42:14 -0000

--Apple-Mail=_31FA4454-BFE8-4349-B92D-49E7904B1D6C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

hi Dino, all,

> On 27 Aug 2018, at 23:29, Dino Farinacci  wrote:
>=20
>>> LISP=E2=80=99s data plane is a UDP tunnel, and as such there are =
congestion control issues that must be considered. LISP inplementors and =
deployers using LISP to carry a mix of traffic that is not =
predominantly"
>> sorry, ate an interrupt, sorry about that.
>>=20
>> ... "congestion controlled itself (i.e., carried by any IETF =
transport) need to be aware that the ITR is ultimately responsible for =
not causing undue congestion, for example, using a circuit breaker.=E2=80=9D=

>=20
> Well I hear you, but you know there is a lot of technology developed =
that uses UDP tunneling. And in this case, it isn=E2=80=99t used like a =
traditional transport whereby a node is originating traffic. In this =
case, a LISP router is forwarding packets just like any other IP router =
forwarding IP packets.

Yep. 8085 is where the we put our best current practices for doing this =
sort of thing, so IMO it's important for implementors to be aware of the =
things it says relative to tunneling.

>>> I am not sure what more we can say. There is an depth discussion =
about DSCP fields and how to use ECN. Basically copies the inner values =
to the outer header equiv values.
>>=20
>> Concretely, I'd add a pointer to RFC 8085, especially section 3.1.11.
>=20
> But I am not sure what supporting text we should put around the =
reference. Please advise.

I'd suggest inserting a new paragraph after paragraph 2 of section 5, =
something like:


NEW:

As LISP uses UDP encapsulation to carry traffic between ITRs and ETRs =
across the Internet, implementors should be aware of the provisions of =
[RFC8085], especially those given in section 3.1.11 on congestion =
control for UDP tunneling.


>>>>>> (2) This is not transport-specific. Reading the document, it =
struck me that the
>>>>>> design of the protocol has a few inherently unsafe features =
related to the fact
>>>>>> that its wire image is neither confidentiality- nor =
integrity-protected. I
>>>>>> think that all of the potential DDoS and traffic focusing attacks =
I could come
>>>>>> up with in the hour I spent reviewing the document are indeed =
mentioned in the
>>>>>> security considerations section, but as the security =
considerations section
>>>>>> does not give any practical mitigation for dataplane overload =
attacks, it seems
>>>>>> to be saying that RLOC addresses shouldn't be =
Internet-accessible, which as I
>>>>>> understand it is not the point of LISP. I haven't seen a secdir =
review on this
>>>>>> document yet, but I'd encourage the authors to do everything it =
asks.
>>>>>=20
>>>>> RFC 8061 goes along with RFC6830bis. It addresses data-plane =
confidentiality.
>>>>=20
>>>> I haven=E2=80=99t read 8061 yet, but I probably should before =
continuing this thread.
>>>>=20
>>>> I will say that I=E2=80=99m far less concerned about LISP header =
confidentiality than I am about LISP header integrity, given the =
opportunities for on-path meddling and off-path spoofing. If the common =
solution to both is something like sticking everything on the ITR-ETR =
path in IPSec then this is less of a concern.
>>>=20
>>> Well RFC8061 does AEAD on the payload. All data *after* the LISP =
header.
>>> The encryption is a more integrated model than IPsec, so we can be =
more efficient by not using extra IP headers and extra control/key =
exchange protocols.
>>=20
>> Okay, that's all well and good. The LISP header itself isn't =
integrity protected, though?
>=20
> It is not, unless the outer UDP checksum is used. Which we suggest to =
be 0 and when NATs make it non-zero, ETRs ignore it.

Ah. Okay, so two things:

(1) By "integrity protection" I mean "cryptographic integrity =
protection", in the sense of "preventing on-path attackers or off-path =
spoofers from being able to influence ITR/ETR state through crafted LISP =
headers to the detriment of the traffic of others". Looking over 8061, =
it seems to only cover confidentiality of the data-plane payload, which =
is extremely useful but not sufficient to prevent these attacks.

The attacks seem to be well enumerated in 6830bis, but the lack of a =
stated mitigation beyond "be careful" seems to suggest that the =
mitigation is "don't use LISP", which is of course less than desirable. =
I'm trying to understand whether the deployment scenarios envisioned for =
LISP make these attacks less likely (for instance, because the ITR/ETR =
path itself is generally cryptographically protected with its own outer =
tunnel), or whether this is something that this document (or a future =
companion to 8061) needs to worry about.

(2) Checksums provide what I'd call "corruption protection". On "setting =
the outer UDP checksum to zero", please be aware that this may have =
undesirable interactions with IPv6 headers; see also section 3.4 =
(Checksum Guidelines) of 8085.

Thanks, cheers,

Brian



--Apple-Mail=_31FA4454-BFE8-4349-B92D-49E7904B1D6C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAluE7sAACgkQihK3vwvq
RqM+gA//cFAdpy/HYmgrKxpxo7f8DNazAKLkMgJr0Li8FutIrJ/Hr26XH2lM3NjE
O4cUtRxTLqV1f47z0TS2hW2zoYd4Us02Cj4GT0zOIt142ZfEIoaVWGkM5xlSaEsl
CDONUOHbYoLk+btflnfus3o6yqwa4yD1+Ly1peSGlE3Catq2m0O7GV1u/0uK+H1A
dqMMfDThVVoFfoilqcS8wHo9zWf1j0trPTY9qxy/u5Wd9Fk3AA2R5rwoeL3Y/BM4
wxUH/1nWTMNmsxYkkX10FYTO/cFsp/572PneVSwzgkrah2tEzGIxJ0q0cmd8vHhG
9HWCpwrM+JETenVNYqPSbg2alcOjuXAaXePXKZaJJMdO4rPubcRp9vd6PiJNrLKH
/y0CJGeKXbjTZCS79lS1AeyuLPW1ikbsCAI49ckgfhM7a0I+lLtIaoXJTpy94taW
XH45zI5IgC0KubGY1ODXHy+RWjcPXNJlvK43WVu/pg7LFsYE9icu2sZlBEpmI4ms
9po7175bDBxs3QyY5RHgB3b4d88emJGWYGBjUBon9Dd0+xQ2kwRUa+MhOJZX7W/v
nxw7KANT6focHfPthJaKaXCV0hacTPXAkf5zS6MiUwMAbIcYYzINrGPTiNFeR0qY
Syo0NE0J5V/k8r0xM8OojttFG6P/enYB8M806vRALIMOsXmTiXk=
=/kyD
-----END PGP SIGNATURE-----

--Apple-Mail=_31FA4454-BFE8-4349-B92D-49E7904B1D6C--


From nobody Tue Aug 28 05:54:16 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 D8536130EBA; Tue, 28 Aug 2018 05:54:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Scott Bradner 
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: <153546084779.23731.3772960451880909496@ietfa.amsl.com>
Date: Tue, 28 Aug 2018 05:54:07 -0700
Archived-At: 
Subject: [lisp] Opsdir last call review of draft-ietf-lisp-rfc6830bis-16
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: Tue, 28 Aug 2018 12:54:08 -0000

Reviewer: Scott Bradner
Review result: Ready

I performed an OPS-DIR review of The Locator/ID Separation Protocol (LISP)
(draft-ietf-lisp-rfc6830bis-16) This ID is the result of a bifurcation of RFC
6830 as such review of the basic technology is OBE. (i.e. RFC 6830 was
published years ago – any deep technology review should have been done then.)
The ID does make some changes to the technology described in RFC 6830 but the
changes do not present any operations related issues that I can see.

The version I was asked to review did not have a “Changes since RFC 6830”
section (as all RFCs that update or obsolete other RFCs should have) but that
has been fixed so I have no additional issues.



From nobody Tue Aug 28 09:26: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 AE24C124C04; Tue, 28 Aug 2018 09:26:08 -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 4_YvLDgdDaYx; Tue, 28 Aug 2018 09:26:07 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0: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 668F4130DD8; Tue, 28 Aug 2018 09:26:07 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id p12-v6so953761pfh.2; Tue, 28 Aug 2018 09:26: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=KLqRxBqNQKW+JR4G77cwQHXEORgk7UOqVvkaCvVrdxM=; b=XgwZBS5gcolnrwECtl+SfUYUmYfHosEKuYDfWqcvTPXForWDN7tE7rElUQ6Sj7Lus2 yKQDISGH1HJAdmSQro4QP1vQhr3QxPwkFa0sCf6yBSOF8OiHlN1URYAYtdEavAajKK1E 78+Rg7KVQGRC/qo60+AE4nXON+HyF4hRMzr3YtGAGzowr0MNMu4VITSgfUuhTShprASz I2efcWv2HRwDofpAdCf9wFGSYQ+JrmHtXGfVAPjj96xwUDpk38Lz4HXHDsd5w8gNuyqD J/uAkrBXa0VJQ3v/ykjaxS9/U01J48mSbcpSj95YP12pnMI9zTSgqhkhxTpcAYmwMX7n pvrQ==
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=KLqRxBqNQKW+JR4G77cwQHXEORgk7UOqVvkaCvVrdxM=; b=nQYXiuHm5B/C0nyXe8eeT7SfFafTDV00MxrljAka+BukGsPV+L5JGXVjRc5iWlDMtE ZGMhZXbAzK+ESM+yK92oWteQBcf7yekLeh/woqftUHJmqdlzIqqZDHSfEY1I6O0lphWX EA7UtCC3QpMZ7gMz5rz3b0Y0NUJTWchsm7qC53o1RanDdCvr9x2C3C2XaUIYK7qB7Bej HLS6CHeabn2pwc7m+EQY2jm+V+CcMWjvf2AoRFIhnIVLOURBOKkEo9eAodP3HZKtEHn1 rBk3CKbt22WLM/whLGuMOXCHxMa3k2auYI/6+hJ2Q9Z2RpDmRbCq9C/Isxt7G19RCOuL ORjw==
X-Gm-Message-State: APzg51DnA7JL9aLNh49c4u3SFp0QxjijBQ3UDvCXGvWAGPjS/8WOGvTQ vfJ1OxfBlKqsXZgOVWHzNPc=
X-Google-Smtp-Source: ANB0VdZZ0KYHyFvBZTrH9O59+MkNAJFVocCJTTJNs8wI2LA2QadTQ+dEttbvaJbpNH0B7Tm+331TgA==
X-Received: by 2002:a63:5706:: with SMTP id l6-v6mr2317322pgb.118.1535473566971;  Tue, 28 Aug 2018 09:26:06 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id n80-v6sm3221987pfb.95.2018.08.28.09.26.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Aug 2018 09:26: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: <153546084779.23731.3772960451880909496@ietfa.amsl.com>
Date: Tue, 28 Aug 2018 09:26:05 -0700
Cc: ops-dir@ietf.org, draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List , lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <153546084779.23731.3772960451880909496@ietfa.amsl.com>
To: Scott Bradner 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] Opsdir last call review of draft-ietf-lisp-rfc6830bis-16
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: Tue, 28 Aug 2018 16:26:09 -0000

Thanks a ton Scott. Hope you are enjoying your retirement.  ;-)

Dino

> On Aug 28, 2018, at 5:54 AM, Scott Bradner  wrote:
>=20
> Reviewer: Scott Bradner
> Review result: Ready
>=20
> I performed an OPS-DIR review of The Locator/ID Separation Protocol =
(LISP)
> (draft-ietf-lisp-rfc6830bis-16) This ID is the result of a bifurcation =
of RFC
> 6830 as such review of the basic technology is OBE. (i.e. RFC 6830 was
> published years ago =E2=80=93 any deep technology review should have =
been done then.)
> The ID does make some changes to the technology described in RFC 6830 =
but the
> changes do not present any operations related issues that I can see.
>=20
> The version I was asked to review did not have a =E2=80=9CChanges =
since RFC 6830=E2=80=9D
> section (as all RFCs that update or obsolete other RFCs should have) =
but that
> has been fixed so I have no additional issues.
>=20
>=20


From nobody Tue Aug 28 09:49: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 05EC1130DF9; Tue, 28 Aug 2018 09:49: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 T82T1le_bO31; Tue, 28 Aug 2018 09:49:18 -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 0C0A0126DBF; Tue, 28 Aug 2018 09:49:18 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id g20-v6so1009570pgv.6; Tue, 28 Aug 2018 09:49:18 -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=GGpbO0zRJjvK8xMGJ8PVnWR2vT/vxFmhw+COh7Ih78g=; b=Hbd2TRO1Jyp+r9+5qAOhvq58yzuQjz+GQ8yW9Fent6PCRAc622hBcm8RIyrT6ruR5q y5Afodz3eohTvLLPjMx9SutClRfkBTZ9uNPNn3n5nozP/r993DZXR7fml1U+olrsl98D uSG9y4LQq6RqMxv8JInsqly9RoyismbHwtTOtqrXr0iHUXjs0aKES07G/aEkbjQmoEg9 xNRH0Sr3BiF1ofmjvuXRamsKt+PWhNmKkmWdxfywff7B60RBMhWEQE9vyAgUOga6vO6r 3mCQe22u7CVYgX+jkK4o+xjVogocpXSPaHz7G0otg03Ra9li6aERECGHoeO3TpH9CAf8 IT7A==
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=GGpbO0zRJjvK8xMGJ8PVnWR2vT/vxFmhw+COh7Ih78g=; b=pt3uaQaHLsMt+J6QT2ITb07/fpxAJfIy31214ywjeX3/xkb/++OZG1N1t90rK55gtJ e1PO2t52cQ742JfWRm3ZcAA/Vo4AnLcF9YpSdYOHe/+CjQFlkFev+ftX+8W3hSv/RNMn Z9foAMAL1g+h+f3rWiAGOprRdNMxgN0g+r12f5KOE69YUdu2/2Zy6T5kaea0AWy46U+D G1MYjAxCM74asjdH9RB4HI+6fhME3q/WYcJiseSB/Hl0SJCMMhL6RsC01wARsNpzJjld zMVDZKWMmiipxCBpbUN/G2BPfHvVPv/BlnkPVI4GP4Nca/JEyUR6oRnAF0V+aHhruDeK 7lGg==
X-Gm-Message-State: APzg51CXeCI0MPGdc9em3EH84tnUB87zkfUoQDVNeT51xk2v+4g62wTI FsLPjeNpqnq7hrJ+jAQ3/Oh3OrV8
X-Google-Smtp-Source: ANB0VdY1gjxrxe5y2Xk+XhZ8ZnxiHi8kA+StiJ7VMpZx3zCniBP96Zz/a89TSVo+W2jZPO8HbKIRVw==
X-Received: by 2002:a62:591a:: with SMTP id n26-v6mr2422342pfb.94.1535474957596;  Tue, 28 Aug 2018 09:49:17 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id o10-v6sm6167090pfk.76.2018.08.28.09.49.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Aug 2018 09:49: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: <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>
Date: Tue, 28 Aug 2018 09:49:15 -0700
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List , Dino Farinacci , "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>  <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>
To: "Brian Trammell (IETF)" 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Tue, 28 Aug 2018 16:49:20 -0000

> I'd suggest inserting a new paragraph after paragraph 2 of section 5, =
something like:
>=20
>=20
> NEW:
>=20
> As LISP uses UDP encapsulation to carry traffic between ITRs and ETRs =
across the Internet, implementors should be aware of the provisions of =
[RFC8085], especially those given in section 3.1.11 on congestion =
control for UDP tunneling.

Consider it added to Section 5 =E2=80=9CLISP Encapsulation Details=E2=80=9D=
, last paragraph.

>=20
>>>>>>> (2) This is not transport-specific. Reading the document, it =
struck me that the
>>>>>>> design of the protocol has a few inherently unsafe features =
related to the fact
>>>>>>> that its wire image is neither confidentiality- nor =
integrity-protected. I
>>>>>>> think that all of the potential DDoS and traffic focusing =
attacks I could come
>>>>>>> up with in the hour I spent reviewing the document are indeed =
mentioned in the
>>>>>>> security considerations section, but as the security =
considerations section
>>>>>>> does not give any practical mitigation for dataplane overload =
attacks, it seems
>>>>>>> to be saying that RLOC addresses shouldn't be =
Internet-accessible, which as I
>>>>>>> understand it is not the point of LISP. I haven't seen a secdir =
review on this
>>>>>>> document yet, but I'd encourage the authors to do everything it =
asks.
>>>>>>=20
>>>>>> RFC 8061 goes along with RFC6830bis. It addresses data-plane =
confidentiality.
>>>>>=20
>>>>> I haven=E2=80=99t read 8061 yet, but I probably should before =
continuing this thread.
>>>>>=20
>>>>> I will say that I=E2=80=99m far less concerned about LISP header =
confidentiality than I am about LISP header integrity, given the =
opportunities for on-path meddling and off-path spoofing. If the common =
solution to both is something like sticking everything on the ITR-ETR =
path in IPSec then this is less of a concern.
>>>>=20
>>>> Well RFC8061 does AEAD on the payload. All data *after* the LISP =
header.
>>>> The encryption is a more integrated model than IPsec, so we can be =
more efficient by not using extra IP headers and extra control/key =
exchange protocols.
>>>=20
>>> Okay, that's all well and good. The LISP header itself isn't =
integrity protected, though?
>>=20
>> It is not, unless the outer UDP checksum is used. Which we suggest to =
be 0 and when NATs make it non-zero, ETRs ignore it.
>=20
> Ah. Okay, so two things:
>=20
> (1) By "integrity protection" I mean "cryptographic integrity =
protection", in the sense of "preventing on-path attackers or off-path =
spoofers from being able to influence ITR/ETR state through crafted LISP =
headers to the detriment of the traffic of others". Looking over 8061, =
it seems to only cover confidentiality of the data-plane payload, which =
is extremely useful but not sufficient to prevent these attacks.

Well at this point in the generation of LISP, the only text I think to =
mitigate LISP header corruption is to indicate that a LISP ITR can use =
an outer IPsec header if protection of the UDP and LISP headers need =
protection. Or is that not a strong enough statement?

> The attacks seem to be well enumerated in 6830bis, but the lack of a =
stated mitigation beyond "be careful" seems to suggest that the =
mitigation is "don't use LISP", which is of course less than desirable. =
I'm trying to understand whether the deployment scenarios envisioned for =
LISP make these attacks less likely (for instance, because the ITR/ETR =
path itself is generally cryptographically protected with its own outer =
tunnel), or whether this is something that this document (or a future =
companion to 8061) needs to worry about.

I think so because of 8061.

> (2) Checksums provide what I'd call "corruption protection". On =
"setting the outer UDP checksum to zero", please be aware that this may =
have undesirable interactions with IPv6 headers; see also section 3.4 =
(Checksum Guidelines) of 8085.

If we don=E2=80=99t go IPsec route, we go with the checksum route. What =
do you think? Meaning, that if LISP header protection is desiriable, use =
UDP checksums.=20

> Thanks, cheers,
>=20
> Brian

Thanks for the commentary and discussion,
Dino



From nobody Tue Aug 28 09:53: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 7C4B3130F47; Tue, 28 Aug 2018 09:53:35 -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 dXaNf0FEcd2i; Tue, 28 Aug 2018 09:53:31 -0700 (PDT)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 5CE67130F43; Tue, 28 Aug 2018 09:53:31 -0700 (PDT)
Received: by mail-pg1-x529.google.com with SMTP id r1-v6so1001343pgp.11; Tue, 28 Aug 2018 09:53:31 -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=Rkt1kNzLwy/rfFsYNwQCC5qSDcJL25fd6rSHhxbQHyo=; b=CmmJ22kYb+uAKtvNMFrHcIanphAAkj3SKm0HiQT6gBE9MraQ18l0W2FBVcxczy+Zlp rudPOMypNJBUmyR64cBSGuVC68OUPt4uh0BNYF3mZAXdVy6WAYc1qUIljAeDHx9lKYvD K0hfKl2cex6cyZwW4y8+GCFgzPqObm6NQED4bYzhg1S2tB+FOtU3rgz5Hqzwx9JvBwh4 vILrCc3JLNXg9MPyveJkbiXlHlUKOXoypgyehcVwyaEEtmysVDLxFEPNTgJHeRC5XZiL jB3juxOKPhVkEkNj0y0mdDkJLL0uhjYkAcgJNllhmkyVn6SIi6fV+qQQGZoKbMgA7H1r OTgA==
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=Rkt1kNzLwy/rfFsYNwQCC5qSDcJL25fd6rSHhxbQHyo=; b=teyJQ/aW3KORddalnwbWaLw1+XDxzm8g5uEier8SDD1XyH+dXHpL92ljN+2dIz2RkO 6RX4TnxskQKL1goVqW5uGHqjkHtZyje5Rqb10rQlsidhZMM4GxKofpEU05pJ+R41bpda mzckM3cMBmsVRbJYzshi3Cqg4tY7BmYq7JT8WmD3TSIK4ZApDXOwoog0UXeQByhNXI8r 8oPmsrgHikFd2N55TMSoYV+hMaL5RWM/6VYiIsXIIz5yQFUnSTq4MmTQIgQvZltzsNA3 VjPApWPoQlcnOfqE/koGXYhP6wqNjO0YgCiicPYxBu1cEZL/9BJ7hSVvUx9vTMtaG4S9 71sg==
X-Gm-Message-State: APzg51Cs8Ripre7oW+OMZpK5UaPUxvQ6UiUpUl/QEh1VmiiY9ywSV581 97rRrENluHJ0BqhCw58YbftVSyXT
X-Google-Smtp-Source: ANB0VdY/14TkBl7JQZ1KRriHbfzPQQ2tvrNPQI7v4gY9NkvkdhhDE5is1PTblzFDtwVTGp9bCPbjQg==
X-Received: by 2002:a63:6283:: with SMTP id w125-v6mr2245152pgb.83.1535475211044;  Tue, 28 Aug 2018 09:53:31 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id o134-v6sm5175864pfg.74.2018.08.28.09.53.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Aug 2018 09:53:30 -0700 (PDT)
From: Dino Farinacci 
Message-Id: <9BDCA5D2-01C6-41F0-BC04-7C1378675236@gmail.com>
Content-Type: multipart/mixed; boundary="Apple-Mail=_BB69CA2C-1A69-4FDF-BB7E-9DD708634236"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 28 Aug 2018 09:53:29 -0700
In-Reply-To: 
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" 
To: "Brian Trammell (IETF)" 
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>  <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch> 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Tue, 28 Aug 2018 16:53:48 -0000

--Apple-Mail=_BB69CA2C-1A69-4FDF-BB7E-9DD708634236
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Here is the latest diff for -17.

Dino


--Apple-Mail=_BB69CA2C-1A69-4FDF-BB7E-9DD708634236
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-rfc6830bis-16.txt - =
draft-ietf-lisp-rfc6830bis-17.txt=20
  =20
     =20
=20
=20
  =20
  =20
      
< draft-ietf-lisp-rfc6830bis-16.txt  =
 draft-ietf-lisp-rfc6830bis-17.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: February 28, 2019                                =
 Cisco Systems Expires: March 1, 2019                                    =
 Cisco Systems

      
                  =
                                     A. Cabellos (Ed.)                                                        =
A. Cabellos (Ed.)

      
                  =
                                     UPC/BarcelonaTech                                                        =
UPC/BarcelonaTech

      

      
                =
                                         August 27, 2018       =
                                                   August 28, 2018

      
 =


      
               =
The Locator/ID Separation Protocol (LISP)                The Locator/ID Separation Protocol =
(LISP)

      

      
                =
     draft-ietf-lisp-rfc6830bis-16 =
                     =
draft-ietf-lisp-rfc6830bis-17

      
 =


      
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 February 28, =
2019.    This Internet-Draft will =
expire on March 1, 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 29 =C2=B6 =
skipping to change at page 2, line 29 =C2=B6

      
 =


      
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  . . . . . . . . . . . . . . . . . . . . . . .   8 =
   4.  Basic Overview  . . . . . . . . . . . . =
. . . . . . . . . . .   8

      
     4.1.  Packet =
Flow Sequence  . . . . . . . . . . . . . . . . . .  10      4.1.  Packet Flow Sequence  . . . . . . . . . . . . =
. . . . . .  10

      
   5.  LISP =
Encapsulation Details  . . . . . . . . . . . . . . . . .  12 =
   5.  LISP Encapsulation Details  . . . . . . =
. . . . . . . . . . .  12

      
     5.1.  LISP =
IPv4-in-IPv4 Header Format . . . . . . . . . . . . .  13 =
     5.1.  LISP IPv4-in-IPv4 Header Format . . =
. . . . . . . . . . .  13

      

      
     5.2.  LISP =
IPv6-in-IPv6 Header Format . . . . . . . . . . . . .  13      5.2.  =
LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . .  14

      
     5.3.  Tunnel =
Header Field Descriptions  . . . . . . . . . . . .  15      5.3.  Tunnel Header Field Descriptions  . . . . . . =
. . . . . .  15

      
   6.  LISP =
EID-to-RLOC Map-Cache  . . . . . . . . . . . . . . . . .  19 =
   6.  LISP EID-to-RLOC Map-Cache  . . . . . . =
. . . . . . . . . . .  19

      

      
   7.  Dealing =
with Large Encapsulated Packets . . . . . . . . . . .  19    7.  =
Dealing with Large Encapsulated Packets . . . . . . . . . . .  20

      
     7.1.  A =
Stateless Solution to MTU Handling  . . . . . . . . . .  20 =
     7.1.  A Stateless Solution to MTU Handling =
 . . . . . . . . . .  20

      
     7.2.  A =
Stateful Solution to MTU Handling . . . . . . . . . . .  21 =
     7.2.  A Stateful Solution to MTU Handling =
. . . . . . . . . . .  21

      

      
   8.  Using =
Virtualization and Segmentation with LISP . . . . . . .  21    8.  =
Using Virtualization and Segmentation with LISP . . . . . . .  22

      
   9.  Routing =
Locator Selection . . . . . . . . . . . . . . . . . .  22 =
   9.  Routing Locator Selection . . . . . . . =
. . . . . . . . . . .  22

      
   10. Routing =
Locator Reachability  . . . . . . . . . . . . . . . .  24 =
   10. Routing Locator Reachability  . . . . . =
. . . . . . . . . . .  24

      
     10.1.  Echo =
Nonce Algorithm . . . . . . . . . . . . . . . . . .  25 =
     10.1.  Echo Nonce Algorithm . . . . . . . =
. . . . . . . . . . .  25

      
   11. EID =
Reachability within a LISP Site . . . . . . . . . . . . .  26 =
   11. EID Reachability within a LISP Site . . =
. . . . . . . . . . .  26

      
   12. Routing =
Locator Hashing . . . . . . . . . . . . . . . . . . .  27 =
   12. Routing Locator Hashing . . . . . . . . =
. . . . . . . . . . .  27

      
   13. Changing =
the Contents of EID-to-RLOC Mappings . . . . . . . .  28 =
   13. Changing the Contents of EID-to-RLOC =
Mappings . . . . . . . .  28

      
     13.1.  =
Database Map-Versioning  . . . . . . . . . . . . . . . .  29 =
     13.1.  Database Map-Versioning  . . . . . =
. . . . . . . . . . .  29

      

      
   14. =
Multicast Considerations  . . . . . . . . . . . . . . . . . .  29    14. =
Multicast Considerations  . . . . . . . . . . . . . . . . . .  30

      
   15. Router =
Performance Considerations . . . . . . . . . . . . . .  30 =
   15. Router Performance Considerations . . . =
. . . . . . . . . . .  30

      
   16. Security =
Considerations . . . . . . . . . . . . . . . . . . .  31 =
   16. Security Considerations . . . . . . . . =
. . . . . . . . . . .  31

      
   17. Network =
Management Considerations . . . . . . . . . . . . . .  32 =
   17. Network Management Considerations . . . =
. . . . . . . . . . .  32

      
   18. Changes =
since RFC 6830  . . . . . . . . . . . . . . . . . . .  32 =
   18. Changes since RFC 6830  . . . . . . . . =
. . . . . . . . . . .  32

      
   19. IANA =
Considerations . . . . . . . . . . . . . . . . . . . . .  32 =
   19. IANA Considerations . . . . . . . . . . =
. . . . . . . . . . .  32

      

      
     19.1.  =
LISP UDP Port Numbers  . . . . . . . . . . . . . . . . .  32      19.1.  =
LISP UDP Port Numbers  . . . . . . . . . . . . . . . . .  33

      
   20. References =
 . . . . . . . . . . . . . . . . . . . . . . . . .  33    20. References  . . . . . . . . . . . . . . . . . . . =
. . . . . .  33

      
     20.1.  =
Normative References . . . . . . . . . . . . . . . . . .  33 =
     20.1.  Normative References . . . . . . . =
. . . . . . . . . . .  33

      

      
     20.2.  =
Informative References . . . . . . . . . . . . . . . . .  33      20.2.  =
Informative References . . . . . . . . . . . . . . . . .  34

      
 =


      

      
   Appendix A.  =
Acknowledgments  . . . . . . . . . . . . . . . . . .  37    =
Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  38

      
   Appendix B.  =
Document Change Log  . . . . . . . . . . . . . . . .  37    =
Appendix B.  Document Change Log  . . . . . . . . . . . . . . . .  38

      
     B.1.  =
Changes to draft-ietf-lisp-rfc6830bis-16  =
. . . . . . . .  38      B.1.  Changes to draft-ietf-lisp-rfc6830bis-17  . . . . . . . .  =
39

      
     B.2.  =
Changes to draft-ietf-lisp-rfc6830bis-15  =
. . . . . . . .  38      B.2.  Changes to draft-ietf-lisp-rfc6830bis-16  . . . . . . . .  =
39

      
     B.3.  =
Changes to draft-ietf-lisp-rfc6830bis-14  =
. . . . . . . .  38      B.3.  Changes to draft-ietf-lisp-rfc6830bis-15  . . . . . . . .  =
39

      
     B.4.  =
Changes to draft-ietf-lisp-rfc6830bis-13  =
. . . . . . . .  38      B.4.  Changes to draft-ietf-lisp-rfc6830bis-14  . . . . . . . .  =
39

      
     B.5.  =
Changes to draft-ietf-lisp-rfc6830bis-12  =
. . . . . . . .  38      B.5.  Changes to draft-ietf-lisp-rfc6830bis-13  . . . . . . . .  =
39

      
     B.6.  =
Changes to draft-ietf-lisp-rfc6830bis-11  =
. . . . . . . .  38      B.6.  Changes to draft-ietf-lisp-rfc6830bis-12  . . . . . . . .  =
39

      
     B.7.  =
Changes to draft-ietf-lisp-rfc6830bis-10  =
. . . . . . . .  39      B.7.  Changes to draft-ietf-lisp-rfc6830bis-11  . . . . . . . .  =
40

      
     B.8.  =
Changes to draft-ietf-lisp-rfc6830bis-09  =
. . . . . . . .  39      B.8.  Changes to draft-ietf-lisp-rfc6830bis-10  . . . . . . . .  =
40

      
     B.9.  =
Changes to draft-ietf-lisp-rfc6830bis-08  =
. . . . . . . .  39      B.9.  Changes to draft-ietf-lisp-rfc6830bis-09  . . . . . . . .  =
40

      
     B.10. =
Changes to draft-ietf-lisp-rfc6830bis-07  =
. . . . . . . .  40      B.10. =
Changes to draft-ietf-lisp-rfc6830bis-08  =
. . . . . . . .  40

      
     B.11. =
Changes to draft-ietf-lisp-rfc6830bis-06  =
. . . . . . . .  40      B.11. Changes to draft-ietf-lisp-rfc6830bis-07  . . . . . . . .  =
41

      
     B.12. =
Changes to draft-ietf-lisp-rfc6830bis-05  =
. . . . . . . .  40      B.12. Changes to draft-ietf-lisp-rfc6830bis-06  . . . . . . . .  =
41

      
     B.13. =
Changes to draft-ietf-lisp-rfc6830bis-04  =
. . . . . . . .  40      B.13. Changes to draft-ietf-lisp-rfc6830bis-05  . . . . . . . .  =
41

      
     B.14. =
Changes to draft-ietf-lisp-rfc6830bis-03  =
. . . . . . . .  41      B.14. =
Changes to draft-ietf-lisp-rfc6830bis-04  =
. . . . . . . .  41

      
     B.15. =
Changes to draft-ietf-lisp-rfc6830bis-02  =
. . . . . . . .  41      B.15. Changes to draft-ietf-lisp-rfc6830bis-03  . . . . . . . .  =
42

      
     B.16. =
Changes to draft-ietf-lisp-rfc6830bis-01  =
. . . . . . . .  41      B.16. Changes to draft-ietf-lisp-rfc6830bis-02  . . . . . . . .  =
42

      
     B.17. =
Changes to draft-ietf-lisp-rfc6830bis-00  . . . . . . . .  41      B.17. =
Changes to draft-ietf-lisp-rfc6830bis-01  . . . . =
. . . .  42

      
   Authors' =
Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41      B.18. Changes to =
draft-ietf-lisp-rfc6830bis-00  . . . . . . . .  42

      
 =
   Authors' Addresses  . . . . . . . . . . . . =
. . . . . . . . . . .  42

      
 =


      
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

      
   routable =
Routing Locators (RLOCs), used to identify network    routable Routing Locators (RLOCs), used to identify =
network

      
 =


      
skipping to =
change at =
page 13, line 10 =C2=B6 =
skipping to change at page 13, line =
10 =C2=B6

      
   Since IPv4 or =
IPv6 addresses can be either EIDs or RLOCs, the LISP    Since IPv4 or IPv6 addresses can be either EIDs or =
RLOCs, the LISP

      
   architecture =
supports IPv4 EIDs with IPv6 RLOCs (where the inner    architecture supports IPv4 EIDs with IPv6 RLOCs =
(where the inner

      
   header is in =
IPv4 packet format and the outer header is in IPv6    header is in IPv4 packet format and the outer header =
is in IPv6

      
   packet format) =
or IPv6 EIDs with IPv4 RLOCs (where the inner header    packet format) or IPv6 EIDs with IPv4 RLOCs (where =
the inner header

      
   is in IPv6 =
packet format and the outer header is in IPv4 packet    is in IPv6 packet format and the outer header is in =
IPv4 packet

      
   format).  The =
next sub-sections illustrate packet formats for the    format).  The next sub-sections illustrate packet =
formats for the

      
   homogeneous =
case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4    homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but =
all 4

      
   combinations =
MUST be supported.  Additional types of EIDs are defined =
   combinations MUST be supported.  Additional =
types of EIDs are defined

      
   in =
[RFC8060].    in [RFC8060].

      
 =


      

      
 =
   As LISP uses UDP =
encapsulation to carry traffic between xTRs across

      
 =
   the Internet, =
implementors should be aware of the provisions of

      
 =
   [RFC8085], =
especially those given in section 3.1.11 on congestion

      
 =
   control for UDP =
tunneling.

      
 =
                                               =
                          

      
5.1.  LISP =
IPv4-in-IPv4 Header Format 5.1.  LISP =
IPv4-in-IPv4 Header 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

      
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
        =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
     / |Version|  =
IHL  |    DSCP   |ECN|          Total Length         |      / |Version|  IHL  |    DSCP   |ECN|          Total =
Length         |

      
    /  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     /  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
   |   |         =
Identification        |Flags|      Fragment Offset    | =
   |   |         Identification        |Flags|  =
    Fragment Offset    |

      
   |   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
    |   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
   OH  |  Time to =
Live | Protocol =3D 17 |         Header Checksum       | =
   OH  |  Time to Live | Protocol =3D 17 |      =
   Header Checksum       |

      
 =


      
skipping to =
change at =
page 32, line 36 =C2=B6 =
skipping to change at page 32, line =
41 =C2=B6

      
      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.  If any ITR implementations depend or =
assume the remote

      
      ETR is =
gleaning should not do so.  This does not create any       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

      
 =
      are due to moving =
the LISP control-plane messaging and procedures

      
 =
      to =
[I-D.ietf-lisp-rfc6833bis].

      
 =
                                               =
                          

      
19.  IANA =
Considerations 19.  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

      
   Data-Plane =
LISP specification, in accordance with BCP 26 [RFC8126]. =
   Data-Plane LISP specification, in accordance =
with BCP 26 [RFC8126].

      
 =


      
19.1.  LISP UDP =
Port Numbers 19.1.  LISP UDP Port =
Numbers

      
 =


      
   The IANA =
registry has allocated UDP port number 4341 for the LISP =
   The IANA registry has allocated UDP port =
number 4341 for the LISP

      
   Data-Plane.  =
IANA has updated the description for UDP port 4341 as    Data-Plane.  IANA has updated the description for UDP =
port 4341 as

      
 =


      
skipping to =
change at =
page 36, line 26 =C2=B6 =
skipping to change at page 36, line =
37 =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>.

      
 =


      

      
 =
   [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>.

      
 =
                                               =
                          

      
   [RFC8111]  =
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.    [RFC8111]  Fuller, V., Lewis, D., Ermagan, V., Jain, =
A., and A.

      
              =
Smirnov, "Locator/ID Separation Protocol Delegated               Smirnov, "Locator/ID Separation Protocol =
Delegated

      
              =
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, =
              Database Tree (LISP-DDT)", RFC =
8111, DOI 10.17487/RFC8111,

      
              May =
2017, <https://www.rfc-editor.org/info/rfc8111>.               May 2017, =
<https://www.rfc-editor.org/info/rfc8111>.

      
 =


      
   [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>.

      
 =


      
 =


      
skipping to =
change at =
page 38, line 5 =C2=B6 =
skipping to change at page 39, 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-16 B.1. =
 Changes to draft-ietf-lisp-rfc6830bis-17

      
 =


      
 =
   o  Posted late =
August 2018.

      
 =


      
 =
   o  Indicate in the =
"Changes since RFC 6830" section why the document

      
 =
      has been =
shortened in length.

      
 =


      
 =
B.2.  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.2.  Changes to =
draft-ietf-lisp-rfc6830bis-15 B.3.  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.3.  Changes to =
draft-ietf-lisp-rfc6830bis-14 B.4.  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.4.  Changes to =
draft-ietf-lisp-rfc6830bis-13 B.5.  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.5.  Changes to =
draft-ietf-lisp-rfc6830bis-12 B.6.  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.6.  Changes to =
draft-ietf-lisp-rfc6830bis-11 B.7.  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.7.  Changes to =
draft-ietf-lisp-rfc6830bis-10 B.8.  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.8.  Changes to =
draft-ietf-lisp-rfc6830bis-09 B.9.  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.9.  Changes to =
draft-ietf-lisp-rfc6830bis-08 B.10.  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.10.  Changes to =
draft-ietf-lisp-rfc6830bis-07 B.11.  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.11.  Changes to =
draft-ietf-lisp-rfc6830bis-06 B.12.  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 40, line 35 =C2=B6 =
skipping to change at page 41, line =
40 =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.12.  Changes to =
draft-ietf-lisp-rfc6830bis-05 B.13.  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.13.  Changes to =
draft-ietf-lisp-rfc6830bis-04 B.14.  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.14.  Changes to =
draft-ietf-lisp-rfc6830bis-03 B.15.  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.15.  Changes to =
draft-ietf-lisp-rfc6830bis-02 B.16.  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.16.  Changes to =
draft-ietf-lisp-rfc6830bis-01 B.17.  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.17.  Changes to =
draft-ietf-lisp-rfc6830bis-00 B.18.  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. 31 change blocks. 

     
47 lines changed or =
deleted 68 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=_BB69CA2C-1A69-4FDF-BB7E-9DD708634236
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Aug 28, 2018, at 9:49 AM, Dino Farinacci  =
wrote:
>=20
>> I'd suggest inserting a new paragraph after paragraph 2 of section 5, =
something like:
>>=20
>>=20
>> NEW:
>>=20
>> As LISP uses UDP encapsulation to carry traffic between ITRs and ETRs =
across the Internet, implementors should be aware of the provisions of =
[RFC8085], especially those given in section 3.1.11 on congestion =
control for UDP tunneling.
>=20
> Consider it added to Section 5 =E2=80=9CLISP Encapsulation Details=E2=80=
=9D, last paragraph.
>=20
>>=20
>>>>>>>> (2) This is not transport-specific. Reading the document, it =
struck me that the
>>>>>>>> design of the protocol has a few inherently unsafe features =
related to the fact
>>>>>>>> that its wire image is neither confidentiality- nor =
integrity-protected. I
>>>>>>>> think that all of the potential DDoS and traffic focusing =
attacks I could come
>>>>>>>> up with in the hour I spent reviewing the document are indeed =
mentioned in the
>>>>>>>> security considerations section, but as the security =
considerations section
>>>>>>>> does not give any practical mitigation for dataplane overload =
attacks, it seems
>>>>>>>> to be saying that RLOC addresses shouldn't be =
Internet-accessible, which as I
>>>>>>>> understand it is not the point of LISP. I haven't seen a secdir =
review on this
>>>>>>>> document yet, but I'd encourage the authors to do everything it =
asks.
>>>>>>>=20
>>>>>>> RFC 8061 goes along with RFC6830bis. It addresses data-plane =
confidentiality.
>>>>>>=20
>>>>>> I haven=E2=80=99t read 8061 yet, but I probably should before =
continuing this thread.
>>>>>>=20
>>>>>> I will say that I=E2=80=99m far less concerned about LISP header =
confidentiality than I am about LISP header integrity, given the =
opportunities for on-path meddling and off-path spoofing. If the common =
solution to both is something like sticking everything on the ITR-ETR =
path in IPSec then this is less of a concern.
>>>>>=20
>>>>> Well RFC8061 does AEAD on the payload. All data *after* the LISP =
header.
>>>>> The encryption is a more integrated model than IPsec, so we can be =
more efficient by not using extra IP headers and extra control/key =
exchange protocols.
>>>>=20
>>>> Okay, that's all well and good. The LISP header itself isn't =
integrity protected, though?
>>>=20
>>> It is not, unless the outer UDP checksum is used. Which we suggest =
to be 0 and when NATs make it non-zero, ETRs ignore it.
>>=20
>> Ah. Okay, so two things:
>>=20
>> (1) By "integrity protection" I mean "cryptographic integrity =
protection", in the sense of "preventing on-path attackers or off-path =
spoofers from being able to influence ITR/ETR state through crafted LISP =
headers to the detriment of the traffic of others". Looking over 8061, =
it seems to only cover confidentiality of the data-plane payload, which =
is extremely useful but not sufficient to prevent these attacks.
>=20
> Well at this point in the generation of LISP, the only text I think to =
mitigate LISP header corruption is to indicate that a LISP ITR can use =
an outer IPsec header if protection of the UDP and LISP headers need =
protection. Or is that not a strong enough statement?
>=20
>> The attacks seem to be well enumerated in 6830bis, but the lack of a =
stated mitigation beyond "be careful" seems to suggest that the =
mitigation is "don't use LISP", which is of course less than desirable. =
I'm trying to understand whether the deployment scenarios envisioned for =
LISP make these attacks less likely (for instance, because the ITR/ETR =
path itself is generally cryptographically protected with its own outer =
tunnel), or whether this is something that this document (or a future =
companion to 8061) needs to worry about.
>=20
> I think so because of 8061.
>=20
>> (2) Checksums provide what I'd call "corruption protection". On =
"setting the outer UDP checksum to zero", please be aware that this may =
have undesirable interactions with IPv6 headers; see also section 3.4 =
(Checksum Guidelines) of 8085.
>=20
> If we don=E2=80=99t go IPsec route, we go with the checksum route. =
What do you think? Meaning, that if LISP header protection is =
desiriable, use UDP checksums.=20
>=20
>> Thanks, cheers,
>>=20
>> Brian
>=20
> Thanks for the commentary and discussion,
> Dino
>=20
>=20


--Apple-Mail=_BB69CA2C-1A69-4FDF-BB7E-9DD708634236--


From nobody Tue Aug 28 10:28: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 3F656130E15 for ; Tue, 28 Aug 2018 10:28:07 -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=kumari-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 x_kVtqJF3SXZ for ; Tue, 28 Aug 2018 10:28:05 -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 188EB130E07 for ; Tue, 28 Aug 2018 10:28:05 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id n2-v6so2307332wrw.7 for ; Tue, 28 Aug 2018 10:28:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xaLdFpVF9n0eVn1pAJOgQ4tnAnLsBw1xOfDn6oXGn9M=; b=IQl+Btg2BVHw1HsiTGEQDS6IMHa5YNy6dW6e1HOUZAGryBIFXpgN5x236CGpBwVJpb YAV5t7UZii13Jj4XD3s7nBsE0HXRGfAxz7rZ0RB3m82m3PcDNd/cqOfQ4Yti9TlaJn8B wWNa3+xSBwaeF/pv8ZsHkAj2JHHA1yBeE60ANM3yZ8OR/FkT2fkfnVtc8byOb0I3sqS7 V3zh54VpOSr1/WutUe/7k8vEa6PY3vlsbDO4JRMw5eCLpUidWnB6GFGBLxSaW1tOV8sh LIRIHvfgdkpIMuz8uGMWgFwgTqg6lhcaxYLY8otCdpnV7D+XQ1KRy8MBDr8AbTrp5fAb kPyg==
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=xaLdFpVF9n0eVn1pAJOgQ4tnAnLsBw1xOfDn6oXGn9M=; b=kwBeEo5wW6M9bMnDv3L1Ork2VPNNZrm32mkzXFgNFFSZt0ikBPekX8lcMLnXGd1c4I gcmLHwScD4snbIsNfgZigbSiN7l+IFZ1KdCuEWqIYhwRxHWdOiYeOFF4wSyceI16UTCq MBq5BAsU2b/Vuqu+XDaYrDEn61FciHHQmvYQ21g8jT+JMphR2Pui+3W3Ux5oyvGFB/Rm foeuc+z85OFiAl8HsXXRO32DjDaT69Vxp9vL/ZyjmkQF0ypAGCjQQrRotCnHDnqvaFcr DQ9Os5Ew0rzpO/+dyVE/lgSZpq9osK4m/sXYjCsNgC9m9eeccuka1y/fJ51d8G7ATAKJ 4B7Q==
X-Gm-Message-State: APzg51DdlEXgvB/cDtXNcLsyiju53MNbp5pqoo5IV9hb3BGDxu6fxumn BxKTnHD+jr2hSnSfYReYsdzTsIDRx/g+WKkb8BsBcA==
X-Google-Smtp-Source: ANB0Vdb2Q5fgVzjAcayvsvgvi0aMZ0DQBLsh5ovTeuPIgSGnHBEj6BCnfS4ZwbJunrdieroJ+hiUaUP3IbOH4kiO+iI=
X-Received: by 2002:a5d:608b:: with SMTP id w11-v6mr1898880wrt.193.1535477283203;  Tue, 28 Aug 2018 10:28:03 -0700 (PDT)
MIME-Version: 1.0
References: <153546084779.23731.3772960451880909496@ietfa.amsl.com>
In-Reply-To: <153546084779.23731.3772960451880909496@ietfa.amsl.com>
From: Warren Kumari 
Date: Tue, 28 Aug 2018 13:27:27 -0400
Message-ID: 
To: Scott Bradner 
Cc: ops-dir , draft-ietf-lisp-rfc6830bis.all@ietf.org,  IETF Discuss , lisp@ietf.org
Content-Type: multipart/alternative; boundary="00000000000006f1160574822a7c"
Archived-At: 
Subject: Re: [lisp] [OPS-DIR] Opsdir last call review of draft-ietf-lisp-rfc6830bis-16
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: Tue, 28 Aug 2018 17:28:07 -0000

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

On Tue, Aug 28, 2018 at 8:54 AM Scott Bradner  wrote:

> Reviewer: Scott Bradner
> Review result: Ready
>
> I performed an OPS-DIR review of The Locator/ID Separation Protocol (LISP=
)
> (draft-ietf-lisp-rfc6830bis-16) This ID is the result of a bifurcation of
> RFC
> 6830 as such review of the basic technology is OBE. (i.e. RFC 6830 was
> published years ago =E2=80=93 any deep technology review should have been=
 done
> then.)
> The ID does make some changes to the technology described in RFC 6830 but
> the
> changes do not present any operations related issues that I can see.
>
> The version I was asked to review did not have a =E2=80=9CChanges since R=
FC 6830=E2=80=9D
> section (as all RFCs that update or obsolete other RFCs should have) but
> that
> has been fixed so I have no additional issues.
>

Excellent, thank you Scott, and the authors.
W



>
>
> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir
>


--=20
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

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




On Tu=
e, Aug 28, 2018 at 8:54 AM Scott Bradner <sob@sobco.com> wrote:
Rev=
iewer: Scott Bradner

Review result: Ready



I performed an OPS-DIR review of The Locator/ID Separation Protocol (LISP)<=
br>
(draft-ietf-lisp-rfc6830bis-16) This ID is the result of a bifurcation of R=
FC

6830 as such review of the basic technology is OBE. (i.e. RFC 6830 was

published years ago =E2=80=93 any deep technology review should have been d=
one then.)

The ID does make some changes to the technology described in RFC 6830 but t=
he

changes do not present any operations related issues that I can see.



The version I was asked to review did not have a =E2=80=9CChanges since RFC=
 6830=E2=80=9D

section (as all RFCs that update or obsolete other RFCs should have) but th=
at

has been fixed so I have no additional issues.

Excellent, thank you Scott, and the authors.
W

=C2=
=A0





_______________________________________________

OPS-DIR mailing list

OPS-DIR@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/ops-dir




-- 
I don't t=
hink the execution is relevant when it was obviously a bad idea in the firs=
t place.
This is like putting rabid weasels in your pants, and later exp=
ressing regret at having chosen those particular rabid weasels and that pai=
r of pants.
=C2=A0 =C2=A0---maf


--00000000000006f1160574822a7c--


From nobody Tue Aug 28 12:36: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 9ACF0130E05; Tue, 28 Aug 2018 12:36:30 -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 qViMGl4OrcOB; Tue, 28 Aug 2018 12:36:29 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B36712F295; Tue, 28 Aug 2018 12:36:29 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id z12-v6so1063558ybg.9; Tue, 28 Aug 2018 12:36:29 -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=SYRjW+8DiJLPwqzBPyCpSRJ+t1uq01oOXINSHwnvVQg=; b=mfdn4QIXe7nP1L98nCC4NqzghLvrmazfuHy5sXEX0QO6NaWzkB69W0n4d48mMgpkCj w7f56IfTsCX0NGXsmV3TZLCod0QKoq+SxRHSQgdfV9sOrY0VuRPyq5GZaHR6CYB0ApZc aZHlU67mIt7eP20cuIdGnP7QP8g3IW2xhoTIPJyXBqFeCPEWFeCftdtFm+GxWT5lhO8V DTwA/32JHeLfbAQVDRT+7RA7bPk/MVkjtTjZRM38yMoHhDSI5LW4l1QIGOJia9AdIX18 7K+pdv3WWSP1QproZelr9zedjfWDtI3BFqzL3X49aIWMvjh/C9hwKrZXMEz92HSry/Bk d3SQ==
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=SYRjW+8DiJLPwqzBPyCpSRJ+t1uq01oOXINSHwnvVQg=; b=iznQ6c4Dg6l1hgfigvH9DrCFzfAUwKVOK72yxeCWtGxUwoPEhqkNYfH5VAInEee53S nDwJ621EAMTVP+YLFfWjmipnEp/Ud/kKxIWeSAYN+fxcAeVHgosk3B2dnYXEpA4H4bTU MkA6HaD88Kq4EY2Rr26iD63p9Wwa0oAgAgBsqR7wpoFdstZU2+3JACdPb/LLMfsTf0sA DO0BEI1bwi0K0mmoVBQN08KIe+Ycjd+KBcRPkNpMcmKQd8WiR5uutFk2vhleDOnXsTIx /g9G1GchjVz/knOZroi1Yu9IYVaZojGtjYeZ78KSprvk51rwX1+bDP03p1vGnKdAVjoI hN5Q==
X-Gm-Message-State: APzg51AU/XSLFw7pzET5ea6ZorsOOm2Xoh2zSFO80HhMc73A9IP/1SMP m1rD4ur818guIZEWDlzaLwL3dDgQ48DeL682zjU=
X-Google-Smtp-Source: ANB0VdYKvAQed7KGrFWon9BStZzVQAsRLarbdTx0UuWW3tWUCXoZokGFF+D/FafYOSpTJgzmwC1SiwpovQ5wsYPlX3Q=
X-Received: by 2002:a25:c343:: with SMTP id t64-v6mr1678606ybf.399.1535484988276;  Tue, 28 Aug 2018 12:36:28 -0700 (PDT)
MIME-Version: 1.0
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>  <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch> 
In-Reply-To: 
From: Spencer Dawkins at IETF 
Date: Tue, 28 Aug 2018 14:36:17 -0500
Message-ID: 
To: Dino Farinacci 
Cc: Brian Trammell , draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF list , lisp@ietf.org
Content-Type: multipart/alternative; boundary="00000000000048c5b4057483f5de"
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Tue, 28 Aug 2018 19:36:31 -0000

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

Hi, Dino,

On Tue, Aug 28, 2018 at 11:49 AM Dino Farinacci  wrote=
:

> > I'd suggest inserting a new paragraph after paragraph 2 of section 5,
> something like:
> >
> >
> > NEW:
> >
> > As LISP uses UDP encapsulation to carry traffic between ITRs and ETRs
> across the Internet, implementors should be aware of the provisions of
> [RFC8085], especially those given in section 3.1.11 on congestion control
> for UDP tunneling.
>
> Consider it added to Section 5 =E2=80=9CLISP Encapsulation Details=E2=80=
=9D, last
> paragraph.
>

Thanks for that. It's the right thing to do (at least in my ballot
position) :-)

Spencer

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


Hi, Dino,=C2=A0

On Tue, Aug 28, 2018 at 11:49 AM Dino Farinacci <farinacci@gmail.com> wrote:
> I'd suggest inserting a new paragraph af=
ter paragraph 2 of section 5, something like:

> 

> 

> NEW:

> 

> As LISP uses UDP encapsulation to carry traffic between ITRs and ETRs =
across the Internet, implementors should be aware of the provisions of [RFC=
8085], especially those given in section 3.1.11 on congestion control for U=
DP tunneling.



Consider it added to Section 5 =E2=80=9CLISP Encapsulation Details=E2=80=9D=
, last paragraph.

Thanks for that. It&#=
39;s the right thing to do (at least in my ballot position) :-)
<=
br>
Spencer=C2=A0


--00000000000048c5b4057483f5de--


From nobody Tue Aug 28 12:57: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 E471C130E05; Tue, 28 Aug 2018 12:56: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 C2Mg8nBQTVVp; Tue, 28 Aug 2018 12:56: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 8CC0B128CB7; Tue, 28 Aug 2018 12:56:57 -0700 (PDT)
Received: by mail-pf1-x42c.google.com with SMTP id i26-v6so1166311pfo.12; Tue, 28 Aug 2018 12:56: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=0UXSyhRFmsrRsRsNBm/YL0Lceb9vu7Ua4BrH4yY5Sn4=; b=TmiuLC/19oxGdRyh+Iscp0EDU/VSUEO/Oo39hwwaM3D95018TKpczn+K3ovt+15AV2 icF53SIE0xnCimTycW25UUBUzgu4bIQ6lhXOrDBHsxzt9N8ARVgvN4GXc9i35vv0/Ki1 Hs4l5oZiSRj57ahJU3IGt0YhMbMxkjY6SfwO/OEU9FI18q35SiD5CO4cnhUA9JUlR9xy 9UcP5Dk/bG3Y8DyBiTsRgiL1RF0MaxLGb1gQj91fHmLoTSKPsD8veirWVvUPyA2SRmwu 5drVqOakQ+wdYI+V34QEE4jx1bea/SOljrUqTjMamAzh84JK1I5PmWSiojIaNFKTwUyL lp5Q==
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=0UXSyhRFmsrRsRsNBm/YL0Lceb9vu7Ua4BrH4yY5Sn4=; b=NZNkaRBThWZ1w2EWHhwcp/1i+YQ+yFt1u8TRUClYyR2+qk8CbGjhIO3jcptUeBho3D CD2ZOV913kkH6IsPHKPbK/KBq017ToGL5MCO1jbp+wguy2H0NauWJBegEJuMxfHqRVEZ 7pdI13WX16jpKQKJZ5YbMWFMfYBQa7lFHcg7hD/XZz+U3/42MjgzCrEd5++pEm3z0a+z bkxWijqqBHuibVRivxXCX9paQvdhD5GlYTFtd9NMOwO5e68gFkxhyAMW/PoS6akCcO46 ZKpqVb+ptvodFBq2WmjBpNrVtxeyoaL+aF+B9CXL+hfq06lzsy5C4/9fuenUKbRZLyXL I9hg==
X-Gm-Message-State: APzg51BXsHeBYvgySpLt1JbS550O/3qgSMojfLjU3Srm6xhfAu9Qo861 M2/l4bTZXFneCDPBPwJvXewtIv6k
X-Google-Smtp-Source: ANB0VdYRySbMWnM/hioAS+PcimGPI5UP1Ou9bs9x2uxBTZkmMhMYYEUz81Vgqq0Zu/J4J9Wxo+qQfg==
X-Received: by 2002:a65:4384:: with SMTP id m4-v6mr2807558pgp.265.1535486217110;  Tue, 28 Aug 2018 12:56:57 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id i65-v6sm8692550pfk.43.2018.08.28.12.56.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Aug 2018 12:56: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: 
Date: Tue, 28 Aug 2018 12:56:54 -0700
Cc: Brian Trammell , draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF list , lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9D85AE36-0CF7-44E2-8978-AD59930A087D@gmail.com>
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>  <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>  
To: Spencer Dawkins at IETF 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Tue, 28 Aug 2018 19:56:59 -0000

> Thanks for that. It's the right thing to do (at least in my ballot =
position) :-)

Ack Spencer. Thanks.

Dino


From nobody Tue Aug 28 14:48: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 5CAE9130F52 for ; Tue, 28 Aug 2018 14:48: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, 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 Xygw07g0yDg9 for ; Tue, 28 Aug 2018 14:48:12 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A94130E1A for ; Tue, 28 Aug 2018 14:48:09 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id g44-v6so3513754qtb.12 for ; Tue, 28 Aug 2018 14:48:09 -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=1ktxUKMDVPAexMzciEohT5brlZpaBfxgrn7Gmtz+AaA=; b=eqK8bHOM7oVY5Z4kiWh8e9PQki0yoLGUk/RoIZPx7x7fyL4DBlwUbBFbHTY8NIuA9q e5sYa9XEqg3tRkDDokbkr4BdGT0x+Eh5gfyos8PcmTth+xnkgUi8StvwGpiOnKDKG2+z 5MWyskjTp3AUm2TnyN/sjGanGm2Jq/bnSfwiE=
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=1ktxUKMDVPAexMzciEohT5brlZpaBfxgrn7Gmtz+AaA=; b=qGifeN+qhIP3opKVAHZgVTqDix1wJa55pHbWY5Q6VXxl8IWc3Y6cPRl0txLiuc4xC5 U1qQv5VeuDPlJWJZ/VHiZHO/ZAR++CbItwUo0KZfWPXaCI0XiWrD86e4chnDxuMPKQkC APtW6HqHMjst8jDMIiEq9D09FSvpck4ycM9Z6yTRZEwAjy3Y/ZhAMhJeKTGXMFIUqeZQ NLdigdhFTOX8ry6CHWDEeGQVFtL5nWVQaM9m2nH0VcVKk+h3798hbKoA1H6Sm+bO7UNj 8syJSbBb12s2BeKEUJDcueG4+W3NBql7YlfiR9Sje9TT/XrKBISYwGuMBG0WUVKlLXkT +81g==
X-Gm-Message-State: APzg51D591Uzta22iCjcMFwhcvt92XHvnq0HJVNUSdytGP+urLzQN8b+ cyCwlSqkt14XYVOrCvCb5GaPVwHJRqDfMf/tXM+BpA==
X-Google-Smtp-Source: ANB0VdZg0eYHlhw7q1ugeGxn/qULEdPeI5kCy40iVKfw9WTIo83anNtP8ECcoUZehuIAYT3BfTCpdb+8p8yDbQXD/iE=
X-Received: by 2002:ac8:2759:: with SMTP id h25-v6mr3856537qth.274.1535492888227;  Tue, 28 Aug 2018 14:48:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a0c:f803:0:0:0:0:0 with HTTP; Tue, 28 Aug 2018 14:48:06 -0700 (PDT)
X-Originating-IP: [72.246.0.14]
In-Reply-To: 
References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> 
From: Kyle Rose 
Date: Tue, 28 Aug 2018 17:48:06 -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="000000000000288208057485cc67"
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.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: Tue, 28 Aug 2018 21:48:19 -0000

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

Hi, Dino. I have additional responses inline.

> For the internet core (DFZ RIB) use-case, LISP proposes replacing BGP
> sessions
> > and global eventually-consistent state sharing with a global control
> plane and
>
> LISP *does not propse to eliminate BGP*, in fact it needs it so RLOC
> reachability across the network is available, or there would be no underl=
ay
> for the LISP overlay.
>

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. From the perspective of end users, BGP is being
replaced routing of the traffic that matters to them.

Maybe this is just splitting hairs: I certainly don't want to rathole on
this point.


> You are missing pieces of the design and hence why you came to the
> conclusion you did. There are three documents that enhance the security o=
f
> LISP, they are:
>
> (1) RFC 8061 - Locator/ID Separation Protocol (LISP) Data-Plane
> Confidentiality
>

I did not review this document because I was following up on authentication
of control plane messages. If that is covered in a document titled
"Data-Plane Confidentiality", some reorganization may be in order.


> (2) RFC 8111 - Locator/ID Separation Protocol Delegated Database Tree
> (LISP-DDT)
>
(3) draft-farinacci-lisp-ecdsa-auth
>

I take it from the name that this has not even been adopted by the WG yet?
Evaluating something I'm supposed to review for IETF LC should not depend
on an unadopted draft.

That said, I have been trying to make sense of this document for the past
few days. I have a few basic observations:

 * 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")

 * 128 bits is already too short for a cryptographic hash, and this
document proposes reducing that to 80 bits for a /48.

 * The entire scheme relies on the integrity of the Hash-EID mappings: if
an attacker can compromise a Hash-EID mapping with a different public key
that hashes to the same truncated hash, they can sign anything for that
space of Crypto-EIDs.

 * The only protection provided by this scheme is for Map-Register and
Map-Request, and not for the response to Map-Request, which (to me) is the
critical gap. The problem I noted in my original review is that the ITR-OTK
only allows the Map-Server to prove that a response is associated with a
Map-Resolver's request, not that the Map-Server is the proper authority for
the response. What the system needs is a global trust network that does not
rely on either universal transitive trust (e.g., I'll just trust whatever
my trusted-but-potentially-mistaken neighbors tell me about the rest of the
world based on what they heard) or n^2 relationships (e.g., symmetric keys
with every other entity).

 * Why a scheme like this for addressing Map-Register? Presumably an ETR
will either be owned by the same entity running the Map-Server
authoritative for its own EID space, or it will contract with one. Either
case is a single, pre-established relationship per ETR, which scales fine.

 * What is the use case for Map-Request authentication? Its only use seems
to be to keep address space -> network topology mapping hidden. From whom?
The end user doesn't need to know, but every entity in the core needs to
have access to a Crypto-EID's associated RLOC or it won't be able to
determine the next hop.

 * My general recommendation for design documents is that the overall
architecture should be clear to a reader with a relevant technical
background without having to first consume a pile of other documents. To
the authentication point specifically, you may wish to include some text
regarding the properties generically offered by an asymmetric
authentication scheme with the appropriate feature set, and reference those
properties in the security considerations section when addressing certain
classes of attacks. You can then use these requirements as input to a
document describing a specific authentication scheme.

 * This document doesn't present a clear description of the problem it's
trying to solve in the introduction. I understand what it's getting at now
that I've read the whole thing, but a better introduction (for the actual
problem you need to solve, I'd add) would say something like, q( The LISP
architecture introduces two address spaces along with a mapping from one to
the other. The integrity of this mapping is critical for achieving the
intended routing of traffic through a LISP network, being directly related
to service availability and end user privacy. This document describes a
mechanism for implementation of strong authentication of this mapping. )
The security considerations should then discuss the
turtles-all-the-way-down problem of BGP hijacking on the underlay (should
BGP be employed for this purpose) so operators are clear on the limitations
of the scheme.


> You find strong asymmetric authenticaiton and authorization in (3). And
> you=E2=80=99ll find authentication of the mapping system nodes in (2). An=
d note
> that (1) can be used and layered under the control-plane to give encrypte=
d
> control-plane flows (or use DTLS as LISP-SEC refers to for the messages i=
t
> requires for its functionality).
>

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

https://tools.ietf.org/html/draft-ietf-lisp-sec-15#ref-I-
D.ietf-lisp-rfc6833bis

> One area of concern, of which I have not been able to find discussion, is
> that
> > of the implications of shared capacity for the control and data planes,
> and how
> > this can allow a volumetric data plane attack to deny a router access t=
o
> the
> > global mapping system, slowly choking off service to uncached portions
> of the
>
> Well yes, this happens with all our IETF protocols. It is a valid concern
> and there are many operational techniques in network infrastructure that
> *help* solve (but not eliminate) these problems.
>

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.

> I would also like clarification on what defines the separation between th=
e
> > control plane and data plane, and whether authentication itself is used
> to
>
> A control-plane obtains information to store in a table. The data-plane
> uses that table. That is the definition in the simpliest form.
>

I mean specific to LISP, not generically. For instance, does "LISP
Control-Plane signaling" include only valid messages, or valid +
inauthentic (and presumably dropped) messages? Traditional attack traffic
(e.g., a DDoS attack against a website) is part of the same data plane as
all legitimate end user traffic; is attack traffic directed at control
plane endpoints considered part of the control plane, or is it a third
category of traffic? If the latter, then what does an operator need to do
to ensure that control plane is always available?

Kyle

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


Hi, Dino. I have additional responses inline.

> For the internet core (DFZ RIB) use-case, =
LISP proposes replacing BGP sessions

> and global eventually-consistent state sharing with a global control p=
lane and



LISP *does not propse to eliminate BGP*, in fact it needs it so RLOC=
 reachability across the network is available, or there would be no underla=
y for the LISP overlay.

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 contro=
l 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, tha=
t is of small comfort to end users trying to get data over the data plane. =
>From the perspective of end users, BGP is being replaced routing of the tra=
ffic that matters to them.

Maybe this is just =
splitting hairs: I certainly don't want to rathole on this point.
=C2=A0

You are missing pieces =
of the design and hence why you came to the conclusion you did. There are t=
hree documents that enhance the security of LISP, they are:



(1) RFC 8061 - Locator/ID Separation Protocol (LISP) Data-Plane Confidentia=
lity

I did not review this document bec=
ause I was following up on authentication of control plane messages. If tha=
t is covered in a document titled "Data-Plane Confidentiality", s=
ome reorganization may be in order.
=C2=A0
(2) RFC 8111 - Locator/ID Separation P=
rotocol Delegated Database Tree (LISP-DDT)

(3) draft-farinacci-lisp-ecdsa-auth

I take it from the name that this has not even been adopted by the WG yet=
? Evaluating something I'm supposed to review for IETF LC should not de=
pend on an unadopted draft.

That said, I have =
been trying to make sense of this document for the past few days. I have a =
few basic observations:

=C2=A0* It does not resolv=
e the trust anchor problem. Instead of proposing a PKI, you seem to be prop=
osing a trusted third party authoritative for the Hash-EID namespace.  (Q.v=
. section 2, the Hash-EID definition: "Another entity")
=


=C2=A0* 128 bits is already too short for a crypto=
graphic hash, and this document proposes reducing that to 80 bits for a /48=
.

=C2=A0* The entire scheme relies on th=
e integrity of the Hash-EID mappings: if an attacker can compromise a Hash-=
EID mapping with a different public key that hashes to the same truncated h=
ash, they can sign anything for that space of Crypto-EIDs.

=
=C2=A0* The only protection provided by this scheme is for Map-Register and=
 Map-Request, and not for the response to Map-Request, which (to me) is the=
 critical gap. The problem I noted in my original review is that the ITR-OT=
K only allows the Map-Server to prove that a response is associated with a =
Map-Resolver's request, not that the Map-Server is the proper authority=
 for the response. What the system needs is a global trust network that doe=
s not rely on either universal transitive trust (e.g., I'll just trust =
whatever my trusted-but-potentially-mistaken neighbors tell me about the re=
st of the world based on what they heard) or n^2 relationships (e.g., symme=
tric keys with every other entity).

=C2=A0* Wh=
y a scheme like this for addressing Map-Register? Presumably an ETR will ei=
ther be owned by the same entity running the Map-Server authoritative for i=
ts own EID space, or it will contract with one. Either case is a single, pr=
e-established relationship per ETR, which scales fine.

=

=C2=A0* What is the use case for Map-Request authentication? Its only =
use seems to be to keep address space -> network topology mapping hidden=
. From whom? The end user doesn't need to know, but every entity in the=
 core needs to have access to a Crypto-EID's associated RLOC or it won&=
#39;t be able to determine the next hop.

=C2=A0* My gener=
al recommendation for design documents is that the overall architecture sho=
uld be clear to a reader with a relevant technical background without havin=
g to first consume a pile of other documents. To the authentication point s=
pecifically, you may wish to include some text regarding the properties gen=
erically offered by an asymmetric authentication scheme with the appropriat=
e feature set, and reference those properties in the security consideration=
s section when addressing certain classes of attacks. You can then use thes=
e requirements as input to a document describing a specific authentication =
scheme.

=C2=A0* This document doesn't present =
a clear description of the problem it's trying to solve in the introduc=
tion. I understand what it's getting at now that I've read the whol=
e thing, but a better introduction (for the actual problem you need to solv=
e, I'd add) would say something like, q( The LISP architecture introduc=
es two address spaces along with a mapping from one to the other. The integ=
rity of this mapping is critical for achieving the intended routing of traf=
fic through a LISP network, being directly related to service availability =
and end user privacy. This document describes a mechanism for implementatio=
n of strong authentication of this mapping. ) The security considerations s=
hould then discuss the turtles-all-the-way-down problem of BGP hijacking on=
 the underlay (should BGP be employed for this purpose) so operators are cl=
ear on the limitations of the scheme.
=C2=A0


You find strong asymmetric authenticaiton and authorization in (3). And you=
=E2=80=99ll find authentication of the mapping system nodes in (2). And not=
e that (1) can be used and layered under the control-plane to give encrypte=
d control-plane flows (or use DTLS as LISP-SEC refers to for the messages i=
t requires for its functionality).

&quo=
t;TLS" does not appear anywhere in the draft of LISP-SEC I reviewed:



> One area of concern, of which I have not been able to find discussion,=
 is that

> of the implications of shared capacity for the control and data planes=
, and how

> this can allow a volumetric data plane attack to deny a router access =
to the

> global mapping system, slowly choking off service to uncached portions=
 of the



Well yes, this happens with all our IETF protocols. It is a valid co=
ncern and there are many operational techniques in network infrastructure t=
hat *help* solve (but not eliminate) these problems.

> I would also like clarifi=
cation on what defines the separation between the

> control plane and data plane, and whether authentication itself is use=
d to



A control-plane obtains information to store in a table. The data-pl=
ane uses that table. That is the definition in the simpliest form.

I mean specific to LISP, not generically. For i=
nstance, does "LISP Control-Plane signaling" include only valid m=
essages, or valid + inauthentic (and presumably dropped) messages? Traditio=
nal attack traffic (e.g., a DDoS attack against a website) is part of the s=
ame data plane as all legitimate end user traffic; is attack traffic direct=
ed at control plane endpoints considered part of the control plane, or is i=
t a third category of traffic? If the latter, then what does an operator ne=
ed to do to ensure that control plane is always available?

Kyle


--000000000000288208057485cc67--


From nobody Tue Aug 28 15:17: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 A6B06130F44; Tue, 28 Aug 2018 15:17:27 -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 sR_LY2Pebtpr; Tue, 28 Aug 2018 15:17:25 -0700 (PDT)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002: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 ECC2F130F3F; Tue, 28 Aug 2018 15:17:24 -0700 (PDT)
Received: by mail-yb0-x230.google.com with SMTP id y20-v6so1236162ybi.13; Tue, 28 Aug 2018 15:17:24 -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=8THKUzmqW2Ga/t2drBHwFkg4pdleGIcMQ8DAlLABx2U=; b=WC2+PFEybR6VVcvYrqKybp0l7T21PdagR+4rsFfXzPchlZpScHGUyBgFWQjP/NMUia 48HqKMzPEatoUuXSeNOL6gZdXyzAXVhK7beRB8KQD2LLc5rFrLFymQKAA7cgdH67sFy0 iyqamR8pJYuaVCuPuL0bZFuVyJCRD2mzDTnI6PzweUrT/2ZwWvzHzw16WlPYNfD/a5rv X0LjIzkQ1/zSPTPezc8gSrcDMBZv5d2drl2oFFHSevXIuEcUo8PBrlritpq6FV4irXZ+ 8WBUJQQJ+Sh//117zxcip+NCz5DioDlYOCpzk5+pmo69PlHEWPfOmTdnsbXZwcGwlVZI f6lA==
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=8THKUzmqW2Ga/t2drBHwFkg4pdleGIcMQ8DAlLABx2U=; b=TPUyX/hrA4H8ntvLICxtGo6fA/ZDXYdW3lnroYTibnz3q6pzUWw2jhr6wCkaAFPKf3 eNn8TawoiM+437QeajIZ+Vsj+9F2yU7v/92YyVjB0QoRkDKNzvAUKdYpb0A8eSNOzbyb JvW+3Mx0RbAweu11GK39aWiwrUl2rGe4edFGF6vri2qd5+c41EhP5AdE6+lGZDKRzLwg JPVY6ZxTUhVLEpPbODwlVmn1yaE5nC/TF/Ht318pvOs9KbM6Y76izEonnLeBafEJMaoq U7Ze8iHFShVR/AWdo6lqUvIi3bpQGAHQTrcAaXW4JTfB6cIp2+EFOtcBOoPK+J1F6+lK nUTQ==
X-Gm-Message-State: APzg51BTLYi2sBoJ3UKlixtf7PGLkuHjvpG0xunGYa1jha+d8mXoi9lP AO5Qk9OwolPNrtU3bHYTO/Y=
X-Google-Smtp-Source: ANB0Vda1585GEHGj+k6V5nKFtECJC503LP316dZNco0mdM4YxMtuPpGsCsjCD8zmX9ohvxY9bWmE+Q==
X-Received: by 2002:a5b:e:: with SMTP id a14-v6mr2000764ybp.246.1535494643981;  Tue, 28 Aug 2018 15:17:23 -0700 (PDT)
Received: from dino-macbook.attlocal.net (adsl-108-94-3-30.dsl.pltn13.sbcglobal.net. [108.94.3.30]) by smtp.gmail.com with ESMTPSA id e124-v6sm823659ywh.66.2018.08.28.15.17.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Aug 2018 15:17:23 -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, 28 Aug 2018 15:17:21 -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: 
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.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: Tue, 28 Aug 2018 22:17:28 -0000

> Hi, Dino. I have additional responses inline.
>=20
> > For the internet core (DFZ RIB) use-case, LISP proposes replacing =
BGP sessions
> > and global eventually-consistent state sharing with a global control =
plane and
>=20
> LISP *does not propse to eliminate BGP*, in fact it needs it so RLOC =
reachability across the network is available, or there would be no =
underlay for the LISP overlay.
>=20
> 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.

> That said, I have been trying to make sense of this document for the =
past few days. I have a few basic observations:
>=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)

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

>  * 128 bits is already too short for a cryptographic hash, and this =
document proposes reducing that to 80 bits for a /48.

It can go as high as 120 bits. The eid-hash-prefix is configurable on a =
per LISP instance-ID basis.

>  * The entire scheme relies on the integrity of the Hash-EID mappings: =
if an attacker can compromise a Hash-EID mapping with a different public =
key that hashes to the same truncated hash, they can sign anything for =
that space of Crypto-EIDs.

A shared-key is also used to accept mapping system registrations. And =
the signature-EID can be accompanied with additional data to make the =
hash =E2=80=9Cmore unqiue=E2=80=9D. That is, the hash is only used as a =
mapping system lookup key (i.e. a compressed public-key).

>  * The only protection provided by this scheme is for Map-Register and =
Map-Request, and not for the response to Map-Request, which (to me) is =
the critical gap. The problem I noted in my original review is=20

We discussed this in Montreal and we have updates pending so map-servers =
have signature-IDs that can sign responses. It=E2=80=99s on our document =
todo list.

> that the ITR-OTK only allows the Map-Server to prove that a response =
is associated with a Map-Resolver's request, not that the Map-Server is =
the proper authority for the response. What the system needs is a global =
trust network that does not rely on either universal transitive trust =
(e.g., I'll just trust whatever my trusted-but-potentially-mistaken =
neighbors tell me about the rest of the world based on what they heard) =
or n^2 relationships (e.g., symmetric keys with every other entity).

There is no reason why a separate mapping system can be deployed just =
for this purpose. But I could be misunderstanding you.

>  * Why a scheme like this for addressing Map-Register? Presumably an =
ETR will either be owned by the=20

You are conflating two drafts and now I am not sure which one you are =
referring to. In terms of security, there are 3 documents that cover =
LISP security, let=E2=80=99s call then RFC 8061 (data-plane =
confidentiality and authenticstion via AEAD), LISP-SEC (that uses the =
OTK so Map-Reply messages are authenticated), and lisp-ecdsa-auth (which =
is used to authenticate control-plane messages from xTR to mapping =
system).

> same entity running the Map-Server authoritative for its own EID =
space, or it will contract with one. Either case is a single, =
pre-established relationship per ETR, which scales fine.

The xTR is run by an entity different than the mapping system entity. =
And its EID allocation comes from a completely different entity. Once an =
EID is allocated, then the xTR entity shops for mapping system providers =
(MSPs) and the MSP decides based on the bit pattern of the address which =
map-servers the xTR registers to for the EIDs owned by the xTR (the LISP =
site). At that time, a shared-key is agreed upon (out of band and at =
provisioning time), to authorized the EID to be registered within an =
instance-ID to those set of map-servers the MSP has chosen.

And with respect to lisp-ecdsa-auth, a key-pair is generated, the =
private key held by the xTR, the public-key sent out of band to the MSP, =
the MSP registering the hash->pubkey mapping in its infrastrucutre so it =
can verify control-plane message signatures.

>=20
>  * What is the use case for Map-Request authentication? Its only use =
seems to be to keep address space -> network topology mapping hidden. =
=46rom whom? The end user doesn't need to know, but every entity in the =
core needs to have access to a Crypto-EID's associated RLOC or it won't =
be able to determine the next hop.

It allows only specific entities to lookup EIDs with an instance-ID. The =
core knows nothing about any of this. All this machinery is done part of =
the LISP overlay.

>  * My general recommendation for design documents is that the overall =
architecture should be clear to a reader with a relevant technical =
background without having to first consume a pile of other documents. To =
the authentication point specifically, you may wish to include some text =
regarding the properties generically offered by an asymmetric =
authentication scheme with the appropriate feature set, and reference =
those properties in the security considerations section when addressing =
certain classes of attacks. You can then use these requirements as input =
to a document describing a specific authentication scheme.

Right agree. But this has evolved and improved over a 10 year period.

>  * This document doesn't present a clear description of the problem =
it's trying to solve in the introduction. I understand what it's getting =
at now that I've read the whole thing, but a better=20

There is an LISP introduction document we decided to write 5 years ago =
that was intended to introduce the idea of LISP and overlays. That =
document is stuck in MISREF. We are trying to unstuck it by publishing =
these documents.

The working group decided that RFC6830bis and RFC6833bis would be =
technical and background material be put in other documents. We have =
deployment and interworking documents as well.

> introduction (for the actual problem you need to solve, I'd add) would =
say something like, q( The LISP architecture introduces two address =
spaces along with a mapping from one to the other. The integrity of this =
mapping is critical for achieving the intended routing of traffic =
through a LISP network, being=20

This is stated in the introduction section.

> directly related to service availability and end user privacy. This =
document describes a mechanism for implementation of strong =
authentication of this mapping. ) The security considerations should =
then=20

This is a data-plane spec. The control-plane spec (RFC6833bis) explains =
more about authentication of mappings.

> discuss the turtles-all-the-way-down problem of BGP hijacking on the =
underlay (should BGP be employed for this purpose) so operators are =
clear on the limitations of the scheme.

This is out of scope.

> You find strong asymmetric authenticaiton and authorization in (3). =
And you=E2=80=99ll find authentication of the mapping system nodes in =
(2). And note that (1) can be used and layered under the control-plane =
to give encrypted control-plane flows (or use DTLS as LISP-SEC refers to =
for the messages it requires for its functionality).
>=20
> "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed:

Right as I explained DTLS does. And TLS is part of an expired Internet =
Draft.

> =
https://tools.ietf.org/html/draft-ietf-lisp-sec-15#ref-I-D.ietf-lisp-rfc68=
33bis
>=20
> > One area of concern, of which I have not been able to find =
discussion, is that
> > of the implications of shared capacity for the control and data =
planes, and how
> > this can allow a volumetric data plane attack to deny a router =
access to the
> > global mapping system, slowly choking off service to uncached =
portions of the
>=20
> Well yes, this happens with all our IETF protocols. It is a valid =
concern and there are many operational techniques in network =
infrastructure that *help* solve (but not eliminate) these problems.
>=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.

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 would also like clarification on what defines the separation =
between the
> > control plane and data plane, and whether authentication itself is =
used to
>=20
> A control-plane obtains information to store in a table. The =
data-plane uses that table. That is the definition in the simpliest =
form.
>=20
> I mean specific to LISP, not generically. For instance, does "LISP =
Control-Plane signaling" include only valid messages, or valid + =
inauthentic (and presumably dropped) messages? Traditional attack =
traffic (e.g., a DDoS attack against a website) is part of the same data =
plane as all legitimate end user traffic; is attack traffic directed at =
control plane endpoints considered part of the control plane, or is it a =
third category of traffic? If the latter, then what does an operator =
need to do to ensure that control plane is always available?

All in RFC6833bis. I=E2=80=99m sorry LISP is spread across so many =
documents but we tried to divide and conquer to create a modular way of =
introducing the entire design.

Dino

>=20
> Kyle


From nobody Wed Aug 29 02:17:25 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 ACB94130E4F; Wed, 29 Aug 2018 02:17:09 -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.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153553422964.14784.628403975182959075@ietfa.amsl.com>
Date: Wed, 29 Aug 2018 02:17:09 -0700
Archived-At: 
Subject: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05
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: Wed, 29 Aug 2018 09:17:22 -0000

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.



From nobody Wed Aug 29 02:36: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 251AA130E4F; Wed, 29 Aug 2018 02:36:42 -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] 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 6RfqqTN_c1_V; Wed, 29 Aug 2018 02:36:40 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDDC6130E44; Wed, 29 Aug 2018 02:36:39 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F37D2340211; Wed, 29 Aug 2018 11:36:34 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.16720);  Wed, 29 Aug 2018 11:36:34 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 29 Aug 2018 11:36:34 +0200 (CEST)
Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 65598371; Wed, 29 Aug 2018 11:36:34 +0200
From: "Brian Trammell (IETF)" 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_5A7B1021-7CB0-43A5-BFDD-3F90F24D5161"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 29 Aug 2018 11:36:33 +0200
In-Reply-To: 
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" 
To: Dino Farinacci 
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>  <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch> 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Wed, 29 Aug 2018 09:36:42 -0000

--Apple-Mail=_5A7B1021-7CB0-43A5-BFDD-3F90F24D5161
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

hi Dino,

> On 28 Aug 2018, at 18:49, Dino Farinacci  wrote:
>=20
>> I'd suggest inserting a new paragraph after paragraph 2 of section 5, =
something like:
>>=20
>>=20
>> NEW:
>>=20
>> As LISP uses UDP encapsulation to carry traffic between ITRs and ETRs =
across the Internet, implementors should be aware of the provisions of =
[RFC8085], especially those given in section 3.1.11 on congestion =
control for UDP tunneling.
>=20
> Consider it added to Section 5 =E2=80=9CLISP Encapsulation Details=E2=80=
=9D, last paragraph.

Looks good, thanks!

>> Ah. Okay, so two things:
>>=20
>> (1) By "integrity protection" I mean "cryptographic integrity =
protection", in the sense of "preventing on-path attackers or off-path =
spoofers from being able to influence ITR/ETR state through crafted LISP =
headers to the detriment of the traffic of others". Looking over 8061, =
it seems to only cover confidentiality of the data-plane payload, which =
is extremely useful but not sufficient to prevent these attacks.
>=20
> Well at this point in the generation of LISP, the only text I think to =
mitigate LISP header corruption is to indicate that a LISP ITR can use =
an outer IPsec header if protection of the UDP and LISP headers need =
protection. Or is that not a strong enough statement?

We're talking past each other here, I think.

There are, as I see it, two completely separate problems here:

(1) The document permits/recommends zero UDP checksum on IPv6 outer =
packets. This leaves the IPv6 header unprotected against inadvertent =
corruption. To prevent this, LISP should follow the guidelines in =
section 3.4.1 of 8085, specifically:

      Use of the UDP checksum with IPv6 MUST be the default
      configuration for all implementations [RFC6935].  The receiving
      endpoint MUST only allow the use of UDP zero-checksum mode for
      IPv6 on a UDP destination port that is specifically enabled.

and

      A UDP application MUST check that the source and destination IPv6
      addresses are valid for any packets with a UDP zero-checksum and
      MUST discard any packet for which this check fails.  To protect
      from misdelivery, new encapsulation designs SHOULD include an
      integrity check at the transport layer that includes at least the
      IPv6 header, the UDP header and the shim header for the
      encapsulation, if any [RFC6936].

See also Magnus' tsvart review on lisp-gpe; his issue A is basically the =
same problem.

None of this, however, defends against the second problem:

(2) Any on-path attacker, or any off-path attacker who knows the =
addresses of the xTRs, can guess the current state of mappings, and can =
spoof packets from one of them, can send packets with valid LISP headers =
(and, indeed, valid checksums if they so choose) which will change xTR =
state in ways which can lead to denial of service conditions. A =
cryptographic integrity check over the LISP header would prevent the =
on-path attacks. I *think* the nonce echo functionality can be used to =
prevent off path attacks, or at least allows an endpoint that suspects =
it is under attack to challenge

Indeed, the security considerations section (and 7835 on which it is =
based) acknowledges most of this, and it seems that work is ongoing to =
fix this (draft-ietf-lisp-sec-15), so I guess you can simply take my =
comment on the second problem as encouragement to get lisp-sec done =
(subject, of course, to the warnings in =
draft-trammell-optional-security-not).

Cheers,

Brian

>> The attacks seem to be well enumerated in 6830bis, but the lack of a =
stated mitigation beyond "be careful" seems to suggest that the =
mitigation is "don't use LISP", which is of course less than desirable. =
I'm trying to understand whether the deployment scenarios envisioned for =
LISP make these attacks less likely (for instance, because the ITR/ETR =
path itself is generally cryptographically protected with its own outer =
tunnel), or whether this is something that this document (or a future =
companion to 8061) needs to worry about.
>=20
> I think so because of 8061.
>=20
>> (2) Checksums provide what I'd call "corruption protection". On =
"setting the outer UDP checksum to zero", please be aware that this may =
have undesirable interactions with IPv6 headers; see also section 3.4 =
(Checksum Guidelines) of 8085.
>=20
> If we don=E2=80=99t go IPsec route, we go with the checksum route. =
What do you think? Meaning, that if LISP header protection is =
desiriable, use UDP checksums.
>=20
>> Thanks, cheers,
>>=20
>> Brian
>=20
> Thanks for the commentary and discussion,
> Dino


--Apple-Mail=_5A7B1021-7CB0-43A5-BFDD-3F90F24D5161
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAluGaSEACgkQihK3vwvq
RqPmxBAAqJdEDX5aVeMsSrhuMnu8IcrUL1jy8n8IEVfRalD4ZlZZPOFUB7O+UAsk
WL0uSIYIeXQ02K2e3SDfIiaEOmKGwwspgjKKdX4Fns2e2pgBNROPMB92PG/OyHGh
XNex+J20UTxKRn889GFlSYBCVmkr20JELLnJn08eN65hZw4arEhCFTKSSCEb7vxX
W2QIFXb8SKZGCokdfmkw9aOhSRyF1wR/ZVaECluu0Eq5grVrIr6jrmXJct4iyEDM
gzJYc/nXAAotLSq37dJBqZ0rsCyNo9q2l9ko2PPawssO15DoslmrTvaKMRdl+LVY
tSo/86VL8Uw03+/CUSOdfKRExtAlVrbstoESHwaga3jHWtOScH2z2sYFc2m/w6Fk
gqbF3lT0bpC0CcVcgz61HxRdlExIHe266YrRKc4xFxgyvXmTxk0hi2G2xNlQitrZ
or2+tvgI8R+ZlfyzvSUodJ1BhlrAGVR599vR5oaJwvz2YyBC8+0SY5PmoRiFm95d
HgPK0frEBCUqeuVbPS61WR/viWsMuduDC51/RvbCnQuwGwISwDhdh27cxdkf4JKH
OdkRrxvTbNCBQg6Kh6ke0jxt7niwmrr8XXiGDNA4KKWxSjmn3QbgdZtdyywc8+Jy
mQCWih9xlaR8HDis+BYMxS9BHvm6tHIJIoWUfL+z+TLaJy0fGfI=
=lixN
-----END PGP SIGNATURE-----

--Apple-Mail=_5A7B1021-7CB0-43A5-BFDD-3F90F24D5161--


From nobody Wed Aug 29 10:17: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 5D5D7130E71; Wed, 29 Aug 2018 10:17: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 5O8eIRSsSJF3; Wed, 29 Aug 2018 10:17:03 -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 82F80124C04; Wed, 29 Aug 2018 10:17:03 -0700 (PDT)
Received: by mail-pf1-x442.google.com with SMTP id k19-v6so2583073pfi.1; Wed, 29 Aug 2018 10:17:03 -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=57dVu+CxkSbgJrPpGVY1VPcxSDkxtyl08TmRaxzniVY=; b=Q5yo2RFcQZ/9TGmgeARXs7edq7u3HxnWUeBc2Do2issk36BlhjVd5uQyLgamxxc8MS CNSxjwAhiQQHox2KluYOE9tQaCGyQYKDb3/QUAt0C2bcYoF0KOZ4iKcdLhMWWfI5ai4t wb6tlBOHXmU/H5CRhU7VzAANTxzCgblt+X3nTIiQdkVcms+Lq9HoyAwhb3t+efvF6wl6 ldvpjT7wLP8nZ+/AmVLoc0avRe70hpwFIjPDgUvHJ1KVzhpLMx2UwpW2EP2ZKZ5q9Pkn 1R9M/dCpKaPPZuS7USaF3uRH4XJ4/6CoNwM8AP8eM78GZogKOlYo6G3yUDKUltfcvAQY KvAQ==
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=57dVu+CxkSbgJrPpGVY1VPcxSDkxtyl08TmRaxzniVY=; b=ARNGfYdmcPswV2FTugH9VXMWGRa/jjO4CvRUDJhyC32Bm+uXzfvRGijYzPx7CcjfQV QhLe90D9KBhStCXi/1E9+YJ7159s+iNthlFCg3yLrMHdSlz4fhyqdwbDG/XIJ2xp4dsx DMI89LVkHI2YZVoSVm3+/NYiIDFV8+Gc2IbqcZhoeb+trA7XmGgSTNOt3kXnQChxS7j4 mbi/xt2jChd/Zcy+lAHUUxTC+dkdj2dignXb1nsAgICzuYkYjVWfdxDxzgkhwICdi+tW jwxJxwy8h8aHfw5jzj8g2+tP7Iv4livLPMjOeEpy2H1CzFG89dnYCT7piZp0T6ZfY9vf rFPA==
X-Gm-Message-State: APzg51CGJdZm8G9Ck1zEW6EeXSPap4jcd+qSS+kODfhX1TaU1g7dSH6n BwcdMWXgPnf9WL70plZZyuI9bwua
X-Google-Smtp-Source: ANB0VdZDnO8AkqTo45IB4bdRLcH4RxlWtMnlF2f/+3t6MA/aQiJpy89eyEGNwFQIi7U1c+x2pYEGqw==
X-Received: by 2002:a63:41c1:: with SMTP id o184-v6mr6560330pga.297.1535563023156;  Wed, 29 Aug 2018 10:17:03 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id d22-v6sm16684049pfm.48.2018.08.29.10.17.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Aug 2018 10:17:02 -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, 29 Aug 2018 10:17:01 -0700
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@gmail.com>
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>  <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>  
To: "Brian Trammell (IETF)" 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Wed, 29 Aug 2018 17:17:05 -0000

> We're talking past each other here, I think.
>=20
> There are, as I see it, two completely separate problems here:
>=20
> (1) The document permits/recommends zero UDP checksum on IPv6 outer =
packets. This leaves the IPv6 header unprotected against inadvertent =
corruption. To prevent this, LISP should follow the guidelines in =
section 3.4.1 of 8085, specifically:
>=20
>      Use of the UDP checksum with IPv6 MUST be the default
>      configuration for all implementations [RFC6935].  The receiving
>      endpoint MUST only allow the use of UDP zero-checksum mode for
>      IPv6 on a UDP destination port that is specifically enabled.
>=20
> and
>=20
>      A UDP application MUST check that the source and destination IPv6
>      addresses are valid for any packets with a UDP zero-checksum and
>      MUST discard any packet for which this check fails.  To protect
>      from misdelivery, new encapsulation designs SHOULD include an
>      integrity check at the transport layer that includes at least the
>      IPv6 header, the UDP header and the shim header for the
>      encapsulation, if any [RFC6936].
>=20
> See also Magnus' tsvart review on lisp-gpe; his issue A is basically =
the same problem.

This issue has come up at least once or twice every 2 years. We suggest =
a zero checksum no matter what the  outer header is because we wanted to =
be practical with respect to what implementations do. No matter what the =
IETF says, the industry has moved forward and not only do not check =
checksums for UDP based tunnels but if they wanted to they can=E2=80=99t =
because many hardware does not have the entire packet buffer in the =
forwarding engine that does header processing.

So I would not want to change our text at this point. We are very aware =
this is controversial but it is emotionally packed as well. UDP packets =
in all probability will not be missed forward because layer-2 chips do a =
very good job at CRC. So if its bit errors one worries about, that is =
very rare. If it is packet corruption due to MITM, that is another =
story.

We can make a reference to 8085 with respect to checksums but we have to =
craft the text carefully because I really don=E2=80=99t want to release =
a spec that doesn=E2=80=99t reflect reality. So if you can help us craft =
a couple sentences, we can consider putting it in.

>=20
> None of this, however, defends against the second problem:
>=20
> (2) Any on-path attacker, or any off-path attacker who knows the =
addresses of the xTRs, can guess the current state of mappings, and can =
spoof packets from one of them, can send packets with valid LISP=20

They cannot if the inner header is encrypted. The EIDs will be =
obfuscated. All that is known is that one location is sending to another =
location and not who is sending to who.

> headers (and, indeed, valid checksums if they so choose) which will =
change xTR state in ways which can lead to denial of service conditions. =
A cryptographic integrity check over the LISP header would prevent the =
on-path attacks. I *think* the nonce echo functionality can be used to =
prevent off path attacks, or at least allows an endpoint that suspects =
it is under attack to challenge

For this context, the key-id field in the LISP header is the only =
precious entity. All other bits could be  MITM attacked and the ETR =
could verify if the settings are real or not (at some expense). If the =
key-id field is changed, then the ETR will get decryption or ICV errors =
and drop packets. Yes, I know that is a DoS.

To resolve this, I=E2=80=99d be willing to refer to 8085 and use =
checksum when users believe they need to protect the UDP and LISP =
headers.

What do you think?

> Indeed, the security considerations section (and 7835 on which it is =
based) acknowledges most of this, and it seems that work is ongoing to =
fix this (draft-ietf-lisp-sec-15), so I guess you can simply take my =
comment on the second problem as encouragement to get lisp-sec done =
(subject, of course, to the warnings in =
draft-trammell-optional-security-not).
>=20
> Cheers,

What do you think of my suggestion?

Dino



From nobody Wed Aug 29 11:18: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 7930F130DFE; Wed, 29 Aug 2018 11:18:25 -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 ej59Om9CEUTn; Wed, 29 Aug 2018 11:18:22 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 21321126DBF; Wed, 29 Aug 2018 11:18:22 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id u11-v6so2655651plq.5; Wed, 29 Aug 2018 11:18: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=2NGpxpOp5WZrDKoSDiuImy6twicVlXsvY8A3TFZMXA4=; b=cJ3wSZMcKUkOAxZatBO5vCK7Je/ctvUsiOupr82nvMEB/395zTXgI0d4BhiUgoVfyp 4zkxIH2DdrZhPDgoyBSUEcG4x3Sq9CQcatjU/LUWLXzloGAYZjVDkINPb+rZxild1li9 6uMEE6mUD3k2PyMGEBqeq7uP6OJsOKXqcTKJJx+eyTCYRZxUUKCJBSbyFkTzrO8apdhd PWDLRZ/jT3C5eYUdafun9cmaaFJBKYZWRGoI331UWVW9RZhz51f7N3H+kQtQWgiZ3OPk 797mdfOYmnOX5ZrUcC+2HnfEwfDz6S4JAwief1fxB7U9UJzCUehhk4u8f8gWo7jy6B4l I9uQ==
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=2NGpxpOp5WZrDKoSDiuImy6twicVlXsvY8A3TFZMXA4=; b=o8oy6P89gEh5VP2tnbHj50k3sbnzZq3Ed4++UCWWVe81RYraukZTpO+LH0AixfOzjW HFjIdLEMP0SDgiF8aagyJSjUIwkolkunfsaRsNr6zpVnGWNSVDbBvk3fJvDD6ahcIuJJ wDy2zPwWMMpbU4+F2xuBXyonzAUgM+7MpUY5t8wn86JUk94UjNr4oYf43OwuuQtyPcS2 O3q1MUurY1qVlSLUJxBy0ql9yLVtUZ71zaJ49SWFsifmxRrs+I2kLn1Fj83bC5yQSdGe 3yPMp8fG3gpoERmS8y2TGqXRcSxfR6NufG04PofW+Anu3IbOrgniHsBCOLNcmnhKzT+3 k/bg==
X-Gm-Message-State: APzg51CuChpWYdlQuicYu0MEouN4eoKIwD6VgMTOMjNbiZCtxWJwrr7I 9zOdUMxhAQ3HYouPSuImeZXLS/2G
X-Google-Smtp-Source: ANB0Vdazwuw5oZFrI7tGO/q58RZ+dEqV4I3l7Trp39iVZLpC+bmbYtZ+7bhNfvY8d4i0E+KrwoiKVw==
X-Received: by 2002:a17:902:bd86:: with SMTP id q6-v6mr190065pls.35.1535566701781;  Wed, 29 Aug 2018 11:18:21 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id k8-v6sm7955925pga.80.2018.08.29.11.18.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Aug 2018 11:18:21 -0700 (PDT)
From: Dino Farinacci 
Message-Id: 
Content-Type: multipart/mixed; boundary="Apple-Mail=_2025227A-6896-4A2E-B811-562029EC52AB"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 29 Aug 2018 11:18:19 -0700
In-Reply-To: <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@gmail.com>
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" 
To: "Brian Trammell (IETF)" 
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>  <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>   <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Wed, 29 Aug 2018 18:18:25 -0000

--Apple-Mail=_2025227A-6896-4A2E-B811-562029EC52AB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Brian, see the second reference to RFC 8085 in the diff file below. Let =
me know if this could satisfy your comment. Thanks.

Dino


--Apple-Mail=_2025227A-6896-4A2E-B811-562029EC52AB
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-rfc6830bis-16.txt - =
draft-ietf-lisp-rfc6830bis-17.txt=20
  =20
     =20
=20
=20
  =20
  =20
      
< draft-ietf-lisp-rfc6830bis-16.txt  =
 draft-ietf-lisp-rfc6830bis-17.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: February 28, 2019                                =
 Cisco Systems Expires: March 2, 2019                                    =
 Cisco Systems

      
                  =
                                     A. Cabellos (Ed.)                                                        =
A. Cabellos (Ed.)

      
                  =
                                     UPC/BarcelonaTech                                                        =
UPC/BarcelonaTech

      

      
                =
                                         August 27, 2018       =
                                                   August 29, 2018

      
 =


      
               =
The Locator/ID Separation Protocol (LISP)                The Locator/ID Separation Protocol =
(LISP)

      

      
                =
     draft-ietf-lisp-rfc6830bis-16 =
                     =
draft-ietf-lisp-rfc6830bis-17

      
 =


      
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 February 28, =
2019.    This Internet-Draft will =
expire on March 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 29 =C2=B6 =
skipping to change at page 2, line 29 =C2=B6

      
 =


      
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  . . . . . . . . . . . . . . . . . . . . . . .   8 =
   4.  Basic Overview  . . . . . . . . . . . . =
. . . . . . . . . . .   8

      
     4.1.  Packet =
Flow Sequence  . . . . . . . . . . . . . . . . . .  10      4.1.  Packet Flow Sequence  . . . . . . . . . . . . =
. . . . . .  10

      
   5.  LISP =
Encapsulation Details  . . . . . . . . . . . . . . . . .  12 =
   5.  LISP Encapsulation Details  . . . . . . =
. . . . . . . . . . .  12

      
     5.1.  LISP =
IPv4-in-IPv4 Header Format . . . . . . . . . . . . .  13 =
     5.1.  LISP IPv4-in-IPv4 Header Format . . =
. . . . . . . . . . .  13

      

      
     5.2.  LISP =
IPv6-in-IPv6 Header Format . . . . . . . . . . . . .  13      5.2.  =
LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . .  14

      
     5.3.  Tunnel =
Header Field Descriptions  . . . . . . . . . . . .  15      5.3.  Tunnel Header Field Descriptions  . . . . . . =
. . . . . .  15

      

      
   6.  LISP =
EID-to-RLOC Map-Cache  . . . . . . . . . . . . . . . . .  19    6.  =
LISP EID-to-RLOC Map-Cache  . . . . . . . . . . . . . . . . .  20

      
   7.  Dealing =
with Large Encapsulated Packets . . . . . . . . . . .  19    7.  =
Dealing with Large Encapsulated Packets . . . . . . . . . . .  20

      
     7.1.  A =
Stateless Solution to MTU Handling  . . . . . . . . . .  20      7.1.  =
A Stateless Solution to MTU Handling  . . . . . . . . . .  21

      
     7.2.  A =
Stateful Solution to MTU Handling . . . . . . . . . . .  21      7.2.  =
A Stateful Solution to MTU Handling . . . . . . . . . . .  22

      
   8.  Using =
Virtualization and Segmentation with LISP . . . . . . .  21    8.  =
Using Virtualization and Segmentation with LISP . . . . . . .  22

      
   9.  Routing =
Locator Selection . . . . . . . . . . . . . . . . . .  22    9.  =
Routing Locator Selection . . . . . . . . . . . . . . . . . .  23

      
   10. Routing =
Locator Reachability  . . . . . . . . . . . . . . . .  24    10. =
Routing Locator Reachability  . . . . . . . . . . . . . . . .  25

      
     10.1.  =
Echo Nonce Algorithm . . . . . . . . . . . . . . . . . .  25      10.1. =
 Echo Nonce Algorithm . . . . . . . . . . . . . . . . . .  26

      
   11. EID =
Reachability within a LISP Site . . . . . . . . . . . . .  26    11. EID =
Reachability within a LISP Site . . . . . . . . . . . . .  27

      
   12. Routing =
Locator Hashing . . . . . . . . . . . . . . . . . . .  27    12. =
Routing Locator Hashing . . . . . . . . . . . . . . . . . . .  28

      
   13. Changing =
the Contents of EID-to-RLOC Mappings . . . . . . . .  28    13. =
Changing the Contents of EID-to-RLOC Mappings . . . . . . . .  29

      
     13.1.  =
Database Map-Versioning  . . . . . . . . . . . . . . . .  29      13.1. =
 Database Map-Versioning  . . . . . . . . . . . . . . . .  30

      
   14. =
Multicast Considerations  . . . . . . . . . . . . . . . . . .  29    14. =
Multicast Considerations  . . . . . . . . . . . . . . . . . .  30

      
   15. Router =
Performance Considerations . . . . . . . . . . . . . .  30    15. =
Router Performance Considerations . . . . . . . . . . . . . .  31

      
   16. Security =
Considerations . . . . . . . . . . . . . . . . . . .  31    16. =
Security Considerations . . . . . . . . . . . . . . . . . . .  32

      
   17. Network =
Management Considerations . . . . . . . . . . . . . .  32    17. =
Network Management Considerations . . . . . . . . . . . . . .  33

      
   18. Changes =
since RFC 6830  . . . . . . . . . . . . . . . . . . .  32    18. =
Changes since RFC 6830  . . . . . . . . . . . . . . . . . . .  33

      
   19. IANA =
Considerations . . . . . . . . . . . . . . . . . . . . .  32    19. =
IANA Considerations . . . . . . . . . . . . . . . . . . . . .  33

      
     19.1.  =
LISP UDP Port Numbers  . . . . . . . . . . . . . . . . .  32      19.1. =
 LISP UDP Port Numbers  . . . . . . . . . . . . . . . . .  33

      
   20. =
References  . . . . . . . . . . . . . . . . . . . . . . . . .  33    20. =
References  . . . . . . . . . . . . . . . . . . . . . . . . .  34

      
     20.1.  =
Normative References . . . . . . . . . . . . . . . . . .  33      20.1. =
 Normative References . . . . . . . . . . . . . . . . . .  34

      
     20.2.  =
Informative References . . . . . . . . . . . . . . . . .  33      20.2. =
 Informative References . . . . . . . . . . . . . . . . .  34

      
 =


      

      
   Appendix A.  =
Acknowledgments  . . . . . . . . . . . . . . . . . .  37    =
Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  39

      
   Appendix B.  =
Document Change Log  . . . . . . . . . . . . . . . .  37    =
Appendix B.  Document Change Log  . . . . . . . . . . . . . . . .  39

      
     B.1.  =
Changes to draft-ietf-lisp-rfc6830bis-16  =
. . . . . . . .  38      B.1.  Changes to draft-ietf-lisp-rfc6830bis-17  . . . . . . . .  =
40

      
     B.2.  =
Changes to draft-ietf-lisp-rfc6830bis-15  =
. . . . . . . .  38      B.2.  Changes to draft-ietf-lisp-rfc6830bis-16  . . . . . . . .  =
40

      
     B.3.  =
Changes to draft-ietf-lisp-rfc6830bis-14  =
. . . . . . . .  38      B.3.  Changes to draft-ietf-lisp-rfc6830bis-15  . . . . . . . .  =
40

      
     B.4.  =
Changes to draft-ietf-lisp-rfc6830bis-13  =
. . . . . . . .  38      B.4.  Changes to draft-ietf-lisp-rfc6830bis-14  . . . . . . . .  =
40

      
     B.5.  =
Changes to draft-ietf-lisp-rfc6830bis-12  =
. . . . . . . .  38      B.5.  Changes to draft-ietf-lisp-rfc6830bis-13  . . . . . . . .  =
40

      
     B.6.  =
Changes to draft-ietf-lisp-rfc6830bis-11  =
. . . . . . . .  38      B.6.  Changes to draft-ietf-lisp-rfc6830bis-12  . . . . . . . .  =
40

      
     B.7.  =
Changes to draft-ietf-lisp-rfc6830bis-10  =
. . . . . . . .  39      B.7.  Changes to draft-ietf-lisp-rfc6830bis-11  . . . . . . . .  =
41

      
     B.8.  =
Changes to draft-ietf-lisp-rfc6830bis-09  =
. . . . . . . .  39      B.8.  Changes to draft-ietf-lisp-rfc6830bis-10  . . . . . . . .  =
41

      
     B.9.  =
Changes to draft-ietf-lisp-rfc6830bis-08  =
. . . . . . . .  39      B.9.  Changes to draft-ietf-lisp-rfc6830bis-09  . . . . . . . .  =
41

      
     B.10. =
Changes to draft-ietf-lisp-rfc6830bis-07  =
. . . . . . . .  40      B.10. Changes to draft-ietf-lisp-rfc6830bis-08  . . . . . . . .  =
41

      
     B.11. =
Changes to draft-ietf-lisp-rfc6830bis-06  =
. . . . . . . .  40      B.11. Changes to draft-ietf-lisp-rfc6830bis-07  . . . . . . . .  =
42

      
     B.12. =
Changes to draft-ietf-lisp-rfc6830bis-05  =
. . . . . . . .  40      B.12. Changes to draft-ietf-lisp-rfc6830bis-06  . . . . . . . .  =
42

      
     B.13. =
Changes to draft-ietf-lisp-rfc6830bis-04  =
. . . . . . . .  40      B.13. Changes to draft-ietf-lisp-rfc6830bis-05  . . . . . . . .  =
42

      
     B.14. =
Changes to draft-ietf-lisp-rfc6830bis-03  =
. . . . . . . .  41      B.14. Changes to draft-ietf-lisp-rfc6830bis-04  . . . . . . . .  =
42

      
     B.15. =
Changes to draft-ietf-lisp-rfc6830bis-02  =
. . . . . . . .  41      B.15. Changes to draft-ietf-lisp-rfc6830bis-03  . . . . . . . .  =
43

      
     B.16. =
Changes to draft-ietf-lisp-rfc6830bis-01  =
. . . . . . . .  41      B.16. Changes to draft-ietf-lisp-rfc6830bis-02  . . . . . . . .  =
43

      
     B.17. =
Changes to draft-ietf-lisp-rfc6830bis-00  . . . . . . . .  41      B.17. =
Changes to draft-ietf-lisp-rfc6830bis-01  . . . . =
. . . .  43

      
   Authors' =
Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41      B.18. Changes to =
draft-ietf-lisp-rfc6830bis-00  . . . . . . . .  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

      
   routable =
Routing Locators (RLOCs), used to identify network    routable Routing Locators (RLOCs), used to identify =
network

      
 =


      
skipping to =
change at =
page 13, line 10 =C2=B6 =
skipping to change at page 13, line =
10 =C2=B6

      
   Since IPv4 or =
IPv6 addresses can be either EIDs or RLOCs, the LISP    Since IPv4 or IPv6 addresses can be either EIDs or =
RLOCs, the LISP

      
   architecture =
supports IPv4 EIDs with IPv6 RLOCs (where the inner    architecture supports IPv4 EIDs with IPv6 RLOCs =
(where the inner

      
   header is in =
IPv4 packet format and the outer header is in IPv6    header is in IPv4 packet format and the outer header =
is in IPv6

      
   packet format) =
or IPv6 EIDs with IPv4 RLOCs (where the inner header    packet format) or IPv6 EIDs with IPv4 RLOCs (where =
the inner header

      
   is in IPv6 =
packet format and the outer header is in IPv4 packet    is in IPv6 packet format and the outer header is in =
IPv4 packet

      
   format).  The =
next sub-sections illustrate packet formats for the    format).  The next sub-sections illustrate packet =
formats for the

      
   homogeneous =
case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4    homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but =
all 4

      
   combinations =
MUST be supported.  Additional types of EIDs are defined =
   combinations MUST be supported.  Additional =
types of EIDs are defined

      
   in =
[RFC8060].    in [RFC8060].

      
 =


      

      
5.1.  LISP IPv4-in-IPv4 =
Header Format    As LISP uses UDP =
encapsulation to carry traffic between xTRs across

      
 =
   the Internet, =
implementors should be aware of the provisions of

      
 =
   [RFC8085], =
especially those given in section 3.1.11 on congestion

      
 =
   control for UDP =
tunneling.

      
 =


      
 =
   When the UDP and =
LISP headers require integrity protection, the

      
 =
   methods of using UDP =
checksums in [RFC8085] can be considered.

      
 =


      

      
 =
5.1.  LISP IPv4-in-IPv4 =
Header 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

      
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
        =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
     / |Version|  =
IHL  |    DSCP   |ECN|          Total Length         |      / |Version|  IHL  |    DSCP   |ECN|          Total =
Length         |

      
    /  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     /  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
   |   |         =
Identification        |Flags|      Fragment Offset    | =
   |   |         Identification        |Flags|  =
    Fragment Offset    |

      
   |   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
    |   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
   OH  |  Time to =
Live | Protocol =3D 17 |         Header Checksum       | =
   OH  |  Time to Live | Protocol =3D 17 |      =
   Header Checksum       |

      
   |   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
    |   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
   |   |          =
          Source Routing Locator                     |    |   |                    Source Routing Locator       =
              |

      
 =


      
skipping to =
change at =
page 32, line 36 =C2=B6 =
skipping to change at page 33, line =
36 =C2=B6

      
      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.  If any ITR implementations depend or =
assume the remote

      
      ETR is =
gleaning should not do so.  This does not create any       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

      
 =
      are due to moving =
the LISP control-plane messaging and procedures

      
 =
      to =
[I-D.ietf-lisp-rfc6833bis].

      
 =
                                               =
                          

      
19.  IANA =
Considerations 19.  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

      
   Data-Plane =
LISP specification, in accordance with BCP 26 [RFC8126]. =
   Data-Plane LISP specification, in accordance =
with BCP 26 [RFC8126].

      
 =


      
19.1.  LISP UDP =
Port Numbers 19.1.  LISP UDP Port =
Numbers

      
 =


      
   The IANA =
registry has allocated UDP port number 4341 for the LISP =
   The IANA registry has allocated UDP port =
number 4341 for the LISP

      
   Data-Plane.  =
IANA has updated the description for UDP port 4341 as    Data-Plane.  IANA has updated the description for UDP =
port 4341 as

      
 =


      
skipping to =
change at =
page 36, line 26 =C2=B6 =
skipping to change at page 37, line =
32 =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>.

      
 =


      

      
 =
   [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>.

      
 =
                                               =
                          

      
   [RFC8111]  =
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.    [RFC8111]  Fuller, V., Lewis, D., Ermagan, V., Jain, =
A., and A.

      
              =
Smirnov, "Locator/ID Separation Protocol Delegated               Smirnov, "Locator/ID Separation Protocol =
Delegated

      
              =
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, =
              Database Tree (LISP-DDT)", RFC =
8111, DOI 10.17487/RFC8111,

      
              May =
2017, <https://www.rfc-editor.org/info/rfc8111>.               May 2017, =
<https://www.rfc-editor.org/info/rfc8111>.

      
 =


      
   [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>.

      
 =


      
 =


      
skipping to =
change at =
page 38, 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-16 B.1. =
 Changes to draft-ietf-lisp-rfc6830bis-17

      
 =


      
 =
   o  Posted late =
August 2018.

      
 =


      
 =
   o  Indicate in the =
"Changes since RFC 6830" section why the document

      
 =
      has been =
shortened in length.

      
 =


      
 =
   o  Make reference to =
RFC 8085 about UDP congestion control.

      
 =


      
 =
B.2.  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.2.  Changes to =
draft-ietf-lisp-rfc6830bis-15 B.3.  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.3.  Changes to =
draft-ietf-lisp-rfc6830bis-14 B.4.  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.4.  Changes to =
draft-ietf-lisp-rfc6830bis-13 B.5.  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.5.  Changes to =
draft-ietf-lisp-rfc6830bis-12 B.6.  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.6.  Changes to =
draft-ietf-lisp-rfc6830bis-11 B.7.  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.7.  Changes to =
draft-ietf-lisp-rfc6830bis-10 B.8.  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.8.  Changes to =
draft-ietf-lisp-rfc6830bis-09 B.9.  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.9.  Changes to =
draft-ietf-lisp-rfc6830bis-08 B.10.  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.10.  Changes to =
draft-ietf-lisp-rfc6830bis-07 B.11.  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.11.  Changes to =
draft-ietf-lisp-rfc6830bis-06 B.12.  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 40, line 35 =C2=B6 =
skipping to change at page 42, line =
40 =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.12.  Changes to =
draft-ietf-lisp-rfc6830bis-05 B.13.  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.13.  Changes to =
draft-ietf-lisp-rfc6830bis-04 B.14.  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.14.  Changes to =
draft-ietf-lisp-rfc6830bis-03 B.15.  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.15.  Changes to =
draft-ietf-lisp-rfc6830bis-02 B.16.  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.16.  Changes to =
draft-ietf-lisp-rfc6830bis-01 B.17.  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.17.  Changes to =
draft-ietf-lisp-rfc6830bis-00 B.18.  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. 28 change blocks. 

     
65 lines changed or =
deleted 90 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=_2025227A-6896-4A2E-B811-562029EC52AB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Aug 29, 2018, at 10:17 AM, Dino Farinacci  =
wrote:
>=20
>> We're talking past each other here, I think.
>>=20
>> There are, as I see it, two completely separate problems here:
>>=20
>> (1) The document permits/recommends zero UDP checksum on IPv6 outer =
packets. This leaves the IPv6 header unprotected against inadvertent =
corruption. To prevent this, LISP should follow the guidelines in =
section 3.4.1 of 8085, specifically:
>>=20
>>     Use of the UDP checksum with IPv6 MUST be the default
>>     configuration for all implementations [RFC6935].  The receiving
>>     endpoint MUST only allow the use of UDP zero-checksum mode for
>>     IPv6 on a UDP destination port that is specifically enabled.
>>=20
>> and
>>=20
>>     A UDP application MUST check that the source and destination IPv6
>>     addresses are valid for any packets with a UDP zero-checksum and
>>     MUST discard any packet for which this check fails.  To protect
>>     from misdelivery, new encapsulation designs SHOULD include an
>>     integrity check at the transport layer that includes at least the
>>     IPv6 header, the UDP header and the shim header for the
>>     encapsulation, if any [RFC6936].
>>=20
>> See also Magnus' tsvart review on lisp-gpe; his issue A is basically =
the same problem.
>=20
> This issue has come up at least once or twice every 2 years. We =
suggest a zero checksum no matter what the  outer header is because we =
wanted to be practical with respect to what implementations do. No =
matter what the IETF says, the industry has moved forward and not only =
do not check checksums for UDP based tunnels but if they wanted to they =
can=E2=80=99t because many hardware does not have the entire packet =
buffer in the forwarding engine that does header processing.
>=20
> So I would not want to change our text at this point. We are very =
aware this is controversial but it is emotionally packed as well. UDP =
packets in all probability will not be missed forward because layer-2 =
chips do a very good job at CRC. So if its bit errors one worries about, =
that is very rare. If it is packet corruption due to MITM, that is =
another story.
>=20
> We can make a reference to 8085 with respect to checksums but we have =
to craft the text carefully because I really don=E2=80=99t want to =
release a spec that doesn=E2=80=99t reflect reality. So if you can help =
us craft a couple sentences, we can consider putting it in.
>=20
>>=20
>> None of this, however, defends against the second problem:
>>=20
>> (2) Any on-path attacker, or any off-path attacker who knows the =
addresses of the xTRs, can guess the current state of mappings, and can =
spoof packets from one of them, can send packets with valid LISP=20
>=20
> They cannot if the inner header is encrypted. The EIDs will be =
obfuscated. All that is known is that one location is sending to another =
location and not who is sending to who.
>=20
>> headers (and, indeed, valid checksums if they so choose) which will =
change xTR state in ways which can lead to denial of service conditions. =
A cryptographic integrity check over the LISP header would prevent the =
on-path attacks. I *think* the nonce echo functionality can be used to =
prevent off path attacks, or at least allows an endpoint that suspects =
it is under attack to challenge
>=20
> For this context, the key-id field in the LISP header is the only =
precious entity. All other bits could be  MITM attacked and the ETR =
could verify if the settings are real or not (at some expense). If the =
key-id field is changed, then the ETR will get decryption or ICV errors =
and drop packets. Yes, I know that is a DoS.
>=20
> To resolve this, I=E2=80=99d be willing to refer to 8085 and use =
checksum when users believe they need to protect the UDP and LISP =
headers.
>=20
> What do you think?
>=20
>> Indeed, the security considerations section (and 7835 on which it is =
based) acknowledges most of this, and it seems that work is ongoing to =
fix this (draft-ietf-lisp-sec-15), so I guess you can simply take my =
comment on the second problem as encouragement to get lisp-sec done =
(subject, of course, to the warnings in =
draft-trammell-optional-security-not).
>>=20
>> Cheers,
>=20
> What do you think of my suggestion?
>=20
> Dino
>=20
>=20


--Apple-Mail=_2025227A-6896-4A2E-B811-562029EC52AB--


From nobody Thu Aug 30 02:45:54 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 39E07130F03; Thu, 30 Aug 2018 02:45:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Takeshi Takahashi 
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: <153562234417.3222.6616411492523634729@ietfa.amsl.com>
Date: Thu, 30 Aug 2018 02:45:44 -0700
Archived-At: 
Subject: [lisp] Secdir last call review of draft-ietf-lisp-rfc6833bis-12
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: Thu, 30 Aug 2018 09:45:44 -0000

Reviewer: Takeshi Takahashi
Review result: Ready

This bis document obsoletes RFC 6833.
Some of the content in RFC 6830 (The Locator/ID Separation Protocol (LISP)) was
added to this bis document.

Though the security consideration section remains almost unchanged, I believe
it is ok. Note that the security consideration section refers to RFC 7835,
which shows the threats of LISP, and it covers the threats of RFC6830 as well.



From nobody Thu Aug 30 02:57: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 59DA4130DC1; Thu, 30 Aug 2018 02:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 563_gdfLI93z; Thu, 30 Aug 2018 02:57:34 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B731277C8; Thu, 30 Aug 2018 02:57:33 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id CBBB1340FBB; Thu, 30 Aug 2018 11:57:29 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.31875);  Thu, 30 Aug 2018 11:57:29 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 30 Aug 2018 11:57:29 +0200 (CEST)
Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 65718244; Thu, 30 Aug 2018 11:57:29 +0200
From: "Brian Trammell (IETF)" 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_EB589D8F-24BF-4303-B865-101E27C9A1D1"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 30 Aug 2018 11:57:28 +0200
In-Reply-To: 
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" 
To: Dino Farinacci 
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>  <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>   <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@gmail.com> 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Thu, 30 Aug 2018 09:57:36 -0000

--Apple-Mail=_EB589D8F-24BF-4303-B865-101E27C9A1D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

hi Dino,

Almost. How about:


OLD:

When the UDP and LISP headers require integrity protection, the
methods of using UDP checksums in [RFC8085] can be considered.

NEW:

Implementors are encouraged to consider UDP checksum usage guidelines in =
section 3.4 of [RFC8085]. Specifically, when the UDP, LISP, and outer =
IPv6 headers require protection against corruption, the use of non-zero =
UDP checksums is RECOMMENDED.


Thanks, cheers,

Brian

> On 29 Aug 2018, at 20:18, Dino Farinacci  wrote:
>=20
> Brian, see the second reference to RFC 8085 in the diff file below. =
Let me know if this could satisfy your comment. Thanks.
>=20
> Dino
>=20
> 
>=20
>> On Aug 29, 2018, at 10:17 AM, Dino Farinacci  =
wrote:
>>=20
>>> We're talking past each other here, I think.
>>>=20
>>> There are, as I see it, two completely separate problems here:
>>>=20
>>> (1) The document permits/recommends zero UDP checksum on IPv6 outer =
packets. This leaves the IPv6 header unprotected against inadvertent =
corruption. To prevent this, LISP should follow the guidelines in =
section 3.4.1 of 8085, specifically:
>>>=20
>>>    Use of the UDP checksum with IPv6 MUST be the default
>>>    configuration for all implementations [RFC6935].  The receiving
>>>    endpoint MUST only allow the use of UDP zero-checksum mode for
>>>    IPv6 on a UDP destination port that is specifically enabled.
>>>=20
>>> and
>>>=20
>>>    A UDP application MUST check that the source and destination IPv6
>>>    addresses are valid for any packets with a UDP zero-checksum and
>>>    MUST discard any packet for which this check fails.  To protect
>>>    from misdelivery, new encapsulation designs SHOULD include an
>>>    integrity check at the transport layer that includes at least the
>>>    IPv6 header, the UDP header and the shim header for the
>>>    encapsulation, if any [RFC6936].
>>>=20
>>> See also Magnus' tsvart review on lisp-gpe; his issue A is basically =
the same problem.
>>=20
>> This issue has come up at least once or twice every 2 years. We =
suggest a zero checksum no matter what the  outer header is because we =
wanted to be practical with respect to what implementations do. No =
matter what the IETF says, the industry has moved forward and not only =
do not check checksums for UDP based tunnels but if they wanted to they =
can=E2=80=99t because many hardware does not have the entire packet =
buffer in the forwarding engine that does header processing.
>>=20
>> So I would not want to change our text at this point. We are very =
aware this is controversial but it is emotionally packed as well. UDP =
packets in all probability will not be missed forward because layer-2 =
chips do a very good job at CRC. So if its bit errors one worries about, =
that is very rare. If it is packet corruption due to MITM, that is =
another story.
>>=20
>> We can make a reference to 8085 with respect to checksums but we have =
to craft the text carefully because I really don=E2=80=99t want to =
release a spec that doesn=E2=80=99t reflect reality. So if you can help =
us craft a couple sentences, we can consider putting it in.
>>=20
>>>=20
>>> None of this, however, defends against the second problem:
>>>=20
>>> (2) Any on-path attacker, or any off-path attacker who knows the =
addresses of the xTRs, can guess the current state of mappings, and can =
spoof packets from one of them, can send packets with valid LISP
>>=20
>> They cannot if the inner header is encrypted. The EIDs will be =
obfuscated. All that is known is that one location is sending to another =
location and not who is sending to who.
>>=20
>>> headers (and, indeed, valid checksums if they so choose) which will =
change xTR state in ways which can lead to denial of service conditions. =
A cryptographic integrity check over the LISP header would prevent the =
on-path attacks. I *think* the nonce echo functionality can be used to =
prevent off path attacks, or at least allows an endpoint that suspects =
it is under attack to challenge
>>=20
>> For this context, the key-id field in the LISP header is the only =
precious entity. All other bits could be  MITM attacked and the ETR =
could verify if the settings are real or not (at some expense). If the =
key-id field is changed, then the ETR will get decryption or ICV errors =
and drop packets. Yes, I know that is a DoS.
>>=20
>> To resolve this, I=E2=80=99d be willing to refer to 8085 and use =
checksum when users believe they need to protect the UDP and LISP =
headers.
>>=20
>> What do you think?
>>=20
>>> Indeed, the security considerations section (and 7835 on which it is =
based) acknowledges most of this, and it seems that work is ongoing to =
fix this (draft-ietf-lisp-sec-15), so I guess you can simply take my =
comment on the second problem as encouragement to get lisp-sec done =
(subject, of course, to the warnings in =
draft-trammell-optional-security-not).
>>>=20
>>> Cheers,
>>=20
>> What do you think of my suggestion?
>>=20
>> Dino
>>=20
>>=20
>=20


--Apple-Mail=_EB589D8F-24BF-4303-B865-101E27C9A1D1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAluHv4gACgkQihK3vwvq
RqPpNA/+I+Dgb3lUohhUU/PPdFkuMIb4UeHCEA20e6oYtVM6UtcWEpLEa85XLI51
OQHlT0BQbQpIil3pg4wzuAkZjKU2Lm+265PwcyvX7sEoqnbX9wbvFa69j6E+yx61
R0LCPLBWyCBIEY8StAs9mWgWvkGSCRIFfM38M4LOQaW60E9zfqYqUxtLTiyeO/3b
T23nZ5DdaYARhiPmkfNRY0tyMwq/OnCvF3JDRi8l9g9fmNk7Jjr5M6y4xYsHYZo7
BjszWDitz+5El8MJxYEhB/FbXtlH9GgggVBkviO3aEEHk14rehR1gWeNVLFm1Rgp
euAz+ivFovAjaAbd0SvLFGzOqHaPmIHfX35sskKPlb/VRJRiSjoUOmyqBufNhGqJ
x0lNL34Oty1lox//C0l2oQDa7ZA1r+T+vDuxLGGHhWU0N9zmPmkEe7YHdfi2Hvs8
FdVm9lJcIzqngX7oK0/xShx5919KViP5y3U2OWa4M0ogFLyR0EMqQFaCB9sjaTYR
xPSC38PjXgKCQiFXs+kMlqNbBaViPbADvaV7ExVIzEkDM9/pMgfuAqIiLgLV6bgm
78BDJ43u5siotSf7f1WA0trPtfOJPu7qpAZwj6afQa/f/Xag4+V9NGrenZEbhOGX
iKAvE7b/MbYMs1uQZg3aSdn+7l8sBAMQ70NKCDe3pfMBEztE7V0=
=3WDf
-----END PGP SIGNATURE-----

--Apple-Mail=_EB589D8F-24BF-4303-B865-101E27C9A1D1--


From nobody Thu Aug 30 04:01: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 60E90130E50 for ; Thu, 30 Aug 2018 04:01:28 -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 YJu6h1dY-N_P for ; Thu, 30 Aug 2018 04:01:25 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 CB7A1130E48 for ; Thu, 30 Aug 2018 04:01:24 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id f21-v6so1526072wmc.5 for ; Thu, 30 Aug 2018 04:01:24 -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=gLVDjsZdaY2bbNjLHqG98l6mYBox4239AoGIdI7XN20=; b=VLT8eU+Cbub7agAZ0UPp9PvI4scSrUUakAgXIcnXRhQozfaqRSQj8wRgwa+HRQUCcO dipRJkikQsF9YwJY2ADOq3XcO+nWCO911DkBQAgWJ4SrzzltRiVc5HDUahrFSDmkcB69 RQ+mlOiRjONOkkOLFljQm6xC4b7vRdMfASWzFYGQ4saVraZoI1LgzjM7Fel4Lwp1cMk3 Q9zRFTepSTUKLLVsouzzxMKF4IghM3kZTecDb5E16dspoRFj3wXtbRO7Pl5I2d40I8Vh AzL3gWIILkYKA9+QT/5iJO0fGJGTnCI1U3C7BnhfsdAcBTrh/mBKarKZCJJcacm0mj6u 5kWw==
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=gLVDjsZdaY2bbNjLHqG98l6mYBox4239AoGIdI7XN20=; b=Z9sA8ha1eiEmWagX9CehIGlz0wLovBvWuPGJjbpgrbuiRxjovTZFsTsLYyKiHOFbxb JpDpVKrmkuyQJh9TFN0U9Ls8aUGTZTEQAVuMaw/U5olLRGR6Qr+0YXHsvo+jyt66GxCV NnB7NpsdUDqJsCuTdYyHA1Jv2sI3DyebSHPRR0mMlpb+6Z5hmaxH6p8H7yFXl6tGFC7I Uf4Wfw1XhctHk5SAdRBoi71qREtUCkoyTuiW4m4bRUjgS6ioYs7wf6mYRoThyBLZlQah LDXmenYiwcqBGRFrEZKOuwPkFA3yEr8w2zlDukCB1BdFhvzgPwcaa9hp6zNiJvZEcSyB KS4w==
X-Gm-Message-State: APzg51CxFO+8ls4Bhbu4WL+hRwBTWlPIGHUOIPD2shATP+YrakpfiU6a hH/1I4kZQOntjC7D8N+8OdAkVQ==
X-Google-Smtp-Source: ANB0VdYO1JtdmIrXg1VxY9nyBizIZFmJeUw0U7NoIPhC6nBwBW6agKRnXFUvFA1kurUenJaC5M/EVQ==
X-Received: by 2002:a1c:93d2:: with SMTP id v201-v6mr1414066wmd.77.1535626883289;  Thu, 30 Aug 2018 04:01:23 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:38:9171:c3a4:c6d3:6140? ([2001:660:330f:38:9171:c3a4:c6d3:6140]) by smtp.gmail.com with ESMTPSA id p89-v6sm11737564wrc.97.2018.08.30.04.01.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Aug 2018 04:01:22 -0700 (PDT)
From: Luigi Iannone 
Message-Id: <0F515189-0329-49F6-9A86-41DD3557BA2E@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C2831D20-2417-4C0F-844E-DA78EBCC9CF8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 30 Aug 2018 13:01:20 +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.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: Thu, 30 Aug 2018 11:01:29 -0000

--Apple-Mail=_C2831D20-2417-4C0F-844E-DA78EBCC9CF8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Kyle, Dino,

I fill like this discussion is going sideways w.r.t. the original =
6830bis document.

You started to discuss other documents and other solutions, which, while =
certainly interesting and important, belong to other threads and =
documents.

IMHO here are the few points that need to be clarified:

> On 28 Aug 2018, at 23:48, Kyle Rose  wrote:
>=20
> Hi, Dino. I have additional responses inline.
>=20
> > For the internet core (DFZ RIB) use-case, LISP proposes replacing =
BGP sessions
> > and global eventually-consistent state sharing with a global control =
plane and
>=20
> LISP *does not propse to eliminate BGP*, in fact it needs it so RLOC =
reachability across the network is available, or there would be no =
underlay for the LISP overlay.
>=20
> 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
> Maybe this is just splitting hairs: I certainly don't want to rathole =
on this point.

@Kyle: can we consider this point closed?

[trimmed]

> =
https://tools.ietf.org/html/draft-ietf-lisp-sec-15#ref-I-D.ietf-lisp-rfc68=
33bis =

>=20
> > One area of concern, of which I have not been able to find =
discussion, is that
> > of the implications of shared capacity for the control and data =
planes, and how
> > this can allow a volumetric data plane attack to deny a router =
access to the
> > global mapping system, slowly choking off service to uncached =
portions of the
>=20
> Well yes, this happens with all our IETF protocols. It is a valid =
concern and there are many operational techniques in network =
infrastructure that *help* solve (but not eliminate) these problems.
>=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
I am not sure I understand the point. Isn=E2=80=99t this covered by =
RFC7835? Reference to that document isn=E2=80=99t sufficient?
If not, can you clarify further?

>=20
> > I would also like clarification on what defines the separation =
between the
> > control plane and data plane, and whether authentication itself is =
used to
>=20
> A control-plane obtains information to store in a table. The =
data-plane uses that table. That is the definition in the simpliest =
form.
>=20
> I mean specific to LISP, not generically. For instance, does "LISP =
Control-Plane signaling" include only valid messages, or valid + =
inauthentic (and presumably dropped) messages? Traditional attack =
traffic (e.g., a DDoS attack against a website) is part of the same data =
plane as all legitimate end user traffic; is attack traffic directed at =
control plane endpoints considered part of the control plane, or is it a =
third category of traffic? If the latter, then what does an operator =
need to do to ensure that control plane is always available?

IMHO, these questions should be asked for in the 6833bis thread. Don=E2=80=
=99t you guys agree?

Ciao

L.





>=20
> Kyle


--Apple-Mail=_C2831D20-2417-4C0F-844E-DA78EBCC9CF8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Kyle,=
 Dino,

I fill like =
this discussion is going sideways w.r.t. the original 6830bis =
document.

You =
started to discuss other documents and other solutions, which, while =
certainly interesting and important, belong to other threads and =
documents.

IMHO =
here are the few points that need to be clarified:

On 28 =
Aug 2018, at 23:48, Kyle Rose <krose@krose.org> wrote:

Hi, Dino. I have additional responses inline.

> For the internet core (DFZ =
RIB) use-case, LISP proposes replacing BGP sessions

> and global eventually-consistent state sharing with a global =
control plane and



LISP *does not propse to eliminate BGP*, in fact it needs it so =
RLOC reachability across the network is available, or there would be no =
underlay for the LISP overlay.

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.

Maybe this is just splitting hairs: I certainly don't want to =
rathole on this point.

@Kyle: can we consider this point =
closed?

[trimmed]

https://tools.ietf.org/html/draft-ietf-lisp-sec-15#ref-I-D.ietf-lisp-rfc6833bis
 


> One area of concern, of which I have not been able to find =
discussion, is that

> of the implications of shared capacity for the control and data =
planes, and how

> this can allow a volumetric data plane attack to deny a router =
access to the

> global mapping system, slowly choking off service to uncached =
portions of the



Well yes, this happens with all our IETF protocols. It is a valid =
concern and there are many operational techniques in network =
infrastructure that *help* solve (but not eliminate) these problems.

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.
 
I am not sure I understand the point. Isn=E2=80=99t this covered =
by RFC7835? Reference to that document isn=E2=80=99t =
sufficient?
If not, can you clarify further?

 

> I would also like =
clarification on what defines the separation between the

> control plane and data plane, and whether authentication itself is =
used to



A control-plane obtains information to store in a table. The =
data-plane uses that table. That is the definition in the simpliest =
form.

I mean specific to LISP, not generically. For instance, does =
"LISP Control-Plane signaling" include only valid messages, or valid + =
inauthentic (and presumably dropped) messages? Traditional attack =
traffic (e.g., a DDoS attack against a website) is part of the same data =
plane as all legitimate end user traffic; is attack traffic directed at =
control plane endpoints considered part of the control plane, or is it a =
third category of traffic? If the latter, then what does an operator =
need to do to ensure that control plane is always =
available?

IMHO, these questions should be asked for in the =
6833bis thread. Don=E2=80=99t you guys agree?

Ciao

L.






Kyle



=

--Apple-Mail=_C2831D20-2417-4C0F-844E-DA78EBCC9CF8--


From nobody Thu Aug 30 07:55:28 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 C99A3130E74; Thu, 30 Aug 2018 07:55: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 JEaVforX8zA0; Thu, 30 Aug 2018 07:55:18 -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 6C38D130E4B; Thu, 30 Aug 2018 07:55:18 -0700 (PDT)
Received: by mail-pg1-x543.google.com with SMTP id b129-v6so3992034pga.13; Thu, 30 Aug 2018 07:55:18 -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=AS0zkAJIHzfUzOiTa9eIQDiF6nDNpN+J3OJYn5kWiVU=; b=fogMRDxNbHsAMPuk6l8LtmkBN3mbOcU5hpt5k6UC2imC4tOsd6fKb+jD3j9jV7Jyhh oIM/6JuHXjFWa758L34ndlKu/+QXq20lAA08Z8bpNNmED4/NVSUK5mO7ZbsNOmqU26rY vjFYjG/I9BFfkC1VztsMyz/X5zBkiyz5ViaQWNK+RUexrb563yqOYUjfqeQcigEjOO9i 4gjS2+ldlaGgp0Oll3vb+aHje4AJB7EpLiUwc7FxpeVQt2ZoUTvbM/vqa3UglIHxmV4r HBSr4gxPHp46Wbqby9E69blTICOYPYmP2I51YFpddVItn3+tDUR+v1i4/XQ+ohBLg8SC q51A==
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=AS0zkAJIHzfUzOiTa9eIQDiF6nDNpN+J3OJYn5kWiVU=; b=NtjrHpgu1sk/wpWxWjK8RSxofyyNA8A1mOG7fw1EPQ0FHWzAiHTN0134+RQZ26DbMW XKR8fdDEBeQNgbBSANnL5LtRGoWjdcuOsBnlxUghcZ6hP9imSy61AWiWx97RxaBkuHE9 BANjfXTK5e45+IWahMKvHSsFK1os1xFQuQKmD2d48W7cy1sb7Il2bZHotFJOl/pSjdPJ xlJr8dde0Pfx5HcoBC3mOQ3qDU7U/WY/Ivh0Eq8IwdvJnGaZ2obimRXqnb/0Q/6q9oNF SgXgf2HW/4sdvaEziAd/Mt7UTML6RtHVZjNYWDR9gdpJOxAfLOgFgN3Hua/2+ux6DMcI wCEQ==
X-Gm-Message-State: APzg51Cy46IMu/V6zbIN7uND4MFzKVgEb2FY9zvO6RQOXcGL51/qN2nF XIY+sizTvH34quc8BbnMuVPw262r
X-Google-Smtp-Source: ANB0VdYw7Ran336tNkCyPnpgHU2alLFnfSk7KQZaBZbv6/fQpSdcQibmuz3qNWIsfFEq2WkuQlvbEQ==
X-Received: by 2002:a63:1823:: with SMTP id y35-v6mr10164283pgl.438.1535640917939;  Thu, 30 Aug 2018 07:55:17 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id l185-v6sm12399148pga.5.2018.08.30.07.55.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Aug 2018 07:55:17 -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: Thu, 30 Aug 2018 07:55:16 -0700
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>  <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>   <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@gmail.com>  
To: "Brian Trammell (IETF)" 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Thu, 30 Aug 2018 14:55:20 -0000

> On Aug 30, 2018, at 2:57 AM, Brian Trammell (IETF)  =
wrote:
>=20
> hi Dino,
>=20
> Almost. How about:
>=20
>=20
> OLD:
>=20
> When the UDP and LISP headers require integrity protection, the
> methods of using UDP checksums in [RFC8085] can be considered.
>=20
> NEW:
>=20
> Implementors are encouraged to consider UDP checksum usage guidelines =
in section 3.4 of [RFC8085]. Specifically, when the UDP, LISP, and outer =
IPv6 headers require protection against corruption, the use of non-zero =
UDP checksums is RECOMMENDED.

Well if we recommend it and when describing the UDP header in the packet =
format section we don=E2=80=99t that woudl be a contracdiction. And note =
the IPv6 outer header cannot be protected with a UDP checksum. The =
link-layer CRC will do that.

NEWNEW:

Implementors are encouraged to consider UDP checksum usage guidelines in =
section 3.4 of [RFC8085] when
it is desirable to protect UDP and LISP headers against corruption.

What do you think?

Dino


From nobody Thu Aug 30 07:58: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 E58DB130F40; Thu, 30 Aug 2018 07:58: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 4ICUuokvgNFO; Thu, 30 Aug 2018 07:58:39 -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 81A26130F41; Thu, 30 Aug 2018 07:58:39 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id b11-v6so4013617pfo.3; Thu, 30 Aug 2018 07:58: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=cLE8TtIC7KCI8SOvUMklfkoS6XRNvX1EVAU9lMU1i5o=; b=ZQt4PyGIqxRWSrWtUSecAaATAPDjjsWzGMLCD/ZAK6fZPk9c87u/mS1+1WDzt2by2S bWI2yculPYwucqH9SWtvdSAcdnAcXm/WmA0NY34Wb5iOMS0wlrARsEbDhM/LjSrS8JHf +NWlt8UySmqkA1NCteHkiAG6wMCRhcWenF85VEON5RieU6MuZfu8v1BRshy7qR1wG61a iApkAzHxtqQNfdDMSeWOnRXISDnedRUHM3H1N0Tf3ZFu0Lqf1YUaX6cEWV5sv2AEdTyW /DLrSZAVNyHU2ak1fxQtT+6qOjaezB62/J6SeWojtGSBJMnP7GW2qDmUQd1cVHSBcw5L cpnQ==
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=cLE8TtIC7KCI8SOvUMklfkoS6XRNvX1EVAU9lMU1i5o=; b=MxpevapJbW8cCe+/VyHIUw3/xt/0gosib3n6S2WrsmX00SS6ng2lINvPkk2SXMQCNE GtVEyB60fbDol8ZCclNkGJmRKWP+uF0S6rEjE0zdSJReQcUUE4F5Z3WasDiZVDByUGUs Einq7C/3ggxGWUrxnWbBFPBiybNTIu58kiJj2fxSNKpH9vEogCl/uLnQQsg9xwO7cohx qI9v0PUDcCxzKvB+luNC2fa0g9Vdc/YaC2gRy2Pjs1PbTzkhO5pU7zpzXe4y+GYvt8uF FH/B7M7yTSZaius/1+0xgQooqrtDL903kZBk9YAzRz8KxG+XE/n9z12ypIvWzejPJ93Z kkGw==
X-Gm-Message-State: APzg51AGUFs1gdF2/L1hgWNhSqiSpr5GBrqfu/QkAx3xOz8HAzzjjVKF wx9Ns0VrZpexV0R66xlfTAO1vd0f
X-Google-Smtp-Source: ANB0VdZCjenD+Utk2oMkM+Xf7ERyQfDLkEMmfwGZCcOdrMxKcpw80FI6/MEYIPkTvoPCkmz5MNplRg==
X-Received: by 2002:a63:e056:: with SMTP id n22-v6mr9934628pgj.205.1535641119149;  Thu, 30 Aug 2018 07:58:39 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id u9-v6sm13066581pfi.104.2018.08.30.07.58.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Aug 2018 07:58: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: <0F515189-0329-49F6-9A86-41DD3557BA2E@gigix.net>
Date: Thu, 30 Aug 2018 07:58:37 -0700
Cc: Kyle Rose , 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>   <0F515189-0329-49F6-9A86-41DD3557BA2E@gigix.net>
To: Luigi Iannone 
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.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: Thu, 30 Aug 2018 14:58:48 -0000

> Kyle, Dino,
>=20
> I fill like this discussion is going sideways w.r.t. the original =
6830bis document.
>=20
> You started to discuss other documents and other solutions, which, =
while certainly interesting and important, belong to other threads and =
documents.

Well I think the security guys want to make sure LISP, holistically, is =
secure. So we have to present solutions that may not be in the =
data-plane. I agree though we should focus on data-plane security since =
that is what Kyle is reviewing.

>=20
> IMHO here are the few points that need to be clarified:
>=20
>> On 28 Aug 2018, at 23:48, Kyle Rose  wrote:
>>=20
>> Hi, Dino. I have additional responses inline.
>>=20
>> > For the internet core (DFZ RIB) use-case, LISP proposes replacing =
BGP sessions
>> > and global eventually-consistent state sharing with a global =
control plane and
>>=20
>> LISP *does not propse to eliminate BGP*, in fact it needs it so RLOC =
reachability across the network is available, or there would be no =
underlay for the LISP overlay.
>>=20
>> 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
>> Maybe this is just splitting hairs: I certainly don't want to rathole =
on this point.
>=20
> @Kyle: can we consider this point closed?

=46rom my standpoint, it should be.

>=20
> [trimmed]
>=20
>> =
https://tools.ietf.org/html/draft-ietf-lisp-sec-15#ref-I-D.ietf-lisp-rfc68=
33bis
>>=20
>> > One area of concern, of which I have not been able to find =
discussion, is that
>> > of the implications of shared capacity for the control and data =
planes, and how
>> > this can allow a volumetric data plane attack to deny a router =
access to the
>> > global mapping system, slowly choking off service to uncached =
portions of the
>>=20
>> Well yes, this happens with all our IETF protocols. It is a valid =
concern and there are many operational techniques in network =
infrastructure that *help* solve (but not eliminate) these problems.
>>=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
> I am not sure I understand the point. Isn=E2=80=99t this covered by =
RFC7835? Reference to that document isn=E2=80=99t sufficient?
> If not, can you clarify further?

And I am not sure this is relevant to the data-plane.

>=20
>>=20
>> > I would also like clarification on what defines the separation =
between the
>> > control plane and data plane, and whether authentication itself is =
used to
>>=20
>> A control-plane obtains information to store in a table. The =
data-plane uses that table. That is the definition in the simpliest =
form.
>>=20
>> I mean specific to LISP, not generically. For instance, does "LISP =
Control-Plane signaling" include only valid messages, or valid + =
inauthentic (and presumably dropped) messages? Traditional attack =
traffic (e.g., a DDoS attack against a website) is part of the same data =
plane as all legitimate end user traffic; is attack traffic directed at =
control plane endpoints considered part of the control plane, or is it a =
third category of traffic? If the latter, then what does an operator =
need to do to ensure that control plane is always available?
>=20
> IMHO, these questions should be asked for in the 6833bis thread. =
Don=E2=80=99t you guys agree?

Yes, agree.

Dino

>=20
> Ciao
>=20
> L.
>=20
>=20
>=20
>=20
>=20
>>=20
>> Kyle
>=20


From nobody Thu Aug 30 08:46:28 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 ECA9E130EB2; Thu, 30 Aug 2018 08:46:13 -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, 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 ViDZ57fOfEVy; Thu, 30 Aug 2018 08:46:12 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1516130E8B; Thu, 30 Aug 2018 08:46:11 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C83CF340EC0; Thu, 30 Aug 2018 17:46:09 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.19358);  Thu, 30 Aug 2018 17:46:09 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 30 Aug 2018 17:46:09 +0200 (CEST)
Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 65765631; Thu, 30 Aug 2018 17:46:09 +0200
From: "Brian Trammell (IETF)" 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_4561970D-A129-41E4-8704-1166273C9D25"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 30 Aug 2018 17:46:08 +0200
In-Reply-To: 
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" 
To: Dino Farinacci 
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>  <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>   <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@gmail.com>   
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Thu, 30 Aug 2018 15:46:14 -0000

--Apple-Mail=_4561970D-A129-41E4-8704-1166273C9D25
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 30 Aug 2018, at 16:55, Dino Farinacci  wrote:
>=20
>> On Aug 30, 2018, at 2:57 AM, Brian Trammell (IETF)  =
wrote:
>>=20
>> hi Dino,
>>=20
>> Almost. How about:
>>=20
>>=20
>> OLD:
>>=20
>> When the UDP and LISP headers require integrity protection, the
>> methods of using UDP checksums in [RFC8085] can be considered.
>>=20
>> NEW:
>>=20
>> Implementors are encouraged to consider UDP checksum usage guidelines =
in section 3.4 of [RFC8085]. Specifically, when the UDP, LISP, and outer =
IPv6 headers require protection against corruption, the use of non-zero =
UDP checksums is RECOMMENDED.
>=20
> Well if we recommend it and when describing the UDP header in the =
packet format section we don=E2=80=99t that woudl be a contracdiction.

I think my point here is that the packet format section probably =
shouldn't do that. :) Yes, I understand the disconnect between the =
reality of the situation and the

> And note the IPv6 outer header cannot be protected with a UDP =
checksum. The link-layer CRC will do that.

Eh, this makes assumptions about the underlying link layer's corruption =
characteristics that may not hold. But yeah, for most packets in most =
realistic situations this is the case, and I guess we've learned to live =
with the underlying phy error rate * 1e-10 in any case.

> NEWNEW:
>=20
> Implementors are encouraged to consider UDP checksum usage guidelines =
in section 3.4 of [RFC8085] when
> it is desirable to protect UDP and LISP headers against corruption.
>=20
> What do you think?

This seems like a fine compromise to me.

Thanks, cheers,

Brian

>=20
> Dino
>=20
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art


--Apple-Mail=_4561970D-A129-41E4-8704-1166273C9D25
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAluIEUAACgkQihK3vwvq
RqMp9hAAif+3CIw2nUhyzEr/fdN0ePx09n1bsoRUwD+vbULr2Mv9TphF40vquGre
4RjSkVXuq4GjA7Ibh392xQNb3C5STb0I3BqR8zbR/ikAWo5JOAOji/J6bmnjxQGe
KQmHTl5+gUFrG9XedHVHBE2jg4y0WvVayu3urcJsembKWiAQsbPrvaO4VTv8upPQ
jcFoSTWzVcKcpVKOPPBqNbqKXWLzxLzReiDPaezeEf1AUzd2ku7RryY0KAfnArl0
fblA/yutLThWUQ72hrDNPwTCwG3C8XUqcXaMh07VjPp4EbdYtI+qHEa+VJqCEzmm
5HT8F7yMaTIQebJr6thX+JGFT+LBAoMQ6beSgt/Gw5212zPQ+sFbXtBH8LpR+FAz
PM78M7vqlciPwQKjV+qfPFTB5IEUTgwKAZJSbfy/+IwKSbAK+lkYUz6Bsl2kznQY
NCIpA6uUFJtp3YmrQgU1FrZBzWq7zSnYZ4SfEqfFvomnCd5Vvdiwh8CLUllWGfT3
JEhl0ztElKouyQtyhS0G2DqVyp4wdg5i8zPNWl1z3v7DYF7RpbN/PUKuBhoffI/J
Q+nSonenULbdUvKX18DfmKOz7cYDf17ptMZ7nmUGhfMVeq+izv6ekkAOKQ415YsC
boljXJkNjWGGZtylUGQ3y1ajGncCwo4eRurqAQbMuQUTQvlvF8U=
=kpYt
-----END PGP SIGNATURE-----

--Apple-Mail=_4561970D-A129-41E4-8704-1166273C9D25--


From nobody Thu Aug 30 09:10: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 74993130EB1; Thu, 30 Aug 2018 09:09:59 -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 9W64_xMXk0Fr; Thu, 30 Aug 2018 09:09:57 -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 70CF9130DD0; Thu, 30 Aug 2018 09:09:57 -0700 (PDT)
Received: by mail-pg1-x543.google.com with SMTP id m4-v6so4084086pgv.12; Thu, 30 Aug 2018 09:09:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=POWn/VEkzu6d6r/JHGMnMIJJF5cHGczz8z/1nR/DByM=; b=FM2HA7VVyblqtbOoIKa310fqdBRIbhfgfyIDryuMo8KUgCNe5sAZApxfSYt48aZu6d hTR8H7pb4+5oYNfkjSjVbpDDrS8ydvNYo6wK215gY6w1tQgxM6gHB0y9mPx7L/Jv87RW AxFBzZZK/lpiQLKd+0nCdTHagHunuMq2QngQPpJpiAerxBv1N/Wotqr8P+e2dzz176SV qarBLqfICWDaC8nfrzG0GjPjPpKeTwbAUDS4xYVRvcUXktl+KAWE1RJNNCJOIj9emodZ ZF9EOYIAUyy/3BuMeuHzF44ieUlu4Vuv/IganyF9/NH8LV+DT96/A1moTfFevZKcXVKX 6OXQ==
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:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=POWn/VEkzu6d6r/JHGMnMIJJF5cHGczz8z/1nR/DByM=; b=jHB8GEMpEe3NCujK4iQguwy1DxqSdw3NNXeIbQV8obUVjkfDlRoMJi/ORLaCtYGnKC 0OaqC7G7CV/LRLle4oNEpmpoM7kKsXXMZ1D7o+mVQUdvNDDl+ygbXEvaxXXiM5/p0WDO af7qKOFqFwOCFiFd0SNvKDDSLzUbiaU7DwyVr+kGJ1Ll4bXVjbtaH+VLoBzOstG6WhdH CihjQULkdR+gy2Mt3f7W2mFUSvMPzj3yzmsVSyvGRLm11875A5BzyZvFcCeoT/bU2Lou jQeHr+XKkiPNH3c6Ao1Njbxi47lujdr/BxODFYg8UExE5fFU68HGxQuHeBciwY7Lbfqb /tqA==
X-Gm-Message-State: APzg51CBMHdOQ/lNeuShBk0kOPtSEZdlLXuSu/IcArrF+GAyVo6abgRS Ghzai94QsUqJFTCnCOeeWVo=
X-Google-Smtp-Source: ANB0VdZpQ8SGK9k1wku2lGx0yUjK9ynBQpa5H4oF1DYb4zWP0vPdWl7a5UM2PH5TdvjmONZUnrebpw==
X-Received: by 2002:a63:f244:: with SMTP id d4-v6mr10200969pgk.2.1535645396963;  Thu, 30 Aug 2018 09:09:56 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id v6-v6sm18064511pfa.28.2018.08.30.09.09.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Aug 2018 09:09:56 -0700 (PDT)
From: Dino Farinacci 
X-Google-Original-From: Dino Farinacci 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
In-Reply-To: 
Date: Thu, 30 Aug 2018 09:09:54 -0700
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <60047CB6-2F13-4BE7-BCF0-4108479B569C@GMAIL.COM>
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>  <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>   <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@gmail.com>    
To: "Brian Trammell (IETF)" 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Thu, 30 Aug 2018 16:10:00 -0000

Thanks for the great discussion Brian. I think we=E2=80=99re all in sync =
now?

Dino

> On Aug 30, 2018, at 8:46 AM, Brian Trammell (IETF)  =
wrote:
>=20
>=20
>=20
>> On 30 Aug 2018, at 16:55, Dino Farinacci  wrote:
>>=20
>>> On Aug 30, 2018, at 2:57 AM, Brian Trammell (IETF) =
 wrote:
>>>=20
>>> hi Dino,
>>>=20
>>> Almost. How about:
>>>=20
>>>=20
>>> OLD:
>>>=20
>>> When the UDP and LISP headers require integrity protection, the
>>> methods of using UDP checksums in [RFC8085] can be considered.
>>>=20
>>> NEW:
>>>=20
>>> Implementors are encouraged to consider UDP checksum usage =
guidelines in section 3.4 of [RFC8085]. Specifically, when the UDP, =
LISP, and outer IPv6 headers require protection against corruption, the =
use of non-zero UDP checksums is RECOMMENDED.
>>=20
>> Well if we recommend it and when describing the UDP header in the =
packet format section we don=E2=80=99t that woudl be a contracdiction.
>=20
> I think my point here is that the packet format section probably =
shouldn't do that. :) Yes, I understand the disconnect between the =
reality of the situation and the
>=20
>> And note the IPv6 outer header cannot be protected with a UDP =
checksum. The link-layer CRC will do that.
>=20
> Eh, this makes assumptions about the underlying link layer's =
corruption characteristics that may not hold. But yeah, for most packets =
in most realistic situations this is the case, and I guess we've learned =
to live with the underlying phy error rate * 1e-10 in any case.
>=20
>> NEWNEW:
>>=20
>> Implementors are encouraged to consider UDP checksum usage guidelines =
in section 3.4 of [RFC8085] when
>> it is desirable to protect UDP and LISP headers against corruption.
>>=20
>> What do you think?
>=20
> This seems like a fine compromise to me.
>=20
> Thanks, cheers,
>=20
> Brian
>=20
>>=20
>> Dino
>>=20
>> _______________________________________________
>> Tsv-art mailing list
>> Tsv-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/tsv-art
>=20


From nobody Thu Aug 30 09:15: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 00707127332; Thu, 30 Aug 2018 09:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 yT_66TSxQ2SB; Thu, 30 Aug 2018 09:15:42 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC76127148; Thu, 30 Aug 2018 09:15:42 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id CABE7340E9F; Thu, 30 Aug 2018 18:15:40 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.27802);  Thu, 30 Aug 2018 18:15:40 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 30 Aug 2018 18:15:40 +0200 (CEST)
Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 65768774; Thu, 30 Aug 2018 18:15:40 +0200
From: "Brian Trammell (IETF)" 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_86D4EE7B-B203-4944-A793-944718DEB8DF"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 30 Aug 2018 18:15:40 +0200
In-Reply-To: <60047CB6-2F13-4BE7-BCF0-4108479B569C@GMAIL.COM>
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List , "lisp@ietf.org list" 
To: Dino Farinacci 
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>  <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch>  <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>   <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@gmail.com>     <60047CB6-2F13-4BE7-BCF0-4108479B569C@GMAIL.COM>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
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: Thu, 30 Aug 2018 16:15:44 -0000

--Apple-Mail=_86D4EE7B-B203-4944-A793-944718DEB8DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

=46rom my side, yes. Thanks a lot for your quick responses on this!

Cheers,

Brian

> On 30 Aug 2018, at 18:09, Dino Farinacci  wrote:
>=20
> Thanks for the great discussion Brian. I think we=E2=80=99re all in =
sync now?
>=20
> Dino
>=20
>> On Aug 30, 2018, at 8:46 AM, Brian Trammell (IETF)  =
wrote:
>>=20
>>=20
>>=20
>>> On 30 Aug 2018, at 16:55, Dino Farinacci  =
wrote:
>>>=20
>>>> On Aug 30, 2018, at 2:57 AM, Brian Trammell (IETF) =
 wrote:
>>>>=20
>>>> hi Dino,
>>>>=20
>>>> Almost. How about:
>>>>=20
>>>>=20
>>>> OLD:
>>>>=20
>>>> When the UDP and LISP headers require integrity protection, the
>>>> methods of using UDP checksums in [RFC8085] can be considered.
>>>>=20
>>>> NEW:
>>>>=20
>>>> Implementors are encouraged to consider UDP checksum usage =
guidelines in section 3.4 of [RFC8085]. Specifically, when the UDP, =
LISP, and outer IPv6 headers require protection against corruption, the =
use of non-zero UDP checksums is RECOMMENDED.
>>>=20
>>> Well if we recommend it and when describing the UDP header in the =
packet format section we don=E2=80=99t that woudl be a contracdiction.
>>=20
>> I think my point here is that the packet format section probably =
shouldn't do that. :) Yes, I understand the disconnect between the =
reality of the situation and the
>>=20
>>> And note the IPv6 outer header cannot be protected with a UDP =
checksum. The link-layer CRC will do that.
>>=20
>> Eh, this makes assumptions about the underlying link layer's =
corruption characteristics that may not hold. But yeah, for most packets =
in most realistic situations this is the case, and I guess we've learned =
to live with the underlying phy error rate * 1e-10 in any case.
>>=20
>>> NEWNEW:
>>>=20
>>> Implementors are encouraged to consider UDP checksum usage =
guidelines in section 3.4 of [RFC8085] when
>>> it is desirable to protect UDP and LISP headers against corruption.
>>>=20
>>> What do you think?
>>=20
>> This seems like a fine compromise to me.
>>=20
>> Thanks, cheers,
>>=20
>> Brian
>>=20
>>>=20
>>> Dino
>>>=20
>>> _______________________________________________
>>> Tsv-art mailing list
>>> Tsv-art@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tsv-art
>>=20
>=20


--Apple-Mail=_86D4EE7B-B203-4944-A793-944718DEB8DF
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAluIGCwACgkQihK3vwvq
RqPlgA//W0NdeFwnYOj7hrXOjMTTywb7DQk1kMP2+K0hLSNMblRl+X63soEYVuqy
2ghuC0PgjBJa6i4KNslkT5wZpkgHo49l7dVZFrqLAamhLPSpEBjErGts+M0eD5kq
9rhxlxEBTEvEfioyxNXjc0shnpt0Hfc52U2aKF6B1PUj4eH7wPkroGegVIRLOJkC
XsMtXvxjPFuJ8ZRftKEmm9s3Bv5GYnZDYaY080S9zmy/jmQfD5UjLAuG1IOQy+OA
HRPMHWWav/sdcJ+DGpMMHihvxgAiN9lWBFSXBNap794XC57QOV+HnMQCQsXW0I58
vGEmEXzmZK6veETlpIhYOvCSzCIX+yzas5s+6XlqXBkPbTs4gHR82e7KJMvN9Pwo
I8mJGKhfsQBCsIu6sydmEmcU3rVmT38YCkY3JIelhr9OHb/evXVtMUQ+9RnVj2DT
mTM+hiG27S1KKfN8HsurUB4QGx6XktRCJaBjOyoB8cGchhvCiaZu0YwM1O8Qu7D2
D57oSM/Gr5zH4wJzaJD26aImBs5fgKECSq4685QlR12/RayLCa4y5VJgQO4lB9K/
Mzwk7c7qznh0eKDFjD9nmEhLlW13USGQxnctvlpgbDymHtyrKwN+P5byAWJPmW9+
wNtHH7OaNfZMmzm3McZZY3Jrc4+5apHkFWSwTy/B36MBCz09PNA=
=E8ef
-----END PGP SIGNATURE-----

--Apple-Mail=_86D4EE7B-B203-4944-A793-944718DEB8DF--