From nobody Mon Oct 1 11:39:53 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12508130ECC; Mon, 1 Oct 2018 11:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fLH0OhUwqKt; Mon, 1 Oct 2018 11:39:23 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D011130E92; Mon, 1 Oct 2018 11:39:21 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id t70-v6so10052660pgd.12; Mon, 01 Oct 2018 11:39:21 -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=E36myEI2NZdHEgODM23aEd5qvMRJhSO/QogMoU9G0SQ=; b=GuKcUhAZ5m51J0QJDGF7gVWe2ON49v33h5pSqhvWkx+whN5S1DWegIzy3QqMmzZC2S ZgtC2/hqCvpiB1yzVIrDaM+odpfTf8f0ILaUpMBXYZeeqiu0bKn5NN/LqYpW7Li3ELgL TJR2jk4iJt9uuDuBSMn8wf1IzWOtRcvP+2hUHRD8M+LsPc6mPNYmvlVUKd8RfuOfqmvy v9cldZnAMeyC+kCwdHboHHg7YeC7ex/AHAUYcJv7etgyszvQ3Km0GU5C5Ya3pHng39lH BfTvrIwYFq47MhbRm9sqt3lc59t0eQoy6gchSGfG3NoA4ezBHQ9Ioo1yylyOH4Ww+5OZ ikDA== 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=E36myEI2NZdHEgODM23aEd5qvMRJhSO/QogMoU9G0SQ=; b=F4JAuqyzORczEQ/EJrkCVkAvL/Oa3XjYU9GyzGyMizGTp2oBNO6AW761R6OmM4RA0j rB1RrMik5qJOf2k8yDIx89lpFH68pw1jrelkjl2wMYRXJnZjmETKJBEOTPS/+NbnU2cC SagYseDc/K/xqsM47LLNOk4V0+9dtX0nPWJ8kENdEoHwFt7LmHQ2qQUkbFFOj07s0Jet l52mUVo3tUWPP7Ua+EzT9+XZlkNxwWuCakMGqL0PFVk6lIMxL8hbHHGMqEJ03ANAEh48 ostWH/fYqN8WMmzSQoNEZUkV525a7fSUeg8WPaHbc8bZ/CDiSJF9dcvRMWSs8auYo+pO FTzQ== X-Gm-Message-State: ABuFfojxLDpvpXI3mGfQmI3ycFbdE3A+ZSXfni8XwANQeOv0sBbkfbRL 1auv/qYGpDXUy9eqL1fV5MU= X-Google-Smtp-Source: ACcGV61EsGWSu2T10JKJlvPQTKs5cVUEe7LwQ0Max7Me4ri+PDrCfxipY43OXgIUR+3w/48f7d5fMw== X-Received: by 2002:a17:902:bc8b:: with SMTP id bb11-v6mr12970362plb.112.1538419160580; Mon, 01 Oct 2018 11:39:20 -0700 (PDT) Received: from [10.31.79.215] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id c1-v6sm15287447pgp.34.2018.10.01.11.39.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 11:39:20 -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, 1 Oct 2018 11:39:18 -0700 Cc: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <27454678-1FED-43EC-9D65-72F18487E619@gmail.com> References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 18:39:33 -0000 > >=20 > > IMPORTANT > > S 5.2. > >> s: This is the SMR-invoked bit. This bit is set to 1 when an = xTR is > >> sending a Map-Request in response to a received SMR-based = Map- > >> Request. > >>=20 > >> m: This is the LISP mobile-node m-bit. This bit is set by xTRs = that > >> operate as a mobile node as defined in [I-D.ietf-lisp-mn]. > >=20 > > This would appear to create a normative reference to this document. = To > > avoid that, you need to specify how I behave if I receive it but I > > don't implement lisp-mn. >=20 > I am find making it a normative reference but need the lisp-chairs to = comment. I am not sure what the implications of that are. >=20 > Me neither. Seems like it could go either way. My only interest is = that the protocol be unambiguous. We are working through removing normative references to working group = drafts. >=20 >=20 > =20 > > S 5.5. > >> is being mapped from a multicast destination EID. > >>=20 > >> 5.5. EID-to-RLOC UDP Map-Reply Message > >>=20 > >> A Map-Reply returns an EID-Prefix with a prefix length that is = less > >> than or equal to the EID being requested. The EID being = requested is > >=20 > > How do I behave if I receive an EID-Prefix that is less than any of = my > > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16 > > and someone asks me for 10.0.0.0/8? >=20 > I think I'm still unclear on this point. The spec says you cache it. That is all you can do. But it means the = sender of the Map-Reply is not spec conformant. That means RLOCs are = used for the coarser EID-prefix. >=20 > Also, when you talk about prefix > > length, I assume you mean the length fo the mask? >=20 > Yes, this is explained later in this section. Was that not helpful?? >=20 > I found it a bit confusing. It seems to me like there are two lengths = involved here: >=20 > - The length of the field (4 or 16) > - The parts of the field that are significant (i.e., the mask) In routing, as you know, the mask-length is always the same as the = prefix-length. It is the number of bits in the mask. > I had thought that "prefix length" referred to the former, but it = seems like here it > refers to the latter. The length of the address is defined by the 16-bit AFI that precedes the = address. > > S 5.6. > >> Authentication Data: This is the message digest used from the = output > >> of the MAC algorithm. The entire Map-Register payload is > >> authenticated with this field preset to 0. After the MAC is > >> computed, it is placed in this field. Implementations of = this > >> specification MUST include support for HMAC-SHA-1-96 = [RFC2404], > >> and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. > >=20 > > What prevents replay attacks here? I'm guessing it's the = Map-Version- > > Number, but as I understand it, I can set this to 0. >=20 > Well there are many. The nonce can change for each Map-Register sent. = Same for Map-Version number as well as the key-id.=20 >=20 > I think you need to describe the precise process of replay prevention = here. Not addressing any security issues right now until we have the = conference call. I agree with you and believe we have solutions, we just = haven=E2=80=99t documented them clearly. And understand why your line of = questioning. >=20 > > S 6.1. > >> receives an SMR-based Map-Request and the source is not in the > >> Locator-Set for the stored Map-Cache entry, then the responding = Map- > >> Request MUST be sent with an EID destination to the mapping = database > >> system. Since the mapping database system is a more secure way = to > >> reach an authoritative ETR, it will deliver the Map-Request to = the > >> authoritative source of the mapping data. > >=20 > > If I'm understanding this correctly, this allows an ETR to prevent = an > > ITR from learning that it is no longer the appropriate ETR for a > > prefix. The way this attack works is that before the topology shift, = I > > send SMRs, thus causing Map-Requests, which, because my entry is > > cached, refresh the cache on the ITR past the topology shift. I can > > keep doing this indefinitely. Am I missing something >=20 > Well if the ETR is being spoofed, then there is Map-Request load, but = it won=E2=80=99t corrupt the ITR=E2=80=99s map-cache. The ITR always = sends a verifying Map-Request to the mapping system to get the latest = and authenticated RLOC-set for the mapping. Rate-limiting is necessary = so each SMR received DOES NOT result in a Map-Requerst to the mapping = system. >=20 > I'm probably just confused here: SMRs go through the mapping system, = not directly? If so, I agree that this wont' work. SMRs are sent from an xTR that changes its RLOC set to xTRs that might = have EID-prefixes cached. It tells those caching xTRs to do a lookup to = the mapping system. So the Map-Request, with S-bit set (an SMR) are sent = directly from xTR to xTR. >=20 > > S 5. > >> \ | UDP Length | UDP Checksum = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | = | > >> | LISP Message = | > >> | = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > What do these two diagrams correspond to? v4 and v6? This needs > > explanation. >=20 > It is th entire IP packet sent as a LISP control-message. The header = before the diagrams indicate they are UDP packets. >=20 > A caption would probably help. The beginning of the section shows an IPv4 UDP packet format as well as = a IPv6 UDP packet format. >=20 > > S 5.2. > >> P: This is the probe-bit, which indicates that a Map-Request = SHOULD > >> be treated as a Locator reachability probe. The receiver = SHOULD > >> respond with a Map-Reply with the probe-bit set, indicating = that > >> the Map-Reply is a Locator reachability probe reply, with = the > >> nonce copied from the Map-Request. See RLOC-Probing Section = 7.1 > >> for more details. > >=20 > > How am I supposed to handle this if I am a Map Server. >=20 > It should be ignored. I will add text to reflect this point. Good = point. >=20 > >=20 > > S 5.2. > >> receipt. > >>=20 > >> L: This is the local-xtr bit. It is used by an xTR in a LISP = site to > >> tell other xTRs in the same site that it is part of the = RLOC-set > >> for the LISP site. The L-bit is set to 1 when the RLOC is = the > >> sender's IP address. > >=20 > > Is the xTR supposed to filter this on exiting the site. >=20 > Nope. >=20 > Won't this cause problems on ingress to another site?=20 No, I don=E2=80=99t think so. But you have to write more words to let me = know what you are thinking about. > =20 > > S 5.3. > >> originating Map-Request source. If the RLOC is not in the = Locator- > >> Set, then the ETR MUST send the "verifying Map-Request" to the > >> "piggybacked" EID. Doing this forces the "verifying = Map-Request" to > >> go through the mapping database system to reach the = authoritative > >> source of information about that EID, guarding against = RLOC-spoofing > >> in the "piggybacked" mapping data. > >=20 > > This text here doesn't seem compatible with either of the two cases > > listed in "EID-prefix" above. >=20 > I don=E2=80=99t understand the comment Eric. Maybe because I can=E2=80=99= t find the exact reference to EID-prefix where you think there is a = conflict. Please cite for me. Thanks. >=20 > This does seem to have been assigned to the wrong text. >=20 > I am referring to: >=20 > " A Map-Reply returns an EID-Prefix with a prefix length that is = less > than or equal to the EID being requested. The EID being requested = is > either from the destination field of an IP header of a Data-Probe = or > the EID record of a Map-Request. The RLOCs in the Map-Reply are > " >=20 > versus >=20 > " EID-Prefix: This prefix is 4 octets for an IPv4 address family = and > 16 octets for an IPv6 address family when the EID-Prefix-AFI is = 1 > or 2, respectively. For other AFIs [AFI], the length varies and > for the LCAF AFI the format is defined in [RFC8060]. When a = Map- > " >=20 > This is just the question of whether "prefix length" refers to the = field or > the significant bits of the field. Prefix-length =3D mask-length =3D number-of-bits-in-mask =3D = value-after-/. > > S 8.3. > >> of the mapping database protocols. > >>=20 > >> 8.3. Map-Server Processing > >>=20 > >> Once a Map-Server has EID-Prefixes registered by its client = ETRs, it > >> can accept and process Map-Requests for them. > >=20 > > This section is confusing because the introduction says that this > > function is only performed by Map-Resolvers: > > ' > > "The LISP Mapping Service defines two new types of LISP-speaking > > devices: the Map-Resolver, which accepts Map-Requests from an > > Ingress > > Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a=20= > > mapping database; and the Map-Server, which learns authoritative > > EID- > > to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes > > them in a database.=E2=80=9D >=20 > The document does cover the operation of a Map-Resolver and a = Map-Server. Some functions are performed only by Map-Resolvers only and = other different functions are performed by Map-Servers only. >=20 > I am not sure what you don=E2=80=99t understand. >=20 > Sure: As I understand it, Map Resolvers process Map Requests, and Map = Servers do not (that's what the quoted text seems to say). However, this = sentence talks about a Map Server processing a Map Request. That's = where I am confused. Here is a brief scenario: (1) ITR sends Map-Request to a Map-Resolver. (2) Map-Resolver =E2=80=9Cfinds=E2=80=9D the Map-Server where the EID = could be registered. That is the mapping database transport system, two = examples are LISP-ALT and LISP-DDT. (3) The Map-Resolver in the case of LISP-DDT, will have a referral-cache = and know which map-server is authoriative for the EID-prefix the = Map-Request EID is for. (4) The Map-Resolver forwards the Map-Request to that Map-Server. And hence Map-Servers process Map-Requests. The Map-Server can = proxy-reply with the RLOC-set cached in its site-cache or forward to one = or more ETRs (described by the RLOC-set) so they can map-reply. Most of the above is described in the LISP-DDT RFC. For LISP-ALT, the = map-resovler forwards the Map-Request across a tunneled topology where = BGP is used to tell you where EID-prefixes are registered to what = Map-Servers. That tunneled toplogy is used for the sole purpose to = forward Map-Requests. No data-plane involved there. Dino From nobody Mon Oct 1 11:59:04 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA1C130E0E for ; Mon, 1 Oct 2018 11:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.956 X-Spam-Level: X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 O3aaUD68DLot for ; Mon, 1 Oct 2018 11:58:57 -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 715A81252B7 for ; Mon, 1 Oct 2018 11:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25576; q=dns/txt; s=iport; t=1538420337; x=1539629937; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7MNnjfrg2fmHK7QPMQ4SVtuIt7DBHetONnz8EjOD1RM=; b=DaNyppISaKQ5EvTOSb4xShOrPMNmuljGZ1Rw/ikpcF5F887n4sfVLmcC 4f7MAlmUSojx/GJXj62OJhk+1ibVwGhdqK9dVUFnyaHJML/OSDHPeXXQb E0t8Hkq39UzdpxBT0JyTE5GVQDppjg2jSrCJqmzRcQrvtzyZXiR+OtVBv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAABybbJb/5tdJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYIOZn8oCot/jBmCDZZaFIFjAwsYC4RJAoQQITQYAQM?= =?us-ascii?q?BAQIBAQJtHAyFOAEBAQEDAQEYIDQEFwIBCBEBAgECAR4FCycLFwYIAgQBEoM?= =?us-ascii?q?iggEPpnaEMweFVgWIO3aBUReBQT+BEoIUfoMbAQEBAgGBKgEMBgEHAkIGhSY?= =?us-ascii?q?CiCskixuJPwkChkODDIZjF4FHhFuDCYEQhRSIeYMThhKCbAIRFIElHThBI1g?= =?us-ascii?q?RCHAVO4JsgiAFBRIRiEmFPm8BAYovDheBCIEfAQE?= X-IronPort-AV: E=Sophos;i="5.54,328,1534809600"; d="scan'208";a="457976335" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2018 18:58:54 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id w91IwsXb029106 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Oct 2018 18:58:54 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 1 Oct 2018 13:58:54 -0500 Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1395.000; Mon, 1 Oct 2018 13:58:53 -0500 From: "Vina Ermagan (vermagan)" To: "Joel M. Halpern" , "lisp@ietf.org" Thread-Topic: [lisp] Fwd: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) Thread-Index: AQHUV3wNmIs472jCSk60soiq0JpCuqUKoRGA Date: Mon, 1 Oct 2018 18:58:53 +0000 Message-ID: References: <20180928220340.GO24695@kduck.kaduk.org> <7924707d-e6c5-5080-7586-dcf1f96fed46@joelhalpern.com> In-Reply-To: <7924707d-e6c5-5080-7586-dcf1f96fed46@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.212.77] Content-Type: text/plain; charset="us-ascii" Content-ID: <14725D1C83E616429B20AA904DE8A13B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [lisp] Fwd: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 18:59:01 -0000 (A) Desirable, because LISP-SEC provides improved security for the protocol, and depending on the deployment scenario and its threat model, one should have the option of using it, so MtI would be a welcome improvement. I am an author of LISP-SEC. Best, Vina On 9/28/18, 3:38 PM, "lisp on behalf of Joel M. Halpern" wrote: >As co-chair, I would like to hear from the working group as to whether >making LISP-SEC mandatory to Implement (not Mandatory to Use) for >LISP6830bis and 6833bis implementations is >a) desirable >b) acceptable >c) undesirable but livable >d) unacceptable or worse. > >Please, do not just pick a letter. Include explanation of your opinion. >This is not a decision the ADs and Authors can make for the working group. > >Yours, >Joel > > >-------- Forwarded Message -------- >Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: >(with DISCUSS and COMMENT) >Date: Fri, 28 Sep 2018 17:03:40 -0500 >From: Benjamin Kaduk >To: Joel M. Halpern >CC: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi >Iannone , lisp-chairs@ietf.org, lisp@ietf.org > >Hi Joel, > > >On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote: >> Is there text we can add about the scoping that will change your >>discuss=20 >> into a series of useful comments? > >I had attempted to structure my Discuss points so that they would either >be >useful comments as is, or rendered moot by a reduced scope. I guess I can >try to clarify those below. (To be clear, reducing the scope is only >going >to move from "has potentially existentially bad problems" to "has >substantial issues that likely require reengineering to resolve".) > >> If so, Some indication of how you would like that phrased would help us >> address these. > >I think Ekr's ballot position on 6833bis has a good summary of the >architecture assumptions that the reduced scope allows us to make. >In order to have the document be able to plausibly make those claims, it >looks like we'd need to at least: >(1) update the Abstract/Introduction to clarify that the EID namespace is > only defined within a single administrative domain. >(2) (optionally, if it makes sense) mention in the introduction that this > administrative domain can include transport over other networks in >the > same way that a VPN would function[*], without requiring cooperation > from or interaction with the other networks' administrators >(3) remove the "global" text from the EID-to-RLOC Database and Map-Cache > definitions >(4) update the EID-Prefix definition to talk about the local site or > administrative domain's "address allocation authority" >(5) Take a look at the EID definition to consider whether references to >"on > the public Internet" are still valid, and the text about assignment > in a hierarchical manner should be revised for the new scope as well. > Likewise for EID-internal structure that is "not visible to the >global > routing system" > >(I stopped skimming and looking for problematic text around section 6) > >[*] Ideally this would be done without using the term "VPN" itself, since >I'd like to get a movement going to restrict "VPN" to include >confidentiality (i.e., privacy) protection. "virtual network" or "overlay >network" may or may not be good candidate replacement terms. > >> If not, we seem to have a larger problem. > >Well, we appear to have five ADs that are supporting making LISP-SEC a >normative reference and thus MTI; I don't know if that scale of change >meets your threshold for a "larger problem". > >> Yours, >> Joel >>=20 >> On 9/26/18 11:44 PM, Benjamin Kaduk wrote: >> > Benjamin Kaduk has entered the following ballot position for >> > draft-ietf-lisp-rfc6830bis-20: Discuss >> >=20 >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut >>this >> > introductory paragraph, however.) >> >=20 >> >=20 >> > Please refer to >>https://www.ietf.org/iesg/statement/discuss-criteria.html >> > for more information about IESG DISCUSS and COMMENT positions. >> >=20 >> >=20 >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >> >=20 >> >=20 >> >=20 >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> >=20 >> > I have grave concerns about the suitability of LISP as a whole, in its >> > present form, for advancement to the Standards-Track. While some of >>my >> > concerns are not specific to this document, as the core protocol >> > (data-plane) spec, it seems an appropriate place to attach them to. >> >=20 >> > I am told, out of band, that the intended deployment model is no >>longer to >> > cover the entire Internet (c.f. the MISSREF-state >> > draft-ietf-lisp-introduction's "with LISP, the dge of the Internet >>and the >> > core can be logically separated and interconnected by LISP-capable >> > routers", etc.), and that full Internet-scale operation is no longer a >> > goal. However, since that does not seem to be reflected in the >>current >> > batch of documents up for IESG review, I am forced to ballot on them >> > "as-is", namely as targetting global Internet deployment. The >>requirements >> > placed on the mapping system are so stringent so as to be arguably >> > unachievable at Internet-scale, though that arguably has more of an >> > interaction with the control-plane than the data-plane. It's still in >> > scope here, though, as part of the overall description of the protocol >> > flow. > >(rendered moot by scope reduction) > >> > There are an almost innumerable number of downgrade attacks possible, >>and >> > the control-plane and data-plane security mechanisms are not normative >> > dependencies of the current corpus of documents, and as such are not >>up for >> > consideration as mitigating the security concerns with the core >>documents. > >The downgrade attacks will probably require some further analysis; >LISP-SEC >would protect a lot of the header bits but I think there may be some other >data flows to be looked at. > >> > Section 3 defines the EID-to-RLOC Datbaase: >> >=20 >> > EID-to-RLOC Database: The EID-to-RLOC Database is a global >> > distributed database that contains all known EID-Prefix-to-RLOC >> > mappings. Each potential ETR typically contains a small piece >>of >> > the database: the EID-to-RLOC mappings for the EID-Prefixes >> > "behind" the router. These map to one of the router's own >> > globally visible IP addresses. Note that there MAY be >>transient >> > conditions when the EID-Prefix for the site and Locator-Set for >> > each EID-Prefix may not be the same on all ETRs. This has no >> > negative implications, since a partial set of Locators can be >> > used. >> >=20 >> > No compelling architecture for a trustworthy global distributed >>database >> > has been presented that I've seen so far, and LISP relies heavily on >>the >> > mapping system's database for its functionality. I am concerned that >>so >> > many requirements are placed on the mapping system so as to be in >>effect >> > unimplementable, in which case it would seem that the architecture as >>a >> > whole (that is, for a global Internet-scale system) is not fit for >>purpose. > >(rendered moot by scope reduction) > >> > Section 4.1's Step (6) only mentions parsing "to check for format >> > validity". I think it is appropriate to mention (and refer to) source >> > authentication checks as well, since bad Map-Reply data can allow all >>sorts >> > of attacks to occur. > >(not affected by scope reduction) > >> > There are some fairly subtle ordering requirements between the order >>of >> > entries in Map-Reply messages and the Locator-Status-Bits in >>data-plane >> > traffic (so that the semantic meaning of the status bits are >>meaningful), >> > which is only given a minimal treatment in the control-plane >>document. The >> > need for synchronization in interpreting these bits should be >>mentioned >> > more prominently in the data-plane document as well. > >(not affected by scope reduction) > >> >=20 >> > The usage of the Instance ID does not seem to be adequately covered; >>from >> > what I've been able to pick up so far it seems that both source and >> > destination participants must agree on the meaning of an Instance ID, >>and >> > the source and destination EIDs must be in the same Instance. This >>does >> > not seem like it is compatible with Internet scale, especially if >>there are >> > only 24 usable bits of Instance ID. > >(not affected by scope reduction) > >> >=20 >> > There seems to be a lot of intra-site synchronization requirements, >>notably >> > with respect to Map-Version consistency, the contents and ordering of >> > locator sets for EIDs in the site, etc.; the actual hard requirements >>for >> > synchronization within a site should be clearly called out, ideally >>in a >> > single location. > >(not affected by scope reduction, since ETRs are affected and not just >Map-Servers) > >> >=20 >> > The security considerations attempt to defer substantially to the >> > threat-analysis in RFC 7835, which does not really seem like a >>complete >> > threat analysis and does not provide analysis as to what requirements >>are >> > placed on the boundaries between the different components of LISP >>(data >> > plane, control plane, mapping system, various extensions, etc.). The >> > secdir reviewer had some good thoughts in this space. > >(not affected by scope reduction) > >> >=20 >> > The security considerations throughout the LISP documents place a >>heavy >> > focus on the risk of over-claiming for routing EID-prefixes. This is >>a >> > real concern, to be clear, but it should not overshadow the risk of an >> > attacker who is able to move traffic around at will, strip security >> > protections, cause denial of service, alter data-plane payloads, etc. >> > Similarly, this document's security considerations call out denial of >> > service as a risk from Map-Cache insertion/spoofing, but the risks >>from an >> > attacker being able to read and modify the traffic, perhaps even >>without >> > detection, seems a much greater threat to me. > >(not affected by scope reduction) > >> >=20 >> > I am not convinced that this protocol meets the current IETF >>requirements >> > for the security properties of Standards-Track Protocols without at >>least >> > LISP-SEC as a mandatory-to-implement component, and possibly >>additional or >> > stronger requirements. (I did not do a full analysis of the system >>in the >> > presence of those security mechanisms, since that is not what is being >> > presented for review.) > >(noting that LISP-SEC needs to be MTI and analysis performed under the new >assumptions) > >> > Having an EID that is associated to user-correlatable devices has >>severe >> > privacy considerations, but I could not find this mentioned anywhere >>in all >> > of the LISP documents I've read so far. > >(not affected by scope reduction) > >-Benjamin > >> >=20 >> >=20 >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> >=20 >> > I apologize for the somewhat scattered nature of these comments; >>there are >> > a lot of them and I was focusing my time more on trying to understand >>the >> > broader system, and the intended security posture, so they did not >>get as >> > much clean-up as I would have liked. (Most of my review was >>performed on the >> > -18, though I have tried to update to the -20 as relevant.) >> >=20 >> >=20 >> > The instance ID provides for organizational correlation, another >>privacy >> > exposure. >> >=20 >> > Is there anything different between an "EID-to-RLOC Map-Request" and >>just a >> > "Map-Request"? (Same question for "Map-Reply", too.) >> >=20 >> > There's a lot of stuff that seems to work best if there is symmetric >> > bidirectional traffic, with inline signalling of map version and >> > reachability changes, though clearly everything is designed to also >>work >> > with asymmetric connectivity or unidirectional traffic. It would be >>nice >> > to have a high-level summary in or near the introduction about what >>kinds >> > of behavior/performance differences are expected for bidirectional vs. >> > unidirectional traffic. >> >=20 >> > Section 2 >> >=20 >> > That's not the 8174 boilerplate; it's more than just adding a cite to >>the >> > 2119 boilerplate. >> >=20 >> > Section 3 >> >=20 >> > nit: "An address family that pertains to the Data-Plane." is a >>sentence >> > fragment. >> >=20 >> > Ingress Tunnel Router (ITR): An ITR is a router that resides in >>a >> > [...] >> > mapping lookup in the destination address field. Note that >>this >> > destination RLOC MAY be an intermediate, proxy device that has >> > better knowledge of the EID-to-RLOC mapping closer to the >> >=20 >> > This doesn't seem like a 2119 MAY is necessary, but rather a >>statement of >> > fact that may not be known to the encapsulating ITR. >> >=20 >> > Specifically, when a service provider prepends a LISP header >>for >> > Traffic Engineering purposes, the router that does this is also >> > regarded as an ITR. The outer RLOC the ISP ITR uses can be >>based >> > on the outer destination address (the originating ITR's >>supplied >> > RLOC) or the inner destination address (the originating host's >> > supplied EID). >> >=20 >> > I'm confused here, perhaps in multiple ways. Are there now *two* LISP >> > headers on the packet? Is the "outer RLOC the ISP ITR uses" the >>source >> > RLOC or the destination RLOC? >> >=20 >> > Negative Mapping Entry: A negative mapping entry, also known as >>a >> > negative cache entry, is an EID-to-RLOC entry where an >>EID-Prefix >> > is advertised or stored with no RLOCs. That is, the >>Locator-Set >> > for the EID-to-RLOC entry is empty or has an encoded Locator >>count >> > of 0. >> >=20 >> > Is "empty" a distinct representation from "locator count of zero"? >> >=20 >> > Perhaps something of an aside, but the check described for >> > Route-Returnability is a somewhat weak check, and in some cases could >>still >> > be spoofed. (I don't expect this to surprise anyone, of course, but >> > perhaps some more qualifiers could be added to the text.) >> >=20 >> > Section 4 >> >=20 >> > An additional LISP header MAY be prepended to packets by a TE-ITR >> > when re-routing of the path for a packet is desired. A potential >> > use-case for this would be an ISP router that needs to perform >> > Traffic Engineering for packets flowing through its network. In >>such >> > a situation, termed "Recursive Tunneling", an ISP transit acts as >>an >> > additional ITR, and the RLOC it uses for the new prepended header >> > would be either a TE-ETR within the ISP (along an intra-ISP >>traffic >> > engineered path) or a TE-ETR within another ISP (an inter-ISP >>traffic >> > engineered path, where an agreement to build such a path exists). >> >=20 >> > "the RLOC it uses for the new prepnded header", again, this is as the >> > destination RLOC (vs. source RLOC)? >> >=20 >> > Section 4.1 >> >=20 >> > o Map-Replies are sent on the underlying routing system topology >> > using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. >> >=20 >> > Just to check my understanding: is the "underlying routing system >>topology" >> > the same as the "underlay"? >> >=20 >> > Is step (3) just describing more of what step (2) says is "not >>described in >> > this example"? >> >=20 >> > Section 5.3 >> >=20 >> > The word "nonce" is normally used for something used exactly once. >> > E.g., with some AEAD algorithms, if the same "nonce" input is used for >> > different encryptions, the entire security of the system is >>compromised. >> > It would be better to refer to this field with a different term, given >> > that "the same nonce can be used for a period of time when >>encapsulating to >> > the same ETR". "Uniquifier" or "random value" might be reasonable >>choices. >> >=20 >> > Why is there no discussion of the Map-Version or Instance-ID fields >> > in this section? >> >=20 >> > When doing ETR/PETR decapsulation: >> >=20 >> > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in >> > the case of IPv6) SHOULD be copied from the outer-header 'Time >>to >> > Live' field, when the Time to Live value of the outer header is >> > less than the Time to Live value of the inner header. Failing >>to >> > perform this check can cause the Time to Live of the inner >>header >> > to increment across encapsulation/decapsulation cycles. This >> > check is also performed when doing initial encapsulation, when >>a >> > packet comes to an ITR or PITR destined for a LISP site. >> >=20 >> > Er, what is "this check" that is also performed for initial >>encapsulation? >> > How are there multiple TTL values to compare? >> >=20 >> > o The inner-header 'Differentiated Services Code Point' (DSCP) >>field >> > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be >> > copied from the outer-header DSCP field ('Traffic Class' >>field, in >> > the case of IPv6) to the inner-header. >> >=20 >> > nit: the first "inner-header" seems like an editing remnant? >> >=20 >> > Section 7.1 >> >=20 >> > How is this stateless if it invovles knowledge about the routers >>between >> > the ITR and all possible ETRs (i.e., a set that could change over >>time)? >> >=20 >> > Section 8 >> >=20 >> > This 32-bit vs 24-bit thing is pretty hokey for a standards-track >> > specification (yes, I know that LISP-DDT is not standards track at the >> > moment). >> >=20 >> > Section 9 >> >=20 >> > Alternatively, RLOC information MAY be gleaned from received >>tunneled >> >=20 >> > What is this an alternative to? The list of four options above? >> >=20 >> > packets or EID-to-RLOC Map-Request messages. A "gleaned" >>Map-Cache >> > entry, one learned from the source RLOC of a received encapsulated >> > packet, is only stored and used for a few seconds, pending >> > verification. Verification is performed by sending a Map-Request >>to >> > the source EID (the inner-header IP source address) of the >>received >> > encapsulated packet. >> >=20 >> > The source EID is some random end system, right? So this relys on >>some >> > magic in the ETR to detect that there's a Map-Request and reply >>directly >> > instead of passing it on to the EID that won't know what to do with >>it? >> >=20 >> > Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and >> > might benefit from an explicit section reference to the other >>document. >> >=20 >> > Section 10 >> >=20 >> > What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it >> > is not marked as well-known at >> > https://www.rfc-editor.org/materials/abbrev.expansion.txt so >>expansion is >> > probably in order. >> >=20 >> > Again, when we are talking about the internal structure of the >>Map-Reply, a >> > detailed section refernce to 6833bis is useful. >> >=20 >> > Modifying LSBs seems like a fine DoS attack vector for an on-path >>attacker. >> >=20 >> > value of 1. Locator-Status-Bits are associated with a Locator-Set >> > per EID-Prefix. Therefore, when a Locator becomes unreachable, >>the >> > Locator-Status-Bit that corresponds to that Locator's position in >>the >> > list returned by the last Map-Reply will be set to zero for that >> > particular EID-Prefix >> >=20 >> > Doesn't this imply a stateful relationship between the ordering of >> > Map-Replys and data-plane traffic? >> >=20 >> > Section 10.1 >> >=20 >> > Note that "ITR" and "ETR" are relative terms here. Both devices >>MUST >> > be implementing both ITR and ETR functionality for the echo nonce >> > mechanism to operate. >> >=20 >> > Perhaps they could be given actual names so as to disambiguate which >>steps >> > are performed with ITR vs. ETR role? >> >=20 >> > The echo-nonce algorithm is bilateral. That is, if one side sets >>the >> > E-bit and the other side is not enabled for echo-noncing, then the >> > echoing of the nonce does not occur and the requesting side may >> > erroneously consider the Locator unreachable. An ITR SHOULD only >>set >> > the E-bit in an encapsulated data packet when it knows the ETR is >> > enabled for echo-noncing. This is conveyed by the E-bit in the >>RLOC- >> > probe Map-Reply message. >> >=20 >> > Why is this even optional? If it was mandatory to use, then there >>would >> > not be a question. But at least clarify that the "this" that is >>conveyed >> > is whether the peer supports the echo-nonce algorithm. (Also, >>subject to >> > downgrade.) >> >=20 >> > Section 13 >> >=20 >> > When a Locator record is removed from a Locator-Set, ITRs that >>have >> > the mapping cached will not use the removed Locator because the >>xTRs >> > will set the Locator-Status-Bit to 0. So, even if the Locator is >>in >> > the list, it will not be used. For new mapping requests, the xTRs >> > can set the Locator AFI to 0 (indicating an unspecified address), >>as >> > well as setting the corresponding Locator-Status-Bit to 0. This >> > forces ITRs with old or new mappings to avoid using the removed >> > Locator. >> >=20 >> > The behavior describe here seems like it would be better described as >>"when >> > a Locator is taken out of service" than "removed from a Locator-Set", >>since >> > if it is not in the set at all, it has no index, and no LSB or AFI to >>set. >> > Should actually depopulating it like this be forbidden? >> >=20 >> > I guess the Map Versioning is supposed to help with this, but we need >>to >> > nail down the semantics more and/or give a clearer reference to it. >> >=20 >> > Section 13.1 >> >=20 >> > An ITR, when it encapsulates packets to ETRs, can convey its own >>Map- >> > Version Number. This is known as the Source Map-Version Number. >> >=20 >> > Replacing "its own Map-Version Number" with something like "the >>Map-Version >> > numer for the LISP site of which it is a part". Writing this causes >>me to >> > note that the semantics of the Map-Version are unclear, here -- what >>is it >> > scoped to? An EID-Prefix? An RLOC? Oh, you say that in the next >> > paragraph (EID-Prefix). >> >=20 >> > A Map-Version Number can be included in Map-Register messages as >> > well. This is a good way for the Map-Server to assure that all >>ETRs >> > for a site registering to it will be synchronized according to >>Map- >> > Version Number. >> >=20 >> > Huh? I must be confused how this works. (Also, wouldn't this be >>better in >> > the control plane document which covers Map-Register?) >> >=20 >> > Section 15 >> >=20 >> > o When a tunnel-encapsulated packet is received by an ETR, the >>outer >> > destination address may not be the address of the router. This >> > makes it challenging for the control plane to get packets from >>the >> > hardware. This may be mitigated by creating special Forwarding >> > Information Base (FIB) entries for the EID-Prefixes of EIDs >>served >> > by the ETR (those for which the router provides an RLOC >> > translation). These FIB entries are marked with a flag >>indicating >> > that Control-Plane processing SHOULD be performed. >> >=20 >> > I assume this is just my lack of background showing, but I'm confused >>how >> > it makes sense to mark these for control-plane processing. Isn't the >> > control plane much slower, and we're not putting all of the LISP >>data-plane >> > traffic onto the slow path? >> >=20 >> > Section 18 >> >=20 >> > o Data-Plane gleaning for creating map-cache entries has been >>made >> > optional. If any ITR implementations depend or assume the >>remote >> > ETR is gleaning should not do so. >> >=20 >> > nit: this is ungrammatical; "they should not" or "Any ITR >>implementations >> > that depend on or assume that" would fix it. >> >=20 >> > Section 19.1 >> >=20 >> > Presumably IANA also updated the reference column to point to this >> > document? >> >=20 >> >=20 >> >=20 > >_______________________________________________ >lisp mailing list >lisp@ietf.org >https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Oct 1 11:59: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 EE4FB1252B7 for ; Mon, 1 Oct 2018 11:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqht2ndjUdyt for ; Mon, 1 Oct 2018 11:59:40 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 E0A6C12426A for ; Mon, 1 Oct 2018 11:59:39 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id v6-v6so4123174ljc.11 for ; Mon, 01 Oct 2018 11:59:39 -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=o+yXGAiCUDtXga5em3wUEGj98U5FHJ3o82xbaACkxlg=; b=a7AIGNGHnlZ64NorAwv6UGJufVoGvO/Voui7lz/Vrk0L4AEGAZMn88iQk6BafLnqG8 LNLgKnQo96eUIRbDF7DDbjoSxb+ociX735Fh+RJzwf9bKVRbnvGb0MSWMJV6q2+jhyH9 FBw4+5Qz5zimfDUeB/KD1u4mn9XBK+7QBdrpC22uw9s9dacECtBZqUIb+gDHLpEx7oT9 vmMjQywUbORIvs9RI69ZQ91ThAcNJ4G94gmazecQ6jCH6TL5ga6Uwh78ViX+XSvBwXMy SWyHPfcKOK4K+DNa9BG60dVjCH38Sujhg5TeU10JhQ/7Q/GHzJHMtD0cegt/E5I1Gmfn Wcvg== 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=o+yXGAiCUDtXga5em3wUEGj98U5FHJ3o82xbaACkxlg=; b=st/Lq6WrNhLDEhp9Lh1aTk2MSr7/h6ufc6YzI0vfoY+0B1RGf0/sHgfY/PJe4P4nJh 2oqos58f19FN29MtXrmqTDcQeuckWjmB1VakEOjU1DxQXDMZ9oee5f/XoCsXsGSJ4ntd r19mXgaFOgel8s10AEHVEVwHWyMw9twYUn4XEL6WE7+zRHBarPLpnvA9HBNLHIxJ3cIe FtaZxdIUnc64KYyhIKOYFDZqglwZ5IlM71Tyx0VQuyIwKfW9OUgjnj/PyQZTR1pK3y3o wY3fhy6XmAurWVSm1IbEv0mL/HoucCqA5+hirqH8loLc9rW+3PBvrBlAjgIN0ipcpuiS GjUQ== X-Gm-Message-State: ABuFfojJGjMuzjU6hU/yDFwXpCYBNJ8yLUXx4WDvXX0u5wITeUK2kVtq 84byy/lUr10hOXanP8ZC6OHwvu/VNDqxhKKd0Qj6SA== X-Google-Smtp-Source: ACcGV60lbnThPV4rOywTXngJIvTQ2fW8zd/QTCgtQegbYPEehHRiV17C9Jy4NjmqtbsT+u/KWhVOHC0FQpD6waeU7oc= X-Received: by 2002:a2e:87da:: with SMTP id v26-v6mr7839632ljj.13.1538420377824; Mon, 01 Oct 2018 11:59:37 -0700 (PDT) MIME-Version: 1.0 References: <20180928220340.GO24695@kduck.kaduk.org> <7924707d-e6c5-5080-7586-dcf1f96fed46@joelhalpern.com> In-Reply-To: <7924707d-e6c5-5080-7586-dcf1f96fed46@joelhalpern.com> From: Alberto Rodriguez-Natal Date: Mon, 1 Oct 2018 11:59:25 -0700 Message-ID: To: "Joel M. Halpern" Cc: "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="00000000000022b03c05772f687b" Archived-At: Subject: Re: [lisp] Fwd: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 18:59:46 -0000 --00000000000022b03c05772f687b Content-Type: text/plain; charset="UTF-8" I would say "(a) desirable". I agree with Dino that the more secure, the better. Also, thanks for gathering the WG opinion on this Joel. I think that it may help if you re-send this question with a more explicit subject line. Hopefully that will catch the attention of those at the WG that may not be following this discussion in detail. Thanks, Alberto On Fri, Sep 28, 2018 at 3:38 PM Joel M. Halpern wrote: > As co-chair, I would like to hear from the working group as to whether > making LISP-SEC mandatory to Implement (not Mandatory to Use) for > LISP6830bis and 6833bis implementations is > a) desirable > b) acceptable > c) undesirable but livable > d) unacceptable or worse. > > Please, do not just pick a letter. Include explanation of your opinion. > This is not a decision the ADs and Authors can make for the working group. > > Yours, > Joel > > > -------- Forwarded Message -------- > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: > (with DISCUSS and COMMENT) > Date: Fri, 28 Sep 2018 17:03:40 -0500 > From: Benjamin Kaduk > To: Joel M. Halpern > CC: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi > Iannone , lisp-chairs@ietf.org, lisp@ietf.org > > Hi Joel, > > > On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote: > > Is there text we can add about the scoping that will change your discuss > > into a series of useful comments? > > I had attempted to structure my Discuss points so that they would either be > useful comments as is, or rendered moot by a reduced scope. I guess I can > try to clarify those below. (To be clear, reducing the scope is only going > to move from "has potentially existentially bad problems" to "has > substantial issues that likely require reengineering to resolve".) > > > If so, Some indication of how you would like that phrased would help us > > address these. > > I think Ekr's ballot position on 6833bis has a good summary of the > architecture assumptions that the reduced scope allows us to make. > In order to have the document be able to plausibly make those claims, it > looks like we'd need to at least: > (1) update the Abstract/Introduction to clarify that the EID namespace is > only defined within a single administrative domain. > (2) (optionally, if it makes sense) mention in the introduction that this > administrative domain can include transport over other networks in the > same way that a VPN would function[*], without requiring cooperation > from or interaction with the other networks' administrators > (3) remove the "global" text from the EID-to-RLOC Database and Map-Cache > definitions > (4) update the EID-Prefix definition to talk about the local site or > administrative domain's "address allocation authority" > (5) Take a look at the EID definition to consider whether references to "on > the public Internet" are still valid, and the text about assignment > in a hierarchical manner should be revised for the new scope as well. > Likewise for EID-internal structure that is "not visible to the global > routing system" > > (I stopped skimming and looking for problematic text around section 6) > > [*] Ideally this would be done without using the term "VPN" itself, since > I'd like to get a movement going to restrict "VPN" to include > confidentiality (i.e., privacy) protection. "virtual network" or "overlay > network" may or may not be good candidate replacement terms. > > > If not, we seem to have a larger problem. > > Well, we appear to have five ADs that are supporting making LISP-SEC a > normative reference and thus MTI; I don't know if that scale of change > meets your threshold for a "larger problem". > > > Yours, > > Joel > > > > On 9/26/18 11:44 PM, Benjamin Kaduk wrote: > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-lisp-rfc6830bis-20: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > I have grave concerns about the suitability of LISP as a whole, in its > > > present form, for advancement to the Standards-Track. While some of my > > > concerns are not specific to this document, as the core protocol > > > (data-plane) spec, it seems an appropriate place to attach them to. > > > > > > I am told, out of band, that the intended deployment model is no > longer to > > > cover the entire Internet (c.f. the MISSREF-state > > > draft-ietf-lisp-introduction's "with LISP, the dge of the Internet and > the > > > core can be logically separated and interconnected by LISP-capable > > > routers", etc.), and that full Internet-scale operation is no longer a > > > goal. However, since that does not seem to be reflected in the current > > > batch of documents up for IESG review, I am forced to ballot on them > > > "as-is", namely as targetting global Internet deployment. The > requirements > > > placed on the mapping system are so stringent so as to be arguably > > > unachievable at Internet-scale, though that arguably has more of an > > > interaction with the control-plane than the data-plane. It's still in > > > scope here, though, as part of the overall description of the protocol > > > flow. > > (rendered moot by scope reduction) > > > > There are an almost innumerable number of downgrade attacks possible, > and > > > the control-plane and data-plane security mechanisms are not normative > > > dependencies of the current corpus of documents, and as such are not > up for > > > consideration as mitigating the security concerns with the core > documents. > > The downgrade attacks will probably require some further analysis; LISP-SEC > would protect a lot of the header bits but I think there may be some other > data flows to be looked at. > > > > Section 3 defines the EID-to-RLOC Datbaase: > > > > > > EID-to-RLOC Database: The EID-to-RLOC Database is a global > > > distributed database that contains all known EID-Prefix-to-RLOC > > > mappings. Each potential ETR typically contains a small piece > of > > > the database: the EID-to-RLOC mappings for the EID-Prefixes > > > "behind" the router. These map to one of the router's own > > > globally visible IP addresses. Note that there MAY be transient > > > conditions when the EID-Prefix for the site and Locator-Set for > > > each EID-Prefix may not be the same on all ETRs. This has no > > > negative implications, since a partial set of Locators can be > > > used. > > > > > > No compelling architecture for a trustworthy global distributed > database > > > has been presented that I've seen so far, and LISP relies heavily on > the > > > mapping system's database for its functionality. I am concerned that > so > > > many requirements are placed on the mapping system so as to be in > effect > > > unimplementable, in which case it would seem that the architecture as a > > > whole (that is, for a global Internet-scale system) is not fit for > purpose. > > (rendered moot by scope reduction) > > > > Section 4.1's Step (6) only mentions parsing "to check for format > > > validity". I think it is appropriate to mention (and refer to) source > > > authentication checks as well, since bad Map-Reply data can allow all > sorts > > > of attacks to occur. > > (not affected by scope reduction) > > > > There are some fairly subtle ordering requirements between the order of > > > entries in Map-Reply messages and the Locator-Status-Bits in data-plane > > > traffic (so that the semantic meaning of the status bits are > meaningful), > > > which is only given a minimal treatment in the control-plane > document. The > > > need for synchronization in interpreting these bits should be mentioned > > > more prominently in the data-plane document as well. > > (not affected by scope reduction) > > > > > > > The usage of the Instance ID does not seem to be adequately covered; > from > > > what I've been able to pick up so far it seems that both source and > > > destination participants must agree on the meaning of an Instance ID, > and > > > the source and destination EIDs must be in the same Instance. This > does > > > not seem like it is compatible with Internet scale, especially if > there are > > > only 24 usable bits of Instance ID. > > (not affected by scope reduction) > > > > > > > There seems to be a lot of intra-site synchronization requirements, > notably > > > with respect to Map-Version consistency, the contents and ordering of > > > locator sets for EIDs in the site, etc.; the actual hard requirements > for > > > synchronization within a site should be clearly called out, ideally in > a > > > single location. > > (not affected by scope reduction, since ETRs are affected and not just > Map-Servers) > > > > > > > The security considerations attempt to defer substantially to the > > > threat-analysis in RFC 7835, which does not really seem like a complete > > > threat analysis and does not provide analysis as to what requirements > are > > > placed on the boundaries between the different components of LISP (data > > > plane, control plane, mapping system, various extensions, etc.). The > > > secdir reviewer had some good thoughts in this space. > > (not affected by scope reduction) > > > > > > > The security considerations throughout the LISP documents place a heavy > > > focus on the risk of over-claiming for routing EID-prefixes. This is a > > > real concern, to be clear, but it should not overshadow the risk of an > > > attacker who is able to move traffic around at will, strip security > > > protections, cause denial of service, alter data-plane payloads, etc. > > > Similarly, this document's security considerations call out denial of > > > service as a risk from Map-Cache insertion/spoofing, but the risks > from an > > > attacker being able to read and modify the traffic, perhaps even > without > > > detection, seems a much greater threat to me. > > (not affected by scope reduction) > > > > > > > I am not convinced that this protocol meets the current IETF > requirements > > > for the security properties of Standards-Track Protocols without at > least > > > LISP-SEC as a mandatory-to-implement component, and possibly > additional or > > > stronger requirements. (I did not do a full analysis of the system in > the > > > presence of those security mechanisms, since that is not what is being > > > presented for review.) > > (noting that LISP-SEC needs to be MTI and analysis performed under the new > assumptions) > > > > Having an EID that is associated to user-correlatable devices has > severe > > > privacy considerations, but I could not find this mentioned anywhere > in all > > > of the LISP documents I've read so far. > > (not affected by scope reduction) > > -Benjamin > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > I apologize for the somewhat scattered nature of these comments; there > are > > > a lot of them and I was focusing my time more on trying to understand > the > > > broader system, and the intended security posture, so they did not get > as > > > much clean-up as I would have liked. (Most of my review was performed > on the > > > -18, though I have tried to update to the -20 as relevant.) > > > > > > > > > The instance ID provides for organizational correlation, another > privacy > > > exposure. > > > > > > Is there anything different between an "EID-to-RLOC Map-Request" and > just a > > > "Map-Request"? (Same question for "Map-Reply", too.) > > > > > > There's a lot of stuff that seems to work best if there is symmetric > > > bidirectional traffic, with inline signalling of map version and > > > reachability changes, though clearly everything is designed to also > work > > > with asymmetric connectivity or unidirectional traffic. It would be > nice > > > to have a high-level summary in or near the introduction about what > kinds > > > of behavior/performance differences are expected for bidirectional vs. > > > unidirectional traffic. > > > > > > Section 2 > > > > > > That's not the 8174 boilerplate; it's more than just adding a cite to > the > > > 2119 boilerplate. > > > > > > Section 3 > > > > > > nit: "An address family that pertains to the Data-Plane." is a sentence > > > fragment. > > > > > > Ingress Tunnel Router (ITR): An ITR is a router that resides in a > > > [...] > > > mapping lookup in the destination address field. Note that this > > > destination RLOC MAY be an intermediate, proxy device that has > > > better knowledge of the EID-to-RLOC mapping closer to the > > > > > > This doesn't seem like a 2119 MAY is necessary, but rather a statement > of > > > fact that may not be known to the encapsulating ITR. > > > > > > Specifically, when a service provider prepends a LISP header for > > > Traffic Engineering purposes, the router that does this is also > > > regarded as an ITR. The outer RLOC the ISP ITR uses can be > based > > > on the outer destination address (the originating ITR's supplied > > > RLOC) or the inner destination address (the originating host's > > > supplied EID). > > > > > > I'm confused here, perhaps in multiple ways. Are there now *two* LISP > > > headers on the packet? Is the "outer RLOC the ISP ITR uses" the source > > > RLOC or the destination RLOC? > > > > > > Negative Mapping Entry: A negative mapping entry, also known as a > > > negative cache entry, is an EID-to-RLOC entry where an > EID-Prefix > > > is advertised or stored with no RLOCs. That is, the Locator-Set > > > for the EID-to-RLOC entry is empty or has an encoded Locator > count > > > of 0. > > > > > > Is "empty" a distinct representation from "locator count of zero"? > > > > > > Perhaps something of an aside, but the check described for > > > Route-Returnability is a somewhat weak check, and in some cases could > still > > > be spoofed. (I don't expect this to surprise anyone, of course, but > > > perhaps some more qualifiers could be added to the text.) > > > > > > Section 4 > > > > > > An additional LISP header MAY be prepended to packets by a TE-ITR > > > when re-routing of the path for a packet is desired. A potential > > > use-case for this would be an ISP router that needs to perform > > > Traffic Engineering for packets flowing through its network. In > such > > > a situation, termed "Recursive Tunneling", an ISP transit acts as > an > > > additional ITR, and the RLOC it uses for the new prepended header > > > would be either a TE-ETR within the ISP (along an intra-ISP traffic > > > engineered path) or a TE-ETR within another ISP (an inter-ISP > traffic > > > engineered path, where an agreement to build such a path exists). > > > > > > "the RLOC it uses for the new prepnded header", again, this is as the > > > destination RLOC (vs. source RLOC)? > > > > > > Section 4.1 > > > > > > o Map-Replies are sent on the underlying routing system topology > > > using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. > > > > > > Just to check my understanding: is the "underlying routing system > topology" > > > the same as the "underlay"? > > > > > > Is step (3) just describing more of what step (2) says is "not > described in > > > this example"? > > > > > > Section 5.3 > > > > > > The word "nonce" is normally used for something used exactly once. > > > E.g., with some AEAD algorithms, if the same "nonce" input is used for > > > different encryptions, the entire security of the system is > compromised. > > > It would be better to refer to this field with a different term, given > > > that "the same nonce can be used for a period of time when > encapsulating to > > > the same ETR". "Uniquifier" or "random value" might be reasonable > choices. > > > > > > Why is there no discussion of the Map-Version or Instance-ID fields > > > in this section? > > > > > > When doing ETR/PETR decapsulation: > > > > > > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > > > the case of IPv6) SHOULD be copied from the outer-header 'Time > to > > > Live' field, when the Time to Live value of the outer header is > > > less than the Time to Live value of the inner header. Failing > to > > > perform this check can cause the Time to Live of the inner > header > > > to increment across encapsulation/decapsulation cycles. This > > > check is also performed when doing initial encapsulation, when a > > > packet comes to an ITR or PITR destined for a LISP site. > > > > > > Er, what is "this check" that is also performed for initial > encapsulation? > > > How are there multiple TTL values to compare? > > > > > > o The inner-header 'Differentiated Services Code Point' (DSCP) > field > > > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be > > > copied from the outer-header DSCP field ('Traffic Class' field, > in > > > the case of IPv6) to the inner-header. > > > > > > nit: the first "inner-header" seems like an editing remnant? > > > > > > Section 7.1 > > > > > > How is this stateless if it invovles knowledge about the routers > between > > > the ITR and all possible ETRs (i.e., a set that could change over > time)? > > > > > > Section 8 > > > > > > This 32-bit vs 24-bit thing is pretty hokey for a standards-track > > > specification (yes, I know that LISP-DDT is not standards track at the > > > moment). > > > > > > Section 9 > > > > > > Alternatively, RLOC information MAY be gleaned from received > tunneled > > > > > > What is this an alternative to? The list of four options above? > > > > > > packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache > > > entry, one learned from the source RLOC of a received encapsulated > > > packet, is only stored and used for a few seconds, pending > > > verification. Verification is performed by sending a Map-Request > to > > > the source EID (the inner-header IP source address) of the received > > > encapsulated packet. > > > > > > The source EID is some random end system, right? So this relys on some > > > magic in the ETR to detect that there's a Map-Request and reply > directly > > > instead of passing it on to the EID that won't know what to do with it? > > > > > > Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and > > > might benefit from an explicit section reference to the other document. > > > > > > Section 10 > > > > > > What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it > > > is not marked as well-known at > > > https://www.rfc-editor.org/materials/abbrev.expansion.txt so > expansion is > > > probably in order. > > > > > > Again, when we are talking about the internal structure of the > Map-Reply, a > > > detailed section refernce to 6833bis is useful. > > > > > > Modifying LSBs seems like a fine DoS attack vector for an on-path > attacker. > > > > > > value of 1. Locator-Status-Bits are associated with a Locator-Set > > > per EID-Prefix. Therefore, when a Locator becomes unreachable, the > > > Locator-Status-Bit that corresponds to that Locator's position in > the > > > list returned by the last Map-Reply will be set to zero for that > > > particular EID-Prefix > > > > > > Doesn't this imply a stateful relationship between the ordering of > > > Map-Replys and data-plane traffic? > > > > > > Section 10.1 > > > > > > Note that "ITR" and "ETR" are relative terms here. Both devices > MUST > > > be implementing both ITR and ETR functionality for the echo nonce > > > mechanism to operate. > > > > > > Perhaps they could be given actual names so as to disambiguate which > steps > > > are performed with ITR vs. ETR role? > > > > > > The echo-nonce algorithm is bilateral. That is, if one side sets > the > > > E-bit and the other side is not enabled for echo-noncing, then the > > > echoing of the nonce does not occur and the requesting side may > > > erroneously consider the Locator unreachable. An ITR SHOULD only > set > > > the E-bit in an encapsulated data packet when it knows the ETR is > > > enabled for echo-noncing. This is conveyed by the E-bit in the > RLOC- > > > probe Map-Reply message. > > > > > > Why is this even optional? If it was mandatory to use, then there > would > > > not be a question. But at least clarify that the "this" that is > conveyed > > > is whether the peer supports the echo-nonce algorithm. (Also, subject > to > > > downgrade.) > > > > > > Section 13 > > > > > > When a Locator record is removed from a Locator-Set, ITRs that have > > > the mapping cached will not use the removed Locator because the > xTRs > > > will set the Locator-Status-Bit to 0. So, even if the Locator is > in > > > the list, it will not be used. For new mapping requests, the xTRs > > > can set the Locator AFI to 0 (indicating an unspecified address), > as > > > well as setting the corresponding Locator-Status-Bit to 0. This > > > forces ITRs with old or new mappings to avoid using the removed > > > Locator. > > > > > > The behavior describe here seems like it would be better described as > "when > > > a Locator is taken out of service" than "removed from a Locator-Set", > since > > > if it is not in the set at all, it has no index, and no LSB or AFI to > set. > > > Should actually depopulating it like this be forbidden? > > > > > > I guess the Map Versioning is supposed to help with this, but we need > to > > > nail down the semantics more and/or give a clearer reference to it. > > > > > > Section 13.1 > > > > > > An ITR, when it encapsulates packets to ETRs, can convey its own > Map- > > > Version Number. This is known as the Source Map-Version Number. > > > > > > Replacing "its own Map-Version Number" with something like "the > Map-Version > > > numer for the LISP site of which it is a part". Writing this causes > me to > > > note that the semantics of the Map-Version are unclear, here -- what > is it > > > scoped to? An EID-Prefix? An RLOC? Oh, you say that in the next > > > paragraph (EID-Prefix). > > > > > > A Map-Version Number can be included in Map-Register messages as > > > well. This is a good way for the Map-Server to assure that all > ETRs > > > for a site registering to it will be synchronized according to Map- > > > Version Number. > > > > > > Huh? I must be confused how this works. (Also, wouldn't this be > better in > > > the control plane document which covers Map-Register?) > > > > > > Section 15 > > > > > > o When a tunnel-encapsulated packet is received by an ETR, the > outer > > > destination address may not be the address of the router. This > > > makes it challenging for the control plane to get packets from > the > > > hardware. This may be mitigated by creating special Forwarding > > > Information Base (FIB) entries for the EID-Prefixes of EIDs > served > > > by the ETR (those for which the router provides an RLOC > > > translation). These FIB entries are marked with a flag > indicating > > > that Control-Plane processing SHOULD be performed. > > > > > > I assume this is just my lack of background showing, but I'm confused > how > > > it makes sense to mark these for control-plane processing. Isn't the > > > control plane much slower, and we're not putting all of the LISP > data-plane > > > traffic onto the slow path? > > > > > > Section 18 > > > > > > o Data-Plane gleaning for creating map-cache entries has been made > > > optional. If any ITR implementations depend or assume the > remote > > > ETR is gleaning should not do so. > > > > > > nit: this is ungrammatical; "they should not" or "Any ITR > implementations > > > that depend on or assume that" would fix it. > > > > > > Section 19.1 > > > > > > Presumably IANA also updated the reference column to point to this > > > document? > > > > > > > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --00000000000022b03c05772f687b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would say "(a) desirable". I a= gree with Dino that the more secure, the better.

Also, thanks for gathering the WG opinion on this Joel. I think that it = may help if you re-send this question with a more explicit subject line. Ho= pefully that will catch the attention of those at the WG that may not be fo= llowing this discussion in detail.

Thanks,
Alberto

O= n Fri, Sep 28, 2018 at 3:38 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
As co-chair, I would like to hear from the working group as = to whether
making LISP-SEC mandatory to Implement (not Mandatory to Use) for
LISP6830bis and 6833bis implementations is
a) desirable
b) acceptable
c) undesirable but livable
d) unacceptable or worse.

Please, do not just pick a letter.=C2=A0 Include explanation of your opinio= n.
This is not a decision the ADs and Authors can make for the working group.<= br>
Yours,
Joel


-------- Forwarded Message --------
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20:=
(with DISCUSS and COMMENT)
Date: Fri, 28 Sep 2018 17:03:40 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Joel M. Halpern <jmh@joelhalpern.com>
CC: The IESG <iesg@ie= tf.org>, draft-ietf-lisp-rfc6830bis@ietf.org, Luigi
Iannone <ggx@gigix.ne= t>, lisp-c= hairs@ietf.org, lisp= @ietf.org

Hi Joel,


On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote:
> Is there text we can add about the scoping that will change your discu= ss
> into a series of useful comments?

I had attempted to structure my Discuss points so that they would either be=
useful comments as is, or rendered moot by a reduced scope.=C2=A0 I guess I= can
try to clarify those below.=C2=A0 (To be clear, reducing the scope is only = going
to move from "has potentially existentially bad problems" to &quo= t;has
substantial issues that likely require reengineering to resolve".)

> If so, Some indication of how you would like that phrased would help u= s
> address these.

I think Ekr's ballot position on 6833bis has a good summary of the
architecture assumptions that the reduced scope allows us to make.
In order to have the document be able to plausibly make those claims, it looks like we'd need to at least:
(1) update the Abstract/Introduction to clarify that the EID namespace is =C2=A0 =C2=A0 =C2=A0only defined within a single administrative domain.
(2) (optionally, if it makes sense) mention in the introduction that this =C2=A0 =C2=A0 =C2=A0administrative domain can include transport over other = networks in the
=C2=A0 =C2=A0 =C2=A0same way that a VPN would function[*], without requirin= g cooperation
=C2=A0 =C2=A0 =C2=A0from or interaction with the other networks' admini= strators
(3) remove the "global" text from the EID-to-RLOC Database and Ma= p-Cache
=C2=A0 =C2=A0 =C2=A0definitions
(4) update the EID-Prefix definition to talk about the local site or
=C2=A0 =C2=A0 =C2=A0administrative domain's "address allocation au= thority"
(5) Take a look at the EID definition to consider whether references to &qu= ot;on
=C2=A0 =C2=A0 =C2=A0the public Internet" are still valid, and the text= about assignment
=C2=A0 =C2=A0 =C2=A0in a hierarchical manner should be revised for the new = scope as well.
=C2=A0 =C2=A0 =C2=A0Likewise for EID-internal structure that is "not v= isible to the global
=C2=A0 =C2=A0 =C2=A0routing system"

(I stopped skimming and looking for problematic text around section 6)

[*] Ideally this would be done without using the term "VPN" itsel= f, since
I'd like to get a movement going to restrict "VPN" to include=
confidentiality (i.e., privacy) protection.=C2=A0 "virtual network&quo= t; or "overlay
network" may or may not be good candidate replacement terms.

> If not, we seem to have a larger problem.

Well, we appear to have five ADs that are supporting making LISP-SEC a
normative reference and thus MTI; I don't know if that scale of change<= br> meets your threshold for a "larger problem".

> Yours,
> Joel
>
> On 9/26/18 11:44 PM, Benjamin Kaduk wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-lisp-rfc6830bis-20: Discuss
> >
> > When responding, please keep the subject line intact and reply to= all
> > email addresses included in the To and CC lines. (Feel free to cu= t this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.= org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.org/d= oc/draft-ietf-lisp-rfc6830bis/
> >
> >
> >
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
> > I have grave concerns about the suitability of LISP as a whole, i= n its
> > present form, for advancement to the Standards-Track.=C2=A0 While= some of my
> > concerns are not specific to this document, as the core protocol<= br> > > (data-plane) spec, it seems an appropriate place to attach them t= o.
> >
> > I am told, out of band, that the intended deployment model is no = longer to
> > cover the entire Internet (c.f. the MISSREF-state
> > draft-ietf-lisp-introduction's "with LISP, the dge of th= e Internet and the
> > core can be logically separated and interconnected by LISP-capabl= e
> > routers", etc.), and that full Internet-scale operation is n= o longer a
> > goal.=C2=A0 However, since that does not seem to be reflected in = the current
> > batch of documents up for IESG review, I am forced to ballot on t= hem
> > "as-is", namely as targetting global Internet deploymen= t.=C2=A0 The requirements
> > placed on the mapping system are so stringent so as to be arguabl= y
> > unachievable at Internet-scale, though that arguably has more of = an
> > interaction with the control-plane than the data-plane.=C2=A0 It&= #39;s still in
> > scope here, though, as part of the overall description of the pro= tocol
> > flow.

(rendered moot by scope reduction)

> > There are an almost innumerable number of downgrade attacks possi= ble, and
> > the control-plane and data-plane security mechanisms are not norm= ative
> > dependencies of the current corpus of documents, and as such are = not up for
> > consideration as mitigating the security concerns with the core d= ocuments.

The downgrade attacks will probably require some further analysis; LISP-SEC=
would protect a lot of the header bits but I think there may be some other<= br> data flows to be looked at.

> > Section 3 defines the EID-to-RLOC Datbaase:
> >
> >=C2=A0 =C2=A0 =C2=A0EID-to-RLOC Database:=C2=A0 =C2=A0The EID-to-R= LOC Database is a global
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 distributed database that contains all= known EID-Prefix-to-RLOC
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 mappings.=C2=A0 Each potential ETR typ= ically contains a small piece of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the database: the EID-to-RLOC mappings= for the EID-Prefixes
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 "behind" the router.=C2=A0 T= hese map to one of the router's own
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 globally visible IP addresses.=C2=A0 N= ote that there MAY be transient
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 conditions when the EID-Prefix for the= site and Locator-Set for
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 each EID-Prefix may not be the same on= all ETRs.=C2=A0 This has no
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 negative implications, since a partial= set of Locators can be
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 used.
> >
> > No compelling architecture for a trustworthy global distributed d= atabase
> > has been presented that I've seen so far, and LISP relies hea= vily on the
> > mapping system's database for its functionality.=C2=A0 I am c= oncerned that so
> > many requirements are placed on the mapping system so as to be in= effect
> > unimplementable, in which case it would seem that the architectur= e as a
> > whole (that is, for a global Internet-scale system) is not fit fo= r purpose.

(rendered moot by scope reduction)

> > Section 4.1's Step (6) only mentions parsing "to check f= or format
> > validity".=C2=A0 I think it is appropriate to mention (and r= efer to) source
> > authentication checks as well, since bad Map-Reply data can allow= all sorts
> > of attacks to occur.

(not affected by scope reduction)

> > There are some fairly subtle ordering requirements between the or= der of
> > entries in Map-Reply messages and the Locator-Status-Bits in data= -plane
> > traffic (so that the semantic meaning of the status bits are mean= ingful),
> > which is only given a minimal treatment in the control-plane docu= ment.=C2=A0 The
> > need for synchronization in interpreting these bits should be men= tioned
> > more prominently in the data-plane document as well.

(not affected by scope reduction)

> >
> > The usage of the Instance ID does not seem to be adequately cover= ed; from
> > what I've been able to pick up so far it seems that both sour= ce and
> > destination participants must agree on the meaning of an Instance= ID, and
> > the source and destination EIDs must be in the same Instance.=C2= =A0 This does
> > not seem like it is compatible with Internet scale, especially if= there are
> > only 24 usable bits of Instance ID.

(not affected by scope reduction)

> >
> > There seems to be a lot of intra-site synchronization requirement= s, notably
> > with respect to Map-Version consistency, the contents and orderin= g of
> > locator sets for EIDs in the site, etc.; the actual hard requirem= ents for
> > synchronization within a site should be clearly called out, ideal= ly in a
> > single location.

(not affected by scope reduction, since ETRs are affected and not just
Map-Servers)

> >
> > The security considerations attempt to defer substantially to the=
> > threat-analysis in RFC 7835, which does not really seem like a co= mplete
> > threat analysis and does not provide analysis as to what requirem= ents are
> > placed on the boundaries between the different components of LISP= (data
> > plane, control plane, mapping system, various extensions, etc.).= =C2=A0 The
> > secdir reviewer had some good thoughts in this space.

(not affected by scope reduction)

> >
> > The security considerations throughout the LISP documents place a= heavy
> > focus on the risk of over-claiming for routing EID-prefixes.=C2= =A0 This is a
> > real concern, to be clear, but it should not overshadow the risk = of an
> > attacker who is able to move traffic around at will, strip securi= ty
> > protections, cause denial of service, alter data-plane payloads, = etc.
> > Similarly, this document's security considerations call out d= enial of
> > service as a risk from Map-Cache insertion/spoofing, but the risk= s from an
> > attacker being able to read and modify the traffic, perhaps even = without
> > detection, seems a much greater threat to me.

(not affected by scope reduction)

> >
> > I am not convinced that this protocol meets the current IETF requ= irements
> > for the security properties of Standards-Track Protocols without = at least
> > LISP-SEC as a mandatory-to-implement component, and possibly addi= tional or
> > stronger requirements.=C2=A0 (I did not do a full analysis of the= system in the
> > presence of those security mechanisms, since that is not what is = being
> > presented for review.)

(noting that LISP-SEC needs to be MTI and analysis performed under the new<= br> assumptions)

> > Having an EID that is associated to user-correlatable devices has= severe
> > privacy considerations, but I could not find this mentioned anywh= ere in all
> > of the LISP documents I've read so far.

(not affected by scope reduction)

-Benjamin

> >
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > I apologize for the somewhat scattered nature of these comments; = there are
> > a lot of them and I was focusing my time more on trying to unders= tand the
> > broader system, and the intended security posture, so they did no= t get as
> > much clean-up as I would have liked.=C2=A0 (Most of my review was= performed on the
> > -18, though I have tried to update to the -20 as relevant.)
> >
> >
> > The instance ID provides for organizational correlation, another = privacy
> > exposure.
> >
> > Is there anything different between an "EID-to-RLOC Map-Requ= est" and just a
> > "Map-Request"?=C2=A0 (Same question for "Map-Reply= ", too.)
> >
> > There's a lot of stuff that seems to work best if there is sy= mmetric
> > bidirectional traffic, with inline signalling of map version and<= br> > > reachability changes, though clearly everything is designed to al= so work
> > with asymmetric connectivity or unidirectional traffic.=C2=A0 It = would be nice
> > to have a high-level summary in or near the introduction about wh= at kinds
> > of behavior/performance differences are expected for bidirectiona= l vs.
> > unidirectional traffic.
> >
> > Section 2
> >
> > That's not the 8174 boilerplate; it's more than just addi= ng a cite to the
> > 2119 boilerplate.
> >
> > Section 3
> >
> > nit: "An address family that pertains to the Data-Plane.&quo= t; is a sentence
> > fragment.
> >
> >=C2=A0 =C2=A0 =C2=A0Ingress Tunnel Router (ITR):=C2=A0 =C2=A0An IT= R is a router that resides in a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 mapping lookup in the destination addr= ess field.=C2=A0 Note that this
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 destination RLOC MAY be an intermediat= e, proxy device that has
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 better knowledge of the EID-to-RLOC ma= pping closer to the
> >
> > This doesn't seem like a 2119 MAY is necessary, but rather a = statement of
> > fact that may not be known to the encapsulating ITR.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Specifically, when a service provider = prepends a LISP header for
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Traffic Engineering purposes, the rout= er that does this is also
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 regarded as an ITR.=C2=A0 The outer RL= OC the ISP ITR uses can be based
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 on the outer destination address (the = originating ITR's supplied
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 RLOC) or the inner destination address= (the originating host's
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 supplied EID).
> >
> > I'm confused here, perhaps in multiple ways.=C2=A0 Are there = now *two* LISP
> > headers on the packet?=C2=A0 Is the "outer RLOC the ISP ITR = uses" the source
> > RLOC or the destination RLOC?
> >
> >=C2=A0 =C2=A0 =C2=A0Negative Mapping Entry:=C2=A0 =C2=A0A negative= mapping entry, also known as a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 negative cache entry, is an EID-to-RLO= C entry where an EID-Prefix
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 is advertised or stored with no RLOCs.= =C2=A0 That is, the Locator-Set
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 for the EID-to-RLOC entry is empty or = has an encoded Locator count
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 of 0.
> >
> > Is "empty" a distinct representation from "locator= count of zero"?
> >
> > Perhaps something of an aside, but the check described for
> > Route-Returnability is a somewhat weak check, and in some cases c= ould still
> > be spoofed.=C2=A0 (I don't expect this to surprise anyone, of= course, but
> > perhaps some more qualifiers could be added to the text.)
> >
> > Section 4
> >
> >=C2=A0 =C2=A0 =C2=A0An additional LISP header MAY be prepended to = packets by a TE-ITR
> >=C2=A0 =C2=A0 =C2=A0when re-routing of the path for a packet is de= sired.=C2=A0 A potential
> >=C2=A0 =C2=A0 =C2=A0use-case for this would be an ISP router that = needs to perform
> >=C2=A0 =C2=A0 =C2=A0Traffic Engineering for packets flowing throug= h its network.=C2=A0 In such
> >=C2=A0 =C2=A0 =C2=A0a situation, termed "Recursive Tunneling&= quot;, an ISP transit acts as an
> >=C2=A0 =C2=A0 =C2=A0additional ITR, and the RLOC it uses for the n= ew prepended header
> >=C2=A0 =C2=A0 =C2=A0would be either a TE-ETR within the ISP (along= an intra-ISP traffic
> >=C2=A0 =C2=A0 =C2=A0engineered path) or a TE-ETR within another IS= P (an inter-ISP traffic
> >=C2=A0 =C2=A0 =C2=A0engineered path, where an agreement to build s= uch a path exists).
> >
> > "the RLOC it uses for the new prepnded header", again, = this is as the
> > destination RLOC (vs. source RLOC)?
> >
> > Section 4.1
> >
> >=C2=A0 =C2=A0 =C2=A0o=C2=A0 Map-Replies are sent on the underlying= routing system topology
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 using the [I-D.ietf-lisp-rfc6833bis] C= ontrol-Plane protocol.
> >
> > Just to check my understanding: is the "underlying routing s= ystem topology"
> > the same as the "underlay"?
> >
> > Is step (3) just describing more of what step (2) says is "n= ot described in
> > this example"?
> >
> > Section 5.3
> >
> > The word "nonce" is normally used for something used ex= actly once.
> > E.g., with some AEAD algorithms, if the same "nonce" in= put is used for
> > different encryptions, the entire security of the system is compr= omised.
> > It would be better to refer to this field with a different term, = given
> > that "the same nonce can be used for a period of time when e= ncapsulating to
> > the same ETR".=C2=A0 "Uniquifier" or "random = value" might be reasonable choices.
> >
> > Why is there no discussion of the Map-Version or Instance-ID fiel= ds
> > in this section?
> >
> > When doing ETR/PETR decapsulation:
> >
> >=C2=A0 =C2=A0 =C2=A0o=C2=A0 The inner-header 'Time to Live'= ; field (or 'Hop Limit' field, in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the case of IPv6) SHOULD be copied fro= m the outer-header 'Time to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Live' field, when the Time to Live= value of the outer header is
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 less than the Time to Live value of th= e inner header.=C2=A0 Failing to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 perform this check can cause the Time = to Live of the inner header
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 to increment across encapsulation/deca= psulation cycles.=C2=A0 This
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 check is also performed when doing ini= tial encapsulation, when a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 packet comes to an ITR or PITR destine= d for a LISP site.
> >
> > Er, what is "this check" that is also performed for ini= tial encapsulation?
> > How are there multiple TTL values to compare?
> >
> >=C2=A0 =C2=A0 =C2=A0o=C2=A0 The inner-header 'Differentiated S= ervices Code Point' (DSCP) field
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 (or the 'Traffic Class' field,= in the case of IPv6) SHOULD be
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 copied from the outer-header DSCP fiel= d ('Traffic Class' field, in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the case of IPv6) to the inner-header.=
> >
> > nit: the first "inner-header" seems like an editing rem= nant?
> >
> > Section 7.1
> >
> > How is this stateless if it invovles knowledge about the routers = between
> > the ITR and all possible ETRs (i.e., a set that could change over= time)?
> >
> > Section 8
> >
> > This 32-bit vs 24-bit thing is pretty hokey for a standards-track=
> > specification (yes, I know that LISP-DDT is not standards track a= t the
> > moment).
> >
> > Section 9
> >
> >=C2=A0 =C2=A0 =C2=A0Alternatively, RLOC information MAY be gleaned= from received tunneled
> >
> > What is this an alternative to?=C2=A0 The list of four options ab= ove?
> >
> >=C2=A0 =C2=A0 =C2=A0packets or EID-to-RLOC Map-Request messages.= =C2=A0 A "gleaned" Map-Cache
> >=C2=A0 =C2=A0 =C2=A0entry, one learned from the source RLOC of a r= eceived encapsulated
> >=C2=A0 =C2=A0 =C2=A0packet, is only stored and used for a few seco= nds, pending
> >=C2=A0 =C2=A0 =C2=A0verification.=C2=A0 Verification is performed = by sending a Map-Request to
> >=C2=A0 =C2=A0 =C2=A0the source EID (the inner-header IP source add= ress) of the received
> >=C2=A0 =C2=A0 =C2=A0encapsulated packet.
> >
> > The source EID is some random end system, right?=C2=A0 So this re= lys on some
> > magic in the ETR to detect that there's a Map-Request and rep= ly directly
> > instead of passing it on to the EID that won't know what to d= o with it?
> >
> > Talking about the "R-bit" of the Map-Reply" is det= ail from 6833bis and
> > might benefit from an explicit section reference to the other doc= ument.
> >
> > Section 10
> >
> > What is the "CE" of "CE-based ITRs"?=C2=A0 Pr= esumably Customer Edge, but it
> > is not marked as well-known at
> > https://www.rfc-editor.org/materi= als/abbrev.expansion.txt so expansion is
> > probably in order.
> >
> > Again, when we are talking about the internal structure of the Ma= p-Reply, a
> > detailed section refernce to 6833bis is useful.
> >
> > Modifying LSBs seems like a fine DoS attack vector for an on-path= attacker.
> >
> >=C2=A0 =C2=A0 =C2=A0value of 1.=C2=A0 Locator-Status-Bits are asso= ciated with a Locator-Set
> >=C2=A0 =C2=A0 =C2=A0per EID-Prefix.=C2=A0 Therefore, when a Locato= r becomes unreachable, the
> >=C2=A0 =C2=A0 =C2=A0Locator-Status-Bit that corresponds to that Lo= cator's position in the
> >=C2=A0 =C2=A0 =C2=A0list returned by the last Map-Reply will be se= t to zero for that
> >=C2=A0 =C2=A0 =C2=A0particular EID-Prefix
> >
> > Doesn't this imply a stateful relationship between the orderi= ng of
> > Map-Replys and data-plane traffic?
> >
> > Section 10.1
> >
> >=C2=A0 =C2=A0 =C2=A0Note that "ITR" and "ETR" = are relative terms here.=C2=A0 Both devices MUST
> >=C2=A0 =C2=A0 =C2=A0be implementing both ITR and ETR functionality= for the echo nonce
> >=C2=A0 =C2=A0 =C2=A0mechanism to operate.
> >
> > Perhaps they could be given actual names so as to disambiguate wh= ich steps
> > are performed with ITR vs. ETR role?
> >
> >=C2=A0 =C2=A0 =C2=A0The echo-nonce algorithm is bilateral.=C2=A0 T= hat is, if one side sets the
> >=C2=A0 =C2=A0 =C2=A0E-bit and the other side is not enabled for ec= ho-noncing, then the
> >=C2=A0 =C2=A0 =C2=A0echoing of the nonce does not occur and the re= questing side may
> >=C2=A0 =C2=A0 =C2=A0erroneously consider the Locator unreachable.= =C2=A0 An ITR SHOULD only set
> >=C2=A0 =C2=A0 =C2=A0the E-bit in an encapsulated data packet when = it knows the ETR is
> >=C2=A0 =C2=A0 =C2=A0enabled for echo-noncing.=C2=A0 This is convey= ed by the E-bit in the RLOC-
> >=C2=A0 =C2=A0 =C2=A0probe Map-Reply message.
> >
> > Why is this even optional?=C2=A0 If it was mandatory to use, then= there would
> > not be a question.=C2=A0 But at least clarify that the "this= " that is conveyed
> > is whether the peer supports the echo-nonce algorithm.=C2=A0 (Als= o, subject to
> > downgrade.)
> >
> > Section 13
> >
> >=C2=A0 =C2=A0 =C2=A0When a Locator record is removed from a Locato= r-Set, ITRs that have
> >=C2=A0 =C2=A0 =C2=A0the mapping cached will not use the removed Lo= cator because the xTRs
> >=C2=A0 =C2=A0 =C2=A0will set the Locator-Status-Bit to 0.=C2=A0 So= , even if the Locator is in
> >=C2=A0 =C2=A0 =C2=A0the list, it will not be used.=C2=A0 For new m= apping requests, the xTRs
> >=C2=A0 =C2=A0 =C2=A0can set the Locator AFI to 0 (indicating an un= specified address), as
> >=C2=A0 =C2=A0 =C2=A0well as setting the corresponding Locator-Stat= us-Bit to 0.=C2=A0 This
> >=C2=A0 =C2=A0 =C2=A0forces ITRs with old or new mappings to avoid = using the removed
> >=C2=A0 =C2=A0 =C2=A0Locator.
> >
> > The behavior describe here seems like it would be better describe= d as "when
> > a Locator is taken out of service" than "removed from a= Locator-Set", since
> > if it is not in the set at all, it has no index, and no LSB or AF= I to set.
> > Should actually depopulating it like this be forbidden?
> >
> > I guess the Map Versioning is supposed to help with this, but we = need to
> > nail down the semantics more and/or give a clearer reference to i= t.
> >
> > Section 13.1
> >
> >=C2=A0 =C2=A0 =C2=A0An ITR, when it encapsulates packets to ETRs, = can convey its own Map-
> >=C2=A0 =C2=A0 =C2=A0Version Number.=C2=A0 This is known as the Sou= rce Map-Version Number.
> >
> > Replacing "its own Map-Version Number" with something l= ike "the Map-Version
> > numer for the LISP site of which it is a part".=C2=A0 Writin= g this causes me to
> > note that the semantics of the Map-Version are unclear, here -- w= hat is it
> > scoped to?=C2=A0 An EID-Prefix?=C2=A0 An RLOC?=C2=A0 Oh, you say = that in the next
> > paragraph (EID-Prefix).
> >
> >=C2=A0 =C2=A0 =C2=A0A Map-Version Number can be included in Map-Re= gister messages as
> >=C2=A0 =C2=A0 =C2=A0well.=C2=A0 This is a good way for the Map-Ser= ver to assure that all ETRs
> >=C2=A0 =C2=A0 =C2=A0for a site registering to it will be synchroni= zed according to Map-
> >=C2=A0 =C2=A0 =C2=A0Version Number.
> >
> > Huh?=C2=A0 I must be confused how this works.=C2=A0 (Also, wouldn= 't this be better in
> > the control plane document which covers Map-Register?)
> >
> > Section 15
> >
> >=C2=A0 =C2=A0 =C2=A0o=C2=A0 When a tunnel-encapsulated packet is r= eceived by an ETR, the outer
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 destination address may not be the add= ress of the router.=C2=A0 This
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 makes it challenging for the control p= lane to get packets from the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 hardware.=C2=A0 This may be mitigated = by creating special Forwarding
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Information Base (FIB) entries for the= EID-Prefixes of EIDs served
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 by the ETR (those for which the router= provides an RLOC
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 translation).=C2=A0 These FIB entries = are marked with a flag indicating
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 that Control-Plane processing SHOULD b= e performed.
> >
> > I assume this is just my lack of background showing, but I'm = confused how
> > it makes sense to mark these for control-plane processing.=C2=A0 = Isn't the
> > control plane much slower, and we're not putting all of the L= ISP data-plane
> > traffic onto the slow path?
> >
> > Section 18
> >
> >=C2=A0 =C2=A0 =C2=A0o=C2=A0 Data-Plane gleaning for creating map-c= ache entries has been made
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 optional.=C2=A0 If any ITR implementat= ions depend or assume the remote
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ETR is gleaning should not do so.
> >
> > nit: this is ungrammatical; "they should not" or "= Any ITR implementations
> > that depend on or assume that" would fix it.
> >
> > Section 19.1
> >
> > Presumably IANA also updated the reference column to point to thi= s
> > document?
> >
> >
> >

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
--00000000000022b03c05772f687b-- From nobody Mon Oct 1 12:08:29 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DA2130DE8 for ; Mon, 1 Oct 2018 12:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ltgbca-y-uaX for ; Mon, 1 Oct 2018 12:08:26 -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 6AAB61252B7 for ; Mon, 1 Oct 2018 12:08:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1C9D54C5E3D for ; Mon, 1 Oct 2018 12:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1538420906; bh=leqNKV4cg655MZCoLJzCiDq+RLLWdC/7IoEq3vvQyx4=; h=From:Subject:To:References:Date:In-Reply-To:From; b=Csu3ARDap+wA/gphVFvFpflC+/X+ETiglD3A0nlYzGd9WC1LuuX3xSy9WX1m63vK+ Z92VKOxu6hUna6qtYXG/2XNa0Z0gePf9wmDpSdv3y/0OK4xtN5P0eUgCqYhy7+ba2h j/sY4h/Z4TtJX4xrdeUVz+KsLjOGQq8JtfPOxrII= 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 B081B4C5E4C for ; Mon, 1 Oct 2018 12:08:25 -0700 (PDT) From: Joel Halpern To: "lisp@ietf.org" References: <20180928220340.GO24695@kduck.kaduk.org> Message-ID: <05a23aad-e088-5931-93dd-707908193574@joelhalpern.com> Date: Mon, 1 Oct 2018 15:08:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180928220340.GO24695@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] Making LISP-SEC mandatory to implement X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 19:08:28 -0000 [Alberto usefully suggested I resend this with a clearer subject line, so folks notice it. So I am doing so. There is no need to answer twice. Just answer one of the two email requests. Please.] As co-chair, I would like to hear from the working group as to whether making LISP-SEC mandatory to Implement (not Mandatory to Use) for LISP6830bis and 6833bis implementations is a) desirable b) acceptable c) undesirable but livable d) unacceptable or worse. Please, do not just pick a letter. Include explanation of your opinion. This is not a decision the ADs and Authors can make for the working group. Yours, Joel From nobody Mon Oct 1 13:34:10 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC311252B7; Mon, 1 Oct 2018 13:34:02 -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.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153842604293.22282.561994645250168841@ietfa.amsl.com> Date: Mon, 01 Oct 2018 13:34:02 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-22.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:34:03 -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-22.txt Pages : 45 Date : 2018-10-01 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-22 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-22 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 Oct 1 19:44:33 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 BCA32127148; Mon, 1 Oct 2018 19:44:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153844826576.22439.2169769692932578945.idtracker@ietfa.amsl.com> Date: Mon, 01 Oct 2018 19:44:25 -0700 Archived-At: Subject: [lisp] Suresh Krishnan's No Objection on draft-ietf-lisp-rfc6830bis-22: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 02:44:26 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-lisp-rfc6830bis-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. From nobody Tue Oct 2 17:24:12 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 B17381310A7; Tue, 2 Oct 2018 17:24:10 -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.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153852625066.11201.12723342182648507896@ietfa.amsl.com> Date: Tue, 02 Oct 2018 17:24:10 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-mn-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 00:24:11 -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 Mobile Node Authors : Dino Farinacci Darrel Lewis David Meyer Chris White Filename : draft-ietf-lisp-mn-03.txt Pages : 23 Date : 2018-10-02 Abstract: This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-mn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-mn-03 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-mn-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 2 17:26:03 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4501310E0 for ; Tue, 2 Oct 2018 17:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMLkcDAr0E_w for ; Tue, 2 Oct 2018 17:25:59 -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 8C7F71310A7 for ; Tue, 2 Oct 2018 17:25:59 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id r77-v6so713299pgr.5 for ; Tue, 02 Oct 2018 17:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=M67uqmIeYx+JA6qtajWGN46NWb7OvJqqrkBPkmvBam8=; b=pOZxrqnxkbjfdyY67ijRcG1bXbx9GYsq3B2sFFj+I1X+YSXsnMyivfkb4U5hn4CD9/ nckoBkM/pKyrAjSRuaUoxwZRGNp1SiATw9lg4RJUgO+z2TTAtaj5rwkXp9ti3TWafdP3 RHmNPA6XxaN1llJZu4PGHgSEivNFrfSaRXCaqzHV91KWorUF64pHVtxL0q+hJNSxQrSx sAmuxo0zf6quO2e6HON7+essyO6lzfTTgWIEso8k0XT2YYRm0LMVt/kSfeEhO44pZjcM KmqZYk8iGClJwAuo9yPeD2QqPfWTNlo/udW0mPZNJfsbFkzq4f2CvYs19QgpMIXrWeBm Lfww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=M67uqmIeYx+JA6qtajWGN46NWb7OvJqqrkBPkmvBam8=; b=ulAME7o7Tg3K7nw5e074VnCOTWUBVM+WX+VtzkEn2rf44z1ZQJeDro2xoUflKNwLs9 nlC/Zed6kDXjgXY35GE7iwKE3Qcx9pjYiq36ZLRU8O5nQ6k5Znvf8g4FyYEhmWUl73/I DlLiMZB//yaKfwmpYvbOCMgEKZOF/fj4Gv+JhxixsLoXWZSa+oyfwneat6GkzwH6oLq2 GfmJzc9nymMmLMEX4DVypuXAAmmK73XbU3BML9GW+TetGdXNbBPoodEZEDUmdv1fev3L DHxTTbDK9yU4IGkDYX5AhHJXsIlaXSeXWf/JK2MOQ68MATZrk/HveN01jP0tRMu1BOtl l+ow== X-Gm-Message-State: ABuFfoh08hDbK9FPPqSpIUZp/4bBLafLndeQr/yO8BLl2ahfrm0HVJgW F7Qc65dK+pyDVco4aj2K6kGE6hUI X-Google-Smtp-Source: ACcGV63jvFOMLoUVNsVlJpEA33M7zX+RAU9hhLMZXAApjygzQb5tRwVMhW/hGNpvZpwPfgHPa9YOag== X-Received: by 2002:a63:1224:: with SMTP id h36-v6mr16724720pgl.120.1538526358878; Tue, 02 Oct 2018 17:25:58 -0700 (PDT) Received: from [10.228.203.131] (72-172-185-190.bayarea.net. [72.172.185.190]) by smtp.gmail.com with ESMTPSA id t26-v6sm9757297pfa.158.2018.10.02.17.25.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 17:25:58 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/alternative; boundary="Apple-Mail=_FCF39A75-9785-4F45-8E80-F84AA7ED93F7" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <52CCA048-6B56-4B7A-8628-279287361F89@gmail.com> References: <153852625066.11201.12723342182648507896@ietfa.amsl.com> To: "lisp@ietf.org list" Date: Tue, 2 Oct 2018 17:25:57 -0700 X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-mn-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 00:26:01 -0000 --Apple-Mail=_FCF39A75-9785-4F45-8E80-F84AA7ED93F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, this is the first example of having use-case documents IANA = request bits they need in LISP control messages. So the m-bit is being = unspecified in 6833bis and specified in LISP-MN. Cheers, Dino > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [lisp] I-D Action: draft-ietf-lisp-mn-03.txt > Date: October 2, 2018 at 5:24:10 PM PDT > To: > Cc: lisp@ietf.org > Reply-To: lisp@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Locator/ID Separation Protocol WG of = the IETF. >=20 > Title : LISP Mobile Node > Authors : Dino Farinacci > Darrel Lewis > David Meyer > Chris White > Filename : draft-ietf-lisp-mn-03.txt > Pages : 23 > Date : 2018-10-02 >=20 > Abstract: > This document describes how a lightweight version of LISP's ITR/ETR > functionality can be used to provide seamless mobility to a mobile > node. The LISP Mobile Node design described in this document uses > standard LISP functionality to provide scalable mobility for LISP > mobile nodes. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-mn/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lisp-mn-03 > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mn-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_FCF39A75-9785-4F45-8E80-F84AA7ED93F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Folks, this is the first example of having use-case documents = IANA request bits they need in LISP control messages. So the m-bit is = being unspecified in 6833bis and specified in LISP-MN.

Cheers,
Dino

Begin= forwarded message:

From: = internet-drafts@ietf.org
Subject: = [lisp] I-D = Action: draft-ietf-lisp-mn-03.txt
Date: = October 2, 2018 at 5:24:10 PM = PDT
To: = <i-d-announce@ietf.org>
Cc: lisp@ietf.org
Reply-To: = lisp@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Locator/ID = Separation Protocol WG of the IETF.

=        Title =           : LISP = Mobile Node
=        Authors =         : Dino Farinacci
=             &n= bsp;           &nbs= p;Darrel Lewis
=             &n= bsp;           &nbs= p;David Meyer
=             &n= bsp;           &nbs= p;Chris White
Filename =        : draft-ietf-lisp-mn-03.txt
= Pages =           : 23
= Date =            : = 2018-10-02

Abstract:
=   This document describes how a lightweight version of LISP's = ITR/ETR
  functionality can be used to provide = seamless mobility to a mobile
  node.  The = LISP Mobile Node design described in this document uses
=   standard LISP functionality to provide scalable mobility for = LISP
  mobile nodes.


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

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

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


Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

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

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

= --Apple-Mail=_FCF39A75-9785-4F45-8E80-F84AA7ED93F7-- From nobody Wed Oct 3 09:38:28 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 5011A131307; Wed, 3 Oct 2018 09:38:15 -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.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153858469527.9054.9223114132218592358@ietfa.amsl.com> Date: Wed, 03 Oct 2018 09:38:15 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-23.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 16:38:16 -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-23.txt Pages : 45 Date : 2018-10-03 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-23 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-23 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 Oct 3 09:52:21 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 F043D131292; Wed, 3 Oct 2018 09:52:12 -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.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153858553293.9096.15901488565248485039@ietfa.amsl.com> Date: Wed, 03 Oct 2018 09:52:12 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-17.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 16:52:13 -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-17.txt Pages : 56 Date : 2018-10-03 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, connecting EID addressable nodes of a LISP site, their implementation and operational complexity reduces the overall cost and effort of deploying LISP. This document obsoletes RFC 6830 and 6833. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-17 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 3 16:20:58 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D75512F295; Wed, 3 Oct 2018 16:20:56 -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.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153860885655.9112.7153769109912109285@ietfa.amsl.com> Date: Wed, 03 Oct 2018 16:20:56 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-mn-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 23:20:57 -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 Mobile Node Authors : Dino Farinacci Darrel Lewis David Meyer Chris White Filename : draft-ietf-lisp-mn-04.txt Pages : 24 Date : 2018-10-03 Abstract: This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-mn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-mn-04 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-mn-04 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 Oct 3 16:23: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 52FC7130DBE for ; Wed, 3 Oct 2018 16:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIvGff9QPZVm for ; Wed, 3 Oct 2018 16:22:58 -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 987AE126F72 for ; Wed, 3 Oct 2018 16:22:58 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id m77-v6so2392343pfi.8 for ; Wed, 03 Oct 2018 16:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=mf0orVw4pazHsYDZ+o8e29ORw+/nu8sTLGvIeM07tMg=; b=ZgsXZiqf+HZ33SnORRRyZMiT91xcxhC/KdWOtxSn4tpF1wstC4Lf3YYmJ0XKzcIkrx gx2LubeFQQqg6Zz6u7n+V1nOXPxfmztNd33nMIgQjVYI34bzp3Msryz4zRfXBaGI7Ke0 km3/o3xXX8ujz05WRrmUS51bGD1JKHrKJX/JCZhwOA5/eeyArtOT/eI5tlmb2P/NUDln BJ6MfM/wgw+vHQZHgynJqIX+fHfLyIii6DctlIMM02ppOb3xE6BC/8c7iEORJU/i/vvK H4Utc1Xk4WfdM412R6iaseOtzi9G3Ofrt8JTe5DTpJmgV/z/zrbfSe6VHvbxT/JtOciZ rkNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=mf0orVw4pazHsYDZ+o8e29ORw+/nu8sTLGvIeM07tMg=; b=oGW85Co393RdyxABY/NOU3GqF9rrTUwobWAb9ccwgDX5tRDYpItPTBQy2aUeLYgZNy HoWbEuRihspc4B7zuG62OHXL2v+E+CD3uf9lcHz5yNeB/2/QNVidYvLwj1naOCPTjqF+ iBqvd+a8lGvowwy2bahyaKpOe1D5lxYovGe8IzLTe3qja7WHJMJppCx9oITfj3RpU4g0 yM0sKR3Oh0BoGbYu2lEtum1GXSdupDQ2QXLecbd6aAC5TJwmtXS/HMQmwk55fDWA2Xhi BRNxzws4ZDcvkhJ4Y9sx385Vv96edAfGjTOYeIZOFjZ4KQxcH/Zq5yGestyZBvI8agCn EgHg== X-Gm-Message-State: ABuFfoi/Zs+o9eDYW3/zFareu474HWVn7LViSrB/2TqJtlmKSZZo3TJg xAWQwbwSBrec9+so0PyVWIkzMBbD X-Google-Smtp-Source: ACcGV63yW0g4CZeNpEfxzhJF+Bu1E9vIqR6WVfFL/8wMEAcSKLh5qjn5QVvkGcbW+FjU9WFBqBU8/g== X-Received: by 2002:a62:e511:: with SMTP id n17-v6mr3866865pff.210.1538608977651; Wed, 03 Oct 2018 16:22:57 -0700 (PDT) Received: from [10.31.79.215] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id v5-v6sm5362739pfd.64.2018.10.03.16.22.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 16:22:56 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/alternative; boundary="Apple-Mail=_44BEC05A-0408-44AB-9227-C223FAEB6B2A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <1849B5B2-F585-4233-8792-25055A0E9517@gmail.com> References: <153860885655.9112.7153769109912109285@ietfa.amsl.com> To: "lisp@ietf.org list" Date: Wed, 3 Oct 2018 16:22:55 -0700 X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-mn-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 23:23:01 -0000 --Apple-Mail=_44BEC05A-0408-44AB-9227-C223FAEB6B2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Received comments from Luigi. The following changes were made: The same format changes are coming in draft-ietf-lisp-pubsub and = draft-erqmagen-nat-traversal as well. Thanks in advance to Alberto and = Vina. Dino > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [lisp] I-D Action: draft-ietf-lisp-mn-04.txt > Date: October 3, 2018 at 4:20:56 PM PDT > To: > Cc: lisp@ietf.org > Reply-To: lisp@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Locator/ID Separation Protocol WG of = the IETF. >=20 > Title : LISP Mobile Node > Authors : Dino Farinacci > Darrel Lewis > David Meyer > Chris White > Filename : draft-ietf-lisp-mn-04.txt > Pages : 24 > Date : 2018-10-03 >=20 > Abstract: > This document describes how a lightweight version of LISP's ITR/ETR > functionality can be used to provide seamless mobility to a mobile > node. The LISP Mobile Node design described in this document uses > standard LISP functionality to provide scalable mobility for LISP > mobile nodes. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-mn/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lisp-mn-04 > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mn-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_44BEC05A-0408-44AB-9227-C223FAEB6B2A Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_6418C101-1B75-4C30-A4F7-426EA3C4C131" --Apple-Mail=_6418C101-1B75-4C30-A4F7-426EA3C4C131 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Received comments from Luigi. The following changes were = made:


The same format changes = are coming in draft-ietf-lisp-pubsub and draft-erqmagen-nat-traversal as = well. Thanks in advance to Alberto and Vina.

Dino

Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = [lisp] I-D = Action: draft-ietf-lisp-mn-04.txt
Date: = October 3, 2018 at 4:20:56 PM = PDT
To: = <i-d-announce@ietf.org>
Cc: lisp@ietf.org
Reply-To: = lisp@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Locator/ID = Separation Protocol WG of the IETF.

=        Title =           : LISP = Mobile Node
=        Authors =         : Dino Farinacci
=             &n= bsp;           &nbs= p;Darrel Lewis
=             &n= bsp;           &nbs= p;David Meyer
=             &n= bsp;           &nbs= p;Chris White
Filename =        : draft-ietf-lisp-mn-04.txt
= Pages =           : 24
= Date =            : = 2018-10-03

Abstract:
=   This document describes how a lightweight version of LISP's = ITR/ETR
  functionality can be used to provide = seamless mobility to a mobile
  node.  The = LISP Mobile Node design described in this document uses
=   standard LISP functionality to provide scalable mobility for = LISP
  mobile nodes.


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

There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf-lisp-mn-04
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-04

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


Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

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

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

= --Apple-Mail=_6418C101-1B75-4C30-A4F7-426EA3C4C131 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=PastedGraphic-4.png Content-Type: image/png; x-unix-mode=0666; name="PastedGraphic-4.png" Content-Id: iVBORw0KGgoAAAANSUhEUgAABFgAAAIYCAYAAABZi1jzAAAMK2lDQ1BJQ0MgUHJvZmlsZQAASImV VwdYU8kWnltSSWiBUKSE3kQp0gUCoUUQkCrYCEkgocSYEFTsqKjAWlCxYEVXRRRdCyCLDQsWFsXe HxZUlHVxFRsqb5IAuvq99753vm/u/e+ZM+f859yZ+WYA0IrlSaU5qDYAuZI8WVx4MGtsSiqL9AiQ AQZ0gDXw4fHl0qDY2CgAZeD9T3l3AyDK91Vnpa+f+/+r6AiEcj4ASCzE6QI5PxfiQwDgnnypLA8A QhfUW03Nk0JMhCyBngwShNhaiTPV2FuJ09U4SmWTEMeBOA0AMo3Hk2UCoKnkxcrnZ0I/mqUQu0gE YgnEjRAH8EU8AcSfIR6amzsZYi17iO3Tv/OT+Q+f6YM+ebzMQazORSXkELFcmsOb/n+W439Lbo5i IIYVbDSRLCJOmbOybtmTI5WYBvE5SXp0DMS6EF8TC1T2SvxUpIhI7Lf/wJdzYM0AEwCUJuCFREJs ArGlJCc6ql8fkCEO40IMa48miPO4CeqxqEA2Oa7fPzpNKA+NH8A8mSqW0qZYkZ0Y1O9zk0jIHfDZ UCBKSFbzRC/ni5OiIdaE+J48Oz6y3+ZFgYgTPWAjU8QpOcN/joEMWVic2gazzpUP5IX5isTc6H4c lSdKiFCPxSbyeSpuhhBnCeVjowZ4CoQhoeq8sEKhJLGfP1YmzQuO67ffLs2J7bfHGoU54Uq9JcSt 8vz4gbHdeXCyqfPFgTQvNkHNDdfL4o2KVXPAHUEU4IAQwAIK2NLBZJAFxK1ddV3wS90TBnhABjKB EDj3awZGJKt6JPAZDwrAnxAJgXxwXLCqVwjyof7LoFb9dAYZqt581Yhs8BTiXBAJcuC3QjVKMhgt CTyBGvFP0fmQaw5syr6fdCytAR0xlBhCjCCGER1wYzwA98Oj4JMNmxvujfsM8PpmT3hKaCM8Ilwn tBNuTxIXyn5gzgKjQTvkGNafXfr32eG20KsHHoz7Q//QN87EjYEzPgJGCsIDYWwPqP2eq2Iw42+1 7PdFcaGgFAMKm2L/IwNNR02PQS/KSn1fCzWv9MFqcQZ7fsyD8139BPAd+aMlthg7iDVjJ7HzWCNW B1jYcawea8GOKvHg3HiimhsD0eJUfLKhH/FP8Xj9MZVVk7tUu3S6fO7vA3nCaXnKxcKZLJ0uE2eK 8lhBcLcWsrgS/rChLDcXV7iLKvd+9dbyhqna0xHmhW+6wrcA+Av6+voav+mi4Jo8tBAA6tNvOrtj cDkbAHCuhK+Q5at1uPJBAFSgBVeKETCDe5c9zMgNeAI/wAahYBSIAQkgBUyEdRbBeSoDU8FMMA8U gRKwHKwG68FmsA3sAnvBAVAHGsFJcBZcBJfBdXAXzpUO8BJ0g3egF0EQEkJHGIgRYo7YIE6IG+KN BCChSBQSh6QgaUgmIkEUyExkPlKClCHrka1IFfIbcgQ5iZxH2pDbyEOkE/kb+YRiKA3VQ01RW3Q4 6o0GoZFoAjoBzUSnoAXoAnQpuhatRPegtehJ9CJ6HW1HX6I9GMA0MCZmgTlj3hgHi8FSsQxMhs3G irFyrBKrwRrgn76KtWNd2EeciDNwFu4M52sEnojz8Sn4bLwUX4/vwmvx0/hV/CHejX8l0AkmBCeC L4FLGEvIJEwlFBHKCTsIhwln4NrpILwjEolMoh3RC669FGIWcQaxlLiRuI94gthGfEzsIZFIRiQn kj8phsQj5ZGKSOtIe0jHSVdIHaQPZA2yOdmNHEZOJUvIheRy8m7yMfIV8jNyL0WbYkPxpcRQBJTp lGWU7ZQGyiVKB6WXqkO1o/pTE6hZ1HnUtdQa6hnqPeobDQ0NSw0fjTEaYo25Gms19muc03io8ZGm S3OkcWjjaQraUtpO2gnabdobOp1uS2fTU+l59KX0Kvop+gP6B02G5jBNrqZAc45mhWat5hXNV1oU LRutIK2JWgVa5VoHtS5pdWlTtG21Odo87dnaFdpHtG9q9+gwdFx1YnRydUp1duuc13muS9K11Q3V Fegu0N2me0r3MQNjWDE4DD5jPmM74wyjQ4+oZ6fH1cvSK9Hbq9eq162vqz9CP0l/mn6F/lH9dibG tGVymTnMZcwDzBvMTwamBkEGQoMlBjUGVwzeGw4xZBsKDYsN9xleN/xkxDIKNco2WmFUZ3TfGDd2 NB5jPNV4k/EZ464hekP8hvCHFA85MOSOCWriaBJnMsNkm0mLSY+pmWm4qdR0nekp0y4zphnbLMts ldkxs05zhnmAudh8lflx8xcsfVYQK4e1lnWa1W1hYhFhobDYatFq0WtpZ5loWWi5z/K+FdXK2yrD apVVk1W3tbn1aOuZ1tXWd2woNt42Ips1Ns02723tbJNtF9nW2T63M7Tj2hXYVdvds6fbB9pPsa+0 v+ZAdPB2yHbY6HDZEXX0cBQ5VjheckKdPJ3EThud2oYShvoMlQytHHrTmeYc5JzvXO38cBhzWNSw wmF1w14Ntx6eOnzF8ObhX108XHJctrvcddV1HeVa6Nrg+reboxvfrcLtmjvdPcx9jnu9++sRTiOE IzaNuOXB8BjtscijyeOLp5enzLPGs9PL2ivNa4PXTW8971jvUu9zPgSfYJ85Po0+H309ffN8D/j+ 5efsl+232+/5SLuRwpHbRz72t/Tn+W/1bw9gBaQFbAloD7QI5AVWBj5iW7EF7B3sZ0EOQVlBe4Je BbsEy4IPB7/n+HJmcU6EYCHhIcUhraG6oYmh60MfhFmGZYZVh3WHe4TPCD8RQYiIjFgRcZNryuVz q7jdo7xGzRp1OpIWGR+5PvJRlGOULKphNDp61OiVo+9F20RLoutiQAw3ZmXM/Vi72Cmxv48hjokd UzHmaZxr3My45nhG/KT43fHvEoITliXcTbRPVCQ2JWkljU+qSnqfHJJcltw+dvjYWWMvphiniFPq U0mpSak7UnvGhY5bPa5jvMf4ovE3JthNmDbh/ETjiTkTj07SmsSbdDCNkJactjvtMy+GV8nrSeem b0jv5nP4a/gvBWzBKkGn0F9YJnyW4Z9RlvE80z9zZWanKFBULuoSc8Trxa+zIrI2Z73Pjsnemd2X k5yzL5ecm5Z7RKIryZacnmw2edrkNqmTtEjaPsV3yuop3bJI2Q45Ip8gr8/Tg4fsFoW9YqHiYX5A fkX+h6lJUw9O05kmmdYy3XH6kunPCsIKfp2Bz+DPaJppMXPezIezgmZtnY3MTp/dNMdqzoI5HXPD 5+6aR52XPe+PQpfCssK385PnNywwXTB3weOF4QurizSLZEU3F/kt2rwYXyxe3LrEfcm6JV+LBcUX SlxKyks+l/JLL/zi+svaX/qWZixtXea5bNNy4nLJ8hsrAlfsKtMpKyh7vHL0ytpVrFXFq96unrT6 fPmI8s1rqGsUa9rXRq2tX2e9bvm6z+tF669XBFfs22CyYcmG9xsFG69sYm+q2Wy6uWTzpy3iLbe2 hm+trbStLN9G3Ja/7en2pO3Nv3r/WrXDeEfJji87JTvbd8XtOl3lVVW122T3smq0WlHduWf8nst7 Q/bW1zjXbN3H3FeyH+xX7H/xW9pvNw5EHmg66H2w5pDNoQ2HGYeLa5Ha6bXddaK69vqU+rYjo440 Nfg1HP592O87Gy0aK47qH112jHpswbG+4wXHe05IT3SdzDz5uGlS091TY09dOz3mdOuZyDPnzoad PdUc1Hz8nP+5xvO+549c8L5Qd9HzYm2LR8vhPzz+ONzq2Vp7yetS/WWfyw1tI9uOXQm8cvJqyNWz 17jXLl6Pvt52I/HGrZvjb7bfEtx6fjvn9us7+Xd67869R7hXfF/7fvkDkweV/3L41752z/ajD0Me tjyKf3T3Mf/xyyfyJ587FjylPy1/Zv6s6rnb88bOsM7LL8a96HgpfdnbVfSnzp8bXtm/OvQX+6+W 7rHdHa9lr/v+Ln1j9Gbn2xFvm3piex68y33X+774g9GHXR+9PzZ/Sv70rHfqZ9LntV8cvjR8jfx6 ry+3r0/Kk/FURwEMNjQjA4C/dwJATwGAcRmeH8ap72YqQdT3SRUC/wmr728q8QSgBr6Ux3DOCQD2 w2Y7F/pmA6A8giewAeruPtj6RZ7h7qb2RYM3FsKHvr43pgCQGgD4Iuvr693Y1/dlOyR7G4ATU9R3 QqUo76Bb2Ep03VAwF/wg/wYEKXFozC1U3QAAAAlwSFlzAAAWJQAAFiUBSVIk8AAAAZ5pVFh0WE1M OmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6 eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3 LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlv biByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNv bS9leGlmLzEuMC8iPgogICAgICAgICA8ZXhpZjpQaXhlbFhEaW1lbnNpb24+MTExMjwvZXhpZjpQ aXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj41MzY8L2V4aWY6 UGl4ZWxZRGltZW5zaW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8 L3g6eG1wbWV0YT4KDXcQAwAAABxpRE9UAAAAAgAAAAAAAAEMAAAAKAAAAQwAAAEMAACyT3aNXxAA AEAASURBVHgB7L0NcFXXee/9OAMe8XHrQ4ozko07IrXfgCF9z8HgscGdygRu4ZjWREBLJNxSJGIK 5FZE4FALN4qRHGJEQm1BbRAOsZHse0EKcZBMDSjKNMKMwZLqgEQDAd0akKbQ6CQR6IzF6/M+a3+s vfY+e58P6Qgk9N8zsL/W52+tvXXWfz/rWXdFeCNsIAACIAACIAACIAACIAACIAACIAACIAACfSZw FwSWPrNDRBAAARAAARAAARAAARAAARAAARAAARDQCEBgQUcAARAAARAAARAAARAAARAAARAAARAA gX4SgMDST4CIDgIgAAIgAAIgAAIgAAIgAAIgAAIgAAIQWNAHQAAEQAAEQAAEQAAEQAAEQAAEQAAE QKCfBCCw9BMgooMACIAACIAACIAACIAACIAACIAACIAABBb0ARAAARAAARAAARAAARAAARAAARAA ARDoJwEILP0EiOggAAIgAAIgAAIgAAIgAAIgAAIgAAIgAIEFfQAEQAAEQAAEQAAEQAAEQAAEQAAE QAAE+kkAAks/ASI6CIAACIAACIAACIAACIAACIAACIAACEBgQR8AARAAARAAARAAARAAARAAARAA ARAAgX4SgMDST4CIDgIgAAIgAAIgAAIgAAIgAAIgAAIgAAIQWNAHQAAEQAAEQAAEQAAEQAAEQAAE QAAEQKCfBCCw9BMgooMACIAACIAACIAACIAACIAACIAACIAABBb0ARAAARAAARAAARAAARAAARAA ARAAARDoJwEILP0EiOggAAIgAAIgAAIgAAIgAAIgAAIgAAIgAIEFfQAEQAAEQAAEQAAEQAAEQAAE QAAEQAAE+kkAAks/ASI6CIAACIAACIAACIAACIAACIAACIAACEBgGcx94KZRuBGDuZAoGwiAAAiA AAiAAAiAAAiAAAiAAAiAAASWW9UHukPUEeqRuY3yZZBvrDyNPrh5kdaP/CJt4zt5VReo4msTo8Pg CgiAwNAicDNMHZ1dsszj0jMoDQKq5IEDEAABEAABEAABEAABEBjKBCCw3JLWC1PVtFGU26xkNr+S eupyKE25ZDvsrKdpGV8hLcoSDvt/YoS1RcQJCAxTAmzxFeaq3y7BIhwKcf5plJYm/rm3Qdtbi+jh v6mRN8ubemhNwCOwDIUDEAABEAABEAABEAABEACBoUAgYYEl/Msa2rS5kkK+cbZ6dVGASl5ZQ5Mx RrBxcZ7UFU2jp15SFJZ4Ass1FljuNQSW549RpHS2M8nbd36zg/Y8t5Y+6Lb3BatAPkp/YCLNnBek 4IwhbnlzM0RV315P1VeJomsrLBEmUuDJIGV/dTZl4BmwusAtP2IR869YxNxPVNnWQzmTblFjcP+o f3sHrf+bTboYatY7wH0ivY5q3uMLK1kg3aULpB0/20b3zV5vhqKKj3so78u3qKwy1zv3IHSyivK2 1tM4n3sdxd+rsp1raCKshtwB4SoIgAAIgAAIgAAIgEC/CCQssLS9Oo0e/l+KQKBkm/1mK1U/M1m5 gkMvAm1v5fMX7D1E8QQWEgO3amq7RjR5bi7NvlUDRq+Cq9fDzTRt1DT7gFK9rx4Hiqj1eMnQFeCS qGt5/RVa82SGWnsc3zIClsByy0SLa820/t5p2jS+mNWMetbDtIct2vL5dXrLyhqzgHfOzVh/p8xa grlJAnsQAAEQAAEQAAEQAIFUE0hYYKHuDjr+QRuFx4boKzMXOcpRQlciRYShpQOLy2niAotL5EFz KUxtzW3U/NY0yv2BKFSAyt8t00UU/jIc7myjPTlrSU6EWFdLke8HB03pky1Ix9njtGPyLCrVqlpE x15fROO4nl3tbVS3O5e2CSsFYyusuUBlXx3iVjtmZYbU/hYLLOE2yh/1MLFUqm3ZL1dT+d9nUwb7 VQqHLlLdq+tp0T8ZT0DUFL9bXNYh1Y79LKz4O3WS/06xUVD9zK8Yz2whVW8Lkk84DR+bQTMfn+w9 NbOf2SM6CIAACIAACIAACIDA8CaQuMBicrrZxs5XH9adr67Loz0/0IcYFexLIM/pSyDEA+3ddfxj N40HHWEK/N0amp0epuaf1dHxlg4KhdljgY+nWGQ9SbO/bJdnQr+soz2H2zRfBuFwBmWvy6GJnF79 kePUfKmTwvwL2pc5kWbPDdLk9Bgm9tfaqOqHe6jy7W1UZxrgsPl+0d+voTVfC2oDIrNqYh86WUN7 Gi7q+fL0j+xnZlPHe3to21uVbO7PCXDcknWFVMjXY+RKHb+sp581NNNFrndamo8yJgUoOH8mdf10 PX0xm13XRn3V5sx5ukEdl7WN62amzYgo8NU8mv2geUUtLR/zV/Q9P6ynEDPWQogI6QHK/dps8rEV TN0PK6ktxH4pjOiC2+yVeRTwMKF3pB779HwV3fVQLofJo9beCpqsmt3zNKJtf3kfrRfiQ6CcuprW cHmG7nbxbW63HG43HixH2B+OunU011D+tEVUp10MUtPvayngdGAc7qD6/VVU9XY9NXV2GNEzKPi1 XMp9JjtmHw53NlPN7kqq/HE99+FmCgQCNHF6kNt4Efku1VHVv3VR9jdLKKhZObHlE4dtFm0uPJI8 OJvWfDWg59fNz8K/1FGH0VdEV3n8a3k0cwJ3Dm6vmn+pIu75Wrwwt1b4Ik8L/IGoFU+reLeScjIv 0rZvbWJBSTxIPDWwag8Vfc1I26iRthPTZvbvoR3mM6NdDFDe8/zM/X0uBUR+6mb0Ye09oZUplzI+ qaMdP6jkdOrYUkrEXU9F/8jvACdXmc6tFS2Ob55Gs/5Jf6EU1bRSyVedFnxWeYiK6EJviTItxbpX +XEXPX6tjkq3ltEeg2vei+tp84Yc7ylnoi+9V6f9az7FYg73CbEFlhTS+nVrKOfxaIGv+cd7qP68 8BDDgCfMptz5PhaBdlh9an4erd9QRDlPRseViPmgo5n74NFm6tTe3ekUeGw2zQ5kUP0Pd3CfE+3K PWdSkPL+wsEjyfewmmdfjy++nc/PLP99cnlm46bZj+dVvMf1v3EX+W8c/51iR8YzeRphIL1DPn/8 B4wmz8uj4JeH8lsxLkUEAAEQAAEQAAEQAIHhRyCS5Hbl/aIIU+J/RZErvV2RMu2Yz9fVRqV0oSrb CCvC6/94OCaPzWvafkl55EKPlUTlEo9wLvGzXz4WUaLKRFqrzLJ6p1Xx4RUZPsKpVAS8w9rLW+ma Z+T3rZEyz7IHrLrPd4nf0xRx4xN8pUkpo/2w9RUlTckmEGnq5XBtFVZ+8h5FyprcaNnTTeSsp63S SD870uqS5IWqvJj3E8ljsIRpfdOoi1u7cSF7PjZZUISnzNmKfeV4hWu7qv0pb1eja39qerPQtQ3V uOJY9hFnHwpUyHR7msqj0jLj9Xwcfc+Zh9t5yfEuW127mINbH1bj5u2y9+fWXW592O05zI40/d6W XaT2+WBUndS8rOPsyLGr9rh9Prt6zKrjEpfn2Ei4q75ELxuHsVPqicR/vxW6PlOR3guRQuVZtupn 8TLbVNav1/294hY329E2Mo0efq/Nt/Jwi2tdK5d9TsRP/j0sc+3XQbxn1ivx/jyvPW21kew47SM5 vWx/DrzKg+sgAAIgAAIgAAIgAAJDhwAlV1RrYGD+iG+Vg+hgpNE+iohEfn8hUvtmeSTPRbTIXlcU KVnnFGCKIheEMMBbz7mmSOUrJdZARv5oDUYKXyyJFC5xDKyetws8V95VxZVApKTqWORCR1ekq6M1 Uv2KfdBafc5SB3rONbrkmx2pePdYpPH9StuP57IPHRXubXUMfoKRopfLI+Uv2vPTfmC7DtR7Io1V lZGKNysjlW9WSG7Zu+wDdp2Q8X8X12dXWYQn4FgDzfkWi2PPK9cDhZx2rU3IsqWV5IklsORFWo12 k0lcbYrkmWWabw3y5f0hdhB/sMbinDkAVdq2q8kucmW/WBlpOnclcuWT1sixKmMAbnAynykTzYUq e78JriuLVL9/LHKsxuobbMyitbvVR3oiTe9WRkqWGKKFUhbxPFZ79S0WSxtrON5KS+wIPl/JeZVZ /UqUM1AUqVWfg5XVZnEjkU9qbWHNunZdvRJpqim3Pcs8lcqK5/GeKNpVG2n68BjXxerDQdugNAlB lMvOzm+tPPtxpIppZQ6ByZZs75VIJT/7JW822i4LIdcpsJTwc9l0vDZSYvYhLq9TqNMS4XeMfNYD eZGKmmOR1nMXIk3cJvI6BaLEpAucdvmLpuBp9g1uy/omRz90eY9HrkRKjD6qiwPivVbG72/HO1iE WVISOdZkidZ9fQ87gPXpNP4zG51sf57XSIcivAkW8/MiZa+URQqVNjXFlaB4D3Skpj9G1wJXQAAE QAAEQAAEQAAEbheB5AQW/gFp/kCsPmcUuatR/rDPc3y5NytlG0wsqYhcUL9C91yIVKy0BlDWQJFj 82BCDtL5B2veK3ZLlZ5Pjtnus/NCPUv+im99RSyM+uotAqmDJDYht31x5W+uVrqBMrbU0ZPV/v+9 lXbQIXw0vWINOIIv1ka61Hhcz3JloMhThBx5KnkYhyY3G5PoYPoVbht9gCUGT8FItRhM8lfnIilu Fbl/EfdKL4HrlsASiBSykFTBglh2IDtS6BDOYg5CE8hnMARJZLDW+qYhGMr+ZB+YVjgFOVGxLkWI EgPjDqO2ynPFkz8ilU0OMY97T+3zlhji7CPSesijn3n1LRlP1iESaXrFFEKD8lmK5mEXDXjqS3Sz sXWXZX3BopxjfGmWSfTfY5+o0bsiFeaz4xTrft/FYtUVTTgtNwayeVVNESHqiOvyH4urqdosUZki 1bZyJpqDyio70mizrGGrQPOZ9Wi7ng6u11UHPJF1R60UseS7UC3SOcvKKvjiMfVOpOtDSwjk6Z62 e1dqLKHPaS3Y09FovSv5HV1p/l0QKfT7PWwrRtIn0X00XhL9eF456dp11t+xsvcVAZHvCasY828n T6mMFqTjFQ33QQAEQAAEQAAEQAAEhgSBpASW1l3GQMsxyDn2oikslPC3TuemDiYsCxVbKP7SWyS+ +Gn/OA1TmFAFFpcpSFoayqCCntcHDap4EhQm7709kZ7f2/9FetQ8eeqBOqZQ8i233RA5WvWxDWqV ODS/3DElwKitLUw8gcUjHyMp193VRkVYMnmKvcd0A9dEEr9oCSxqXtHHhTUxLHASz+62hkxksBYV RhnQZseY5tWjWLmYVgtyegk/E0XvRz9VOgyrDzvFvqiy2Oh59y0znlkOEc28poqCUmQwRQAW86So ye8HIS46n7kefg6PKYNQuwhglclpyaOXwSle2SrEJ1b8VFmqOHMwzyWPPg+UrbLa3iFGBjJ9ReQy 89b3PZHW+mq2IMmLZC/J1v7lrWRLGcVSzs7WiKVM6Yt6rfG7yWw/e1yrrNFCtFEqmS5F1Lj9fg/b K530meRo9tF4KfTjeRVitsnPa5qVZZHmPqUyXvFwHwRAAARAAARAAARAYPATSEJgsQZzQggperkk UsRTdUrYVNwyTecf2FG/3K0f6G6DCRORFG9IETsUQUL94W7G0ffq1Ax9Kooc/EnRJnrQb31NFPeU PEWicfI1LVVs9VEGKLbpD/bCRmQ94/7oT4ybI3mHRYSoG1sdqOJRVIS+X1AFlnKeatD6cav+r6mR p6LY+0Ve1dAWWRIZrMkwxsBY5RNz0K/0N1PYkP2E+2bU9Cu1yX7P028+ZIsNRxvLsrj2M+++ZcZT +7Z5TR1gy7qZ6SuDbPuz5f3s2Z9p7zKJ6nZ9aPiIMfNTGWjHVnx7ulEB+31BWirx+0Va8iWVauyy St4udRWiRTwfN4K/GwPZZqJPOfoLE46YFkD2uFZZzb4ZXVXL8kON2+/3cHRGSV2JxVFLiK3+8uYH Innsw0tsFp8408lcnlf1b4bnsy6nELnx14qA/0AABEAABEAABEAABIY4gYQFFvUre8wBVJSlSSI/ 0HkawovmQEz58an8kPX80coDA+kfwBjYWoNTPU3PAYk0xXdMA1LyVQcMZlubP9zVQaj6A9vp+NOM J/ZyCobL4EkNp36Rt+VjDxR9xk4wLWsgvf7e7KKjJ3PFGpB4mLwzRzklJG59k8n51oc121y14rCX wurnZhiLj5g6ETWitaIrjktNIUrm10crCRnf1QrCKquzb5nx1OvmNbNeouCybka79nysToGgiOkb JvpdYU5rYqeztuk13mVyy8+CZx5Z8d2eWTNUKvbqu7Ckvi9Tj2KX1Y23Vm6bpR/7aHm+PHLsw9bI FZ4ydKGNfam8afmscmMg28xVYPEqk3Vd7RM2jkr/VfPt93vYlknyJ54cjaSkhY3ZhxWRMNnnVbz/ TQsWlYGt1J9UG1aayt84WwCcgAAIgAAIgAAIgAAIDHUCCQssx0x/D/PL+Ed9U6TxeKP8J76gV8pp Qk4nidYPdLeVhkyAMn3VmkQROrytQvjrqRRK9Gk38ms3f8m1+QQwM4u3V/J1+7Fs/nC3DTgUE3G7 I041M4VFXMHBCmvLR03OecwDHcnCYb0T7cPDGTn589gDNj29WtO/jutAXw/TxY6FK9gSqoz/VdYP TksXs81VkcFGTFlZxmwvVXSIORBX4ppTfazpBAn4+TCn1CkFkoNb137m3bfMepp1EEma19S6y7Y3 01d8xuSpDmyVMsU+9C6TiBeVX1RiVvxyN183UeH7ceGcOVBmAVNMh0o6Kaussd4vKm+RhWTAz3ZZ vdu0sQvSH4pbulZ8twG+V5ms62LlONMJuVrlrnrLEbKab7/fw2omfTh267dqMpKHKbAoImGyz6sq sHj9nWt82ZxK68ZfLRmOQQAEQAAEQAAEQAAEhiqBxAQWxVmhp8PS31vObu2m5OoPdIqUuPiTuFKv LBFrDtgEUUXoiHZ8qSNvfNl0wMlfdE2ns8pceq8fu1psXjmllVcpOfah3SGhmq+b9Yf5w91WT5vl SICnDkRbLFx5X1k1JobgoNfM4mbLR78Z/b9NXGEnocJxJos+0oJETBtI9cBTfvH1smBRppU5/PbI CsivuqYFEzsz7tMAXaY4IAdmm6vTZGRGYmluuVKIIjAqDpG9/eD0RKoVvyTS54/KxdOnD69SY6zk 4hQgrSWZLce0sry82o9p1SWfGeOmWU+1z5nX1LrLwanZj23PqvtA3Mz/ysdsbcFTymxOoPmm6eRW zduMEzH7mpmfvGEeWM9L8BUXkY79v1w518oriUU/l2YKie85L1M45OfKuey0TIf9PFU+nx0JzC+S zoH1e1ZZVUHCjOfGW9yTzD2m/bXWWCunub23IvK9yAN8F1HO5O+Mq/oDovklttVvWt9X3t3iHWM6 GhcFlvnxsx1l2SgCGJvXe9i838e9F0eZnNmnzL85/XleOdFjL5rWWbxs+ovVkStmV+P6HXvFXMFJ vOcgsMg2wAEIgAAIgAAIgAAI3GEE4gssPV2RpjetVSQqP+YVO5wrWHCYrqu8Yg3/wNamBKysjFwQ TiG0H/HWYMKcLiCWf21qatL+Vb5oCSTivhxgCtC2QZuedsmbvFwyW884l2/V/KjI1YnseQbWVURa zYEVl0lfqtkajIhVWqSfEjEQ+7haDkDL3m+N9Jg/lLlIPV1XIscMUSfIc/evKM4vrrxrcRJ1Kalq 5NU+jKWhX1Z/YOs/spscHLuUVU9EGU2fCMRL4V5RV0VR43F5uz5pUgb4/HVbXTrWsXRuOVuI9LgM rpLt1z1dLE69b3251vqFWN1E/OOBbCMvFawuz+3muFTk2XXcSsPsH8T9R0GebNFSH577t9nmxBZc rdzmPdrqNa2R2l1qP4peWrfJdAytPRt5kVp+fsytR7SxMlB3WkOoq5KI5ZGPtV3R2k7kbV+Wlwd0 prhoJm4OHkW+S8r1/s99pfW4upyvECWbNGe0IloP+3OR9eQ2MPu2HKgaddfCmumLa0Z/tPnc4CXB j4m6ir7G/8Rz08hLNav+msrkQ8f3mYX5/hDPVRc7pZYb11f2NZGfWBEoqg+rz3x2pLZNhBHPhmgj a+qMELrcrDBkXokeOJ4r8Y5p+qSL3xWcJ9dFna6jvdcU4UG8K01BroKXNBbOgOXGdZVtYNbVuGkJ LDwFa2U5Cx0iv67IhY+PRcqU5bVFftpKSvyMSk5cLkuACWp85HtAcOIym2US77wu+S4VmfMqTlJA NN7xAUtMkM8t52sTWBTHwyJMUu9hCSTJA63NxSpLSl8WVpHMSq4oJd6zfG71Ket905/nNWITaHRO AVdOEFiSbFUEBwEQAAEQAAEQAIEhQyC2wMIChzmvXP0RLY6tH9I8sHH8+A7M102hdbFEHfgYP845 vjM9cV7odITqIrC4xdOWsXUuC8s/dlXrDfd4RjnWWT+wq9UBr1nOgO48V35FN68bexsLt/iO8KT8 6C43Bl4XquxCU8zycnr6V2YvtobTXsU3gppeIMaKNgn1XPXLtLNubudsgSFXhnJkYFlaKH3ixUZH qNt4GuMZUJmKY7GEbfTWxVYm7oNRe3xeTtw518RmlaTwcTJ25Ws5HrXno6RjTq0TFhHnlWkvSvoV 53osv0HG9WqxlLQpsBjX9GeA65pI/9fi8MpWxiD+So1TfBRlNJwze/CPEpS4SK5inVIXjUMKxbuu JmvZY0/GnL8QjEwJRXWQa8WJXVfLokdZwtlZL49z7R0c5z0Qs0xmh2YrjOrnzSkuSh/ifLOXWP3b ehcaEfv4HjazTXbvXhd7eS3uxnXTgkXLrB/Pq4h/tSlS4vh7qOcXiGTL6xBYkm1XhAcBEAABEAAB EACBoUIgjsByxbKisP2AZweVYpClbWKKg/UD2/rxak6TsUSAvDebIleaaiNFK+0/1LPXlUUaeSAX tSkCSyV/6W16t0Jb9UHNo/BltpaxfW1VUuFBQe0rdqsSNW7eixWRRvGlW9ma3nQZ7K2r1kOw7wVz aoWVDk/HkSxEsB62+LFbNehhg5Hy93l1HYfFjulMUfVXYKXtNTCw8mx6xUWYCZhOe8WAN7ptivo7 BaeryVN4s8oeiASX5EXKa9hCQuEbdciOOytsZcyLNNp4RsW4tRd4cFokhYjo9ggEgpFCl37kLGRr faUHs0CkaBdbbERZZJgp9EQaFeelFl8uy/zC2D5ruJ1KlphlDhh9Nxip4H5oF31Y7OCwebZnXI9X zY5oe8wVfLT7LN6J502ZZiQEzlrFYW3ru3ZLFbXMwZUlkerjbEVlVo/3Pa5CRZE+jUXwdymXuw8S 9hfzbpnLM8orxQiHsPwOSfnG1ijljveZWd/AkhK24rG/X1R/JWY46duE33duorCtrjwdrdz2vOjt FFhSxO9Qtmzapb6/zHcwvwdkPzD7Awvaxnvgwrsu7yu2nnETRYWlUeP7xyK179Zq07wuiKmIkQuy 3FECi7jdh/ewiNaX7cq7yjRMl35jMbc4EL/f1f4o8u3786qX+opwOvx+LXMSU1DZIkhkIKf9OVat 06PgfxAAARAAARAAARAAgTuAwF2iDvyjcwC3MFX91SjK3c+TeHa1UvXKyVZeN/lwhHUadXSzjfJH Pkx7+Ab/cKe8L6dZQeLFtUIS3QxTR2cXhfmaSGHU2HHk8ylpqWFTdWzkqSU3YhRlpPtSlfIdmU64 W7QOt8/YAW6X20wvfK2DOkJhrR8S98Nx432UFusZMMvL/Sl0rYu6uN9rfdjHfThBVuFQiMJpnA+n cSv5hjo7qKubyysKnDaKxvkSrKtZ537stTpr74g0nVMijPuRH3WH6OKlDv0dM8JH49IzON/+JBg7 bjiksxWhRvkGNq/YJeG7nXV0V8ZTfBCg2o4mCqZ7xLgd72GPoiR6uc/Pq0sGHUc20X3/s5TvlNCV 3iLKGOg+6VIGXAIBEAABEAABEAABEBhYArdAYCGq+fpdtGg3CyxvssDyjCKwxKvbzYsssHxRE1gq 2yKUMyleBNwHARAAARC4ZQRuhqhq9TjK5fc7v+GptaeaJt/ZGmnf0Iaaaf24abRNxJ5fST11ObrI 2rfUEAsEQAAEQAAEQAAEQGCQEhhYgYV/fDf/rI7y/mcuNQsA80vo2IbHNYuSMPlo5pMzyef1FS90 kep/uoO+8jfaT1IKvlhJhY+lUzjMX+HHT6TZjych1AxS+CgWCIAACAwZAiwSlD5XQk00kSaODbHp TDq1vVRKdWYFlrBw8H8gHIR+WUPrN1cSTZhIPrZsSruXqPQlYYepb9lV/KHha/j7ZfLAHgRAAARA AARAAATuJAIDKrB0/Dif7su2flg6wfEqIlQYcP/cWfNXbPXC04rctwA19TSRR1T3KLgKAiAAAiDQ ZwLhX+6gUX+y1j3+/DK6UFNIE91f5+5x7tCrba9Oo4f/l/ZJIaqGwRePUfULs2G9EkUGF0AABEAA BEAABEDgziAwoAILdR6nTf/0BoXHRvsfCXWPozUvFVFgvDvIjg+q6IUfNrn4MQhRaNRsKvtOjrf1 i3uSuAoCIAACINBXAmyRWP92JdWfvUjhHpFIGmVMfpgef+xJmvnljL6meufFu9ZGVT+sIV5OXPPJ Q6PG0eSpAZr5pzNp8oTov4V3HgDUCARAAARAAARAAASGL4GBFViGL1fUHARAAARAAARAAARAAARA AARAAARAYBgRgMAyjBobVQUBEAABEAABEAABEAABEAABEAABEBgYAhBYBoYrUgUBEAABEAABEAAB EAABEAABEAABEBhGBCCwDKPGRlVBAARAAARAAARAAARAAARAAARAAAQGhgAEloHhilRBAARAAARA AARAAARAAARAAARAAASGEQEILMOosVFVEAABEAABEAABEAABEAABEAABEACBgSEAgWVguCJVEAAB EAABEAABEAABEAABEAABEACBYUQAAsswamxUFQRAAARAAARAAARAAARAAARAAARAYGAIQGAZGK5I FQRAAARAAARAAARAAARAAARAAARAYBgRgMAyjBobVQUBEAABEAABEAABEAABEAABEAABEBgYAhBY BoYrUgUBEAABEAABEAABEAABEAABEAABEBhGBCCwDKPGRlVBAARAAARAAARAAARAAARAAARAAAQG hgAEloHhilRBAARAAARAAARAAARAAARAAARAAASGEQEILMOosVFVEAABEAABEAABEAABEAABEAAB EACBgSEAgWVguCJVEAABEAABEAABEAABEAABEAABEACBYUQAAsswamxUFQRAAARAAARAAARAAARA AARAAARAYGAIQGAZGK5IFQRAAARAAARAAARAAARAAARAAARAYBgRgMAyjBobVQUBEAABEAABEAAB EAABEAABEAABEBgYAhBYBoYrUgUBEAABEAABEAABEAABEAABEAABEBhGBCCwDKPGRlVBAARAAARA AARAAARAAARAAARAAAQGhgAEloHhilRBAARAAARAAARAAARAAARAAARAAASGEQEILMOosVFVEAAB EAABEAABEAABEAABEAABEACBgSEAgWVguCJVEAABEAABEAABEAABEAABEAABEACBYUQAAsswamxU FQRAAARAAARAAARAAARAAARAAARAYGAIQGAZGK5IFQRAAARAAARAAARAAARAAARAAARAYBgRgMAy jBobVQUBEAABEAABEAABEAABEAABEAABEBgYAhBYBoYrUgUBEAABEAABEAABEAABEAABEAABEBhG BCCwDKPGRlVBAARAAARAAARAAARAAARAAARAAAQGhgAEloHhilRBAARAAARAAARAAARAAARAAARA AASGEYH4Akvk9WGEA1UFgeFNoOqzrw9vAKg9CIDAHUMg53O77pi6oCIgAAIgAAIgAAL9JHDXs/1M ILHoEFgS44RQIDAsCEBgGRbNjEqCwLAgAIFlWDQzKgkCIAACIAACiRGAwJIYJ4QCARBIHQEILKlj iZRAAARuLwEILLeXP3IHARAAARAAgUFFAALLoGoOFAYEhgUBCCzDoplRSRAYFgQgsAyLZkYlQQAE QAAEQCAxAhBYEuOEUCAAAqkjAIEldSyTSummEXpEUrEQOBkCYQ6clkwEhB3qBCCwDPUWRPlBAARA AARAIIUEILCkEOadnNTNXurovCFrOC79HkrDIE3ywEFyBGIKLN0hCoV6ZIIjfRk0Zqw8HXQHvaEO CnWGiEak0cg0/jeeyzsYB9iXaig3c7HGb/XZGzTrwcFYSJfmvRlmvh10vZvobsF47CjypftcAvb9 0nVOv9cUn8xk0saRb3xyjFrWf462bucE8g9Q5WvZZkrYDwYC3I/0NhbPaR8LJPqIy989CCx95Ilo IAACIAACIHAnEoDAYm/VUOc1ajp5geoPNVPp7mbK/lExVT+Tbg90h52FQzcoTCMpLU38c69c21uv 08N/2yxvlje9Smv8I+U5DgYRARbDaMTgbhtvgSVMjdNH084Whee8fbT3UA730MG1hU7V0P7ixdRw OLpcK0/9hrL8LiKAOYh3GaRFp5LaK6GjpbRm3gtaoll7z9DKZZNTm4Eztf7WNdxBJ8u/T9s3bnOm TDSvgnYdWkFjou8kf0URnmyR/RW099SKxPvdzQ46mHY/7dcSWUEvhyvo/tvQzrY64IQJhOlM+Vp6 qeANSSMzv5xWl62m+5MQbs+VLaDijXWcRpAKzh6gGYpACYFFosUBCIAACIAACIDAYBJYjr9aTdtO 36BxHs3iGz+epj02lYLzHyBfqn+4dnfS+j8oJudP+ezXWWBZeQcKLDdvUP3bP6f1f/sTsmQTBu+f StkZp6nmPT5euYJ6Xn9Us3bvaDhC982uli1T8fGrlDd1sA15ZfGG78HZD+muh3kgsYTb7n/rbTcY YXgLLEQtmx6hrVuUXjkIBZbe01W03L/ME+0MFjAKnALGzTbanTaFGuj2DL6vnyilrz+hCywLD1+m JXMyPMvf7xv9risLbQtYaHMRr/SyZbOAcSA1AkZ3M+32PcLt4tgWs7D3TjLCXojqRnyeKrVkNtOO m0XkIrE5MsHpwBII08n1o2m7sCqK2grp5e6tdL/HRwVbcFOE8/PVFv7T2HKDsqZaESGw2GjhBARA AARAAASGN4HBI7CU055p36B8/vESf3uAqlufo+xJKRzgX/sPuusLP9CyDs4nqhMCA293pMBy7RNa /4XSKDFJr7Hy/3wepNeqg/Re2UYQWBROg+gwzALLKCGwRLXdICokFyWWwGKW9PK+fHpuOddlEAos Z0oeoZeKhQgUoJW/OECzpk+kkWIqyzWeyhIi+sJUPjcrYu5ZdNjOAstJyqbS7gOUaY3PzBADu+9u o8Z3PqAb4TR6eHlOUl/vky5Yf+t6rZ6K0udQO2ecWbCPCjZl071j06i325iONX4i3Zvk9J24dTCm f/S2vEHLp+cTJS2wEF1uqKLW0yEaPfVJmpU1wBZCcSuEAKFDL9CahaUaiMyN+2hDQZBCv9hGRYv1 a1RwiCrLgnFAhamBxb7ditgHgSUOMtwGARAAARAAgeFMYPAILK9Tx9lPqK35Q/pK7hGtSQpff5aC D40m4hkPFP4t1e87QqX7PzGaK0hXPv1LykilJUu415gqQ1Tz7CpatPsOFFjCnZQ/upj2GBSzv/cs lf99gDLYVDocukZ1bEW06NuG9UCUFUQvVf31NyiXbeAhsBgAB9kOAsutaZDGpZ+jnQfY4Gv7R7Rh bSCxTKVVB1tfsMCS0JfzxFIefKH6W9ezVZQ7VVgIBVmMOnRLxaheznu5yHsQCnuDr6EHc4lCdGT6 52mv+Gjj30o7ThVKiyJ1uk/xtUP0kM+7Htcb2PJrDlt++YPkpzpq4fQgsHjzwh0QAAEQAAEQGPYE BpPAojXGzWuUf/cmTQCobH2NcibZm6h+azl95Vun+eJUavzNWpoZ44eRPWYyZ5aQcKdZsBzfXEqz vq2LVEXVxVTyVef0J6vuYnBzgUWsiVLEsu5Vfvx9evzaaSrdeoT2vCfSe4DyvjOXNm94lDK8vswL key901R/+DQ1n2Qxp0UvR2DJXFq/7s8o57HxUY3U/ONGqj/fy9OUWGWbMIly549iEejnVPnjs1r8 wPxZtH7DfMrJio6rJtbR8h9Ud+Q/qTN8k9J8f0CBx79Es/33UP0PG6g5JGwNesk36cuU9xcOHtc6 qeqHjVT59hHOz0iRp1EV/X0WrfnaVE2YUvORx91c1x9/SFXvfEhNgo//AaKM8bRo3lRK6zxN679L dOw/n6XZE2SMlByET7MFy5/0zYIl3NlJNW99SJUNv6SODr04GRl/RLOXPko5S77k3a59KLlqwRI6 XU9nGprpaihMd7Nj0XsmBcg/73G6cWgDFSzmSXuOge7103X088Nt7KhyFOfcQ73hDJpZkKNNG7x8 tIp+XlFFZw7UsfVDgGYU5NGSYqevhTBbGtTRvx+tozMtzRTiL9PtPFEu059Ns9YX0tylj0dbn4g6 svXE5fMhXiFGTDt4hPZzPH/xAcpZzJYKwvrB2MZMmEw+t/dSmC1Yxt5iC5ZQGzVU1FGvxkoUUOc1 Y20O3ev1nJoV4f11bpuf791JjdtrmJG+Zc5bQXNXraFZCwLunESwPtY1dLaNrnP03rM1bGUgpjOx v4sTW+k+tawjfHT/pIGb3pSswHL50Bv072e7jP7IZQ/30D3TuS9lTRQkYm6hlno6vq+KGrn/t/P7 JdNPdG9WNvknpVHLaxuod+FR2rBptkxD5sVXen0Bmps/mz4920wtv/iAftvZRZ+yE617H5xJU+Y8 Tr4k/IvIDJwH7Ffm5GtVdJVGcVtz3+EJvJ+2s++h7cIXSYByD+6jmZkXqW7jC1R7WLfoWrKvghYu NURHJT4JLk/kkH98O/38tW1cZ+5TXGf/4s0ULCmkKYpPE2cx+nTeyVZQE3QrqKgpcYqFVNQ9NTMW CqvY6qyWry0/cYZ870zRphtBYFEh4RgEQAAEQAAEQMBGYPAJLGxhcbduYeFqJXGefUz8PzyA5M31 vq12fT2xhIQ7SmDhaVDTeBqUZp8SZZ1isQo1vEfjZv9E8+PRxX48rLGixcUK7TyaS603FtFkdUAk grBwtp6FM6ePGzV28J+LqPYbLESY281PaNrdpXp5zWse++zXi9hXjhLXDMcWO9sWFdN6Y8qXedl9 v5R6PsuSK6y2vf0uPZwrBhLeW8WH36O86ffYA3Qy5/sMzvY7trOU9d9Lp2naH5Unxul7z1H1hi/a yiFOju+uplnP6pZjUTeNCxX1XNcsR129Ase5rgksPGWlLn8KVbIlSPQmBmhaT40SWC6XP0LPFRj3 tIgrqPRSEZ3L/2Pay6KHc/O/doY25FvTNeRKL86A5rmrA9V4PkHMyLxXnaPevEgHH/tj2s8Dybjb vHLacXB1Sv1L9bbs5Okua6OyXn7qBs31Ox9SNViITm5aRtu3xOr/hVTcuZUeMrXN/tZVWq2o5XA/ Xs4+MOYqPjDcQ/XtanICS5iOjBhNe51ZqX3Aec84t6aZeQQQl1VxUU67ihFeuZV7+NcUnBNf5FGi RB32nub+44/uP1EBHReW/OI3tPAxH/We5ulWfp5ulcC2kvtkVsw+mUAiShDZjiwEPX/pI5pi0847 qG76/VTJz+UMfj8UKO8HJQlqL19MRQU13A7s8JidKn9oWK5BYFEp4RgEQAAEQAAEQMBGYDALLFEW LOyYtWrNNymXp+4IC5amG2spEGuMYKtpMieWkHAnCSzSuoFRlB3/PhU+xtOv3Labv6Wq7x6li5kB KnpGHYxbXMxoJT9ay9O42GfN5nLaZPqt+ZHLyks3O+kpFs604Zp/FlW88CjN/PIfUvjiBdr052/o 19kK5th/FdFsc8DGmVw8cZotT5pp7bcb+UwIKGwNMj9ItRsClNZxmqeTsRCkbW4WTb+l0s99izYZ IUSfKfrel2gUCyCbfnBaXtUOljxNx/5xpmbVIs47fvou3fe0Obh8gEoqF1POkw/w99vfUf3+Rlr0 D5YYUf2rVyn7wZEyvfrCVfSVH4jTqVTxr4tp0Z/+IRs93KC2f2umvKffMWWDlAmE4dONbLXylsw/ 5oGLb5bmV1+naf9gCRYlP1pH2U+mky/8O/rZ23WUa04Z44TLP/w+reFVfvq7VX36p/LLsJ5WkBZu CXKeF2lvsUOGUweZHLj3/Af04YmLbCXBX85XvSAtK8wyzdi4lfy+EO3eWKpdmrGPB1BLTYFFFUoC tOS1IvI/wZYYnNbxTXPooCHQLDl6mRZm2a0kLr+zgZ5bto2tDAL85d3iJc7lxtcztzfSyrWP65fY kmMrW60koq/whMTUOW41C9R9kU4e/Bl9KmRDhZdzgGgGN/d2EWoFrT66hqawXxm61kYnt6+lvRVm /dlRaJgdhQort/7WlQW3qixhLRCgTObYbhaG+Waax7xvbwmwsFNhCTvKvVQcyoG5o995pX2VLTHO nOd12Nhi5GrDNtov2MTz39LJz9WEBVqSmQUVtHp9Nn3Bl0bXLzHfsnyLryOdqyd4isrRN/gZ4UG/ urH11cKFkyl0sJQalM628CA7M15g78dqtLjHN0N07hBbeh026sUR/OzLJDi9g15avMGK7i+iDVsm U8O8ZexjiLd8c5lqjn+Q47/D8Q8wFz/f4/L5N1ZQUJSX091p1sVfTrtOrU7NylCczdWDhgWccCrd zSs62X4r8HtgKTtRPqCWlY/VTbGAWc3O92dNIhnH+fzAya0KDscgAAIgAAIgMMwJDGaBJXvdIgqy I9u2gzwY9mdQ/XePyMFp8J+fY2sHdfCfyoa0hIQ7SWBpe/sttsgQQgVR9X++RtlJT0+xuAjz8Mb/ epZmSjHkBm2b9k1aL37cuwziRZ7hzt9SF3/tzRhviRHiOvGUmWn36RYYrlYditVS8DvrqPaFL2nR xH+hU4007lFdXKjgpaPzlKWjO35cTfct0oWQ7O+to8oNX5LWKeHOC7T2vpelL5rKX/F0tAeNZMOf 0KLRpaQPYeZS0+8WUYAHT+qmilX2FXssRlEWOSKBaxdo0Rde1tJO5VLXIWbbw0b8oV820sN/LlZ7 mkVNVxZRuliyWdlGpd9jt5BgsekutrbRN47zX89QQLapfjV06kNmrFuNET1NVz6bT/0YsmmJvvTK u/xlWBew/MWHaPXGII0xp6KxEHBkOVujiMGP2LwGutLPhx6MiC0q2jfTQxOMkVQ4RFev9dC9Exyl 5ak+V0Oj+LrPjGjsO2j/iPvpIJ85rV7sAa3BWayv32acXuH4NsxnLCDsnTpHG4CubrnMUyVYLFKm FtHYDPepRWZC/d0rvJwDRDVp2wpJ+fto12s5UYNeU2wS8dQVk1JVVylyCNHpFvurkXl79TsVluP4 6jv5vHpUfMfMFmP2MRNmHzNm3zfSO8eWE8XCcsLNEuY8+6eZtEzmvPzor2muMh3pasMbVDAn37if GofKsl6K4COtO4SfnBDXgd+RXo6pZXwu1RJewWqhsoKVlU5qymqCubxvMTvJFm9xtz7EjmtZKN4t /l65tjM/46tYgKng+9IRrvXcO58fCCwmdexBAARAAARAAARoMAssMZtn3bPUtS2gTF+JGTrJm9Yg +Y4SWN5igeVvhcAyi1o/fYYmO37Ux4cUm0ubmb7n9KNeamvgJaB/epqaLt3QshvnG08TWejZ9G1d CHETWKTjVhZ1mm48a7daYsuYRWwZI35G2+NaZbULIEotzSWNHXFV8STIU49q/y6dwmKArGxpI27Q ptHfIt1GQi2Xki+Xt6I6i6ZN/kNK942mUcw7jfcU6qQm9ivz8PQBWG7crJNnGyiV4MOLLLp90RDd Ygk+zbvZyuVZ/gLNm52zdim5/7jNnuQ2axCxeFrMrkMuX60VMcB9AMRx1TD+zbT9RBHdm2CfFn5f Wg6+Ry2n2RJGbOw05f4JE6m9+AXN2iS2cGINtGKH05OW/8vyJrFMc3eIQqEemUTMA/Zf44u1so7M P9pJp5ru5QoemK7S5cXlp35Dc9kfiE0IEoG7j9Ny9m+hbW4DVJlXEnXVU9P+lyKH6+BYCWgcSmEn +lbUlZG+DBrjEEzVQDJvt3qpAV2OvQQGZ1CZB9/QrTkC9IX0dBotfOWMSNPKd/U0+6MZO5EyH7QL gWrcp9hCJcfFQkVdPUf1MXL9UofwZpXQNiY9g0Yaz5NZL1VMM6+pz+dlFpiecxGYrLD6VBubxC6n hkULIf1pV5mnax8K0UFeUpv9tbsKLNdP7aSvP7aWb/L0ok6eXqSJztZzD4EloS6EQCAAAiAAAiAw PAkMZoEl+/V1VPKn9xgOJHup4xzPm654g7aZ/jRWPks9r/NUkZQ3nTVIvrMEltdZYNEHydVssZH9 YLLgLC5ug2wpsLhYsAjRYiY7X9Vz987XLV1VYGllgcXu3+UG7Xjqm7SW+4Q9rlXW7B+5TFnSimBN IVLjqpY+3iVV76gCC+snJ47QuJnCisRrm0pllUF2kvvFlPddycqlDdxKI9ssnuimWBFVfvwq5Uy1 DZHckva+xgLLoyywiKkETx34NeUsdPcTIQf6XgNdOYgPUryVQGRh2IpkP09DOSi+XMfYYgsn1kAr djhHBrK80QNJR0h5erliAYsd5lQ1edn9wM3aQQ0p848lsHDdzC/3atxYx27tI/NKvK5qFpaIkEh8 xRpBTcTjOJNXfiqNsfKTzNutXh5pmpfloD5uXMsHiBnXuffnb6WFm9ZYFllGAFk+IRyEeTUqN1Hx ZjNtTXtEEwulNVaYr43VrznzcjtX/fSY9VL7u3lNnQ4ly+aov1tYmWeIyzVelMvZ1v1rV5lnVLoi Z+sZVsuvlYkd8+5P0y3ZqOAo7d0ym3+D8BSwEV105LH7tVWJlv/iI8q81kX3zplNPLOLYMEiWxMH IAACIAACIAACg1lgifLBojVXL9UUvkyLfsC+ONwsGlLSpMrg/HUenK+0ecdLSQ63I5FwC/vqmKZP pymp/z4VZSXrS8PiogoSZl3kYN05uGefLpvuNq092GD7H5fSmq9OoskTRvHS0L+jiyd5VZ2//Ykm vrilK0UDbu9ogcWrTNZ1T5FMcbyr5tvG1hoPG9Yaom6Ku1WzqvrezzsxUJ+/iK78ZK5tyfAQ+5BY v+J12hNrIM/TnSLKdCd74n07k6wStGCRbUbsnPhTdk7sNlgTRTnfzM6lX9cKVdnKAgtP3evzpliw mM4w3dKS0wocgzUZtg+DeJtvkcVFVLAqmy0E0tkHC08nam+mWsOHhDqQlPnJA2twFjucjKAf9KG8 UmRyJOV6miqBZQFPjTB80cTo/ZpflHYuiL/YvtKNVrY+1FWtkxyouw6O1ZDimNvDVmbnfft5vKW1 Zd5e/c6enO1MDuoTiStW2Nn+Am3faE6/syVlnKgWFPolWT7hWyTMvkXcntnuDyjXN0uLIPtoUj5y eNUcxRGyWS+ZFqdsXlMtWGTZHPV3C2tUULFEixZY+tOu1jQsnnoUOqBNYZJ5UogaFnyednM/V+uk 3WdO+mpfVmivo1xmFPSnQWDxAoTrIAACIAACIDAcCQxmgUUd9KptY/nWcBtwGyF5GkbN/l/SxRBb /0/4I1rEy8z63H6IqgnL4wQG5zKs/eDiiWaq+bdrfHE0Bf4iQLMnJSti2NNL6ZkySKb5z1BX7awk p1hZXNzaRg7WHQKLHPRzZcp4JZrCqJVoeGnuz+lLc7ula8V3a2+vMlnXo5eb1qmGGtjSZLZuaaLm GzrVwD5H3tEC2XyzJNgYHadO08867qHsv2CnvN03qKvbMMpnfyid5y9Q5TfZCksTXniq1g2eqpVC EyzJav5Sbt+suO1riUnRDobV6sqVpfii09eNGi6hY17Z6dHRugWLf8tHtGG94iRWJmCJGOoATt4W B8kO4pWB04wtR6lgPX+ZdmwnV32OtrPfhahBly2cVbbY4WyRlPKyz4pr7LPC57jvciqWST7e0M5L ALvcdFwamfk4zZpjOvN13BSnklcsCxZ2Ilu2gIo2CquZQtrODmwTnXZly1HmlXhd1fhyoJ6QwMKD /UNV1NrJVgZqIm7HPNVPLIM8Zao3fJm3QyRwS855LaaQoAZm58Mthz4gH5clk6efXA918fLOHID/ RvXy365fcX12btSdPavTckQSsnx8XND+Gc3gKZZRm+KgVfZRdlh75p0auiryibeF0+ihZTl0v4HJ rJdMi+Ob19TnU5bNwc4trCyC7CtOgaWf7ar4qll+gledmq48RIo1TxY7wV4pnWBzqZIQop7v/Eyb PgQLFtmaOAABEAABEAABEBjMAovXl/L6olL6yndjWLAolgmyhXk6UYSnEyW2WYNz7+kl0Sl1/JSd qj6t+xIx7/bNmawZO9V7rtez3zBWYSLKY/8iFa5LG/MqQpvfobKWDNrzv/9ScfBqcVEFCbOUUmBx WE/IQb/Hyk9tP+blkBfp0yBc21xOT2GB5VOeIuQQyqr+ehXl8mR6Z1xVFKD5T1PTnjkUSNeHYG1H GtgZrC6iiPLb6iPz4xvr1lJk21SzivY9r2rV1vIJddAf0uzppmfYXtoz7RuUzwJKYXUJlX3VvG5F bd5aStO+FaP/WkGTPrJY26ctmQmFQ7+li5d6aeKk8ZTGHFWrJvKacscWJ+t5So8+3OPVu37Hq3fF 8GFh5uW55+fzq7xk90EtQIAKzjbSjAeVwQ9fDx0tpTXzXtCTUBxr2tKUA7MYX/LVCDI8f513Drg4 XO/ZGto+dbHug2Uvrzy0zFusaDSWa3UOftXsoo45/+1pU7SpUa7LDAsrmvMdNDJzMvn6wzcqY+OC Un99VRQ7czOatBziC7GmcFGog1f0aSOaMC3KT4gQc/pVV+mXI8G2NQufir2Zt1e/i5GHFBLixLWW L/YQsXiKTy5P8RGbnOJj5CtFDO3mVtpxotD+8YAtY44s5KksbJ0hNqe/EP1qcv+b9VL7u3lNnWIj y+aov+xTjutaKWS/jDHlKbni6qFtU30OUWVZUKai+qhxE6mud7KvmpsyuCZ8jRwRouPLp2hccw+f oT/zT6Qxhs8jCCwKKxyCAAiAAAiAwHAnMKgEFv7a33HpE1r78A80p6WF1UW06U//gHrEDx3x9f9S J9X/8Ce0frcYnPLmZyuMJhcrDF6p5SleqcXuuSC+Y9fwNV7lhr/ujRrRQ5V5xZpfD1q5gq6U8qo1 4qtfmssKOFpB9P+Oby2nWd86rVxhEaOymCq+lm67dltPLp2mu/6oXBYhsO4Z2rMuQJN5ZZ9w6L+p iZdENqfriEDl7G9jjeFvI3Stk/b8bTGtF/5Omr5HuQ+OprSxxjdjbrv6f3mLvvIt9rLCU2Za98yi yem69Y416OcJByuX0p7vPEqT+ctox/lPqObVA1Z7cn55lUVUNv8PeYDJcYWQEmbHuO+9ZwgwU6m2 dQXNFvmKe9wnQtf+m/ZwW4kylf1rMeU9zssLy8HpDdrD/lny+Z7c/GxVwqKIc7MJLOwGsuqvWYjS PCBymZlR5QYusxBnuC8KDvX7P+Slms0e9gA73y0ynO/a45ZwfdZ8lZ3ZGmPZMMfdxgz1Ja2DdOXT v7RNLXKWK+lzRRwSKyft+QavnMRC0MWzF6hm909ok/Hs5LH4U6GJPywIPcWCkMloyVJq+udZUojq OH2aXviTcrnakuvKSEkXkmjnu+dozUJdshHRl+xrpCy2vhjJg6LWfdsc0ybYxL9zH3/p1yFKx5fK qjwFvCrPw6xliUHRyLHj6G7uHyPHOgQEZdBPPL1iQ8tmmvLgOPqUlx5ueWcHWwwoUzV49ZwdvGz0 mLE+6eiT2AIg1N5DNJYHWvlTqJIHsJkbD9CGgsf194PBQXUOakMjB5J8dd5WennfGm3p2FA7539g B+0uNvKXS9zaYid/IsrbyeUVm3heQm1yFaOsfR9Rzpx03WqCb9kcv6rl5HtPvXaUgkvZ14R4rtgX RYgt4U5WlNLe7Wb/L6e9N1fbrUfUNJKoqzaw5Wyun65UNeLYAABAAElEQVSi5+aJZYBZgGs5RA8Z lhR8gd/DcZz5aoGS+M/GaRTnvcfIewWVXioj302DISfpbNteHohfNwfi3N0u7/0GvbRROAgu5LhF StxRbElpVUIKEaKY8zZT6WtrKFPeD7NFzjZ6bqEuMDod2driivhs5bP68Gr6Avf7kWx9cXCOsVSy uDXPxamsuJ7E1surbv3qNaNe2nORzT6h0xQLFqMv8zVZNtHme7l/8zMr4rdsWUDbt/DfBuW6VgT2 Hh5qP270yyBtOL2bn0nLuW4SxXQN2l7O1ljGamULD/6al6yeyMu811HxpAXULmIkuDR077UQL3Xe IQUWYfWynH1HjUzT3zEQWFzx4yIIgAAIgAAIDE8Cg0Zg6f0O5fNX8j0JN8NUXiZ4rbJMsBKRl9l9 ipfZNX/+63cWUddncz2nTKgigJJS1GEsi5TmV8tp2j/YBZa++TqJyjalF0ItvOzuNGUw6ZF6kAfo 1cbSxm1vWQ5yreBszXCDrRlGWCv5WPf4Z/+PTOeyyhLOaoAYx9qKNlN/y5YTmwzLCStw4J+LqOkb D1DMMpljaxYXar79Bi36rr1dRGrZSx7gaWS62GIXWPhm9ye0/g9Ko/K2SqEcrVtBPdseNRzW2gUW M1RgfoAm0jWqec8SdwZGfGPWn+Plss2MPfY2a59E68piY9frj3o+Qx5ZuV6u+uxvEnOm6merM/Zn IzbN6uPBi+yoc4pmZeKasLzIU1O6eRqO2Q+M6+fKHqHijfFcLctESHWIepKtVrYfsO55HTktDtRw ieQfNWVBTSDhY2saU2JR7NYDvS1VtHz6soSiPsWDzRx1ioURK+m6KlM6Ymfs3rax43jdTY6TrW0T Lq+et2r9IYUIW7ECNGPxRLp6oEYf/Gv3oi143OPaEjJOitj3yGaH7xG3cDGuXaqh3MzFUQFWnr1B U06t1ZekNu4WXOLpSiFeQnqq1W9W/uvbtPvPvxYV3/TvYlqC2QLE8yVkCxznhIW+KrYaqzWCZc4L Uvth65dBAdfDaT0XlaLnlCGrH0JgiaKGCyAAAiAAAiAwfAkMGoEl8gPa89dsbWBYDXi1iBioBuc9 Snl/xwNWaakQHfr4q2/RrH9oNG48QBXH11LeY/dEBzSv8FfZaezEM/bQaxY1/eYZClgfIs3Y+r7z Pyj/Pq6HeXXlM3Rlx6zUWiiYafd3z5YUO4oO0Nrd0cJDYMnTVPbCn9HsqboFishK9VdiZR2kC2yB MZHUKSTWXZu/lW7Or3AP52cJDCJkYEmQykvn0KifVfMywFZ7Vf/qOV7lSIgV35SWJGbK5tSbiz99 l774tPVjWbvv4nBWXA938tLIv/wthdgiJu1/3EMTpz5AE8dfo/Xs+0XYUUQJLCISizN1//IePfUP 9mlf4hbRA5T3nSxasSRAM21+drjMbBGS28FBWh7g7++fuPQpXr75X5+mvLkDZNnEPhy2fUtYBtnb NjB/FuUue5Ry/uJLlOF8driu9T88SuufrXMvbz2XNyt15a367OsMKEzt+0qpaHmpAKpsQVp+mL/+ n2BLlmJ9uWBxczUPhmZlihU+/tiYXqREiTosYgegm10cgIbpTNlatjJwCIx+tgIo30pTRvyM1jyW L1NTp8i0V+RT0SpHPBnSOlh48DJ/Kc+wLtiOQtRStp62OvOnIC3ckkMzlrJPjgkOVcgWP/GT9vLF /PXe4hczJlsW7DjomGrCFi9HSjYolipKCv4gLVm1gmYsDGpWCsod5TDJuvJqMrt5NZkGJQXXwySX 5HZNQ7l4jjkVJ8hpyeHLtHCO0bahD2j7+FnalC8lOc/D3KOXKZilx+09+wYtn5qvOQomFhHbDRFR jewvqKCcTSukHxTzniWwsJVM+2oKHXyDjuwtpZYWIwT35dz1hTR36eN2qyIzgWT23dwmvug2EdNq /J07abm2lLFI0HAkG6qjokzDOoTffhvOVNDJKc741rTAlk2P0FZh2aJsfvaPtMHFP5ISJLlD7ldV cx6hWpOPFjtAq08do1l+rz/mShYOkca6U8jvmK3aOwYCi0UFRyAAAiAAAiAw7AkMHoHl9dS3BQ+m w8J8O22kPqUk9Tm4phg2nJrK6TOuoQbJRZ7ac/HS7/QZUCNG0bj0e5QpNqkvo/AB0tWtpzvKN7B5 xS19J0+Xuq+cgz1AtVeKKOilH/BUpI7OGzojDj2Kpy/5fCO9kxf9boTV58LMOBwW573Uxf0xY7wl XHknkoI7YgpVqFebHpLG09sMa/bYCWvTroRjXhGMxSifmBaX+vLqAotRFDHtpLNLP+E+6EtPYNBj RO3zjv2dhK7pUz/ElKIx5hyuPieYZETuB9e7Q9qUM9EwY5zTmZJMbkCDczm19hEdSJt6xbySKe9Q quuAgrQn3tvNTnkNpmLq1fVQmKefMWN2eEu+DBrjobNZAovd6khMX9Q2MR0Mm4NAmK6ebqNP0/jd wtx9kyZ78nVETOgUAktCmBAIBEAABEAABIYHgTtaYBkeTYha9oUAW2xUrWHrmN0istvqRH1JFHES JWATWBKNhHAgAAK8ZDpPw5m0jElETx8CnttDAALL7eGOXEEABEAABEBgUBKAwDIomwWFSiWB0CdU +q06aqLxPK3sBls03UNt362zfPQ4Vj1KZdZIy50ABBZ3LrgKArEIXOeprC1782mnMa1myT52ACwc ybKz2DEPzqSHJt0C669YBRym9yCwDNOGR7VBAARAAARAwI0ABBY3Krh2JxEIn26gUX/yjnuV2GfL heq5NNHDHN89Eq72lwAElv4SRPxhR+DmRdrN/ocaPCvuspqTZ1jcSCUBCCyppIm0QAAEQAAEQGCI E4DAMsQbEMWPT0A4cH37Q6o/+9/sC0UEH0kZk9Lp8ce/RDOn3hM/PkKknAAElpQjRYLDgMC5iheo 4Sxbqzjr2t1Fo59YQwuX8apb2G45AQgstxw5MgQBEAABEACBwUsAAsvgbRuUDATuVAIQWO7UlkW9 QGD4EYDAMvzaHDUGARAAARAAAU8CEFg80eAGCIAACIAACIAACIAACIAACIAACIAACCRGAAJLYpwQ CgRAAARAAARAAARAAARAAARAAARAAAQ8CUBg8USDGyAAAiAAAiAAAiAAAiAAAiAAAiAAAiCQGAEI LIlxQigQAAEQAAEQAAEQAAEQAAEQAAEQAAEQ8CQAgcUTDW6AAAiAAAiAAAiAAAiAAAiAAAiAAAiA QGIEILAkxgmhQAAEQAAEQAAEQAAEQAAEQAAEQAAEQMCTAAQWTzS4AQIgAAIgAAIgAAIgAAIgAAIg AAIgAAKJEYDAkhgnhAIBEAABEAABEAABEAABEAABEAABEAABTwIQWDzR4AYIgAAIgAAIgAAIgAAI gAAIgAAIgAAIJEYAAktinBAKBEAABEAABEAABEAABEAABEAABEAABDwJQGDxRIMbIAACIAACIAAC IAACIAACIAACIAACIJAYAQgsiXFCKBAAARAAARAAARAAARAAARAAARAAARDwJACBxRMNboAACIAA CIAACIAACIAACIAACIAACIBAYgQgsCTGCaFAAARAAARAAARAAARAAARAAARAAARAwJMABBZPNLgB AiAAAiAAAiAAAiAAAiAAAiAAAiAAAokRgMCSGCeEAgEQAAEQAAEQAAEQAAEQAAEQAAEQAAFPAhBY PNHgBgiAAAiAAAiAAAiAAAiAAAiAAAiAAAgkRgACS2KcEAoEQAAEQAAEQAAEQAAEQAAEQAAEQAAE PAlAYPFEgxsgAAIgAAIgAAIgAAIgAAIgAAIgAAIgkBgBCCyJcUIoEAABEAABEAABEAABEAABEAAB EAABEPAkAIHFEw1ugAAIgAAIgAAIgAAIgAAIgAAIgAAIgEBiBCCwJMYJoUAABEAABEAABEAABEAA BEAABEAABEDAkwAEFk80uAECIAACIAACIAACIAACIAACIAACIAACiRGAwJIYJ4QCARAAARAAARAA ARAAARAAARAAARAAAU8CEFg80eAGCIAACIAACIAACIAACIAACIAACIAACCRGAAJLYpwQCgRAAARA AARAAARAAARAAARAAARAAAQ8CUBg8USDGyAAAiAAAiAAAiAAAiAAAiAAAiAAAiCQGAEILIlxQigQ AAEQAAEQAAEQAAEQAAEQAAEQAAEQ8CQwWASWqv8v4llG3AABEAABELhzCeR8btedWznUDARAAARA AARAAARAYPgQgMAyfNoaNQUBEACBwUgAAstgbBWUCQRAAARAAARAAARAIGkCEFiSRoYIIAACIAAC KSQAgSWFMJEUCIAACIAACIAACIDA7SMAgeX2sUfOIAACIAACRBBY0AtAAARAAARAAARAAATuCAIQ WO6IZkQlQAAEQGDIEoDAMmSbDgUHARAAARAAARAAARBQCUBgUWngGATiE7h+qYN6ZbBR5Jvgk2c4 SIDAzTCFOrv0gGGikZkZNGZEAvHupCA3iXqZw8gRaURJ1r03zNB460vcPiPksvZymYnSaCQXOdUb BJZUE0V6IAACIAACIAACIAACt4UABJbbgh2Z9oWANsDjiEkOSPuSlVec3tNv0HJ/vu32ytM3KGvS AIw6eVB7PaQPpokH4mN8A5CHrSZ8IrIb4GycDP2vnaEN+ZOdJbnzzrs76OTendRQUEotSu2ythyg JQXZ5IvTr3vP19PepXOoQUYO0PLD+2junDjshKDV3kbtJz6gk+/soYbDzbS65QbNmhq/oUWetZs2 0P4DzVaJ/StodXkRzXpsonWtn0cQWPoJENFBAARAAARAAARAAAQGBwEILIOjHW5JKTrrqapgJ133 uVtcjBk7jkanT6aH5jxJU/ypGzylpG4322h32hRqoBX0criC7o8zGE1Jnm6JXKqjoswF1K7cW8mD 1awEBqtKlNiHNzuoZfv3aevGbY5wQco9uJmCCwKO66k5vfxOPj237A3K2neGVi6NM2jvT5bnayh3 0mKZwgwWWArucIGl93wdFU+y9xsJQDsopJdDW+n+sfar5lnv2SpaPnWZeWrbP8XtlePRXr2nOZ4/ Ol4iffb6iW309Sc22PJST/xbGmnD+sfVS30+hsDSZ3SICAIgAAIgAAIgAAIgMJgIQGAZTK0xsGXp Pb2TB1trE8vEX0ilh7dS5vjEgg94KBZYtrPAcpKyqbT7AGXG//g+sEUKN9P2sY9weYgSGawmXJhr H9Du9FksJMXY8vfRrvKclE+rubyPBZblb9CtETzC1Lh0NO08QLcovxg8b8GtyxWL6blVNVpO/uJ9 lJMfpC+M7WEhbSVtL67TS7DxKFWWzI4uDQtu+9Pup4PanQCtPnGI/OmddGThI7TfsGYpaP+MZkyI jhpqKKU1c17gGwHyU7O0nInbZ6WgKdIMUsGp3TTDn0G9nc10JP8Rqjys5xU3HT1Y3P8hsMRFhAAg AAIgAAIgAAIgAAJDgQAElqHQSikqY7iDzp1oo08vVdFLPJAW21OvHaD/90HdouXGpWZqWL5BDsLI X067Tq2mMSnKvl/JyAFfNr3MAsv9t1tgkeVJocDCaVaxiFRrgJrBU0eWrwqSLy2NrvPA9ufreWDL goS25R+gyteyjZPU7CCwpIajWyqXKxawwFJHmcVHqXSTKqJYQhMJ66xuts5y9O3rp3bS1x/ThdEl R39DC7MMC7TQB7R1/Cztec1ka5JSD2uS3m6e98V9aCRd5P71x1r/iieMqJYvK0+xhZZfKVSYrcnG CmsyIv9rH/H0rv5bVEFgces1uAYCIAACIAACIAACIDDkCEBgSU2T9Xa20Yf7quh4Qx078NTT9KUH aMrSHJq5eDYPklOTT0pSuWkNtFaf/oxmTVJTDdPJTbNo+xbd54LbQKzPdWUfFGcOMqN3qqid/UCQ nwdm6RNpxrwg3d1ZR5VbiJ5vP0BTXL7EEw/qtvOgrk8WLDdDdObAHjrC7XNS5KttAcrauIbmrsqh zAkxGkeU+ejP6P+evkifsnOSMekZlPlEkB56sCvhwapKN9bx5X1s5bBct3LI2svTdJY5p+mEqHHV 52lnhZ6Kqx8NFtHO7HuDjhys0eqayYx9D84m/9L59NDYTjp+oJ7uXVBEcxdETwHrj8ASOl2vtesZ 5hsyKumbHuS+n0OPso+QkVEVt4SFrH2/ppWLx1F7Qz21n+2kG+EeGuljzo89SQ9NzYiKKS/0oV0v H3qD/v1sFztqHcX+ZnqIJsymuUu5H4q02D/JEe6bWh9hbk8t30pPr52dGoExdJHOnQ1T5nRm4Zje dpWnZhXw1CzysM46s+kRekl7HjfTjptFZMgrGoYzJXyvWPRpvhfme460JStxIJ+h+KKgNSUpwBZj H0VZjJ1c+jnankLrIwgstpbCCQiAAAiAAAiAAAiAwFAlAIGl/y13rmIDFa9y+suwp7vy6GXKyoox WLQHH9izeNYXLHbkTliglcEpsPS5ruz/pWjCHJvvErdK2vJjIejgY38sp0G4hZfX5pXTjoOrowaY 19kHxUvsg6JdBow+yOKv8CtdvsJfPrSNnlvo7YPCTMlWZvNisntF9CLaSrtuFroP7EPMcbzB0WHF cr2F6zo9dl21YvkraO+pFZroETrEU0gWiikk8bdc7sNBZx/m6SsNaxfQ7gpTuHJLZwULZ+UsnKlC liWwuMWQ1xaX0/a9q+leNSrf7Fu7hunIiNG0VybOB4v30Y6ydNqdOcey3FLup6RtlfTcDk+uYrFC E80KaXt4K91rE0ksTtHWL8yhgf2kzBF9NAHLrnjPvVq481XsJ2eZdiWXrWaCptWMuHKtnram67xS 5a8HAosKH8cgAAIgAAIgAAIgAAJDlgAElv41XXv5Yioq0K0OREpL9h6lGVmTaUy4k7+Il9LOYuve 8hO/obnT1e/P/cu7z7HjDbTYkWsuO3IVmzrA7E9dz6z/HL20XaQYpJXs22XGExPp7nAXXf7Fj2n3 wrVSAFHzE1/ct7LVSouIFnfjAWaYpw6pg1OlHiL6DPZ9sXDpk3QvN8FVke9iK9+nDvyachZaVh1X D26ggsWWaObPLyL/VB9dPbyBag3/E2aRbGU2Lya7VwSoGWy9UhBlvWImaA24bVYLyoBYCzmvkFbn zyff2BCdO1BK+4UA4uc7AiaLCnvfydEEFnPqipl6rL2fy7XBVq4QNSz4PO2WPLJp9eEimjI1nac0 tdHJLXN49RkzxSCVXjtEmcxe39R6mNfYaqQ4j8UUFm02lso+QVTEwsNmS3joT7ueqKNfnQ9Rb3s9 7S7Wp8mZuQs/JQu3r6ExmjWV/tyu5hWiZg3EClFGppalCF9w88GiCG+u/YKd3+Yazm9Xn+WyPuhQ oqzKsZWO6Sja/lyrQeSxze8L0fKDH9FMtkQSqwrt9y+QPoK8fL/IdBI8gMCSICgEAwEQAAEQAAEQ AAEQGNwEILD0o314UJzLVhn6toJKOyuinMJeP1XF/hP0L8HagNhh4t+P3PseVRlorT7LU4QeVJPi aSjrv0I7t+sWCRvYeaZ/At/vV12twbR/O/tsWOvw2cCOXbezY1fhMHY5+3uYq/h76L3WQdfZhQR1 t9HeqXO0MKtbLpOfne/23lTKPTaD7IsjWXmKUKtbfsPL0srRvR6R06zymT5PFP8X3c201feIIewE acPpfeSfZMW92rCTCuaslZmnQmBRfV64Tv2RuRGZU3msKSUhOjL987RXiCe8Ldz3ES0R016U7fKh F9gap1S/Mo8FlkO6wEJiCd/OLm1p5st7v0EvbWRhgZ3o7igJ6lNoZBqjyDfBYiAuh46+QGvmGWl6 ON5tZ8e5RYa/H7uAYG+fzIJ9tGFLjmWBxFN2Gou5HxpT1SzHu/Z4SbWrrAsfOAWp/ArasX2FnMqn 9bub48iXHkOwUNPry3GIHSWP1x0lC3FnQ/tH+rOmpqVM67EYWAF6W9hx9XS9L8bth8pzHzesyIKf j+38fIjn0m1beeo37JvF3ifcwiVyDQJLIpQQBgRAAARAAARAAARAYNATgMDS9yayfCdECwNqqu28 gkiRsYJIQgMbNfJAHCsDLeKB5fNLM/nrNg+025vp+KoXLIsRxdKhf3VVB8XZtPLAasqcNJEFkXGa P4q7hTISaqP282G6b3rAfXUcWeYEl2lWBqY0r4J2HVzBFjNCqVE2Hjv/auNow7LG+qpvCRjcrh5W R+aSxiK1VLSpaskQLz2rfIZlh5g2xFM22rksmWwFUeq2Eg3fO7OJrYi28IGfBZZThsDCp+Zmputq KWEGknv21bNqtDG1hVd2CvHKTmPlTeUgTA28WtBuzZJFncai9olo3yJ6AiGqY+GoUhOODB8j3A90 XzwcIsl2VQpFKu/MjYeomAWlaD8xaowUH7Nlyn52OHvQSHbJ4cu0cI7LFELZ791XW7p+opSXUtan eMXrN0lZsHC5es/WUPHUxYolkZ3BwgNnaMlCp58ge5hEzyCwJEoK4UAABEAABEAABEAABAY1AQgs fW8ec0Cqrf4R5tU/1OkparLK1/J41glqtAE7VgZtXnn4CypoefEKutcYNPe3rtdPsK+IJ2L5MwlS 7j52vrr0cfeBriyzOkj3Kj1fV6ZOxAhlu2UOUK26uvnEMKKkeJlmmwVLnGkplrijL1l9P/ev5exn Rmwxp7SwiHa5pY1VmMl0//hoywyz3m6WEkatlZ0ikChCnBJAHlrinGIlRFb8WIKOWSZprdNuTYmR GcQ5MNtVDSYFFj/7uznl4e9GjZDKY4dvIVerLjM/2e/dBRZZDw7vVk8zGW2vpBU3rLJCkZjWt/oX r9Kj0yfSp+0fUF3BLDpoTAvL/QX7Z3ms/1YsEFhsLYUTEAABEAABEAABEACBoUoAAkvfW84a/BWy /4+tMQSWGnYYuVjLKOYAuO9FSS6mMtCasbGc/Jk82Gbrjl5eJcc3aTI9xFYkPseyR6mo6/WWGqrK X0wNmkWCR5F5GdtK2zK2RjhZ5sQElt7Tb7DokC8zyfQTtbvmK6bSiOlQ2XIFI6uuMZzNyvIkMLCV pYhxoPgV0VbVWWr5g3HGamF/Nlu3i6u6AOQTAovphyOOOONMSz036520wOJwtqumKY4tfzaq9VHy AotYnvsL5/vermq5pDARRxxS46TkmC2r9rNfoYNGYm6Oa+35WJzchJjeFuYxXfRzXWwTj7LnlkSf tdJ1Ee04HXM5cbcyeeYf4wYElhhwcAsEQAAEQAAEQAAEQGDoEIDA0ve2usxTf57Tpv4E6PnOj2gK +wVx2643sBn/HMOMn32MZCk+RtzCD/g1ZaAVvUyze+79rWvoVB2d6cygRxewoNEdouvdvESu2MTU pPMf0PH1y6hWE0BUKwc9iB7OdNDpdJaqhFEPlS/wWezAdqXiwFYN5nZsLZccpGJ2zPqQLzqUanES 1xogOnr0FaVNyF/OVhWr3VcRYsuZrWMN/zCmOKBYSD118DLlLHCZamLmKPzWeFhamQJLYoNmHvgv GE07NUsGryk+eqbneCnhYm0pYVUEsIQDKjhElWXs88Vls5YhNoS18Ae0dfwsbRpbsu2qJi8FFtUf jRpgII6vNVNV+iNUa6Q9Y3sjFax9PG5OcpUh7hd7uV+oU5ksx9NxRF6Ri9LH4vVZ63nnpdOvfUZT bM9AiA6O+DztF2nyNK29h/QVqcRp1MZT/04eqKOrIaLREwI0g5esH+PS/yCwRJHDBRAAARAAARAA ARAAgaFIAAJL31tN/cpL/BV/72vZtsGPlrLytVeY2peGeCUVV18VfS9H0jGVgVaiFjX9qyv74ZjO fjhYQHGu1mOWvb3sESraqFuSlLKlQtSXeC7z9jTd4ebyFnaEO9XxqT4coqvnO2gkT3/xCb5KHaNW oTEzNfah0810+RrPnHlC9/8SYoewawyHsK7+OXiFlbrH7jd8g7h84Xekn+hpe/kCXpGqTgvu5ZPj TMkCeqlYDyOnZygrzQhLhuLOA/SQi9jXvu8FdjjLTmkLDrCgkR1VLFNg8Ro0X++8SKFQGt0/SRdw VN9CT+07QzlLo/1xCD8ey9mPh7bZBuOKwMI33ZaAFstOf52XndY2U0zqR7vqCRn/m1PIzHRtNwfg hB0nb2fHyabDWCcvIUCeC2WQf04g6h2i9scCdko940GjfOpKPzFEKlkbhV285z50lJfvnidEYTfx WPGNEytfW780SuFh7QSBRbYSDkAABEAABEAABEAABIYyAQgs/Wk9Fg74K75cpnZxOZXySiSZxsoj odN1tiVNE7MM6E954sQV1iLXeMUY/qpsrsjz1IGP6Okn0qmX/b+O9GXQGE/xpz91tQ+ml/AqN3MX sphhaCS919qodvkU2q9ZQxTRDl6S1+f8yq0MDmneVnp53xq6n+OH2tuo5cAOa8ldZQBn+SphLv5C en7vN2mKIQ70dndQe8OP6SAv1cy6j7blsnVRUFgXOQeGizezBcYKum/CKAqdrWdxhac5GXHEzr/3 IyrgVXtGOsushEno0DEIF6sBLRTpisjhDjpZtpK2G+IK+dlx76kV0solxMtKr5HLSrPPjKNb6dEn JtNIbvOrZ49Tw6Y50m8GeVhtWL5SWPA4eIbmzmPBJNRBl0+8R0eK8+XULjnId5R3xpZDtHxV0BC4 2N/L4Td45aK1surLedWZucaqM6LNj3CbV4o297NVU0szZW05QEHuF3ezf5b/aniDXlplLZOtCgJ9 blfO6npnB0+FG0XXT++h5+YJn0BF9PIl9sFyU7eoGjl+HN19M41Gej4HsjpJHNj7vzYd7UQRW3Lx syi27naqWpjPzmRZgO1mAdahHRJzlqta+TfTy78o4r4fpjMli6XY5uWMWViIXednvlfkozz3Wdy3 cubEeO4v8bTGTFMY4+ftnUK6XzDh9M68toxeMpamj2lFxKuDbeXVwcznSxTBy18VBBadDv4HARAA ARAAARAAARAY4gQgsPSzAXnwU8Vfpk2zf8/UxDK2r+XIAbFnuAG84fRLEp1VDKeuInCf6+ocYOo5 Z87LpnvpIp08LCxX9C2LLSFWulhCiLvn2MqlWLNyMQK77OzxeanfVZ+nnRUuAaMu8RSLEPvRMQbW 6hSgqKDKhUw+bhfnLHjsZcFDnb4hLie7xVu5RU+PRYHQZllW/Zp9wO2dr+VrJiqMWI1ovL4aUdQ9 ecE+hStRTlksQq1cpi8d3XuW/YZMzddT9PPOPgKXOZkH0avV9K1d4/d/I8cUtaVZ/oTzjeFHxfJj Y6aq7NkiaS9bJLn1PWu6mxI+6tD9ubemZ+kR/IuzKXSgRllVyFjZyUtYVKezyTzd/RpBYJGAcAAC IAACIAACIAACIDCUCUBgSUHr3QzRmb3bqGpVqTL4MNPlZYmPbqasrOjpE2aIW7Y/bznbdc1zMVtF vGNZRbiG6VNdWWAR/jo6OcWWAGWyU9n2qMSZ02HmNCcWpxC1lK2nrRvfcMQO0sItOTRjaTZlTnB+ /ie6fGgnWwhYlipqZH8+57k8m/yPsbWHekMcd35A+/OtFVPM22KFpYWL0+jgE8ssbSDGINeMl/Ce LQ3qNi6jygpLeDLjCiuPnIJsVz8WIkzoRBXt5XKZU1HMeGJ6Wi5b8PzZUncfGGa462x1VbV8gbRW Ma/784toJg+wH81ysdTpbqPGLS/Qzi01ZnBrv7iIni8uZMshn3XN0Q/9xftobmYbbRXTl9RtHsct c8RV7ifdro58laTsh6lsS5FyqJl2j3/EZvVkz9A8M5bd9hAs2t/hKV7L7IwyC/YxI2/h9urBF6hg sT2OmZvc8zSpXe+4pRGmc/tKqdjZLhxRW2WshFcZi37cZLLi4Fx5PhUXmM9rgFb+4hBlPRbtIwgC iw0bTkAABEAABEAABEAABIYqAQgsKWw5wxz/RrdIM8xTbsaRb7wysExhVrc9qWTrKlYpGsFTL4zB Yy87uv00nEZ3j+ApDOx4NSlOHP46xyfeU1oaT2uKM8ozYInpIaJtRorgaaNojM8nyxOLZ++1DvY9 oseLPY0qVirJ3xP5/lcnZ2xsPvYv4z2Fywyl769z3BtmmceO47omxkimIhwR87Qx4RD37rGJcRIr UYkpaNp0FI47mqfbJJXvLW5XWdchdNB77SJdbueG5XYZOXYi3f+gb+BLz/6NLp+9SHenp9On3B/H ZE6MWmUsZiHEs288q+bz7wwPgcVJBOcgAAIgAAIgAAIgAAJDkgAEliHZbCg0CIAACNwxBCCw3DFN iYqAAAiAAAiAAAiAwPAmAIFleLc/ag8CIAACt5sABJbb3QLIHwRAAARAAARAAARAICUEILCkBCMS AQEQAAEQ6CMBCCx9BIdoIAACIAACIAACIAACg4sABJbB1R4oDQiAAAgMNwIQWIZbi6O+IAACIAAC IAACIHCHEoDAcoc2LKoFAiAAAkOEAASWIdJQKCYIgAAIgAAIgAAIgEBsAoNFYKHI67ELirsgAAIg AAIgAAIgAAIgAAIgAAIgAAIgMFgJQGAZrC2DcoEACIAACIAACIAACIAACIAACIAACAwZAhBYhkxT oaAgAAIgAAIgAAIgAAIgAAIgAAIgAAKDlQAElsHaMigXCIAACIAACIAACIAACIAACIAACIDAkCEA gWXINBUKCgIgAAIgAAIgAAIgAAIgAAIgAAIgMFgJQGAZrC2DcoEACIAACIAACIAACIAACIAACIAA CAwZAhBYhkxToaAgAAIgAAIgAAIgAAIgAAIgAAIgAAKDlQAElsHaMigXCIAACIAACIAACIAACIAA CIAACIDAkCEAgWXINBUKCgIgAAIgAAIgAAIgAAIgAAIgAAIgMFgJQGAZrC2DcoEACIAACIAACIAA CIAACIAACIAACAwZAhBYhkxToaAgAAIgAAIgAAIgAAIgAAIgAAIgAAKDlQAElsHaMigXCIAACIAA CIAACIAACIAACIAACIDAkCEAgWXINBUKCgIgAAIgAAIg8P+zd/ahWWV5nv9RaJEqhUk1VmO1wqYo Xaomwj62ZrDKgk0XEbIpYbISQaKwWScWEm0IoynEKAQ0hXR0CayKW6bd/BGDYHAykMoIOnYayhdG a3waTCutjc9A0oaOdD0Deaoe6nFr9nvuvefec+9z7/OWaN6+F5LnvpzXzzn33HN+53d+hwRIgARI gARIgARIYK4SoIBlrpYM00UCJEACJEACJEACJEACJEACJEACJDBvCFDAMm+KigklARIgARIgARIg ARIgARIgARIgARKYqwQoYJmrJcN0kQAJkAAJkAAJkAAJkAAJkAAJkAAJzBsCFLDMm6JiQkmABEiA BEiABEiABEiABEiABEiABOYqAQpY5mrJMF0kQAIkQAIkQAIkQAIkQAIkQAIkQALzhgAFLPOmqJhQ EiABEiABEiABEiABEiABEiABEiCBuUqAApa5WjJMFwmQAAmQAAmQAAmQAAmQAAmQAAmQwLwhQAHL vCkqJpQESIAESIAESIAESIAESIAESIAESGCuEqCAZa6WDNNFAiRAAiRAAiRAAiRAAiRAAiRAAiQw bwhQwDJviooJJQESIAESIAESIAESIAESIAESIAESmKsEKGCZqyXDdJEACZAACZAACZAACZAACZAA CZAACcwbAhSwzJuiYkJJgARIgARIgARIgARIgARIgARIgATmKgEKWOZqyTBdJEACJEACJEACJEAC JEACJEACJEAC84YABSzzpqiYUBIgARIgARIgARIgARIgARIgARIggblKgAKWuVoyTBcJkAAJkAAJ kAAJkAAJkAAJkAAJkMC8ITBXBCz9/+8/5g0zJpQESIAESIAESIAESIAESGB2CDS+9uXsRMxYSYAE SCAfAQpY8hHicxIgARIgARIgARIgARIggblCgAKWuVISTAcJkEAWAQpYspDwBgmQAAmQAAmQAAmQ AAmQwBwlQAHLHC0YJosESECEAhbWAhIgARIgARIgARIgARIggflCgAKW+VJSTCcJLEICFLAswkJn lkmABGaGwAsnmCUzExxDCRAg3wAQXgrrBCsBCbxaAnP0naOA5dVWA8ZGAiRQBAEKWIqARaelEXiR lGTie5Ey2/vS8ndk2fLSgqIvEpgrBJKDbbKv4RSSc0B+le6SVaUIWabwbiTxbjgH3w1NAr8vnkp/ 2XvyFU6r+/4oe3a8azzk6aIkMHZFdlY0WFlvefSdbF7jfFQWMow02oixZ5LCB/R1/C1d8ZaUly+C fC/kMnXylkK5Ztx8viHlq8vdq5k4UfUmeCxdgf5XMdWniHbYF18Z6umKYiIKpjT/NQUs+RnRBQmQ wCwRoIBllsAvomjv7nhNuge8DFd0fyOd+9d7N3i2cAik05LC3+tLMBAoQ+dKCx3UDJg+XyC5HT2y Qb44cd/KTcsDDPbeL7YzmZabG9+Us3EDSG2f9A41ylLj1rw9ne6s58QNaV9dIwkFoAFcLi0QLvO2 QGcg4S/SaAeKfU+8eJPXO2Vf7VHrRnXvqOzZ9YH3cIGdZcbuy7XjR+Viz3BWzqrOfSOtzYv8G4r2 RQknlpbyXZlu25RVIsXfyDy4IE2xZp/HPfiOVBf9HfEF4V54EwDuLeuk6P5Xge3w5KVmad11wYss 1iO993a/1G8ZBSwebp6RAAnMMQIUsMyxAnmJyUn0HZXBoWeyTE2SJEX+uvWYbN70jj/GidtyuePX 6rHtaMU2aTzeKMv8roq6SvQ0S/te78NbdW4UncM53jEeuyHnD54VTBXmzGtKfi5Np1uk3OjkZR5c kcvH+yUV8Kvcbu9ukVUh44vxwVMyfPWhE1dSlq1pke0HP3E7J497jspX152yc1z5405K/GSnjDz5 NqusVm1tl7qtL3f2P/Pkhnx1pE0uD9gCBw0t1rxN4j1XrMvShBA6pLn3+/j4BunosPN7eOxHqVxZ fBrjENJ0OUIay/dCEbC8eCjnyyplRHZDu6enNO2e5xCwrHQELIeuy8XjnxQPmD7mDoFH/bJz3a5p CctSdzrls49tAUv91XHZXhP4fs2d3E4vJemH0r28Uu5GhbJQ2omo/OW9D+H0DginMXFT9HdlJtqm vOkrwMHYsLRXbLUFyI7zPXEIWNaFdBAKCC7oJBPvl6aNeN8CR9H9rwLb4dS9C/LZJkNg9AqE4hSw BAqXlyRAAnOHAAUsc6csXm5K0jKC2fLzcTOWY3LmRbuYIgRzVt52WSedU0NSMQPf/MTprdLeOixF f+DNJL+i88lLDZiNsQUD+aJsefQjVNU9V+OnN8jnrX5Bg35ahVnX1qxZ17RcW/Km9GpHzu/Or/8i dZtU6YSVnXK0HmXzjV026fvSvnyDr7PmBIOfaQxyvUAizxJ9bdLepJbK5D5msvOYO6ZX8zTz6Ibc vP5IZMX7snmHJwwrJfbxvmb5vAlCyIUycMIgphsClruyDXV0oMT2Iymjl67In56L/KymUSpnaGa3 lPKhn+kTyEDA0qQELNOp41MP5eal2/Jdukz+uqlRVi3QpaapEQiSamxB0qe9N+VvGz6UZUugHfj8 W0k+T0r5mg+KW+Yx/eKbYyF4Apaivysz0jbNIA58u7vx7VbCtKLzUkgylLYOJoDGexrk871XSuh/ FdcOZ+JnIdjZPy1BaiHZUm4oYCmUFN2RAAm8cgIUsLxy5LMX4dQzuXliq5w1Zsx9sz/uzI5O4jbp GOuTtStnQLqCIPUgcj4IWAR2YxJf/6ukrM7JG5Ic2ixnuxWX9dI02CU/00iWvyOVmwLaOOD8+M5D +WF5Ur742LYXoImKZAu11LPM2EMZfwIhSY2acVovFXIfwpJ26U4fk7fROUrhWWIMneuhGjsdsQPS em63xDZ+4Gq5JB/clnEMRjP3NkvXIS9GdfayZnt1mdqxbZPWe/9bqtapWeW0TMavyMVNu9xZWF9d sz3wv0PA5Tidwedcoum2JdvkVxCwhGltzaXkMi0vn8CMCFhefjLnRAzjfRgMN0HAHzuNZRYtbhs/ JxI3JxIxPQGLrV03R9omt618SQIWp7z0N+Zl979e5XtOAcuceBmZCBIggTACFLCEUSn+XmbiofxL X7/cGhmW5ITtv3zleqnc0SgfNXwic8UmXXCdbOzEN9J20F7LnbmHmYdNmHnQB1Q8L8Lugf9Iyzjy +LvrwzIavy/JqwJBwH2piG2TzQcPyJYdH0Z2BrM/8GkZ7bsg/wZeSx2BRSb9vfys9u8kts7Uq1Ep UPFekd+e65evBvSa9PWilqBsaVaChpesKv4E6u3vK+FHEdog6Dj1YxbfMtLZultGuu1lUnvuQQ04 piU0frp3926Q7h5P+yVL40WnI7Rs7LAmL7VBSwYaJbW7pVouyAjKSGqxHnpohtdDJ7GEY4WzhAPC oF9NHcsaSGceYNY6priJfDr4R2nMWqqEcr1+RW4N9Ev83jPLncg7UlH9C/kIM9SVlrDGua1+XjyT u6gDk/IGqsT38lcfN0psRQL14pTcRP1IxDEmaTgmdccPSGWUAUzYgUjA7a2efhl9Moz6qwRaEJTV 10Fw9kyuHeqUKiw/qA9ZfpB6MCy/xVKupWWIXx1Ig6z8SKp3Rdd726H9P/nghoyO3JfJJOzUwAjg X72POlz7oXw3hDJTBnOjBCwQ+I0O/FquoY25e1XXj/VSfWifbNnbKBWrs+vT+NAF+d2jb+20qnSu /gTvJ951FdYlhHXJCSu2Xj5t6pK/3f+Jf3lZ+pmMXv0n+f1VMLr3VOJ439VR0XBA6lpbsLwwx7Iz d4lDkRosSFu899fyp/QbbjuSSYv8p/rd0eVpo7X+F9sOp+6hTRl5arU/GXlXqnZ9gjbt1/KV5hyr k+2tfy+f4n6UXRxlK+NfoGlz69IwGIFPDCsL13wisa0fQCB6RganGuXM4AHfMkIjyaWdTqMOqwhT qIe/7T0rN7vxzjgpqEB7sWXvPtm8dX1kXlU7nFDvq3p30A4nUHcqVr6LOtwoVdC2i6NOfbey0be8 0Qle3LYgqo5rh8Hf5EMZgR2SjH7n5HvJpN+Rqv2N8nZ2tQ/6FvXO3UK6RvHeJJ2n5Rvr8F1ulL+p 8QTU2mNi8IL8/kkaDOx35qNa5Ov0Wbk1eMN6BxSnuoPtsrk6R/3XgRXzizIdf/TU0jb400CbdHfg O1d7TDpPbpOlStCvDxiJXxVhDLXYvIrD9juwVfU7A0Brm1swqaLrSD/aVQj38e6r976xo10qy5+i HboBo/V2Gyzlb8jkIN4Z1S7FdktbLyYFEv8g/R37rfdB0Ddo6emRzbFynQPnt/S+hKqHeolQ0Vof pbZNKtUltMNupjHxMnr9N/JvD57KDzBWvGwlvnMf18naNd+6xryLzosbeP6T7P5XDj/TaIfDBCyT I/jW4Puuv5uqn/fm+3VSjTYyeBTTNlHAEqTHaxIggTlDgAKW6RfF45426dibe4nEnuvjUl39koUA BWRFf2QFHWOxBkyelkTW8qCQjnD84GvS1Z0jIgzkv8RAPsxmi47bnUGBAKILAoh4MDgIfS46Qh/r UfK+XK7ZIINZDg2PzX1y5nTjzA5ijODdTgOWPBQ6I5+8fhQGGTsRSrucSR+QW2U/kYsqzNYhuXiy zghdn3qdRn1HpE46ng/JWqdv6qYjpGxsP89kcMkquYwLpbVSt7wfNgvarEetiR+larUX8nTPRmGD 5IsOe9DdgrXjm0PXjnvp2XPvLxAsORlRkcPeT//qzZYAKjItzT0o191uuYYZBozyGyrIgoBmeNMq uZirLiHAGOwEtYXYCQpf/lXAMjosbRhurpSLA2GpVQJOR2gSUq4pCKm+gJAqEebVuVcNo5d7fEYv Q5adQSh35uRKOV9Rk/3OIRxf597YOSIq2hiMVbeZxqrhZ3DTe3I5D1srvNrTEDr4bRdZ96EuH7bU LSuukEQV3w5HLb0LCTzCnkBy5JTsq7HfrxBfzq0ihUzRAdlPplWHk3L3yC7pPqGF1GGRHZCOiS5Z uyLw7Pl96a/dIF/lLV/jfQixMxEI1b2sOnFTWg9+6F7rE3fJgb7h/DZBUL0lQlBtOQGnkf1b5bwh sA4EgcvdcjhxWiq1gPIF6l9Z1FJLv++ZNjTraq34owm5Mvjqp6XkFX7D2LbEx+WnV38pHYdClsjC cOkXTWfkcKvTXun48/6ul8PPv4FwxnNYSl8ifmQrbFblqrs6/G1yeGJAKnUdnoG2qbR22E7P+NAp +bw+XzsRaIN1VmboN6v/lSvcabTD2X0U9Gu2wl6OmujxHdDOemFqZxXfNlHA4gPKCxIggblEgAKW 6ZVG4nQD7Ip4HZHtvdelqhrro9MTmCXulLMd3rOmO3+RLRuNHsb0oi7Jt/7IVp+D2v71BmvAZw2s 3n9qG6XE0pM9O76V84fC7EGYH8r1sv1cu8Q+xmxn+qncOlIjg84HdDuESfUhwiQdtytgSd6GBsRm d+AYg9HdjzZiRrS2TlZpTOgYXcZWrYM6t9BOOHwIM/YVb0kShlV/u7fB6/A3D8jFc9u0yxn9dTsN BQtYPGGJHhyOw8r+55aVfb/QxEuo56fl3jfy780bbEFAKwx8nrQNfLrpCBmIq3A8AQQ64UllO0cb G8XMOgYwnSEDGC/+Ys68tEqsS768dyBUqKZCTN7pl+GBp1KFWV81M2odU/elq3yDN9C3ynWbrFpZ LslHv5FBLJVyDTz6hHZJeTwI7alLp2yDujGEFodA5FCP1NVDY+DqKe+dg3r9l1CvN4V9ySEIveqV 0AsaNeeuS92Oj/A8jbp0S641b3XrkltHLZfev8yT2/Iv0HjABKRkEjCE3KG0kvII3QxNJjukOqk/ USfleG96OwKC2WC5YoC6E4YQ9VHV0Sf1O34hb+P9mPz6H+R8w373/fl0ABpC9d6s+uSdYfnDk6SR Th2K+l0v9d37ZNnEsFw8YbdRviVcpvATs9J7jjTK2nXvIiwYwa7d5ZQbBk0TGDTpQQxmhrtgmBPF UcABZmm0QVj+5j/S8hjaIOOYsV+Kcvl9d7OMIMCo8tB+S22HrfK8ekOGW4+6HFV57oHwZ1XZhHyF vOp6uBPtd53ZfmNQe7lsld02od083Pv38p/XvCU/JLFEcOCsdLXqss1TP3QmCvydTh32D2p3S8v1 fdASQ515/lDudu+XXlcYEdh6PKQO7+zdLf8JmhSTX/c774EWFHr59dqjAjIXrPvay9RTuTv4G2vW X/DODO+1y8onENRu3d+kjGz9iZx3B3XQorgK7Yt1KyUFbdO7J2rQfmjHaCshxK7AO6UO9d7EoaXT a73bTp5q26HpCU0SvC9f7LJtowSF37bv0v8rDZ8Ope2HyQ+lMaKPCjUZ4h64v6ZHDvdhEsN9d0rP q4BtfPA2toD23jU3KpxUNLTLlhpo8Oxts98DJWg8t17iQ7+ROOqLejfVUd87JD+buCJnVb/BOSoO 9Unjuqcur2q0T3vc9qmUvkQRAlGkwdeeTbdtmk47POhoJzpcYs3oN0FDd/JqG7R+NC37N3ed9rst 9iqr/5UzgNLaYRVkdh8lCRtzP5FeHV/tAWmCJmUFtMjWvu+8dHhWSttEAYuGyl8SIIE5R4AClmkU Cbav24ltRO1jt3RO9EiFHmw4d1P3oEEAOxT2EW5/w3n4Sn70R7a6b1TqyjCr0nABA+9v5HDNffls Y7PETlyXxjX/hPsRyxWg5jqZfEPezlJRxmADmhODyEXk7L9jyFN1tJo2PpVudya9Ttoe9EnM+Nhq GOasXvi2nOio7cXsSI/tw9ep0oHMwK/bacg3mNZxGXWjFUZwq9bgAQRKXRAoqT5pZF70zgjw8zdT jrE4uNf5ctMRMRhxtZAMYVPiJIwLH1KzfkUsb4LrnAcGXPY6driK1MiJDsFNJ5xka18of0mU60/c cg3akDGXum0PLOfxBtvZmgNufQq1bYDlQVtXSS86vQVtZamXa+WpE9q4s8pVrGNIWg7VeYMjDBiv Nb0nvXqw5ytXQ4gFvy3xv0BLyOuQqvAEmjH95fYyNKt8p7BjT3DZhJtOy4eI0grqhlaQ4y7z/Bls Db0l5QFbS5kJ3F+C+ysCAWKQ2b7a3v0iOCCwwkrb6epdV2MNytSMeAztYgZCE/eA7aLAJlvuI/Pk JrZ4VzuF5BSwGO+aYlB8O4y6vETteIQDwsIzd4zlPBAEdkMQqIQsWe2au9RAJEybInXnLLTH9sNn iMaBiqvEo9Q67C7RUfFC4+/Lc9m7w41jeeHnankhDnN5olmHKw4NyOGObV4dhtvMoyvSsa7BEVJ5 AhYVTgr1KIMlfakHv5bPa9UsPspo7KSUv8ASHONYiiUTntDAeGCeGu1OsO6ZzjztQdxVeYV2YzDs BL5H7cqwtDqCu1QZ70ys47q0HfF2sDJ3SwnVkrNDnNZ//Z0uZHvyaefVSal+13TC93wNrVu9yyCW LyUTWG5Y4ZWRdu99yyAAgaaCJdSChtqXQ7ZwW7vLeodL6UtMJSWZ/B5bMyflFjQCVVtd3feNNNas xLIxnXL8LnkD7Zm/rSy9bZpGO+ybSMju50yOnJXWGtVG2EeuOq3dlPqr61RWORQQYGQZhvh1+yjo g/SeXi9fGVqN2wdHpT5kWVCpbRMFLCEFwFskQAJzgwAFLKWXgznIC+tg65ATsN7evteeJX6ZH1Ad X65f9yPb+0dp3fpUdsKGhprNjsXuW+ul9zz4Tirj+2HDI0yDxQ5ZrfOOD/6TxLGW2DowUlq1+l1J dBy1hAdRH3Adt+3J+R+D7Y7rsN3h7ws5D81ZLgyWn/dlz3gvKZPU13opTp6BmC/i4i7cTkOewbQO VVvsD9o+GT2+FctqlLAjTNjmdeTseiLuOnNl7NDSxtBbnfoG4k6sUOt1dyMw7bwYtlKCggqd3qJ/ jYGOORArKBzDb5CPz78xuA0ONNy6FGZbRjMKKSt3cIqI6qHFVQUjwaojvhQdcikrxyAMxo3jT2UZ bKMoLZFcR0F1wpdXb9DhC9fnBjPEQ422DQxjAK84fTm4W15Pm6MIhALZxx8OvSlfdNshhrUvXjoh ODo0JB3H6+zwfYkIu7BtJNwdgq2NsaTlYFn5uxCuCrZytwfhYfFZDt08TUeo570PUW2Kimva7bCb 1jBBSY40wJ+9UxISAQ2HVmg4/Gz1SlkGmxRLcWsZ2kVlnPpP6XJZG/M0i1Sap3OUWofdNgmRN2G5 3hbsyuQTeqlETd2SJj1p4LYxWFa3US+rC2u37Nx4A/06LKMcyhb06fcyYrmVHUqe/0ZZRdY9aGPc hdC92xK647uRxC5Wy8PChUAAAu3zEOAFtdC8dyZbSCtGuUenISy+wu957ZvRHoR6n35e7WC9eq4E gm2PBiQWZcPK8uC518J/0y6K977CnTMB4t3zMlJqX8KMy4vfCzfnmVuHCmybptEOu+WIBEVpMI+7 mq1zaImQD6BX1mFl6HOKC+/dMZ+sxwTBP2dPEDhOSm2b/sdrX5qR8JwESIAE5g4BClhKLwvv45nn Q23MhkXbqig9HcX41Gm2P5TvYsYe2wNjFsg+DmDb5i4RvYzC7WA7jzFbfrm6MrctFDiN+gjruJ3Q 7J9c2g9uR8jnI+dF1ixzTteFP/Q6Df7Z2fAQPG0e9bz+xDHVH4SBtzJ5fKjNEkKp+9mzn15Hxu24 G6rJ9df/ItvXqCUju0KNoXoDHAQO1e7tyiYK4n1dbmMZiLNuPUwgoRJT7GF2Og1tmYKCMfzmE87c 3AsNBjVQCgzK3LoUuG/FD5s9XSvU8qOQsnoOw7wrtWHe8NR+eqJPthRgQLOgOmEMxoJLeMzY3Q6m +c7pAanpMM+5W28Md2468yzlMrxYBknVcoWEeTPkPCw+y5n77oaUQUg44be89yGqTVH+3LqQT0Mr qh120xo+wNHaG2FpeAw7RB2OHaLQPEAdvuXI38Mg8Aza3yqpDnsD3dB0ht3UdbGI9zX5AIZkl7wr FSHaiG491OGGxZnv5SlU8AAAMgNJREFUXp6ysr179SbYbgSD94Rz+IYb2l9uWsPaEGjXXcPyI/Xd jKz/wYiKvHbrdF5W089rkNnOr7EUblMe6TI+LNlGZr175rui82LeU5p30+lLmAKWosvArUMFtk3T aId13kUOYEfALmtHwKyqYE6MwJZZdagtsyxfRd/QafGVQ0GhhJdrlFfv3TFdKDt0x1xbauYTqywN LWT/s4gr572ggCWCD2+TAAnMPgEKWEovA/3BUh/PX+HjmW1PwAn7yRXsQNNgXRQ921J68kJ96jTr j6zXwYTzjpty8QiMDOoORWDw6lsjiwF8695tUrFmJWywJGUycd+1V6DDDiZAxx28H4NtkLYw2yBG x97yE8P/eNC3utZr/0WCy0XCXJdyz+s05O+UZeIXsASqOX80WcIlryNjdhofY4lPh7XEp1067nwg HWrJWVbH21DPzhPzzBi7NeOLntUOTYrbwVXq3aOw+ZO9k4D2dxcCFmsmGmr+vVjSoDQD1OHWpSwO eOiGH1FWMNY5fKRZLrr2JqwgA/+wVOQFlooE7pqXBdUJNy2omxi41EcMXNz30MhP0H6F2p0mkbP+ w7BjAoYdV5upNGYUA++z35VxZdoWwe2qQ6dlS/0vrJ1LMtgi7c/3hqW/KY8dDDffEWVgRBd96r0P UW2K8uvWhVLbYTet4QNmHX5UGhKDp2ALpy2nMGo7hKP11blqUzSF0CdF12Gw9Bma9NrMYPgVuJHA n7s0xmiH8wlE4S3ycN+XQuthWEh5ysr24tUbySP8nXTtY/gnSdy0hgpYvPDNdjosuaXe03Uuu50P huilpdS8BpkVNgnkxesx8O6Z74rOi3lvun2JVylgmU47rPMuAjtl+J6Y9sDckiyoTruuSz7RaTHL obDAwss1yq/37gRcKMPmWDaW3Qoi/BLbJi4RCjDmJQmQwNwhQAFL6WXhzjpjgO8z9hgIMjXSKZ/V 2IbxsrUWAo5f6qWnTux+ZGEDYuRIpzyeele2HG+3bMh4H0gMnNPt9qyD2cmGnZbWg96adJ1kPRh2 w9YPnF/9ga/AmvZOrGn32eHoxS4ou0xjfsoTZgo3YqZQDSrzdJSdKF7aj8ck/4DRzVdtF2wVfCKv Y/26PpZiSdP41aMwxKo0SoLGbr2OjNdphTODvQ4nq+MNuxg7YRdDHdv7rkO9+w1D/b8MQjDMGMJw rEI5U8ZudXmrOJvuYEePjQFbHepB2GHkR9eFMGeq/IdR/taOPwHNG12XsjiogNwOa3ZZWVvqfv2t VKqt01EuqeS3NqclylbEQ/nduf8FwYut7ZNPGFpQnTDyam6J7s+vV+6+/Jg2e3wGIv2+81256TSE N7n8uO7haCcMVtdlGayGQewl71k2S3z11AzULQO/AVHTSf5zj0tUm6LCmHY77Ka1WAELtiweuiLJ lb+wtonPJJOSUtthqwO2IsYhiBre5WisTUeoYIfo/i+1Dnu2mHLMpruxGCfgo7ebL8Xekg7JrVeG fQ79rODfPGVlh2MO2HILfz0NJP9SIDet80HA4g5OS8ury8yx/xX5TvsKyXs3PffePfN91W21e89o E6tK7EuYApaopTe+5JoXbh0qsG2aRjvsLecLfuu9BJn2RzyW3vOZOssqh4IDDi/XKO/uu+NoTGau d2I3RccwNNrBLy9l234qtW2igCWqFHifBEhg1glQwFJ6Efg0FZRBL+xgo2fY3VDNzqkydqh2dgld D+76eIknxoeydxR2ViI0B7QGi+pc6p0+3E5J+GBaGTnshpFDNYCPmuV0P/Bu3EiPoRpaj0HkdneX ARuDNq6mtFRaH31jG4sNIZQaeyiJR8/kpxs/yWs7I8R7/lsuE/9MZ5ZHQ903UtV6CsZuy21jt35W XvkEB/fJoTbsfqN3JUGsgQGbO8jUtlqyEoZZ6Zk2dmssuYgyLqqSoXYR6t1/SlYd7JPtlraKf9eL YF510scxu2wZW8YNvROTfuZqfAQ4WM/dumrUX8fjeM9W+XwvBCjN2Cr7XMhW2fFTsnOjvZ1m3s5u IXXCtwuWqsM3UYf9gqhkoAPaiw6o1Y64+VCJ97ZTd7Li+1FLM8afQ3iGXb2CxjyjNNJ8ARgXbgc5 wjjr+OBRlEun5SOq7Ew7FU1Qe98SVHtXWm9PnsFoJmzgRLaH3vvgf0+MxOJ02u2wwTksP9ntlhM/ 3vWu5fZOWK4ha1/SjK2yCxRu+bxHXJRah913BuHmWq4m2AUpEX8osvrn0FC055t9wlRoYm0J0cRK wqD7eWjXxSM0ibx65Rdm6GxmEO+fx9Ly0/ffhU0kfTfwm6estGvT7tmn0JJrDNGSU9+sJnyzrCMg wBW3bctuQ5R7/V0Kqy92gNP7r+tcsJ0PC3XaebUC9d61wvJkuMf7vdl6v7175vuq8+LeM8owTDBf SF/CFLDEukexXXygL2MZ5X0qmeWwGRUw3l1022Skt9h22NzxK9T+FbQFhzdp+0aeMfuwcp7uvaxy KDjA8HKN9K6/i8a3Wcdt+YEdsN6AHbBS2yYKWCJLgQ9IgARmmwAFLNMpAXOZBMJpOC2d2J2jwvmg Jx8My+XYVnt3CjwODhKnE3MpfjPYivNaU6VcxNpxNVN+pg9bxQa28lCzsH++p3d7qJPDD/qw9SiM gIph0BG2Dtrix6RSbUmKMOOXzvi2Z1S7NpzBNrTLlivjoYjL0RRI9P5Svjh0JWCjJSmD2MLvspOh nVdHZcvHyiAktC4wDvU65crBetlztU82YxtsK1w1SwyDu7eON7hbRAt2RLp4MKgJ4wRe5I+1+8UL eIIBVG8HDLWbi70ripTBMOqLMlmmd1nBoDEx0ImdKWxBiOVu5VvecxU/3KSwe8LwStiyUddg1X1i m7y9HAYnsS792i67fD4d+Eb+dtNKEey2sswagBraHMqfMWBLjd2Wf6zYLF+p++jUnDkN9ihXc5CS eo7dF+5g1yhni+I9X/9RNsPwpmI8nWP0yGvyxQkdwnpputojH338gaW18+dH/yp3T7bZ2ykrJ7Ee 6b232xIe+AbFeLRz8BvZUostv1V9ST+TeM9RbHOrt/z0G6rMgF/8xFZww5al0BL6Ve8+WeWWgdrt 4pbYO9ioXRvOo56+47IwO3qxjj5p2g/2ejudF0mE2yxdztbqbYkfJWYut8G7kZxyNBQi6oQ2GroM O6Jo/kHh2Pa+m1JdgzqMzvXv+05Jt7G1qTK22TnRB00yu2BMA4jibAVc+b5tz0NxSIz8gwxiq2Yl 2FTHThg3rovZfrN3b4FB6TGoqTu7tyxd8RbKCe9ZQMBhvnMVzadlT0ejZYQ6+QTlebrNt7TK2sGj 9l3rXRdzUGwOSlQZ9aGMkKxkAu3FwBlnW18kOKCZlhpTO87Yh7lTiHJ35jiWL2plsDJzd6NptMNq IPZoWLpi9g44dvuDsrERihr0/6HHbrfUDmt7mj9Cm+k8NPMIYVTLnf8tf6PeKYdD6gG2rUW4Vtlk LQd0MlnCT8l12JdevU05NLlU+SsOMMh7t6dTersde01yWnpftNjCvjEsc61whBFw/mkvtjivBwug UJpf8XPQytN2nkK1PuDJFVpACK9Y7lfaffjePLqFeI/KZWfJnm87XzxPTuh3DmEkHzrvdvbuMUvL dVsJd6aBbFxWnRiSpr343jl5Hb96AW3hfjyxD8vob8wWJgkMSY9f7XSEiPbOL5XqG6i/Zc+fym+x g436jqr68l83feC00Tq0Un9RBmPf4nujlr3ZdU4N6DvHsKxCfYecw5dPdW86eQ3Zlad+ADsMflxu 78qDb9wy2A5biu+TeaTw3f+t05fYDi23Tze+ZbUj2i6LWl7WAi3XZfCm66t7b8k0+hJuIrxBv2oz 2x70WEZ5UxNP5fHVK3LZ2co71PaJ+R4U2DaV3A5DwN5f9p79bVZpbzgGm027YQz7DbQ72B5+U4Pb P1SPY9DkbcUWxroNUfdKPszvlSoHp/9l9c8g4BCtbYdvWXDHpdLaYbQFqp8Rd/qPRh9F5WH0OPoK HXZurLpw6COkAf0n6500diWEk0/PoX3Zkb9tog0Wmyf/kwAJzEECFLBMs1DQuenHNp7W4DZXUGqr yJBtMXN5mcln5qDJDNdnFFbPPJgOcF6BGaJOzBA9PgmDjocwqC3w0FvdujOujj9XVVhdowPSjQ6I 2gbVPLRfdW+8D5oMjtDCdBN2Xtj68TCf/ntJaE/sU1tVF3C0jWEgvsLsNPo9eZoQ6BS66ty2m4ra OklcHZamf/i/0vvf/6ffo3Xl7cjhWwvuzA4lLzVAE8neocrn2ejcZJe93jUKAo8XtsDD57eoC/92 ytFelX2QPtgH8Trq5paw0f4g0MKOJ5v14Ccw0NP+9C5eemZZ37d+DcGO7uz7n9dZmlF3B/TAEk+D GmnolLs7xvg8R1wYs3dKKmBqakX4QO8agsG4/X55Wh+F8lWhwhZUErag0GH11ZXICPHAYOM5Cwjz vAeRZ5q/6aCQ9sK0wTMZVZfNQI1z30x7ie2wqZnhBq2ZRLSH7vtsDtRcz0DasA3ChCvWrmz6dssj zPIHNJf0s2J/S67DiCgT74d9qF0FRRnU/JiEplWrVvXPEUL4sjLlAfUKwvSLOfyqR165moPoPJ6s x35tE3PpRS7f1eby1OCA2PGov0fekg8zxJnZhtucxTdDzzrX9dN4UFJe0S6NbMQuSlo6a4QXPPXa I5Ri6LcR3ylouyZ2vWltq277t43mZ7AddqveDtvRisucLq0vYaYrhQmDzz62tQ3N+77zgO0u/azY tknV3Zt7f2IbXNeBRP567bByUmjZVMBtAn/hbbJ6UMRR5PfKbdMQRantcNY3x+iDqJTf3QF7agOB PBh1uZS2iRosAZ68JAESmDsEKGCZgbLALNto7ynp39sZYuhwm+zBNsTV0LqY1QMd/nYY2k0EEuEz CjtxQ7qwRWewv+Wpk6dl9OR+aKFozQInsNg2aTndJZVLfiP7NjW7MWh/k1hS0OosKVAP9X3LoVpC sem9rJ2JgsuFUtAG+sdDW+UrpX0TOCpqd8uW5r+TqtoPrRmzwOOSLgvtFFlLY5I9UlH2TK7VrzJ2 ZNLRQrAwBsOjUEZRA+27BzdLd3dQSIWlI7c7ZeTDuiz2SkPjzCCMrTqz4q5xQKfzkho5JftqsjuZ ara9TdvJiSh7acWytpMhy9p00ov4HR86K2cxI5zI8rMe2yF3SV0TZjOdPJhOUmoWr6NNBgeCTJRx VSwpOmhrT7h+MJA+D4HmiHtDnXhLb+JHNkiX0mwxDpOFu5QKz6OMxtar2bOs9MIe0A7YAwp2EI14 zFMzTvs+7HX0Ke0me2mN57YOWj+wc4TBQrejOaOeBQfkim8/+AbfTeU21oz2pWmbxDCTbi0tUjdR 5tqwtrqMPKLqgNKmOrhLegOGgCtg3Lrp+AFZOnIQW8/rdsDj748HGkEnD0pXsL3AIKv+RKNU7YCR bEPglrp3Vj7btN8fROQVtOvGhpz3ynFUQjucwOCv3R38OeGAyUW8F4phdptpxOsMYibhLWEIx3xJ xvbNh08ckMp1jnaE72FpF6XXYSc+aIFcO95maKoY6YjVyfa9u6Wqvs7TCjMeZ6At99XB/Z5WmvGs uqNP6vbifV1h3AyeIu5h7KSm7Rzpx6oN37yrUT7a6sxaOw8SpxukvTVEgKw9mr+BttJ6hHp884TS rgkJA3X5cAfKxrfjEQbSeM/PBt5z/c2axA57rY4WoBt1WLzuw8JPUjCO/lkBxtErDsGG2fFsG2hq Z57i8gp57kG0l1nfo2Ca/e93UPvQdm3b9UmdM8qrAQL8S7slpXclVA5jWOp45xh20ymtLxFM2fjQ KXx3ggam10v1ob+Tjxr+u1TGonbvKq5t0vEW3Q5rjxO35XLzZk/T1rkfa+2R+oYyGfzYto9m3Y5q k3VYBf16O13ld442LYG21NHWLLkdDn5zfPlIo65tzqprFdDs6zxpLNUtsm2igCV/6dIFCZDALBGg gGUGwaulMM+/le+mVJhpWVqu1NhnrmM9gymdXlBY5pJ8bqttL12OJTBaZX56oRbkW6nsJ5+DLdSW 1dIdaymMpxRRUBjz3VEKqr+vl0Flfa7lG2rsSkU7OaXWcUD1V9f/EMFKsAwyUFVPTXyrvGGJSJm8 uQLq/i8jf3hHM2pZjEqT+sNygBTS+/pypD0pWM7lX1oVTOe0r9VSDJVPdYSoZtsPov+rZT+qfbHK XqnvB5aCRfss7Yl631JWe4Y4zSUYxQSn6gXKV/AreG+XBZYbFBNUQW5fYTucQd2x2yKkDPlT9fgH qN6rpWIvrW2cqTqslodY7xxeNLwLVnoLLBvLoK/6Bqh3tJR6qMooiXYC8b6StgzveRLfZmv5GaJ9 E8vjXuV3q6B6O1OO5lNeZ6gvoerjD6p9gRF5q31RbXshB/yU0jaV2g5nnqP/gqZQtd8lt6eF5Gu+ uymwbaKAZb4XNNNPAguYAAUsC7hwmTUSIAESIAESIAESIAESWGAEKGBZYAXK7JDAQiJAActCKk3m hQRIgARIgARIgARIgAQWNgEKWBZ2+TJ3JDCvCVDAMq+Lj4knARIgARIgARIgARIggUVFgAKWRVXc zCwJzC8CFLDMr/JiakmABEiABEiABEiABEhgMROggGUxlz7zTgJznAAFLHO8gJg8EiABEiABEiAB EiABEiABlwAFLC4KnpAACcw1AhSwzLUSYXpIgARIgARIYO4Q4EBm7pQFU0ICJEACJEACJDDHCVDA MscLiMkjARIgARIggVkkQAHLLMJn1CRAAiRAAiRAAvOLAAUs86u8mFoSIAESIAESeJUEKGB5lbQZ FwmQAAmQAAmQwLwmQAHLvC4+Jp4ESIAESIAEXioBClheKl4GTgIkQAIkQAIksJAIUMCykEqTeXmp BF44oS95qbEs7sDTyH7Z4kbA3M9zAguwDlPAMs/rJJNPAiRAAiRAAiTw6ghQwPLqWDOmeUxg7Irs rGiwMtDy6DvZvGaeSAFepCU58UxSUyKvLymTpcvfkPKV5TNaECmEn9HCJx1y2VtSvqI4RvGDr0lX NwJoHpCL57bpkPgbRuAVlGtYtIJyziBuJQVbqgSNhQgb02nJwOlS1L+C3JsRIy5Vt4r2q+qj8qvS maMa+uru8nekfJqvxkKtwxSwmJWS5yRAAiRAAiRAAiSQgwAFLDng8BEJOASS1ztlX+1R66q6d1T2 7Prg5bLRAotCBrBhKUk/k7un/5d0HzqV/bS2R74c2i3Lsp8Uf8cQPPk8x3qk995uWeq7mePixTMZ LFslly0nu+VX6R5ZVWrec0Qz7x+9qnINgnr+UG6eOyVnOy74ntQPjsv2re/47umLyZF+GTy4S0bi +o5IRfMxaTp4QNbmElAmEVfPBRlG3U24XtdL/bkuqW/+JGedSj26Ib/tOSsXu6+4PiW2Tfac7JLq 6ne9e+os/VC6lleKm7xYH+psY87w/QEErhZwHaaAJVDWvCQBEiABEiABEiCBKAIUsESRWfj3Uw+u SP/xYRF31jYpyzYekMbmD8MzP3ZDzh88C/euh1B3Kfm5NJ1ukfLpDpBfJOVmx0G5+1xChAFJxP2u VFT/N6mq/0TKc8xShyayyJupO53y2ce2gKX+KgaVNeGDyiKDDXf+4qGcL6uUESlV0JCWm1vflLNX w4MX2QYBxsDMCDCm7sv58g1Ia+BowGD1UjGD1aQML/mJXLSCOSZnXrR71TIQ9OK9fIXlakCevH5K WmvbjDve6c7r41JXnf0uPD65VToOoW2JOKL8ydgwNMW2RvjC7RzCweTQUdlX3xnpN9b9jbTtX+89 x3vWj/fsK32n6DqrPerfV1+HEz1HZfDeM7d9TKFZrDp0UjbHcrfROsWF/lLAUigpuiMBEiABEiAB Elj0BChgWbxVYLynQT7fa8z0KhQ5NA8mLzVI666A+wh8LY9+xDKaiIeF3k7fl/blG4xZ7GiPTRjo bQkZ6EX7KPLJFGbVL92W79Jl8tdNjbJqeZH+i3GOgV83Bn53IQjpnBqQimKFR89vSPvKGotbRWuf tB7ZJm8vL5PM1DMsF8IIbMW78naRy3fyJl9p3ECglolfkKaNzSIlDFbHofHw+wdJeXPdL2Rz9UvW EMqboTnoYBbKdfxSm3y+S2tBrZemwR6p+vgDKUd9so4QIWrmUb80rdtlP689Jp09B6RiZZkkIdDt jTWgXqsjvG6P92xFm2QLZup7r8uW2p/L0vRTubZ3g1x2BIafDvxRGusD2ihiCp+2Scv1dolt/EAy T4bl/MYGV0ulNfGjVK22k6b/j/ehHWxCu1YLoeBQMUJBHYL3+2rrsJlnLw1ZgiTvUclnFLCUjI4e SYAESIAESIAEFhsBClgWW4l7+R3va8bAQqn8b5PDj3qkQk16Li+XZVEDemiUJL7+V0lZg+k3JDm0 Wc52q/DUwKtLfqb9wZZB5aaZGSAnH92Wa+s2y6CKJtYuh2GbYxkGdanEQ/ldzy75ytDSCB94KY/z 7HA1WKBpAgHLKs210GxggLvTGuDWQUAzVLyAptB4Qty5g+sZGKyGBL+4b73qcp2ANslqrU2yWzon 0EasyF8ErsACGlidU/Bj1N/MAwhfYrbwZc+976Q6ZjxUQas2Jv5Uyt9fDyGOERc0pbqgKRXHrapz o9LaHNK+PH8qibG0rFr3gW0fxvGeundWPtu037raE0ec6/xxuu3gfKyzsG+TmoJNnOQt+ex9u6wi +Rg4iz2lgKVYYnRPAiRAAiRAAiSwaAlQwLJoi17cgUWpS0aeYCD/vhoslbqUpTD2k5hFb1Wz6NCK uIhlJ+aRjF8xZqghUEhCoGAOzEzHxZ7DFsRIz7Bkyt5wfH4vmfQ7UrW/Ud72j9FCQ049gD2I3rNy E/YgEo6LitrdsmXvPtm8dX20rQfYhuiGbYhiNViSjx5KCvFkHl2R9ga1nKlOWu8Ygi+VhiXlsur9 7CUd6tFMHMUKWMaHLsjvHn0LQ6Q240z6e/mrjdugwRLUUMhOXTJ+Q2719cvNkfsYlMO+R0zk7ept Enu/TOLn2iRTf13ajnzienTjwp1M+XrZAnsePzy6L/Gvb8u/T3wrP5SVydtrPpLKmg/9g3s3hBJP nHr0HfKobNJkkiJrm1tk7UoICq06ovNwXyoasESvo10q3y93I5tuuWYm7su/9PTLrcEbEo8jjth6 eXtjnWzesU3exJKcW18npar1mMXNjRQno0c2yBcn7uOsTg5PDEllAcIV5d9rV7qk98UBfz13hYci YcIO5T/8gLbGDix7G8ghYAn3CKGN1ggLj9NNL4wr90KA++d7N1CfHsm/J7+HLd+35GcbP7QExlH2 hNx69QrqcFQWVR7tZYUl8IkM1HtAAYvHgmckQAIkQAIkQAIkkJMABSw58Szoh+7AQglYStCUcAfT JfovFK6bzogZZnNWvAoGaFtnyABtJn4Wy13smW8zrU2Yed8SnHk3HUhS7h7ZJd0nom1QiByQjoku WasHrS+eyuCm9+QyBAV5j9rTcmYwYOPG1W7I61uaMIu/JTCLn99XYS7cOhFRVv5Q0nJtyZvS67+Z c5madjp6HIP/DjX4z3GYaTAG2Tl8uI92Xv2j1NXkF/K4HnKchNWjlvi4/PTqL2GnJGTJnblMb5rl muhrk/YmvcQnOpFZy0qSt6VrxWZLY6TixE3pPAi7THo3IAiich2uQDREMJO6cwq2jGx7Li0PsBsX hGEFHVjq0w4NjQQcF/uOT8I2S6tjmyUsTrd9yZmQ3dDyOy2VWcZ5X2EdzpU+Clhy0eEzEiABEiAB EiABEnh1BChgeXWs51pM3sBifgtYMPKTERh1Pa+WC5mD6ukCn3oqdwd/Iz9gq1eBHYjhvUetAV6+ mXd3q1Yr/t2wB7FPKtdhsI6dWO5275feHi0YOABjs122sdngjiY50x5ipBY2YvqrlcHO9VIBLYWE 9g9thQp9jt9EfD0EOz2eYMd4NhOnxQlYRCZHrsjokzS2j1bnp+SyYpPPfouxdKWitUdaDm6Tn8LK cWoMfE82e3wD4UzeGZb49QvS2xEQamCXmfr6DyQ52Onb8SbXDjlFsUI9ig/ehnZRWn7f3eyLQ4VT 0dAuW2rKJb63zbZPYqZ7GuXqCTrs1MZasZNO7Xp5cyoht47b6VBaP0r7J7isxBRaVjRDo2as01iO p2ycdEVrGRnlo7Tb2uLHIJh4Q8av90t7vRZYtsuZ9LHchrCtJYm3ZPzBbTnbqo3XHoCWWldeLbUM 3rU/3Hkof7qD8taCzuY++fJco2sQVpeh1w7qO+ABjZ7KCmjx9B6Vu4bQsw02XGIBGy6vsg57KQyc UcASAMJLEiABEiABEiABEpglAhSwzBL4ORCtN7CY7wIWtSzBMVRpDk5nkrExgMklYDEHphI1oDMM h5qz8ZnnzyQFcwqCQXXvuhprsK00HWLQcskouzf6gI2bXBs5uUKOl6xZpJNj/rpxlyDomrzUDO0j 2ATK49djjCVhaSwJCxhafXy6QTpaIUQxNUF0It1lbfaNput/lC3GcqTJkQvSWgMjvdYRbojVeVjS z80dr1nLXLTnPV+PS/UmZ8nWi7QkE1guVfGOZWdIu9G/LttCytXQQFE2klru/XNgZ5m0xI9sli5r CVCIgCVCe0unRf1W936D7cqNXXmMh14ZGTfdU3B9DuPN5e6N0BPT4K12sB3aY/U5tceUSywn2ojl RIZgRN3tnPrRZw9G3VOH1w6qKwhwxo5ZRnnVlToSl45K+y5HwJOnbr6SOmwny//faJ+CwjK/w9Ku uESoNG70RQIkQAIkQAIksAgJUMCyCAvdybI3sHj5ApbU2DPJFIh62cp3fEYq3XTmGNwU4qbA6MOd GQOYXAIWc2empnt/kS1YAuETjqjQp25J0+oaO56wPLlxlWbbpqiBOFLhCnbsFOX8v7Qcg39om0Qd btxh+Yry5NwvtAzdOOAvdqhH6urXy09XrpQ3lQ2MJWVW+iYfwB7NcmzjvcY/ijf9fjo4Lo1bs+3R mNv9mltyT6cO21n07IgouyZtjwYklrXkJBqSl/b872tqBNuK1+TbVvyZXF6yyjIgHYPh2DbDcKxZ j1WKYh0D0rQX9mywVKf3413W0iF1P2xXHnV/HMtyPo/cMnm9tMb/WarW+ctG+TOPDLaFHzzeL+Nj F+Su0k6L4Q9Ckz14r6rzbEOchKbS5YFhSfZcsdJqa+rA6O5zx5i3EZFb7yCIahv7RmKwjRM8Hh/H ttMdasnfejkMN5UhbpQfN6w89d8ry+LrcDBt1rXbZmQLy0LdF3mTApYigdE5CZAACZAACZDA4iVA AcviLXt3MFDIjHgIJm+QkGfAh+2Wu7DdMsZGBR1BGyduOnMMWlw3s6rBggH0Xsyc9xSUTdtRWJ7c wVIerhHRFFwuln8sr8Js//kCC6ei+xvp3B+utaCCc+MOy1dEevVttwzz+n0mwxtXycUcaY41d0n9 kX2ydrXfxoebPlXn09ihKaD9YqXlBeprmV1fXcHDNOuwnUdPwLLz679I3aZynfWCfn1pz2MzyROQ 5MinihVbdyceTcjb69b7dg9zy0K5aR2Qiye3qTPr8NIB4UBAMKMcmLv2SG27dHQfkLXYSmjyHrZp doUzEFRMQFChbRDZQUf+T8X75YuNu5ylb8fkzIt2KZSeTwPl0HW5eNwzfKwidPOaq+0wbOHkFLDq ndleYh0OheS2GRSwhPLhTRIgARIgARIgARJ4VQQoYHlVpOdePO7A4qULWB5CwFL5EgUs3sA13/KS kkvBGMBED7CQDtiCOatm261DCSK0vRXnlvNTgd8E/mId/p1ucMva9cTeEeTVCFj8abZSEPkvyxhq wKU7+M47wAx4xKVbHwvx++IZ7Nkcle5DapvxqCN7EO+mL9fOV1O3ZWf5ZitQd7lFUTZyRIJCQjuF Xj1tgaHhzUUaGvbSnr9euCxz5TMKG+5PDmLnrgbbOO7OO99J3UZTUGXYPGodgvClzhdSAku02tUS LSy3cW0MaReGoMLS8MqjiaK9qV8vT8Uv3XKXZtX2SO/Qbt/ORm64OQQsHvvwnYh0Ot2wXmId1nH5 fo32ya2zPgfTu6AGy/T40TcJkAAJkAAJkMAiIkAByyIq7EBW3cHAyxawwFjl6KUrMpkOJCDsMl0m a3c1yipjetpNZ9Sg5fkNaV9ZYwkscg0uUk9uw2jtLfkO8f6V2qa2+oOwFITfMwYw0QIWCE1ObpX2 Q2opwQHphgHbt8M0JMJj8O66ccHGyHPYGDFYeI6iz7zBYP6BuAplfKhffj8BQ7PRQdpPUH5qG+TK HEs73LijyipHHHnLWftVRmOHbks50lIBDYhU8ltsn42HYJ1JTsgfkJ+zh2zhgGnjRnl304fzqOUt MoH6hCVcCbhx69M06zCCwuEJWHLVIdtt9n8v7fnL1TRwG5lPHYWy7xOop15cItkCFsGWyY4tmSyh hClkPCBfvujyG5WdugHhVY0Vc+zcN1iWFK0NpZOnfz27Lvnzr/3o31w2mtx6J+14Z4+FvrPmkqtc ZeeGla/+T6MO6zz5ft02w6izPgchF6jTjweuyOOxb7Ed9TvyX3ag3Y3QKKKAJYQfb5EACZAACZAA CZBAGAEKWMKoLI577mCgRAGLuLPRpdkKKZSym86swRxCgEHY4R2VctHSGqmTDggk1oYJJMauyM6K Bl+U1QN/lD31BW7FawxgwrZ61QG7Ri5x41OE3xgVfhJLM+IPRVb/PMtOiCCu7rJKy8ht6JbK6aRM PnkGY6gfSHmYPZRXVC46z75fHXdYWfkcZl/kLGfDeebBBWmKNeNOhBALS3x2YomPOoJLWEzBgcS6 5MydA/6dbKAZc61+lfRa9Sm3toIVQVH/PAFLrjoUGaRmW4hWilnfsa33l0MtfkGHigR5vXloj5zt Hs6uq4aR3Bi2aW5T2zTrA8ulurHk7y6ug3yVE3cLbfD98t4Bf7wItx3bPyfgLuz9SE08E1F2fkyF GRUojtEj2JrbMsobpsGSltTEt/L6Cr/9JtunZ2tGcmmwwHFWXlUAU/flfPkGGVHnedi/ijpsJSP4 z2ifXKFg0E3g2r/bmXq4GwKmnlABEwUsAXi8JAESIAESIAESIIEoAhSwRJFZ+PfdwUARAhY1ALKM ti55Q1IPfi2f17ZZoPRuN6IMjb6AodEVISOkUpBCmDB6ulm+OIQlB7Vd8qu+ffLTJRhMKQHF1X7p 2qu3b8XMbe8odqEJ10pJ3Tkln31sp9VNBnb56cW2raGaG5jdTU58bztVs/tJb2ef6r5vpLFmpa01 gUc+w6/GQEd5/vTcdanb8YktCFG7xDy5L3d7OqUXg1r7OC29L1r8aTDDcPK8CjiTiYcSHzgj5zuc ZTHNsI1xzrONYZUNAk096HfKRRkTDQicyt6S8pkqG5UBHyezTsCg6NhJKX/hMITToPHiDOpSSu+O hPyN9/7SLmdrJxfY2HD9viHlqz2pmU9IUntMOs/tkwr3eRoaOadgYNU28Bo0ZOvzq9KPut9ytUV+ uvwtWYplQIM1u+ytktWjkMG4ul30MYW6lPwehpuTcqu50hLe1A+MSt3H5XYdwjuzrKwMW1WHvzOl lqtvAB1rl8N9LfKf18CoL96pcWxZfbnWM1YbKig5+Jp80W3ndvvgqNRvxbulhDL7V7l2hsJsySSH 2mRfva1BFDtxXVpaP7F3RYLWxrXm96R3wA6z5dGPsnmNR9Msm+oTfXhv6mTVSpR7+pnEz/1SulQb oI6QcnE1VGCEdmdfl3xU+xHeORiYfn5frrVukItOnEGtmQzK5g/nnPYFW5oLtjiX5i7p2L9NsPO3 pBK/kfO1zZZASEUdbGNmow6rdGQdRptRmIAlCTtGP8myYxQl+KOAJYs4b5AACZAACZAACZBAOAEK WMK5LIa7xQpYkrDLsM+xy5CPT9vYj6G7ceTz53uOQYPW5PDdD7mowkCu9aDfeKXpLBO27WzHTbl4 xJiZdz14mgburZwnWLJgGEzNwCBnEwxyFnJ82jcqjTuyhUKPT26QjkPh9lt0uNXwu0f7DWw/rN1k /2LZ0RSWHYWP5bOd57xTHCffIL7g9NoJMAe25kDcS956qWp4Vyax5CHh3szWrAr363owTtqlM4nt esM0hAxX+U8LNyIcqq1UMKeQcn3xVAY3vSeX43lSCQ2XM4Mtfk0e5QWaG93Q3FCaKvYRsCkUIuiw 3EEIM1i2Si5rbxB6VDW8I3exq497hBibVUuzdurdtVyHwRPs9JPATj+r/feT14/KvlpP2Op/qq9g HDcNwZ0SmKoD7UsXNMXy4bEdi1QcGpCO49s8YWjBZWOHMFN1WKfH91u0gCWsXmbbLNJxUMCiSfCX BEiABEiABEiABPIQoIAlD6AF/LhYAYtnAyEfFGgvJLEd6nQHpxggXsYAcTBiBFQRq5PK+m0YvG2T te9jpjvXgUHfyP6tcr5HCy12S8dYj6xdGe7JM9QZ/tx3F1omZwYDS02g8XLteJuhqWL4QLq3790t VfWYoY/UJklK/ORBzNoHjbjWSf2JRqnaAfsj5g45SSxjWKGXMRhxBU9jx6T7TnvoMoCg00KuH8Og aYdl0DS/6+1Xx6W+xtkWGUtFurFUxBu85/a/8/q41FXbfjOPsERoXbNUKC/QOkgorYPAEWvtkcYj u322fJQTT8ByQDoTLZIcvCDXejslrutYbJvsPHhAtuz40BtIB8Iu9jJ+cIN0dWen0R8OtI0e3ZSq 4LbN0y7XtDzuOyW9TUcNwZMTc+0BaTm4O7ctIsQ/uGuDXHaWTOk0V7T2SRvqoSus0A/0L7RObh6x lx/pW/pXaXVtb/4klG/q0Q35x4M18lUgPstvA7SVutulIuKdHcfWzP3QNtFFqeNTv1Vqm+lD0ErR whV1E+1Lf9l78pU6Vwe0odr2viMj9c2BerlN9lw9JtU1AUHoLNVhO7GB/0ULWKARd+eC7Pu42Q2o +txN2dMcJnAWoYDFxcQTEiABEiABEiABEshNgAKW3HwW8tNiBSwLgUVmKm1lI2o5xoznUS0PgW0I wRIQZUh0KZaiLItYChIaN5bQpBCGqKU0CKMov6EBLoybqhyXOkwFS69SSZSr4gqDt1E2PFTOPQGL X+vI4qscmANwdb1QDsXo+bfyHeqRWhK3tLy4eph68lCSL8rldSwJkxXvytsrC1OBymAp358TSSwP K4ONlLSUv/9BqH2VIGbL31gSyxHV+1qGJWLvFry0TS2pSj6fcJYylsnbsFW0rEhhbyaZlB/UO7cE 75xaK/QSjlLrcGhSShCwWOGAr20gGkvUcmSTApZQ6rxJAiRAAiRAAiRAAtkEKGDJZrJY7ngCluyl FIuFAfO5yAi4yzpY5xdZyS/s7JYqYCmQCgUsBYKiMxIgARIgARIgARKggGXx1gFPwAIVehiVrFqZ ltfX/Dep2uQs41i8aJjzBUggBQPD8d5mOWvtRCOyvQ8GgLFEK5NOy7I1H+VfZrYAmTBL85tA8t4w lrcloZX0VIb32svACjNyW1y+KWApjhddkwAJkAAJkAAJLGICFLAs3sIf79kqn+81DE9aKEJ2tVm8 iJjzhUIA9jbOw97GSGR+WO8j0fDBHCWQlmtL3pTeQOoqukelc3/AXkzATbGXFLAUS4zuSYAESIAE SIAEFi0BClgWbdFb258m4gnJuAiwleyKn0vFmnL3Dk9IYKEQeNxzVEYeQVslmKGpb+XNj/dJ/S61 Sw4PEpg/BDJj9+UPY9A81ElOw+bMxvX2tvD63gz8UsAyAxAZBAmQAAmQAAmQwOIgQAHL4ihn5pIE SIAESIAESiFAAUsp1OiHBEiABEiABEhgURKYKwIW+Y//syj5M9MkQAIkQAIkQAIkQAIkQAIkQAIk QAILgAAFLAugEJkFEiABEiABEiABEiABEiABEiABEiCB2SVAAcvs8mfsJEACJEACJEACJEACJEAC JEACJEACC4AABSwLoBCZBRIgARIgARIgARIgARIgARIgARIggdklQAHL7PJn7CRAAiRAAiRAAiRA AiRAAiRAAiRAAguAAAUsC6AQmQUSIAESIAESIAESIAESIAESIAESIIHZJUABy+zyZ+wkQAIkQAIk QAIkQAIkQAIkQAIkQAILgAAFLAugEJkFEiABEiABEiABEiABEiABEiABEiCB2SVAAcvs8mfsJEAC JEACJEACJEACJEACJEACJEACC4AABSwLoBCZBRIgARIgARIgARIgARIgARIgARIggdklQAHL7PJn 7CRAAiRAAiRAAiRAAiRAAiRAAiRAAguAAAUsC6AQmQUSIAESIAESIAESIAESIAESIAESIIHZJUAB y+zyZ+wkQAIkQAIkQAIkQAIkQAIkQAIkQAILgAAFLAugEJkFEiABEiABEiABEiABEiABEiABEiCB 2SVAAcvs8mfsJEACJEACJEACJEACJEACJEACJEACC4AABSwLoBCZBRIgARIgARIgARIgARIgARIg ARIggdklQAHL7PJn7CRAAiRAAiRAAiRAAiRAAiRAAiRAAguAAAUsC6AQmQUSIAESIAESIAESIAES IAESIAESIIHZJUABy+zyZ+wkQAIkQAIkQAIkQAIkQAIkQAIkQAILgAAFLAugEJkFEiABEiABEiAB EiABEiABEiABEiCB2SVAAcvs8mfsJEACJEACJEACJEACJEACJEACJEACC4AABSwLoBCZBRIgARIg ARIgARIgARIgARIgARIggdklQAHL7PJn7CRAAiRAAiRAAiRAAiRAAiRAAiRAAguAAAUsC6AQmQUS IAESIAESIAESIAESIAESIAESIIHZJUABy+zyZ+wkQAIkQAIkQAIkQAIkQAIkQAIkQAILgAAFLAug EJkFEiABEiABEiABEiABEiABEiABEiCB2SVAAcvs8mfsJEACJEACJEACJEACJEACJEACJEACC4AA BSwLoBCZBRIgARIgARIgARIgARIgARIgARIggdklMFcELP3/7z9mFwRjJwESIAESIAESIAESIAES IAESIAESmDECja99OWNhzYuAKGCZF8XERJIACZAACZAACZAACZAACZAACZDAvCJAAcvLKa7/DwAA //81gXAtAABAAElEQVTsvQ9sVcmZL/ilhZEb0MbdD1omMJPLpDsPArtz3eCIxi2Nuwe0jmE1HmK0 rGG0XmInrCFaJ+AeDwaNn8AsG0PGqwDLNG6eV2P8WOHwPDvGYYVDHD2gUQPhjh40nkDEnTe4sYKV viPZ9FVfXmd/df5VnXPq3P82xnxHsu85daq+qvpVnfrz1ffnS7/HRUmunv+a9HWSlPyKEWAEGAFG gBFgBBgBRoARYAQYAUaAEWAEphsCNS+9P92KNLnl+dL3Jpe+Rf1LzGCZEpw5E0aAEWAEGAFGgBFg BBgBRoARYAQYAUZgWiDADJbJaQZmsEwOrkyVEWAEGAFGgBFgBBgBRuBFQOCpVclZL0Jln0EdGd9n ADpnmVcEpmkfZgZLXlvZIcYMFgeK5/TmaZxio586hZ9bvJAKeIJ38JgWN09jFIt+RlToLk1abRV7 RI/HiQrUpLNepqLiIjVk5t7Hgd3DRzQB8Gbjr2D+K1RU5AFy5taea6ZBIIFvIjYaI5qF/lAo+sRC mstdQoPUswlKxONGxgVoH0pnLsIcljAWnqI9Mywz0iWQPu28FPIZl1NJy7eMgIpArK+JdlQfQdAu +lG8nRal0+9VAs/qfgrmVzF/e6+Mx+ynD6in8Gt0HoTKu39D9ZuXeEnys4rAFLSrmp1zb4/lYm4W gWl8B1mPw2LOEPmJdWHG80Yacw5oO3srTGkFIawz0qiPg4X3Zhr3YWaweBsrP8/MYMkPjpNCJRGL 0ediYyk2EQEDyEh3Nb1Xe87Jv/bGE1oXDojsxOKbqUQgsv0lau/055iyrZQB2Z26ktrG+yk0g5s5 8fAWXTywj053DrirjqfSEzepsa7EF84BMxuB2I1zdLa1moYu+OtZf+N3VB5+QZiO/urnLSSdOUeb GZjId84co4HafRRRIzQP0ukD76ohzn3i/iU6v7eJzvbecsIovI0ajrZQ2eokGygjrw/oYkcTXVcy K23upE3N22jRPElOdyfy7dq8loactCVUe6Gb1q1dpouenzDBCAIlPvzID5zTjcqdvSvp4CGzHzfc fkJlSyd5csbmTzCYs72man6VjCd3SUMdN6ltZwZz+Oglalm8lqKCTHU3dZ2pcR86ucm/sE9T1a5e gCduX6KLR39MZ13rtRJqit6k8GJvbPEcpzvdR6gH80VUeV3e2k1VjTW0IMkYPjF8iX7ZeZxOd8h9 D4U3Uv3hdiovTzJvGPkg36M76WDjKSfXUN1Rajjc4Js3ErdPUW24zokXPnGHmupymCOmcR9mBovT zHm9YQZLXuHMAzFroeodeChcSaXFA3RdbC7qMMGcMCeY2NAR2rG2ycm4PvKEyldkP/E6hPgmbwhE O+uoZbsc0G3CqdsqRle2v0rHfcyZjfSj8V5aNFObOX6XOuYtp+s2UN7fCvT/fl5geWGZyc+J2z1Y 7GwNrGJp1x1q3JrD4ieQ8iS/iN2is9vbKFakZw7NnfcKFRQtoa+sfou+WV7i3qA/fURDzd+ne+P6 tL6Sg2H/xvafYBG60P0qwznHnRiMAzAsji1dq/1ew62D1LTXz2CZuHaEvvu2nLe8NMOHrlDT7re8 wTixfEBncZLd539jhWyktrFeCgVAkhhGP1qh70fru+9QzebJ6ENxurJ5Dh3vJZqSzXcgNpm9GDnT Rmf7HtBcG0vRfxrRf1Z7+o9FNjZ4nLo6fyXja7OLEb3eQPW7/X1CGz1Z4Bi+nZ0B3w7KSotL6BsV G+mbYJy5JECT0czy3b0DK6m11WSw7Hn4BS0vzpJQOsnQh7eIPpwto2EK59dEBN/bKv/3VorNamMm m9UxMFiKLQZLEqZtOvDN2DhT2K4SQzAsDm+lg80Ks8N5WUl7Hvb7vwXMWwOrF9HpiBPRc4N0o0g3 3xOMx1j/PtpR1eZ/YYWEwbhrCmTcxen67jnU0aFLDsmzcUieqWvq++doy9JqJ3LGfdZJad1MdR8G zlea99HHkIC3rwlaQlWHWnzzIzNYbITy+8sMlvzimRs1LBh6ilcaYpBJCfk2mHEaWjWHTmLASr1p T0qZX04mAk9BfBbaagPaCoyyjNtq/BZ1FK3ERmZmM1gmhtrou2v3GS2xvusK/Vn1WxDNjNPE2KcU G4tR0evLWCVkMvvpNKR9BxuYg8YGpoTqL/dS2aolVCBEeMegPoa91Gsr8DwNy52qSN5TsuTxW7AI 3C8XgfFb1DJvpesEMHl6It8pXNZzjpmTl2GxvqOf1m1eAzW+omAR8ad36WThchoySFRS442TVBpe SIlRSK3VraTT4hABl258TAzjVHGFeapY2ozTzu2VOHn8jCJH66mj1ZJ2a+yn04crTSLqfyw4zxYu spgzJdRwrZ/CxaN0sWolnbUW+43RL6h0sZooH/eSwaKrUz5yyD8NlBnz1HGrLWz6IWyM2wI2xlc2 v2Qwkey4wb/boEbTmbMaTeL2cTBddwZn47zZRnuiR2n5YnX35LzMy00Cp+pXBoeJ5i+lss3vTupY 5HxzvnVgelV5JvOrsfYhGumExPX2c5BCzZDBQkJC7hx9Mkb0lbU1tHyyJYTSg3JaxZr6dvUwLMK7 qKmzgd54Xajs4lsLUKcZOVNH7201DxzDrb1gtm6kIqzvRi4cofeqzHUfafu2OiZtpIbBFgqvWgYG /wCdXFXtSE4GjeEqcyaEuaOpsZJil49QS7XFsNHOG3LszrzPervHFPdhzLPtmGetqc0pjE5ynhks Djx5vWEGS17hzIEYuM8ncWo/ZJEoPdRLtdsx8EBULhF7gAVkExaQFpfYd3IhB4HnZwGXA1bPddIc 2srZmMxsBouj9hY+Sl03GiZ1sfpcd6UXqPD25i35CdXzCUhs+C5NgHnas3orFkPY+F/upNA8czP4 BEyH6x1b6by90W2Eys1h+/Qfi9Ibt6Anfpd6quoMRsv6E730x68XQdJDwQJzyD++vdZg3LsWiTnN OaDvYliAIXINalqrkHeKS5VGqodKa7mq0qqUKQxVwCaNKuDjyC36vHgZLSpWN8wxurjhVeoSOGkX 50QTN47Td1ebG/JNg7+jqnKrrLEPqX1+mbEQDUFypk0nOZOiTslf5zDmJyc8iW9lmaniKHV019Ac 9KnZgnEWsHGisbt0J/LILJPS5wgbr8bD3zLSi5dzF79JoaWp+0nKyoHBOgK1wffe3mpEDTV2U72Q YkP44+GrdKUWKmQKkcbhJ1T6utpnlJfP0W2uDJZnOb+OdGNzXXsqCwbLc9RAz6ioU92uKsNCSNW/ D6n6uSnrrowrvn0MGHBW/yAcIrZBStunBj/2gKIP47RoBaTSlHFIHdv1eyDMD6swP0RQwHA7Hbux i+wR6N7hDdTaLJjzldQ61k9v2C+MusjyuubOlPWcHhFsld8nl9uo0ZL80eHDDJbJaa8Zz2BJYPH5 UXcPXR0awELUBLGouISWb66hNdXv0nSxl6mKmFb13qFNVV5RZfmhE7VQR3w/LXAGGPmuIfI7+vrY APUdPgJbBUJktYTKW3fRpt01wXWNP6I7F35GH18YoOgNMHOwgBVXqHoXVTY2aPXho32n6OP7MC5I MN66+F1aU1EEJtBxutp3yUgfqthGlbuhS59CJzIWQfxBbBJgGHF20UL66up3aDlOM+90HaN/jr2M UnxGc5ZWUvkGDx5YzF3pOkVXzxxBfkZxMXBW4kSzASeolQZjygrN208CeUb6BlDeX1D0/iOKGjiV UCl0Rtdv3wHOfTqLN9lWuoEuaWGngsESu0tD0KN9UviywdhIxIjeqMOpRDE2KNCz/WVXD10ZumXU XfSPmtYWnCa5ZiQscMGp74WNBHx3140+KGqFfti8g9Ztr6GQ7iRRLJaHHxinHp/0CmYiJryK/dR2 eCMkFRRU0EcWLfbkZ702y3ecrkA3N2qFiX64Dm1TtgHqFQoZ4/ZZ1BUSA0NdlygBfBNxYItxqOjh AOxJ9AAzfH8GTruoqjm5HrL4boa6j9P1IdQ1UkIhfDOhikqMaW9BjLaHPo4tocoD0Cv2dUngjDS/ PNFD55GfeZVQuG4jravbhhMhvfi/iCfyvIo2Ndsf40OYaEH5RgrjNDFyookSVXp1ECuTzH/GH9HI fXTAQnFSBikDbJ7FiVdNtdhESXJzFy+DxIR8lneo6+A5utrbQ5Eb1saPgFP5O7SmFqegK/x1nbg9 QL+8cBc2r8yxJxFfSGvwfRdhrB0Z7IHut2yn0sbv0KZWv+62zD+DO+fb1p3uY8zYXgZVQTEua947 aYUKyhew/+DP9/GZJqhQHXFtbHKbc9AfBiGuXWGe/m0Bw6LSZlj4s3eFOBtE9PW28Zu+RfR1SEJ0 9ApbS5mdctun40EMFmknYz8de9riLLBF4aSEFN7F8c6ZW11Fz/IhhzEftgoy7cNZFtKTTJY5W1UU u8+J9KdhM2OyruuwcdbRif7iUxOMU7RPnFBbp+Jg2L8Phn3qTWB6JXWPFUgTx1qoeA2Vb33LP9f4 SGY/DjsMygBGoi8rEZCH+VVLN8NAewOd1reNdUSk6wP6JG6uRURWYs78atU2Wp5qrYX6RjHPXRXj NSQcxLwawti/vKqSvlL4iC42t1HphRGqWmvNAUpeoh2/vKoGa9dXaOTaVbonmNgxrE8LX6EFq96h 8NvuzX2GEPiiu/vRZ6hjBnNOHto1u7XEI+qbtYjOitqAYfE+GBbpfVfKuNJ6k07v9djhuQ/1t6WC YRrAYPGhZwVgDuyAtMZ1PGrX1Yr9kyq0+ya73UVyRXXH9w7jr63eaRhXrn4F/eoSRYdH6Qn6SQHW oyHsWd7QrCWMkin9yl5/TlofNjIM+GerFeK1Dh9msATglmPwjGaw3OtsotbtwrJ78FU/OOLXSQ+O PjlvlA882WLGEQHEguV9LFjkgCYHgeACanQMReRAQ6qSku/U+ClE0wvTE00PNEiKk8qB6uWOOLjM TXcHSYanUpJh5Mw+iBhaYn266Airv4Z2TbJZDEgWHPwQ+pghqY+pi1iLE9x1KU9wZVvpBjodXSfM 2UhNngRLIgKx61XmKa+db0NkhF678H1w+TV6tuFOSJlscxaUE7CVcRC2MqJ2Ys1vOU6m6z0n087p iya+O0hn4DdG1/dupY5DNsPAncJ82kWto+30hqLX+yzqOtK5EiLSJgNTV0oZhgVGDCc4OAl2XZiw rzT/KR3vSE3DJwoag82CtSupL+Ki6H7ASdSxoyZDQX0hN6BqqOc+kwW/J6n/Ed+JRkXBHw8hnj5o xBn9kHoWlyVXt6zrRF23uTbTI0fRPo0qttuo7WEL3av7mikd4SmAT+XG8z7txxTfdnTvS9RySFDT LDydtO7F072jddR1+U1qOtNAE50b0O8GyBnLc55z3CeCxgIbi33hDSilRx9nEU3kY8ygXO2wtSC6 aDlsotSnaxNFtc2iORkVRhXthXIIdmHaPHZhJmDL7LuGLbP8ja2RvRuoPemYZPeOjbA50Ou3OZBl H7ap5vYr8QpiWKWib2+ms02fir75XpYzaNPulAMJGmCjrixPNur8Y4UokW5+Mkvq/M9mHAYTviW0 Iem8atMvhRRWo0cKK7f51aac+6/dFkFt5cohQAXSGcNckZUHSNYlt/FhxnWN3cqY5FAK4047V+J7 He5OzeRxCCW/8fej9OecnNo1h7WEKjGy5TKY66uLwBgC9yulRx8clmyHHRQwRKkCkiT9UpJEoCSl STQHCSJCwPUYtllsCQ2dnSuVqb/n4U2PXRj0l1WmTRh/v5TjS0DWZnA1pPy6GmiB90BrKvtwkgLK +rvXCHYSZrDYSOT3d8YyWKJHq6mlUW4IN3UNUmk5bDfER6HL2UbHbXUb4Jnexji/wKvUnBMJBNqD lfreucfEceXQj+lxaCNV4ZREXv5BYFMX9Mtfx/xwYINx8ivi+k94EIjFuaOnBw8O9XtrwI1dQono h3S2Qoisi6sEC0AMSsrm9PE1IclxjrpahS6l4EJjU1LRAsOEkDgYHaCDW61TI63YncL9FuQRp+rQ O0j3Czrb4dkkV++nPfAMIaRaxOUSS0S+m7rbcdLwJs2hR/Rx7ynqaJQMtXyKBKu6/6G6/VQFKRkh ifHba2Ao1NrMHv/JqFFo1z/ZVtORwULjkGDq+xBukeP0cUed4mnDrESougXeNiCttN0Sv1Y3M1gE bsEi0L5KhUX4ze/QgiKix5f/I52s3uksENf3/oZqqqTFd/ENtAojpuESSzLIyg/P8kIfe72T9nRv c7nLi+yGl6YOOxa8kAzugHQCaEPi6HrHThhetDfMHheaz6KuRp4/M8o1pCzeqk70ww4FJEEOr4VX FbMu4UNQkdit1l9ZnFjVXX+om/54VTE9uf8h9W03LfKH8C6KP1f/UjegeEfGdwVpotArFIOR0l9u r6bzdnnqeun0iY0ilnnhe96y2GzXUGMnNeAbfw2ifxMPge9hbOJtfNW+YKfN4XcEUhfvQeoilKxP RG5RqOMK1e9UxkOo27TDVpFdHbOuG6FSUkSx4V9Q39qtUnWgopPe70d/ssqZAI4fXYMkVfwBDVh4 qlUobW6ncFGMTuIEVFylYAI0pssEUAl57x0mCTb4cRiwdklQCAmeMhjnE/04OYNlC5i8lQaTNwZb T6/C1pNFD5v1i11XacGG71A4jMWwYjQ4qzkHDHLHEDXmjU3lo66xu+rEFaqqCzjJ96gW1fbdpDUw RCqM5Z4Nb3DUZIN06SV0kAK4cZU+GR6modqdzlzVcOPnVIY6ui7lIEE7DyonfA1QJSlLdULuIq57 kHbRdG+9Yb5NQQ592Es7u2c5T2XLILE309mmT6/cspz+zZFFQcHStalOL4PAWMZYMYSxApuqRPQS nTTWQikYdFmOwxnZatIwunOZXwMByOKF3ScC28pFM073YHdlRDBtlfVIqrTqGnH9iUGqhE2ouUgf u38VNp42OPOcmw4kXvrPUQSebVxezVAeIalbugKb/1ZISyvla4K9Jr2HHCVSGre5zDnZt2sOawnU SWXslEOKOdbaJrHBPmDPCUg26ySVkVaVfCQwJto6aiBp+xm8Cu2jdtu7j9YeihtMIVH+62t36ZNr p6jLZmQHqCo9hhv1RsONOhg347D/5GKEyDGEvGsfhTEvcy+h9a3fATNFGJlvc9a0fs0CkWIq+7As ofeOGSweRL70PU/A5DzOTAYLxMG2wKWbeYEbPAqddoU5IMInbvRAHxsbOuNKZ2NsRZ2EH9XoU+pF pa4AygCBBXgrTsPkSX0M3NlXTYvdmolXUEuMwlDkrFeoaL5r1CHCxqoFG6so4rg2ayKRuBSuv9db xMSNU8C3zojm1bNXXfeVHhqkHfAo4IjPYSPQhZPnISMlTpyGIfIORpFxgRvcAaOOQgyQaBdO+Nt9 J/zqxiGZNJBBIsN/sfsPqKB4Cc2d504oJwzN5scdFU+yrbSY+uIrAeombAq8CNl2L+wS1F+GVJDt QQKn1bHop1QQgkEzYzMo6yXiC1W1shWeTc44bEUULbekCnQTnZmTvQhLp/1c7R0wudobdUFdu7lC +FTXVeYHi/lRWMxfbNYdyw8a2oyNsWCyYPPfhc2//W2op0YUbqG2wf1ua/DY9J59e7kjoaL2L9eC CKL0hq0CO0vjF+2Hk6XjnWaguuGTGON0Ng734EZ7y8T3wMxuFcxsnSSJjJbDnexb7kWxnqRUBYEU hEZaSmCseufyiwWDrvOt2XlAAiq6n96wF43xGD0e+4wWLLZEzO1o2f46+QmjrxjXMBR/DlpCxfX6 iWrqE/1BXL4FIMKctEYMzz/9mJTznINNq2lw25Od+giGm1vSUnmJsaADY4E5livh1m06brdVpjeF kVDsfsCUPO1iSloEFYaQrg+p0mzqd2Olzu5nPAbVAoiRz4rR1brlhgRUefdNqllbbKg6OERnvUxF YP6pV176sEow43v5zWXLIHHG8YB1R8ZF0iaQ5dS1q5kknTha4ukHOmuh5AyWXMbhCazTEvQyVHU/ oPcqhAcuIelwmIqeQjVJuQqK7TlZCVRunXbJM0NcySLw1s47uK0CkzpzdKq0DsZaG25QD9qwyPgW da6iH8MAa6NlgFXgu2cYxpEdZqvHxW+++7VvHM9szrGxTWfdlMtaQrSQ9wBb12oNN7AG9DK6rYgj 3ZCorPUcptpEPIcedrD7F980HHscF2O+crWNf+FTORWvnT6B/ZHfA6fCDPe1qRw7BB1h56npkCLh K6SAWiFRbLloT9U37XVfqnhOebPow6Kc3osZLB5EmMHiASSDR3WQ9InJK3SisGjeAovm4srbokqh n+6tMzDq9OvTIiIHAd2H69APnFCFPjBcQPdDV/VhzMhxbtESbB6IzoJrLy4dPvKj1SziMVnodSJl WQMnAuU0Uc1XbvSwlxMGEGtx6imkEpWrYNandHae7SlCUy4lbsa3lq2af4Stmt+aMMFg3zJaAOkd U/JGN3h7c5H1V+vmjaV9dibgdPLRUsggUJZTSBg1DfdCIsrDgFOpKRsYwRh4v28bzTZERpVISP7r 5jl0sMMMC6q/0199k51Cy7p17C7guRYT+jrYAxFqCq5r/CrV2gxXLc2prqvMTyfu7Eyunu9VqulA oswn5mrVWJE2kfgiP0fdBt/EWLdHQgJpZ0Ei5bK0qaGOI/I7x3fX3EmVVSX0WnExzRF2SpBOMBwf 34ah1nlLKCQMrOb9knip5dJm43wjeOthULniqwwCD85GPJVOeD91XGtRbF65KOXnQc0viCJEqjt6 d/nFkJOm1Y8VzjeW5ZzjO1EX9pJO7KAFGAcGNpc5TL71fZBU2yAl1eyqJYbPUeuKauX0z35j/urt kLnjCPVWcYIYeQhDwL2Q7hHSbpBo0qqlKhjp+tDENXgue9uUupTfjSe/rB9l/1UZl4HklLLm1IcD M0jnhSzzpDNYBLN+9NN0CoXxxsuMkuXUtatJNJ046WUfFEuOkfrvzSlHDuOwk7e9PtKNW06k4Bvn 29fOhf50Ew8FYye9ay6YO6rxUW8qO+/gtvKmsJ/Tb0Nn/kTSKhj9LoWnGcHALEDfocIiHAjFICUL 9+NLSwzpWjsH8WuXT0hlN0Zvaj2KSeanMg/n1IetEqjffRZzjlP2NNo1+7WEKCvawunHZtk3gXG8 rmIJfQJPQK2O+r7XVqRVT6SP7C2D+qQtWWyH27/wlheDtzzPQab91v6NDZ6CtBFsa3ZC8giBoTAY PxEwHcdwoO5ZhjjYaBksMdiTedW0J+PDTvY7oqCDeOUQW8QJtOElaaXq/7n0YRsf9VeOT/q9HKsI qWjl735GSrDIjymFHp9z6pBf3dxMm0f9mBohsVFqS2ykTUh+uLrFoYOHb/DACamlmhFNkZeOrvxo dYsK6dXBnVaWNUiagKDuYxvQUtOqp64pimu9zh+DJR27L0J8388d95ZU1l+tmzeW9tmZgNPJR0sh g0BZzqQqBDZFe9FnP6fxG1T/ZP3VTRZlVKQu3O8CnjTfgCpVNDV1ldjqJlrndMlVVpkmkDFpVTkB 1Z2RsUJaFLZcFzv9JgATTbBblF7qKGuiGkHhunaq2gtDz7aER1DErMJl3XV4uUgqjL7g8cVMcQXG MQ2JHd1GxcFM51nAlWN+Hpz8hEj6NiwQRw1j05I4DIU+DTAUqqSV3xQwMxbB+jEw1zlHjv2ihB7V O6U82s15THrtEczbhss/oW/C7fbnUEsdaARzBsaMxZXWt2hGhTogmNwVtn0hZeNjv1fKpOtDan0k hnbiXH9l/02Ldr76cE7FlmXWtmEatNMdx33MuqS0vTZOZDl17WqSSidO0kxTvpT9J8ncrPTBlASt CO5x2Ax08nLND+lSVJgI6aSH1HA7pIbFBjadK9mBpkhv94ngtgrKJYM2VO1LBZATqrXrdsKQvOfM yC5fsj6v9lf7e1bDArJUgr192Hrl9I/s5px0ym7mJLHMeC1hEFDS49mr7q2u0218rBoaP1F47Wkx vPaIA5tuqoXK8QIYsr8Hg9SSOQPDuU/TNZwLxgrsMrbYjJ1meNo7YHvaM3N2sNGu0ZX6+NYC8l2y 9YRKX+v9yCiGQiuVAfcc+rCKtX3vjBkI0LUJM1hspPL7O8MZLJ6Fnxe7+zBcutQ0XJrWyZI3fZ6e E5FTMCxaZ1BzuY9Mm778cHUfj/PxeydUjy58afNRWlf1juGlJQGXS7+9MUA9taZdBx1d+dHqFhVB ZZLhgZOsoi+v5qtKKwhoQviL4s93gZNtrAiEEa0+GNHyqDT44qcK8NgWqYKLi9K1JfBcglP/0Sh0 d49YNn10OHiJy/qrdfPG0j47E3A6+WgpZBAoy5mOYUDvAsM8TdBlZ9nrwUS3JwrDjo5qjIwb2F9l FOsOZXSdpNi0fRGdvuJVZTNjTnVdZX66b8D5rlzfq0yTalHkq72yYTPe2d+HL6LEb5PqYUHEw1hx vWMfdTQLm0tBl99WU1DMzMJl3XV4uWg530hqI6m29xHhYrILLiZtVSyDnkNnKr415KjmZ9tgAdPg ZPFKS10SJ6rDOFHVMd+dtO7FkzDy3ndjCdUfbfCNgTnPOcrcGYJaTptHLUeO1f5TTDVv37yLuvTA G8R5QKKT7nK1tfdBYfL6x1bZh3R0ZZn0DClvVpk9y7z95dJQUtozlaHfpH1YQzr9IFnmZJvNZPTS Hce9c0cymn4jsrKcgWODgmdgnOSZpnzrjNnaDZyVPB/jMEg5efk2gymLaURIt12MyChz+7zlzxeD RRQcY+fA3jo6bdsHMyrj/Yf1ITbxqrCDg00SbBOQdqv1SLvl1oetcjn9NLs5xym7a93grbN4lt9M xmsJi5wz7kDSpy12062qr6jy+yUYoY6DNdtJwUSHumsXbL2p865U5wYTKgZ15BRSLFZxjB9b/UYn 9Sel3zG++5wH2PbKoELuY3xIrNJlsAQfsiq0fPmoNbHus+zDGkpyzMBL3RzEDBYdarmHzUwGC1R/ 3jNUf5Iv+B2vPKLT3XhC5TAy+UwuZbFqqFcoRhfTK4/8cHUfT9DA60zUyGQLvClVlnvtCTygk7O+ ZizwdXRlet2EEFQmGa43CgX7OI5HB/dg4Jzso7wu2yzpgZR1LHnaC6bAQzAFij2kHA9DOhw8cZXJ TYepN7brOccJ2EUr5YNsp7TKqZxKl8OAbb1iwDZlVp4IQf3VE814lKchu+C6vD1LNY6prqvMzz+h Kwto10JJNUrn37T6sBFqUg5jUfH4orPh4UvsCRCGefs/pKLyjYYtq4nYp6ZqHugLRuyv+3voeLOp SphsEeKhmsFjcrxchJRNjM5bjIyriPXqVImm9FtDqZT81BMwuTBEnCB3mE5a93gp66q5y3XOQZ62 CqiOwSLVdP22liTzhWjP2Be0XN3hwD6OFNd22yDS1MIdpJRJN2Y5mwKNXru0KZDiUMadY5pPsv+m ZVA/X304zdLpo8kyTzaDhWJ36Ur3h3Bdry+JK7QwRKWb34Wahx0qy6kbS0Ws2GAb3ImnVv96fO0c Xb8Mo7X0Cn11w0ZavtTVMe0Mtb/J10J2khzHYYuMk1cF3E73Z+52OpP5lWBj4g4MzT72qGLbNXL9 xgvpja0wWJoENjvvoLZy0XM9pG5nO3oCKoMfXf6Ulle/C/s0cTLmK2s+nIBNq3888WMwXkz7H14G r12+oLWpyEPbn3Lqw1bJnXE8nXWkXVv565TdtW6Q7+VdLmsJk4pcE2sYLE49NDbvFOYL1UHS5IRb 0iRxbR+YV21GJpnuyZwy6ZhjirZC7bUn8PapDDaKlJafoS37HSUxvCtVrpK1naSVqv/n0odlO8s7 Z8xAkG5uZAaLxCqfdzOSwSJPowCVhktqAIhBwD4pM05FMuSW5rMRDI6youqgN8yIHGED5MqB79NA ZBnVn4GBS4e7Kz9c3cfjDLyegUd+dHqRxZE+uEOuNgc770Rk1N8ZtDCo2KeuCjA2R9mbVmVskdDd 79xFoWJzwBsZPA4DbjsdKq76OPnhdZLBTiwKRiK/wlJ9CS2H6Hmul4OfZmEu2u763mrLRXAKlTSj ILKtvLikLKczcaWTT0pqKSJkWE6nbIJscgZA7PYtqLBAAuntEmWhLIvj4O3przKGvJMbOb+oqoyF u9gj6OfeJVr8psZOyNTX1f42tAwJ+yTeU3/VOLTuFN6oL4xEn91g2sBQvWjZ+Rm65UGSECAgPANF hx/Ra6vedfTT5elcABMLbtu3wG27uHQi7caLHP/Z5dfi5aItT6NEcNA3NgKvAu8ZXgUCJCWc/jwV 3xoKmiS/e/AE19pqbgi09XfSBtfXBZHxgD6f05yjbBYxLr5/Q93oye9JtzmXGxTdAYjC+NKN8TEY joXbFiE96L1U7yG6xbn63qWKq0py6vL0ZpTxs8Qj3HGHmnYuc1MwDIY/oARsGC0w5sE89WF3Lhk+ yTLr2jAdYpmM4+nQ08eR5dR9G4nhAepYscGUwPD1U0kx1t9EO6qkB0LxJiOHA/aYncKmkT2OZTMO 26WV6za9tFUCc91vH8bptaVQEXUYUXZqqaaTrfSCpJT5nd0ndG2VnFrydlbTjnSaLumprh8b+Er1 lXkfOUJbVgkjwf7Npl0+8U4r7QoHGu2w5xYREZJJKxnvM/znjOPZzTlO2T3rBl0pcllLCHrqYadX lVM9FHCt30VCjLV9hYsMeye6A5CJa0dgC8tsG//3B2YZbDXNnq+z8/OIzs6ybC9qD0zwHvn2iTJ4 xnjXvADPUKUuqWrZ70RS3UH0RAQOU1ZtFa/hnRHSsGc80rDmG/yXtFL1/1z6sJOdciPHDH+fF9GY waKAlcfbGclgER3ZEUMTYBmuwKDXbm3iY7cHXO4gAzcreQQ6JSmPGopwh1rfCNei8OzzeewBRQfP Oeo6glZtBFzYFeYicwLuyn5Zu5xOQ+yu/sYIvO68QgXzrAUoPBncOVFHB5thzBcqMz/q/I7hrlTQ UD+6UN1Rqm81Tx9i939F1482ucQrDe8HMGI1dx6OJ8SkDQOmIxfaLAYMjKDe7oa1dWFIDO/EqcHY A/olPCeIMm25cIf+ZDVcZDsMIfcCUpTFNlBo3Cv/3AO0HKBEFNNlLMos2hUnFAKHj3t74KrZZAqJ RUzbOMQX/WtxJYfUtw5nHFHLOwZp01a4/ZsVN1SoBnZvdbkybgD+Ybi+natsAAwvTeIEBVdSjxLz 4MlJSSfiOwbmBK44JelasdbwvGHkA0ka26BrASaduTnWU+RHGs8XwuBk5dtw7SpOsWDYdG5hoexf RiLzn6p7S+FdtKfrhzgFNKWiEuNgcAz9R+qDq2ZzcYJ+AamxSkdqDIYOH8LQIeo50v19s7+CUdP2 EOoNFnYil4Ii1NPpRwhwFiVmGUy3jDi5EnHExuU+DGB2tlGX4/77KHU9bTDFUp9RXYVnmL7F8PaD IobhRathO/qT8r2OXLO8RNjf63zrm1NU50RthUV74TJZjBEJjBG/vnCKpMtw90Sqfuviu6i/0A33 5svM7xU4jNy+RFcPwFsNvlfjUryxuNJaxkxDi1Em48I4ABW596rME+L1fSMwauqVhLOiZvoDRmks Cg8Z80wvLGIsCTX3UlPjW2KIdy6vYUUXgx2xtsAN8LqKErOuYFJHOhV3kFgkqyLDiTF4VBO04eXG /tYaIyP0DXihE99aAb7R2eijzvjqlCL7G8M7iPJtG/kVYwyxvbq52r2EGm70w+C0+R0kxmIY937l lLWqD9/qavNb9X0r3iLmMOcIUtJ7mtiM9FNDc6XBMI121sF4vKlKFjp0BepDaC/1ciT+ECj6+Jld pkFDfK93Tmylg8IjFS6fJBy+dUdqBjZ/amBD4esYX4QL1+iFY9RSZS7MDVfWPjFwEIRhY8d9N4xI /uhyC9x1Ik/0+4MWAystCROjdJn8U+etjZgrOw2D4ROjD+jehXN01nEHLhmYufThTEoWHFcpc8oT cYuKGG9tY7WYi0a61HFcqGLAo5JhGBuGRtUxPLgQKd8IV60XrbWPPZbORn+IRe9C8qKNTtruW0Ep marrPdiFaLXsQtiZ+k+z7Tf4FYy+cct7D4ynSs8+Ih+sAazxQqRQxyfXWJrhOOzkrhw0CS+M9Tvf pdkYK387fBVz3T46a6nFuL+fLOdXJ9Msb1Sc1D4BtcxjB8D8iEsMvZ60nLUPslbXTeLQ9NgBZQ4o dHvAdBgNSBduhY2PnbDxYa+rgFPkUB21t5pjjNfVsprWqDHmuz17gS+MuX8OZt1BqMzbl+FooU6o 1eZ25TbnZNmurjkls7WEUVuVKS2cIGD9HxYSXzjgOel4AYWHxFF4SPR4cI3sfonaO0zMxN6gcq3J cE7cv0THlprrW2HXyyuRLNfhJbSlu53WVKzBOg9rH6jSXGxcSad7TZpB7RI9CtsvjeZBRRWMr2/a sIQS9weodanpKZU0DFh1fLH3KOWHeg1D/2Kc+e0Q1lzbJWPWe6DzLPqwrjeq4457T2XGZgaLDrXc w2YogwXAYDHVU7TScgmbBKgA165JUkzaKxcnNEkuYiHRaLk2loOOmsCSSJklF6TqW8k9VU4L1QhJ 7g0jZiseQfrnaz5sbbd3SctkMwEw0V1v3WpJfrgzLK0uMb1CINg3GKTbroIkNqBdh4O4ye48kz6l YXDKnV6RCHJOttwx9E9u8UI9jvqU2Z4yuqkp7urcL3xPKoNPvnS7v5XhujuI4sPNtm0pXpVE0cV2 wjSugBM4Qai1TxCciPqb9d13qGazmNCfTV1jfXW0o9prxyT59+qSCsGCoB0Lgoi+ek6oWHiLMUK9 RrohtVErFwPqO++9uhlRJ2cZr4RKq5fQ495zih2k7E7eJE333fXNL8FrjjtM9+TCx4ogdbl1KWSY y5Vk2vYGlO9bksrqTo+tSUpdrHk33IZL7MtvwW19EvsImm/FW8hs5hxJA4xy26W4FRjCb9S6D2R0 4L0UqTYjh6s3UszVlzTeGFyLeicT343W7bYV6zEklxotySVfwkbYBDjstgngi5NlgHoyG0jCYwso qz4cSDzTF5kzWCIwGt3emU4+LfC0sd9nFyidlK44GcyttVCBXudTgZbU1M2XHRpoD09h9Nlxk/56 TrWzHYdlHli3wevJaRmgvVPHj1zmVy3xdAIzxEld6z0+Uw13ySYTJJ2s1Lr6mCSCQLjSsF91HV5n nEsj3a5N6ySQN+JwYw/WlnNlUHZ3Oc45ObVrDmsJUdkJ2I78rmU70qi85cXNBkLrzU28hBRQC6SA onZE0TbFsPF2QXoV0o3hKkPfTur/1cwbdiT0R6m1AKZSRSUY87I/qBK/IkliGLYxV9SZqcP4SbHo 8nq+e1Z92Cyw+7+6zlC/MzsWM1hsJPL7O3MZLAInbOLvdB2hnu1t8mN28NtI9YP7qRynuNPqEicy e5uoy9IRVcsWqt5PNfDUsXxFkROs2itxAm0VDXIPKPZ7l5gbTmovQgqjy2MMLFTdQrUHdlHB0G7n NNIUa72CiUosvl6l457Nj21N/HH/PmqssqVIrFwDDM6K0/zobXFqHMep8EJ6bQVc581/QD2w/SIM HeoGA9GukRNt1N6o2yyWUHnrDirHgv2NDHSobWyCfoWocRdEjYc8EUphBX1L4zt0Z+ciOungoejx j31IHcVlhtSJJ6n/Eaeqx+AO1jbKO3HtOMQld/rjaUJ04paaaCmDIrtX4nRBTnT6BMLgpugHNrfM HWuk/zj1VElJFfVtuA7fXO1GCkOiqUB54ZuslXfqbQgW4ts8FuKN95AAuHgA340jqaKkwgS+afs2 Kq2qNKQ97DfPoq56ZhDcEmLDsYgeQIz1a6YYq11I/Lq+VxEef0BXDjdZhpWViLgV3nwqG78TaD9g AtJ7f9+8gc7bkipK8lDFNlpX9x0qrXjLJQ1lLzRCIi4WUVG4wvVeYUjc1ezdllT/3psm1bMqCZEs bhWkZjZppGYmhi/RQCsMvfb6yyu+2027PfYCcKqnw9+ft9VeQqos18slcq4Sw+nfQ5z+FcuwKBhk LTaDTGwOjpYY5RXjpPbSbCC08TKcc9w0wCjfq2GUhyF9dgFqrJ7TS5kWXiO626i11jNPIILoS7UH tvk8fBhp8Z0P4Ts/qfvOIY3UcO0nVLYquQSVy+OEVaC8bZhkBX13QtLrOKRsoq43mK+av0Nrqv+c lof95c64D7to5/KQOYMl3c2pMCr9PoxK57w5hQRWS8g6fdZUVYxnYswvrRJSfpoIahC+w5PY9A3Z YXWddOzoNmcutoPNX6jHYf3T5cz37rfeJ3Eg1uRhdmczDrvo4jsYaBZSxnKDKN6LOpfBDsqaDZYU p5Uo5/nVlXm6D8BpA3DSzDV+ChjvohjvFptvVBUUf1xviHusVG08BRnbrzoxSJW1qi0fk6bTh4WE zd5lWGceo4uHTjnfbKh6F+bXBipbnbvquZFjjnNOzu2aw1pClH/i9jk6Hq728R7Wd92kmq3B0j2J hx9S33bpMc5EX/yvxL7sJ9iX6fEdgWvmnoo6X34iZWlrL9U2bwz4ZkUMXDEcvK/FwbuLWSKkQn9O ZWG5rzLiqnbKECCkodaFYPTZO2dVtIDZtsu35npWfdgou+cfM1g8gHzpe56AyXmc2QwWGzNDZeVT ejIuArCRLxIihZ6PyY47XX4htv/44SP6HOWZPauI5hR7VCPyXE6htzth4KNRw8hzXinJjQ7QlsUb EK2Emh7epLCyyXCltUSSEwgUm3Uhvq+q5rji5unBEOcXKisQC56LPmSoROWJ9kwjI7AS31yB4MMI 1aKiKcBLqP0IMXWoMQl1I6NP2Oo3kwjwM6lrHHUdkyLWBr56npev5uJ7j41hLDRwstomSdrEuB0X pMR4GotDdQcJYPCWhNpWkrS+zKc4IIE+IXS3YbqDEvg3J1/qdFNcj0nPLoc5JwGV0JGHMaOIBfOK aRFUmNK60IdHhh/Q7OJi+nw0RnNDS3xqklo6ou9H0YfBmBdXwfwlhvc7bVxNoFHeKMprjBFIC/XW qboSUJv43JhDCk3VwDQYdVPfhzNnsEwVfpOZjxjnxJVPFcBk5c10HPbRssdi9KHZhZhfp/E47Cv7 ZAUAk8RTqDGL70r8YYyYQLvOngeGAD75ZOs2h8HiVYsT36u40vhWzYjP2f8c1hJiPfB4+C59XoSF OlRW576+zFTRTgOCiYcP6DHSiKugsJhew7yRzpparLdiY6OmijzUtxaElmWgdojy3kZ58b0Q+kXR UqTN5LtBX5jAXCnMEoh1pqPebdQiT/9y6MO6EjCDxYMKM1g8gPDji4EApFOu7IR0TKeorltl5sUA gGvJCDACjAAjwAg8SwQUBgtUXE7DcCNfjMBMR8BRueE+P9Ob+sWqn2K3SacVwCpCk9MdXgwJlsnB jqnmigDE9fqahfrWEnptnjhhXkgjh9qk+J9HdznX7Dg9I8AIMAKMACPACKRCQGGwIOqWrm76MoQ7 XquA6u3iTI57U+XD7xmB6YHA48glGlq11lLRraSGCz+EYWZIPaLfL1j9bmo1s+lRDS4FI2AhAOPv /bCRJwSEolCBbDVt/zGDBXiwBAt/JTMdgcTt41QbDrAxApstHb279Hr4Mx0Yrh8jwAgwAowAI/DM EACDZcMcOn7BUwDFu5jnDT8yAs8vAqpnM10tuN/rUOGw6YxA/Ba1zFvp2A+yi6pzUMESLDY6+f1l CZb84snUMkFAGCE+00MfQwffcAEM+whCH/KN1e/QGyvS1OHPJD+OywgwAowAI8AIMAIpETAM0A/j +NMWWMFJflH4Lbi8TZmUIzACzxcC8FB2pXUf/XP8FV+5J8Y/pW/UHYbxbO74PnA4YFojEIt8SCMY t2fbpYQ9z1AYDiY8toSYwWIDlN9fZrDkF0+mxggwAowAI8AIMAKMACPACDACjAAjwAhMawSYwTI5 zcMMlsnBlakyAowAI8AIMAKMACPACDACzyUCL9zG67lsJS40I8AIZIQA22DJCC6OzAgwAowAI8AI MAKMACPACDACeUCAGSx5AJFJMAKMwPRCgBks06s9uDSMACPACDACjAAjwAgwAozAi4AAM1hehFbm OjICLxgCzGB5wRqcq8sIMAKMACPACDACjAAjwAhMAwSYwTINGoGLwAgwAvlFgBks+cWTqTECjAAj wAgwAhkj8NRK4bG8nzEdThCMAGMcjA2/eT4QmIF9mBksz0fX41IyAoxABggwgyUDsDhq/hF4GqfY 6KeSbuErVDTf9tcog/N6Z+T5iCbG4VZsViEVzHuZiorZNV5eMc6FGNonIRaRom0EnTQ2nIk4fMTh KkCadOIbkcU/kY/IDz5CCzLtdkibQFqjnGmU0cmTbxgBLwJPH1BP4dfoPMLLu39D9ZuXeGNM2+eJ 0UcUi8XMsRTj91yMpV73jDkVPvaIHmOsNsYCm9CszMfsWF8T7ag+Agq76EfxdlrE36yNpvZ30ttV myvG1EzHcnu+yGEMz3jeEGW38k2aFn03hr5rXLOwtinOdJKx0lo/M7UPM4PF3c78xAgwAjMAAWaw zIBGfI6rMNK5gd7bPqDUYCMWv72Ts/iNP6LrR39MHc1ike25Kjrp/f5tNNcTzI8ZIoDF8QT+DMZV ocLsMBgmyWlN3L5EF9E+ZzvV/lBCTdGbFF6sSxunO91HqKd2H0WV1+Wt3VTVWEML5imBntuJ4Uv0 y87jdLrjnHwT3kj1h9upvDz55nZkqId+efgInb9wy0kbqm6hmgMttPz13BbQDkHdjcXM0b3isOcc gdFL1LJ4rdmPq7up60yNm6GQ7+oJ5iBoZs8IiVP0zDE6u7WJIr6ybaS2WC+Fknx/viRBAQrjyR2l ktrG+ymUwed2Z+9KOnjI/GYbbj+hsqUZJHZnPoOfpqhdvQg+jdEd9KcBjOWu/tQ8SKcPvOuNbTwn 7l+i83ub6GyvHIcpvI0ajrZQ2eokY7iR1wd0saOJriuZlTZ30qbmbbQoWb+N3aUrnadoAGuIqFOq Eqo60U5Vde96vtk4XVk1h447eVTSj9BnF+XQ7WZqH2YGi9OZ+IYRYARmCgLMYJkpLfl81iPWv492 VLUphcfifByL8xwWIQox5RaLnQ1Y7FxQgly3k8jYceWT/4dodxv19T+guUU62jhRhkTQgtAyeqNi I4UWu4GNDZ2irhNXA9L66U3MW0O1h7ZRkef0V7vYRfJw3UaKdJpMjOBNDRglh7fSwWaF2eFkXUl7 HvbT8mInwLx5+ogGVi+i087i1fOekG4U6eZ7w4n8fc4dJ9xxk5p2lrgDrSd1gauLUHvtd7RulbYh dNHTDxvuoS0rthJNxeY7/VIljxm7RX3NbfSYJB4T895F/6nx9R+DEDbTF3c2YeMi4+symIi9QuvA CFuuZbrpUgSHRbv34dt5pO3/EzGi0NvvUrga302OJ8/BJbDejIHBUmwxWJJsKlPSSSsCxsLNGAt7 iYK/yeSERrqr6b1a3fdqpsuWrj/XGF3Z/iod7/S+wXiNeSKTzeq9AyuptdXcjO95+IV/TPFm8QI+ T127SnDF3HFs6Vq6LoOcu3DrIDXt9TNYJq4doe++3eTE896ED12hpt1veYMhdfKAzkJSrM//xgrB +mMM6w/dEPRwgLaENgSmJN8hTZyu7y6jjg6bAZR5n/VmNtV9eOJGD508fEmOj5BUW1DVQlWb9fOj t7zpPjODJV2kOB4jwAg8Nwgwg+W5aaoZXdDE7R6qDWMDSbkvQrRAKRuYUGM3Ne7dCAmHQkqMQ4R3 FDup+UtowWSrJmkLlmtgnIZwSnYykh6dqt47tKlqmRN55OhKeq/RXgA6wUlu/AywaHcTtdRqpII8 VOojT6h8hZvBQyQWoXOwCLUih3dRU2cDvfH6QpqrSsB4aI2cqaP3tp4yQsOtvVS/eyM27XEauXCE 3qvaZ8augCRAv1cSQGW0baSGwRYKr1pGifsDdHJVtXN62hj9gkq9G/ind6m9cLkZp2I/7QGjKRR6 mR4PHqOWaitPqB90QP1ggYcB5Sl+xo8JMFhqBYNFW6eMyU1JgsTtU/im6zx5JZE8uA8m0lIxBqS+ SqFG05izGg2+nVn4dlJnR+Udg1S703tCnUbCtKOIE/xz9MkY0VfW1tDySZWukAwW/TeZqtCPqG/W IjprRNtFrcMt9AZ2pIl4jIRayQQtpEWv63aoqeim8X78FnUUrcRmPPN5IgGptSuDwxjrl1LZ5sls yzTqMS2jTH27OuOahcf6jn5at3kNFRVBzUyE6cZRjMMnMQ4PGWkqqfHGSSoNL6TE6C26WLeSTluH KLq+nRjGmLTCHJNKmyHpuL0SEiufUeRoPXW0WpKTjf10+nClQV39p0rbVnUN0rqKN6kgDqbw9pV0 1spzfe9vqKbKLT2Tz7XNVPdhtc4OFmAkdUHa16Wy57zM7oYZLNnhxqkYAUZgGiPADJZp3DgvUNHk QivzhXNaMNkSAJBsyFS0PC36zzIS9LxHwCT6pLfJWCQKBlJDHU6YnqJQEIeOXj5HxxslA6QJzANb 5SYxepeiw0jf/2M62YEFJhgcjYe/RXNEWvUa/RkdNJgo7vYZ6Qajo9ZkdAjmWOONn1DpioVIGafH kXN0evVW52RSd6rtkiap66b3T9SkoaYlN4g6iQ5ZJj8zyKjS2AOKPozTohXLXCoSEzeO03dX7zSi 6Bbn4sXE/Vv0+GkxhZaKOsorenQDtTSKBXpAnjJqVnfO9/E8MVhsphBqvGXwN7Qu/Ap9DjsJc4u8 TDYJyciNS7DnYT2Poc9tNfvt+hO99Mdi0y76JWwZhN4uobm6zZckldad6P8fHV5Oxw0GXyXVX9hP IUg9JdBH7l3ocauQYePVhY1XPjcWaRUy75Hk9xPUz5NmiQ1uBza4QuKg9toTSGwFt2dSOtm8dDbX 7nEoG1KcxoPAVLcrpBDPFi5ypEnqIf1Xnob0n2RYENXfANM+rPS/OJgv80zmS/gEJBHFPOi5Hkdu 0efFy2iRSyotRhc3vEpdglESNMaKuTTygIqWllDRPIUomH7tYPpFEFR64g411skDDBHLGbsnaW5Q SpL/W6ilTsSEyi+Yb/OXm20VhE8OuTODJQfwOCkjwAhMTwSYwTI922WySyXsXVy/8AuKDGHDiFPH KBYdRCW0/tAuWrddY79i7BYNdV2iROHLOKkkemMzxPwhMnuxo4fu9A5ArL+Eypt3UVWzJq1SmcTD uxRBviPCsC0kFIoWQ3VlLU6R4ucgfluNmPldOMeG7+JEVSxyzllSBjjxutZOX1HWZDSriBZ5Nsx2 kY0NWHcPXR0agKSLGVpUXELLUf811e+Sf68Yg0rMB/RJ/GVjI5aIf0ZffrsGOuHYkI9Bf7sLtM4M UAR4h2Dzo/zQflq31r0gs/PO9PcxmB2NYHaUdmGRt9VNU12U6t4/hkRIo5AIgQrKadh/8F2OLQSl fWJQa5hvqTVQC0T29/tE9tV81/fhdG+DerqnnJiG2+n9G7vSYK6IkskNIrXepNN7PYtoRxIiQ2aH ssHIdOMp65lhnj6g9QEO/SwWt5n3YX0ZMg2VGwtshLTSSykoos+dhDj/EKI13P4CNjNSxM/2tdNf tsH+U6fL/lMC4975WnlCnVcVMGzYIl1yrBDFF2PrV6u2pWfLxxhPTmE8OYLxxKp8uBKn8g2QAqh0 bwJd2MjvJ5N2Ef3ot5CwIWxie1ab0l6bem9SqZC2URiyRUuX5YX55Sqy/ZAhg2Xi9gD98sJdGLB+ 2aSA8ZiK11D51rdSMsoSD2/RR5AqMsdrqIuFiYpeh8rYhmVQMzxGfeM1dKxvl6PuJvMS7biQSoUd KNjsuDP4If3zw0f0eRzMxdAS+oaY71ybe7ty2f7mNufk3K6wbXan+xRd7DuHNYWY18CAEDht/ha9 MW+UrvZeogUbWmida+yHquYg1IMrTPXgLYO/o8ryorQAkONKCQ5LJ+tlHgAAQABJREFUbvrUia9v fok6evXMjmQZjHRC7W071N4yHmPl95ScwWKOL0Vg0n9845Zh3D9BL9OXwbBZvvYtzVrCLK3sV5Pf h4PxkXXMHJ9gqvYbZrDYSPAvI8AIzBgEmMEyY5oy7YrE+uFNoUpKNPgTQspjDAYElfXOSCdUSban o0qCDabWwGGcIrCz0a61s6GWQNnAq8HZ3DtSK6kT12IDuM6jvnKvs4latyfDCRvHwREYRVWkGeK3 qGXeSsUAHhZ6YHhsWfwLalxrSke4S5M/iRpbckO3yKP4h7RlXpmRte69ndYlETL2IZ2s2EmLDv+c Kt9+ZKnHyPLegU2Dg5ZNgwbgV+bBz6ynZKLU38AJZVh2KlViZMtlLLBXCzUD7DBTeoOAWtF2qBV1 ImpFOx3rxybHzMz4f+/wBmptFtIk/g2zEs13+xj2gBote0A6aRtfAicAfXtvGbUbBjQzy9MhobsB A7MFOv9R3TtPWClsDjRqbA5k1Yc9tLN9lBuhbBksUhUgE0ZApuWV5QwYe5RTcdf3kWlG3viasUJE SWYDyCYxcmYfVOTMzakd5v2tv4axaZUcmyJ7N6CPWmoQ3siu542wX9Trtl+kMB9dUTUPoY471LbT zeDVRMsuKEMGi14FUo5hQYWIDR2hHWuDbXyY6dzM1CvY2Au7NulcpYcGacfuPKkpafpR2nNOju06 Eemhg6u2ph6jwlAruaGqlUBiZBUkRiJAy2aup+OVR4DrMESFZJyHMQNV4HbYMhJky7vvwBtXmv1Q tc2SqZ0rqJe2LDXHad3hhRxfROGDr9oLkPJbqx5AmHGnsg8Hl44ZLMHY8BtGgBFgBDQIMINFA8oM D1L1astbO2nNhrfotcI4/RoGH49bC/AQjMu1qcblxh9QpO9ndL1jJw2J1Yt1VZ3oh/5zIZgna2HN 3wwMH4Jo7m5VqkDZEFvpypvbYTgSG9NGj9eAfEqwjOOktXw5XJ+WUAgSI1Erb8IJW8i+x280UkKt o530hmIQNXq0Giof0ojjJuhcl5bjZDY+ClsJbXS8Vb5zn2rH6R5O8n47TvT48hF4xPEwpSC1sgV6 3xODddRn4JW/DbnNJEm1yAtDjLnJI8Zsp6XwUUiSNBiSJIkI9NVX1ZEZfwndwynlvXiI/qS2EifU yoLLXiArmKq3sWs9NND7gEp3w1ZDsXyjGlQsb22hWGubsTA2YlS00J4T8MrjMcprp1ZPP6n6KLV1 1EB65jOcpO6j9kZLZSlAl96mIX4TkAL49bW79Mk1GPu1N59pqipNDN+ie5CQute5lfoumFTLu25S /Va176u5ZXavt2ESQENz6pp9Hw7II8NgdWORFYPE2UxnyaBJs7yynAEMFtCZHBUwjBWQkBiB9EcB pLI+7qgzxlYdA1StikutDmPbpu52Kit/k+bQI/q49xR1KOqAjcNPqNTwbJWZrSY/gxHf++5qqFI9 goQCxlJnDsBYGpalE+G1l39O68AsnZTL6RPBbaXmm7j/IX009EDwbCkRvUQnW8XYkCKtqroClck9 XT+kr78O9TaoYt7rPY7xxWa6u+kkIJnw0YUBGsCcFlULAbXU9a1vEd3+kM5D2tO5mmHr44Df1ofz Pu2bXOacHNpVYXQYRa3YBdXUb0FyKgac2sy5T/QN9AkfYxJMyw6o8hiGbeH5Z1P5KJ0VKqrWVXXi CrzyBEgZqe2D+LV9N2kNpECFsdyz4Q2WbRYirR0tOwPjFza7blylT4aHaah2pzX3lFDDjZ9TmXIQ 4EpiPxiqt1dpBG16vNFmdO7C4RLWNfPsSOavHF9keKh6F5W/vYRilz/AOkCuEar6RmjTBskUFSmm sg/LEnrvlPleM9d4Y2f6zBIsmSLG8RkBRmDaI8AMlmnfRPkvIE6KYtFPIa680GWDQmTkeEkJMGQm T+ngpSUKLy2L7eLFaGjzq3RSMA08aVVJBYJx0B+daVFcIcKDzFF4kHGYGe5Fq00911+5yEmDPlym boHLVPPaRm1gvgi7DOolrOt/F/ZFzGs/HXva4pKiEOGO2o0VqxyLxlpl0TgBsfFE0cIkovxWwjR/ bCaJMPpaW1tCn4PJI2ywfHLtHHVstxeBWHgOw4Dr626idlp3qPmk3fA5Gx3ESYORoaPrZQDo4jRA 6iVosTvSDRfftXJR7kqPPpja7TYWjS43miaFtvEvfGLnLtriAfV3DN5ik0skFsnt1PV0V0rVA5E8 3UsYDRVi5BO3P6D3KsSJOvrjw8NU9BSqDspVUAyjwKpNkjz1YSWLjG/lN5clg0TpY1kxaNIssSxn 8NjgqGil2pynmacumj22ar83OwGkFTogIWd6XAnY0DkGw5FIPY0fj8G+zWcY82N0tW65YW+ivPsm 1awtNlST7Cxo1stUVJyEQTJF7eKUR71x8g5uKzW6695hCKRIq2z+a2HjY51q4wMEJ67BVtPbO3Gn kYRxymfm7DWOnHh4ibpCax0mQL77dU5zjlL21OVSJFBQ1Sr0o00ezzIjkAh8z/YQ6N2UO8aKTZy0 /9F334e66lzdSxyedBRZDBrNe6+0pCYK1IalwVuyGUE4HDrtOhzSpSRSD6nsGJvQV6o8fUW8k+OL eAID51o/lSmSZW4pILdUlEjhuqaiD7sytB+YwWIjwb+MACPACKSFADNY0oJpxkUSeteR/nMUGbxl 2CiBdjm99jrEUyP76Lw4jVcX5k7t5SSrE2N3JBJcaWUasSBtherRG761uxonxeLXKUtmN3KRk5q+ ukjVLbDtnKPQ2W4ROtu4dAtSlWmxCfZHqjw66DadfP2q+QXR3AQx5CqdGLLLWK07tXbDpyzGdRIz bgq6J7S5x232JizS11UsoU/gCajVUX9ogVee/RqvPKpajo4+bMLEYBPGc5rojRkbPAXJK9jXgStp cdAqTuOjETAxxsBU8/VTNbVgDLbRxct36XqvlGYS303gpkBNnum9re7m+raCieSrDwfnkPqN/Ob0 30dKCkof031favrEGLzXCO2yNK4CMDXnKv1CljN4bEgnThpZJ4kix0Dt92allIweaFYII561OLn3 1Ltg1qd0dp5tPFS3YZN5+SVVkhTRfpVBuxhJLMaOnTzpb+ErVJTMm5uTd3BbBdFPuw2Rh23ElyBJ 1wgPZV9ZXAzjzKZdrbnwcCOMXX8SL6I3wh6VDqd8KEUQ43kUKiWLLdU/xSV3Ln3YrrM6B2Q85yhl T/W9keqVD3VoO+B3pSzKdGfvS3TwEG7C8Oh2Q3p080nn4eCl7cQOWgDm1sDmMuoTgzEuv90uM1zY VGtdUe2RFDLfif9eb3nyjXIHtaAhuJGPwNbOdSFFAslWgqRrKb6rRo1xXCUlCUZZ34EeGnl4CnZn 8AbzhphAdIwd2e9QLo2EiqA7AZW071oqaVUXIMWy1i3FIuKIS9JK0f9z6cNmVp7/csxgGyweaPiR EWAEGAEdAsxg0aEyk8NiEPX+U4h6S7FUbW29J05GJDnJ6jYBjqSKK61MQ3W9dPrERm12tjpKSvFt berUgWkvTEBKLlJTqO84p0kwwqmxQWLTCcM+RpPGPkbqUmcWw85PnJKVY4EYu3HKNH5pL/5uw+NC gPtXJ63SdvYiWKdSJAxdOiLeSdo1uAZKv0Akr3vLEcUNs26xH4WdlRbDzgrWtnC3WYtN0AKoud3r U5kzMJwLiRLtCaimYFHYtWixGTvKxkcT1R0EKaErrVsd9bpkC2R3wvSfnP6rtE+y1E57prJDk6IP J8sj1TunzIioa8NU6YWUkO2ONXn6zNRfQh03YSNEqnHJcgZvWtKJk7I+SSPI70E3ttpJ1e/CDkv+ m5zBkhzXAMppt4uZXnfaH0AZH7PXVocnppN3cFt5UjiPmbThPdiXarXsSzkE1BuhDrP3h6bxcjXc KV+yPo/+CubySbExd6Q9c+vDdhHs7z6rOSetsps5qYy+pEw6SMuORO6Ccw2vPQrjTLaFoLcLxqXb pXFppRzazXzsQ2qfX2ap9FRSw+Wf0DdXLaHPox9CPQvMGYErLtuul/mU4j+MWZ+tWGkxdkpoz8Ob tLw4RRrrtVsCxS/NKuuKPhvvlfVUySt11s63VlwXrXHQgupb0JV1H9YSlOOTtk20adIPZBWh9LHi mIwAI/CcIMAMluekofJUTLeB241U29tA34C72rnYnMZGYWflcBNO9MF80W7k5CSr2wQ4k78rrUwT gseXNq/HF7tezkYv84WzTSLZr1O2NET87UWqb+HnzeA+PB8trTZCdYtMm052Eh7ezFI/6/KLdtZB ysa0SRLCiWob3MzqLjutq91h5Lanto0W7D5J61RDvgYBZZNA/kWlLg9v2PXt8PYgDNWCIdQWgzcI RaqAFFUI/ymmkjeYO11g2hUoxEfONMEAqLCTABH+GIw1q3SVeLpbW01Dbnx0sTRhWCDbp97JFsia lGkFOf03TQkWpz29mxdvbin6sDd6Js9OmZFocjfyGGM80lDJyumVvpPlDB57JGNDx7BIllu67+Q4 qRtbbSqOpxMrIITfqHXv+rGYqoYRaMXTjRlH5jW57WLm5i2zq5zeh2nCYBHFioJZe7K6SY+vVe5N MLJaVV4ka6FslHVzghkxRn2zXqWz4sH5nnPrw3YB7O8+qzlHKXuqfiG/GeHhCwbOAxj3drl8v8q4 E4JaTptHLUf2Gb8EozyM0eSNOvTAhfh5ZOj9zn1l8AbYUoIIT1V/b1Ibd3FA1AbGR0hhfEiskhzY KPNHsu9f0goeq9SyZdWHVQLOvRwzXGsE531uN8xgyQ0/Ts0IMALTEAFmsEzDRpm0IqmT5FG4mGxw XEzaWcb66mhHNTbkLiaJ/Vam1y0CnMnflVamUQ2o2hTtX3WB8qMUJzN2mkx+nbKlw2Cx3TVi479n FCdZHvsrdr4TQ20Q691nPNZD/7rco39t10mHlU0jn7/6/BT8kVnQqZ6dVt/u+lJKBgkMDV6DrYJV yqpSn8QV6qiU6RgsymLft1lQmC9UNwipKLd4euLaPqp927Q5o2sXVyE8D06ZnI2PJ0Lgo8R5Mtrb 6b8VMELcbxohDiwKXsgNSm59OFkeqd45ZUbETDcsBm2lD6RKP9LfQx+Pxl2MNm354kQLyjfS8hVy UyzLGbRpkZ6wkn4fcMl7Hepmj2NEcxaXUCncuLvs4mgLZAem138cKUEka4AtpTKPLSWbWvJfmZfb QHfyVM7bDNpFpJm4fYmuDkXhKtmhEHhTEHqLypK5rXfyDmqrQNLpq1fA4HAU6rOx4ncoDFsZiVgM 6meWzSOoO43cgCHbrU2mBIV3nHDK55fKkyVDf1q1iM5GEKLMlbn0YZu2PY5nNQYpZU/1vamefNZD 7aXGY5jVLo/xCyPOpNqHEoHIy2ZI6xgsUsURTIlxuE5X+o4c24j2jH1By+WnDMIK88qRDhIZpnEp ZUpZfw85KdHj75dyfElieFdRuUrWdpKWPx93kXLow25C1pMcM9Q+q42qBD6G/bfrl2Fkml6hr27A uLvU1VhOTGawOFDwDSPACMwUBJjBMlNaMp16yEnS7+kH6WE47iy87hj6z96Fo0XePuH3bXrFe/sE yJM2svslau8wCVTBFskmry0S6DO3w/CfWG9m6lrXpJrGf7tsqVQmQEo9IRNqTV4JCSM3LMbsk7Ig SQlnsQs3zY1b03QXmUZVgqIE5qcs3gx8PQtWQc9OK09Ug3JRwh2pIxGmNwYs3ggvQl07j9Ci3d0w hChxUDeLXsaPXLBqNufwItFXiA0KaPu8XSFs4hr02d82Xaz6PUnEaWL0U5o932/gmeCF5ewsy3aF bnEOVaDYGKwV6QyAKi6VJ1WCRXNCKjBOwMPJbx/G6bWlSwzD1fnqw4J2tpfcDGjaMB2iyoYvq1Py dPIQcZyxAZsWnwg/bP0cqKb2VtOYsrefOlnAnkNP4deMk3MnLCPVOTk2a8dWm6j6zQXZ+BBx0VdH Ir/CdnMJLYf6hPuSeYXhUrnJ61LZMIL+gBLzltCCYmVnaxOZqnax81N/nbyTSAOo8dV7p51TpAUD tx2GhMV8pDMITmDAXJw1h7oEbYVBIh5VtTYxL7gNwRsx6N7hariRN+02JdtMm7Ez+2+P40n7UBBJ B1uNZIg3jau/b4QXvl6XFz47ehRe3VogBUmNUA8+rKoHK0ZyFc91ZjrZP334IkJssI12VIiDDR3z OEYDcP982mg8eGnySmyCWRaDS6miIn+/Vr1z6RjzwuA4CftN/qTSOYBufHb6HYoMBrn/YAsqpttf peOGNGcK7B1ak9iHzUbw/E/eJp7IxqNbWtqM4Z+PzXBmsOgQ5DBGgBF4rhFgBstz3XwZFh6TpCNK X0K1F7ppDVwF0vgjig6eox6cykUdiqa3kgXzihyDkMIwbt9iMGAQJ3xokBq2r8E7a7UhTvauWZ5O KtrpR53fgc51kXlyhc3nltAGh3JpKzbatZX02rzPaGSoh1oghq1eDTdGqGwFjLx5T73USGnem15Y xClqj+WFpYQaIx5Duz7DiooKisjHcAO8DW6lzbrGbg+43EG6RJHF5gQbeOEWdKTr+3RQLKSxuDzW DDedOD0XHjrmisXdrEKfB6c0q+SPFseicRxYuvLD6TmMMRZYGD7ua6LGatO9aAjlaWp+F4tMtA8K NRH7lKJ22jC8PPVvw8n7K+ZCsjB5OR0jhkapRJ+C2++3l9Fs4PDb4V/RdVvlTLz3iv+73G1WUtPt bgqLE67RD+nk4jLL0wY2KaPwVuWRIlKZdlsu3KFK69RbuOo8tnSt42WlA7r9C5R+5EioYHG+Be5t 11SsgRenQrhrvkUXG1fS6V6jIqYBUZehQ+XbgVvRhsO7KLwaqnWgLfpD16oNVp5gJmikmUyqOfxX Ntal+Pbqd74LjGPA+Cpd79znuAMv7/0N1VeJDXUOfTiHYqpJs2GwOIY+RZtBIqRrhdmW63tv0p+t hrcbfD8FOBGfq2NyqZmney9sRAwds8YG9LXhbvo6vvPPMSZ+cuMX1FdVZzF+QdDDOHZlAXW69mLb LoT9JvkmyPAiZkVVPfsIpu6xA9Z4Id67xidlo4NXocZOatgNF+VibAIuE3A7/nFvD1w1mxJchvrd ONTvzKHLyk2lsRHfXSeF4cp5Aiqi9y6co7PbbTfDu2BgWvl+wMR7DM9kBWDEn0S7RECtCu2yDu0i 8jYveCBaLMaV/F0OTp4+IeaJMLJOWHkXgGnq2vyKzTTGReNCv5GeuLCJjSAtxhQ77Vx44bLHSi+T pOEabHzAmK39fuL2OToerjb7hZfJpTApbAQ2dQ3S8tfRb2d9BhXctVDBtd9AnSQGdZJ59nOWv7nO OVm2awxzyg5rThHMpIbBdvomxv4ClOcxxqWhvWsdeyh6Rsk+MErMfhpu7aeG5kpjPHWptcJ+WZvX ftlDqOaGqk2wxFrjzC7TmDnyvXNCeiSUY6GFK9rGkZqpa6eanTX09aVod4yV0QvHqKXKXof420Ud y8oPdVPl5kp8c+jn8UcUOfF9arcYZj7VUtf4Apfm8DYXxWFE4+Vd8Ewoxpm79Mu6DXRefEzi8o4x z6IPmyXx/FfGDC9T0RPTfrwHO2mtlp00O6y8+w7VK4csdjgzWGwk+JcRYARmDALMYJkxTZlWRdTT /bQSWJviCVt1yJXIclM5Sy5c1NfqSb60i6HG8N7b7m6F/rTmZNUbPdWzsilNHlXjbhNuJHuKVrpP pHVE6uA15oR0JZmuQccQ6tfmPTnW0U8Zpmz8vXFdCyHPhhtxhYekb9yopve2B7g6tuKs86g+ubNx n76536lPG3Ga2w233q6dHk1ETtF3V9XJiJYnBzsg0KMD3BC3wJV21I4YrqTS4kfw6CCNN+uMzcYG 5aLeTur/hU2ZONxuiw2dcrmZScoL9TYT47hqupT3OJmF3YbTKeK5JD2y7MMpskj7tbopSUvkXt04 pcglpVpCivTm6yTfjjc9mKzHuv0qlU40RerBCYPb7iAjy4/PVEOqTfE+JRNp77JqV0GpEd5bDkvv LTbxtOYBjG1dGNsKRCIN48Cm5f1Nq629iQKeJUM0IIIarI53ymZajRJ4r25sA+oaroYEBmyHROzN MIg1DMP+CJhTzhWQ1nnv3MBdb+TnOEjInRmV05yTdnl1UmhgaEC666Al3eVUzXcjxv5ejP3eFzEa 2vwqnXQYTmAYIkrUieZndNiv7sAI8UHFCLFomxi8ucm0mjHcxdC3Kfl/dfMGudze+9OYISXUFL1J YaeeGYwvBgF4vhuH5zu7Oz2rPqytXuYMluhRGKJvdK8tfDaLrLyYwaIFnQMZAUbgeUaAGSzPc+tl V/aR/uN0vGqnshgRdEqoqusoJAGIehzpAQRD2qFLiPZGeqh21VZPhlgQwIXuInpAZyEe3+d5u2Vw hCoV46hCVeTk21vlibAVf/2Jfiqdf4taq017JiLY61XGQzq9x9gtOjl/pSUJkSQJpDY6rrW4JB2M 2JAQuNN1hHq2t3mwEm83Uv3gfiovlyovIvRx3z5IitinxyJEf+WlfhbpOwc2aBe54dZBatqr2CcB Hj3AQxgAFJfYHHz9tiivKdlihrr/uzZ27leuJ32fElHQr060U2VtsD0K14mwQnV9102q2Sq9vSiv jNvEww+pb7v0GiHfV6JtfoK2EZIc/msErpl7KhTJBCVKaWsv1TZv9DFXjCiiP5w4Qgcd6QAlIW6F m+mqzcHldcfO4gkSHQPNTXS6071oDVVso7KtNbRmA6SSvKfhWfThLEqmTZIxgwUMoZNgag5pqbkD G278jsrCuW9OI3tXUvshyZRz5QJmXznstYjNWymklVJd947WUWujaVBa9Pv6y/1UvlrvblVVj0tF 11A1eQgpLkhrOBfaNXKijdobdd8uyt26g8pR7jcCbB4IOiP9RzAPqFKLIhRpm79Da6r/nJaH1bL7 N8Mitv/ybjL9MTIJmbh2HOp+O9NK4lYXhAoKNu9dyuY9GREhkdm02xorrY3tYySIehi+Dg24b95z aJfLlo/xTmFYCAmbRQ9/RhdPHKMhh/FbQuuRbt32Glrg/VYd4pnd5Dbn5N6uhgoo5vXrvmJX0pau H9KfbA4e+yGmRtf3bqWOQ+4xjcIt1HZhP6Q8fEStAHiM626jVqF+5LnCkOqqPbANXuU8L8QjxtCh A010ssOTnxF1IwlppTLY3dFdE8OX6O93r6XzFzRvq+FmuqMFUq7ud9d3r6QOx2Mj6F+ooU86qqVk jxW96sSgZo58Rn3YXQXrKXMGi2BKncQhyJBNr66Tjh3dpp1bmcFig8S/jAAjMGMQYAbLjGnKzCpi ixWLVIUQ6xbqIp4T+8wIph9bqO08gVh3gVCXgRqRLXqdPoUpjgmsJsY+pScQjxeqFwVFr1CRUH/i y40A2lSoGcTG4wgvhIqShVM6/QoYPx6+S58XYYU6FqO5ry/zMwvcuTlPEw8f0GOkEVdBYTG99roi 7u/E8t+IfhgbGzXVBKCytQCuROems+kxvp0H6BNxSmSYp78UWYSI/hgDxsB1diG+H91Gwkv2GfTh jBks3jI/j89x9Al8B5RCtS5vVTP64qdmPwTRgnlQ7dPYl0iWnzDi+rkoM74BQ+Uzne81GcEZ8C6B MawAbWjMicAmARXYz2HoVrRtUowVBotPksfAeAaAE1CFiTHM6xiGxXiUFCNN+sTYAxp5aI3h84pp EcbwtC6ox44MP6DZxcX0+SjmjdASrX0VHy2hVhvF+I/vVVwF85fQojRV20x7VzH0BXOeK1qMPBUX 1L68dAHoTxNm1jRbUeXVRc02LOs+rM0wCwaLRUeUQ1wFtjq5Fa7+MINFRYPvGQFGYEYgwAyWGdGM XAlGgBFgBKYVAiqDJXuPN9OqSlwYRiA5AjD+ehLSnEOI1XAbXp6WJo/ObxmB5wUB28GBzp5OrnVg BkuuCHJ6RoARmHYIMINl2jUJF4gRYAQYgeceAZXBQtXt1FCFU+nCJfTNqrdSu1N+7mvPFXjhEIg9 oDtQvz1Ya6pthVthDFUYZoaUhJCQWJ6GmtkLhxlXeHojMHqLrvRDhRJSSR931NFQBMVV7RXlqfTM YMkTkEyGEWAEpg8CzGCZPm3BJWEEGAFGYKYgkLh9imrDdb7qtI1/4fFq44vCAYzAc4fA9c0vUUeg zZcSavN5c3ruqsgFfsEQGDm6kt5r9Nio8noDzAMmzGDJA4hMghFgBKYXAsxgmV7twaVhBBgBRmBm IAAXyDduGfaWnPoUhugNl/FU5w3fMALPNQLC2OvZrlsaO06f0kThu1TTCm9zbN/muW7jF67wcFd/ 70bUkGAx6g5zKnOWlphu4fMIBjNY8ggmk2IEGIHpgQAzWKZHO3ApGAFGgBFgBBgBRoARYAQYgRcJ AWawvEitzXVlBF4QBKYLg4V+/7cvCOJcTUaAEWAEGAFGgBFgBBgBRoARYAQYAUaAEZhxCDCDZcY1 KVeIEWAEGAFGgBFgBBgBRoARYAQYAUaAEWAEphoBZrBMNeKcHyPACDACjAAjwAgwAowAI8AIMAKM ACPACMw4BJjBMuOalCvECDACjAAjwAgwAowAI8AIMAKMACPACDACU40AM1imGnHOjxFgBBgBRoAR YAQYAUaAEWAEGAFGgBFgBGYcAsxgmXFNyhViBBgBRoARYAQYAUaAEWAEGAFGgBFgBBiBqUaAGSxT jTjnxwgwAowAI8AIMAKMACPACDACjAAjwAgwAjMOAWawzLgm5QoxAowAI8AIMAKMACPACDACjAAj wAgwAozAVCPADJapRpzzYwQYAUaAEWAEGAFGgBFgBBgBRoARYAQYgRmHADNYZlyTcoUYAUaAEWAE GAFGgBFgBBgBRoARYAQYAUZgqhFgBstUI875MQKMACPACDACjAAjwAgwAowAI8AIMAKMwIxDgBks M65JuUKMACPACDACjAAjwAgwAowAI8AIMAKMACMw1Qgwg2WqEef8GAFGgBFgBBgBRoARYAQYAUaA EWAEGAFGYMYhwAyWGdekXCFGgBFgBBgBRoARYAQYAUaAEWAEGAFGgBGYagSYwTLViHN+jAAjwAgw AowAI8AIMAKMACPACDACjAAjMOMQYAbLjGtSrhAjwAgwAowAI8AIMAKMACPACDACjAAjwAhMNQLM YJlqxDk/RoARYAQYAUaAEWAEGAFGgBFgBBgBRoARmHEIMINlxjUpV4gRYAQYAUaAEWAEGAFGgBFg BBgBRoARYASmGgFmsEw14pwfI8AIMAKMACPACDACjAAjwAgwAowAI8AIzDgEmMEy45qUK8QIMAKM ACPACDACjAAjwAgwAowAI8AIMAJTjQAzWKYacc6PEWAEGAFGgBFgBBgBRoARYAQYAUaAEWAEZhwC zGCZcU3KFWIEGAFGgBFgBBgBRoARYAQYAUaAEWAEGIGpRoAZLFONOOfHCDACjAAjwAgwAowAI8AI MAKMACPACDACMw4BZrDMuCblCjECjAAjwAgwAowAI8AIMAKMACPACDACjMBUI8AMlqlGnPNjBBgB RoARYAQYAUaAEWAEGAFGgBFgBBiBGYcAM1hmXJNyhRgBRoARYAQYAUaAEWAEGAFGgBFgBBgBRmCq EWAGy1QjzvkxAowAI8AIMAKMACPACDACjAAjwAgwAozAjEOAGSwzrkm5QowAI8AIMAKMACPACDAC jAAjwAgwAowAIzDVCEwXBkvPf/39VFed82MEGIEsEah56f0sU3IyRoARYAQYAUaAEWAEGAFGgBFg BGYoAsxgmaENy9ViBCYRAWawTCK4TJoRYAQYAUaAEWAEGAFGgBFgBJ5PBJjB8ny2G5eaEXiWCDCD 5Vmiz3kzAowAI8AIMAKMACPACDACjMC0RIAZLNOyWbhQjMC0RoAZLNO6ebhwjAAjwAgwAowAI8AI MAKMACPwLBBgBsuzQJ3zZASebwSYwfKctt9Tq9yzntPyPw/FjqOQhc9DQbmMjAAjwAgwAowAI8AI MAJ5R4AZLAGQPo1T4mkhFfBC2QQIeMRGP3XAmlu8kAp4k+bg8aLdTCqDZfwJPYolHEhfLvoyFc1z HqfdTTz2r/Ro9DOiWbOosLCAXp6P8k7HcePhLfrSH/6tgd/pX/+Eal4vmHZYagv0NAF8/5Vi4+Bb zCqgwnkFtLB4jjZqtoEx0P/MZj7ZRArn0ML5mWE0sGs7rf8bEKj/Hv3+b0tsSvw7HRBAP4obbYw+ lOn3iXRxpBf9j3jemw6tyWVgBBgBRoARYASmLwLMYJFtk8AGZOjEMeo6dEoGUiVt6d1P66pKKLOl tkJimt8mYjH6HEeus7HqDGIojXRX03u155ya1N54QuvCma5SneR8M5kIgBlGsya3bSaPwZKgnje/ T1siCkDf2kafnf/mtBMKeHTjFu3767+lD36mlNW67fzVj+k7YQ0TwN7EP4NN2qOLP6Ov/Pd/b5Tw O/93K3X+RbG/4PkMybWu8X+lcz8ZpG//5UV/qb71F/Tp+TIq8r/JPERhPLkSh/+CPvtVWfr97um/ Utvsv6S9BpEy+vjzv6Blz6CdXXXgByCQoEs/OUN/+r9dcdAoqd9Mp4+U07JkjNunT+jSf7hCx/7m p3ROGY82/tVf0IG/Kkue1smJbxgBRoARYAQYAUbghUNgOjFY7h1tovO3P6W5Aa0wd/4S+urqSgpX lNDcPC9cH/e3UWPVvoCcEVzXTV0namYOk+VpjO6cOUY9tfsoqtY6XEmlxQN0/YK7zrGhI7RjbZMT sz7yhMpXTO4m3smMb9JHYLiHtqzYSlSN/npm8vrr5DFYiAZa2mj9//4vss7TkMESv/0RvfzfqYxY WVxxtxEMjJ96GRhPR6ludit9QM9m8x279jN6ZY3JYGn5//4POrDuy+5C5/Mp57qC0bYejDYN88os ZgkYGN/LDwNj/F+o7r9pQ7t4rk1g7P0/mTD2ntCRl35Iuw0yf0affPEtWughyY9TjUCCzu36Pn1b SBX5rnX08ZNv0zLdNPZ0jPbO3kttvjR2QAn96nffo5K8cPhsmvzLCDACjAAjwAgwAjMCgenDYPmM hlbNoZPKSVEwwCXUePsKlS7VrYyCUwW/idOVDXPouGAq4NrUfYXKN0BiZfwuXaxbSWet8KoLI7Rp 7QxYMo/dop7ilXTerG7w/wps0vvVTXrcaSNmsATD9izfJMBgqRUMFl/b5bdUk8lgsUt69+/+jr7x P+PUeRoyWC7tb6M//WvBBPoD6rz6Pdqyaj4VClWWMaiyxIiWrMCzXRH7F0yHb4PBco6wOXuCzZkv gh1xkn7HR6nnP/yGPo0X0Lv/yzcn9wQ+17qO/RO9+drf0C1AUfKDbfTTfSW0BKpB8XFLHWv+v6El GarvpERVSNyAcR+PXKGX3/w7TASZMliI7g59RJf+8xN65b9dSjXlkywhlLJCHOHRP/y/9JU/GzCA KPmrbXT+Byto9D8N0pvfNsPoBzvp90dW+ICKD6MPfAN9ANdGpNv7v67A95KggZ/8HX37r2+b8QPS mi/5PyPACDACjAAjwAi8sAhMHwbL7yk2fItGIj10cOsRoz3Wn+ilP34dR0Ri4RsfpY+7j1Bfr1hy i6uFjsX3U1FeJFkk42DT4AhVlStMlPgtOjlvJQ2JLCdZKkBkMelX/C7qs9ysDzIrPdRLtds3GjYu ErEHFIEUUUerpQrkqy8YUZvBiOqFiQGWYJn0psomA2awZINa5ml6/sfttOUsUeX/2ULnv/8H6RFw pDogfQEGi/bkPD1K0z9WrnUd/oi+9A0hIbQCzKidU8qMiiPvl0Xe05CxN/0bfjqV8Akde/OHtFMc 2oS/TZ/8ap0jUXS1/SiV/aVglKygK7/bSWuwzPBeDyL/QvHiYlpWXKC8As31oCkkq7h/KLjwLSPA CDACjAAjwAg4CEwnBotRqKcP6GTh1wwGQMPtL6hsqVNU4+bO4Q10sFmcPlVS61g/vaFZGLlTpPc0 cf8WPR4vplBYYa5YSa9vfok6wFSYbKmA9EqaW6x7B1ZSa6vJpKrqvUObqpZ5CEomimBidYCJtcBh Ysl3DZHf0dfHBqjv8BEaumCcM1N56y7atLsm2MBn/BHdufAz+vjCAEVvgJkTMcsRqt5FlY0NVLZ6 iacsRNG+U/Tx/ThUs2BEdPG7tKaiCEyg43S175KRPlSxjSp3t1BZuT+tSiwWQfzBWxSLx2l20UKo mr1Dy9HWd7qO0T/HXkbUz2jO0kpILnnwGLtLV7pO0dUzR5CfRRFqVFXbG2jd5spg46vjqGtfD9L1 UFTgE4bBy+IlVFpRSbNHB+j0IaI90V5avlgtZe73iduQYAlnJ8GSGL1LH3WjzEMDMGhslqWouISW b66hNdXvuto1nxIsj27/E/3iF/+FHsSewvjky7Rw6R9S5bf+iD79h5/SH30b9jc8G5nY7duwe/LI MCgr7CvE41+mmh98kxain969+BF90AkpgrO3If3wB7TxB2V04N95bS0kIGlwmwYu3qZLkf9Cj7BZ ukX/QiVooy1N62jH//RHfukTAQekJ+7eRz8sFGoHbbQX6Sr/3ffo8CaMGYIJbF1Fi4tpoW5cApP4 23OmWIIFDfnByf9McRjfNS8Tr43f/yYtSUOCJoa2+eDfD9Hpv7llSJMIGiXfKqMd28tpy//wB3qc RKQs6/poeJRiIvndW5AyEOpMK+inH1W7mVGzXqZlS78scpmUK1MGy91/uEIDw0+s/oiyxxO0sLQE EizzU5bvUeSfqOfvPqLT6P+3ML6UhCH99M6bVLl0Fg38Xz+l+J//gM7v+7cOHScvhMSL/pB21P9b ig//Cw38p98YhpbjhbNoyetfo3fW/REtTGZfxKGY4ub/Z+9toOO6qjzfnV4Jy6Y9tEyHXhaEfjaT zMQhzXK5ExZJ4I0xZBpXQgPluIfIhGYiiy+H7rjlAO0yTZ4j0+DInTwjA1FKkHYoJasTKWAihXaQ yKxpOTwHSnlOKGXGeXJW2yl5YXdXNXGoeshv7tvn3ns+7ld9Slap/C8vuW7dez72+Z2Pe8++++zD fmWGv32EjvMIvET0NXojlV6ZpJ33CeXE26n3h53UseoM7f3SD2nvU45FV0/6k5S81VU6GvFJcHnf uyl+6b/QwLef5jJzm+Iyxzd9hLp3f5DWXy7baAWZqr18iq2g3upYQQWWxBkWUoFrFdKfevABuuoz PKb7xqUK0XAZBEAABEAABEDgQiHQfAoWtrBY4lhYhFpJvMw+Jq7kCSR/Qq/PdcWd0/LQlscp/Z3E XOdw/tI7M07JFR90fK4ErFO0GK8/s5s+/UH2R8Nh+tmPh/aJoxUsOrT/qJv2nL2X3uafvLHibJAV Z+WWJa25/xd01x2siJCfc5OUXPLHXh8x8prv+9rv/ILu3GLEldfZYmf0lndS2l3mJU+Hf/fRQ+c+ r/zsvProV+iLn9gdHtQ92/WzV2ndNT6l3CnmfJnLuUzsOWu/J0cpufLm6jh9fYLu3H5dQKpjqbvo 7s86lmOBi7KsbN21zrXumhMFCy9Z2dt5N21nS5DgR0zQxISNP76JzNQ3d9NVf+leswPcQJncBjrc udN5s2yf0//FH7ibRrr0cg2104sO4j0KdaBaySeIkYTpHJV9Oex+907ayRPJip8NH6fcD9fZiqKK YasMUHr+GV7u8mggdF/mm7R1TbkJ7W9oOPld2vi37nKIQArixI008auNdL3UIzRaVmW1EpqZ52Tf UZb/6nLye4LX9KM2Bcss7f+dL9Ad/hzMNuC/5v7Wy8wiAojTZttXy67KhDcu9f5jD3XfKCvHuFDD YelFbj/vCrafSkn0HP47Sr6HlTG8lHfpux6uFNy+nuI22Vm2TVaVjAqk6pEVQWO5JK3XQwCH+Tfa u/ZLtJ37ZYLHhyFjfFAJhB2YvlnqWEIWliTOgQAIgAAIgAAItBiBZlawBCxY2DHrxB1vpm+lRCXE affZJ2mlfyI/x/Xz6qN38STbmXgudh8syrqBGW3+p3+l+Hvawmmdm6GJr/8dnV6ZoI9+wpyMBxUs mx56ktZcTvR8z83KV821D/2S7vyEzxKEFVX3suLMnmeuuZ26dnbQFVevotlXnqXHPvQJ5zz7pthx 6hf0TmNOcPpno2x5MkwP3S2WCwgFCr85/FCS7tqeoEvYEuRrn2BFkP0Js2iaoR9c/DbS83e2PPn6 +zneT+mx+901+G5suuUe2vHl222rFnGq8ORXaOtHpXIlxn557mUrmbX8/naGso9/l+6/Uysj7uS3 19derhviL7f/Dn3tfpFKnLp+fC9d+95V9IZSnl79pyfowY/eoRQhc6VgmX3xu2y1skVkWPkT4pvl lb5bKHmn3iFq00M/oWvXrabfZSuEXz66m74ll4xx6p/62b/Sjde0UcMKFp4sbmd/JJri1ZT8xtXU XvoXuuOrvl1jzEkmy1B6eZqGnz3DB/9CvZ/5obKskIVP/PVGircVacuXnDpOpHkCdaucXZmKkrdT zwNxir+PLTE4rXTyPtrNVini0zP+DUqu81pJTD0yRFdtfpqtDN7Ob961gkf8Vh8+v/b//CKlvvAO 5xQzvImtVnytTQX3Hsyh41aZ8NkzNPzE/2DLA1ZGGLxSrKDoLKOg8CqhbqD0+Dp6/9W/T3TmFA3f 9wjd8aAsPzsK/S07ChVWbo2WlRVu2/930SbeTjHmyD3d+TBfU3U6+fwfsmLnNq3YkeHm6FtNzH3t Lir5489M0vixWVrKFiPHn3madgo2lSbfp16ki97aZycZ23Ybpe9iHzNtl1D+JPO994Dm60vn+M+E 5dUE9xFFxxGLra+SH2unU0+M0oA9yDqnkz9kZ8Yf9rbjqHKEnueddA7/6EX66Y/dcnGgOPsk6b7m 3+gDG4d0FLbqG/nGChr4k++yjyH+qG2qOf4THP9Rjv8Yc1nD11i+OO/E0y3kfepp2izLsubjlM+s m5udoTib40+4FnDCqfRveEcnPUTzVR4H/gs7URY3ByUrH4d+2OLt59M0NTVDA3/+qNuX307pzDbq CNspLDQNnAQBEAABEAABELhgCDSzguXaO++lNVcupdwPeHqyZjX98ut71eR0zf0TbO1gTv7nvspe //m36NPvke8m72GfL8k58vky97JWk+Krj25hZZGz88mdr/wvuvayamKZYUwFS4LuPvU4XaGUIQUa vebNlBYP9yGTeJHK7KkZev3i5dR2qedJl4gVJcnLHAuMUKWDYbW05u6f0F071yuhXv/5d7mOHOVC F28dvc7YOrrwg7to6y3OFP7ar/+Etm5fr6xTZk89Sw9ddoPyRfP5l3g5GiuK7A/73bmf/e48Z//o pt2Fe2klT57Mj6ms8vrm0YwCFjkigTPP0v0rbrDTnsutrl9ntjzFo9dfHKAvfkjs9nQ77T7ZS23n eEmL8blkRbt3By62ttnM1jbOh+OcStFKVafO2dd/PsiMHasxIu4H55L0+d/pN1Kt/XDym3209i9f tCPG/487KP3XV+u+VTpD+/+crVGkZixqoqv8fMj82aLin/+Urr/MtWwo/YaOn5mlVZf5Jpi81Od4 4RI+799G+d9o5+98yd45xG/1InNwvvXkrJq33yV2fJsvcUxWINxx1X32BDR99Bu8VIIXpp0zUl72 e+FLi4wgDR0avMopWDw7JHXdTvkH3h2Y9Eplk5DH3DFprsqqlBysWjnf/mpU3lHtrkwlHH/kYXrH 5gmv5UlIeM2Yfcz8ln3MCAWV8Tn8zQfohr9kJUqYJczL7J/mPzjjuIjSN95DW43lSMefmaB3rH/Y TW1uHCqrchkKn0mWca2QUfjJ+TWXgcfIKMfUKj6H7uEdrJLGDlY6nbmR1S04y8JLef5cyBfWhmZp gLeD3yLuVxXq2XR4KxVE9I0kWXcZilWZKb5BAARAAARAAARAoJkVLGVr587Hqb83YSxfKRu69osv 86T/Srnsgi0rTrJlhXwJXntqTRHj1e+zguVT4sH8dtpTStHbfA/1lYXUyoNrv8NWKlu8Vioq/cjl RyV6lf17PPck+2A5WbCz+922VfQWVvQ8drejCAlTsCjHrZRgq6XHvVZLbBlzP1vGCGWIN66W1asA MUoptzT2xTWVJ2t46dFdn1pNs2KCbHwuuThPjy17G/3APmfKZeTL8nY9/nlaeeUqamtbTpcw7ze0 tbF5zBS9wn5l3nrN3G83TrJMkXVgFIIPT7PS7U5X6VZO4fNKiq1cPutYuQjO/e864E2oll/GRJ94 WUx+JOSttScM7+YyErJdrhlmzUdo+sgGWlVlmxZ+X0b5zfroi2ccydveSKsvu5Qmv/pD+w11ecVJ bQoWhUbJW8M2zWd/QzOFWZVE2YMlb6T2cjvrqPyJyilYlI8Jzqwv83e09UrevcdUBAkhzk7TUvZv YX/CJqgqrxrK6qRm/6+UHKGTYyOge6gUO8FLgTNL234v2ncSh1Z5h5UrkJr3RJSCwRvKyIMvONYc f0irVryJlgtfORdfYst3/EX2R7Ps9yl2uVcRqOTjuN1sodIbYqFi7p5j+hgpnPw34c2qqs/yFb9H 7NLF/shymco0ec5UUEyxgumqEAWTDnsb9+UbvL571NKwoCKkkXpVeYa2od/Qbt5Se6coXaV65mVB A196ikZP/jMN21Y4rFhhC6vEA0leWgQli9NC8D8IgAAIgAAIgIAi0MwKlmu/8xPa9F72b2E/3Jeo 8PIU/d+pT9DIj13x2SfKQ+wTxX1frcrU8MHJcbp35QfdZSt6WUTD6S5wAq9+/xZWsDiT5DvZYuPa y2sVSCsPvMoMJx2lYAmxYBFKi7vZ+eorFbIMS9dUsOxhBcvbPAYwBXr65jfTQ9wmvHG1rKFLlmw5 9BIiM65p6VNBXPeyqWAhev1ne+nT7xVWJFGfOG3+fpKd5F43521XsQqpgzBpVJ1VUroZVkSfZwXL /gYVLM52xTxBHOqh3o/5TGZcQdVEP2oCpCbx0TuBBMrMViQ7eRnKbvHmusxnfhUswYlklChTD/ax Q03H0icqjDofZu2gLvKB4lVOwcLKo8/w0okHzYgVjsPqR+VVfVnNXLQSoZr4hjWCmUjEcYx3fsqU 2flJ5R1Wrog05Wk1qa8YV/sAkXH93/GujZT8yjptkeUGUPIJxcFveTeqMKXiuRN00xt228pCZY1V 4nNvdM758wr7bfrpkeUy+4U8Zy6HUrL5yh8WVuVZYLneLOTy13Vj9aryDKQrctZKUlN+JVPUwZkT tPM/73bHjzDfLlERcR4EQAAEQAAEQOCCIdDMCpaADxa7Vkr03PYb6P77hemvd2I7F5U2+9Iw3X31 LUoRsOnHvG3zB1nJ0wKf2efZV8c1W+ySbPrJv9JH17E1RU0frbQwFRIyCTVZ90/u2afLY0uktQdv Df3lPrrxo++nt13WRrO8y8mvfj5Kg5/6is08LF2lNOD6DipYomTS58OsbWyZDce7Zr6vsrXGF11r DRFuJf+9wn+Bzxo+IybqH7qX9v+gWy9x4VOvPz9Mg1tuoWfKTeR5uVPaWO4USL+OE4pVlRYsqs6I nROX2Dlx2GRNyPHyMDuXvsWW6PMvsoLlqrmxYJHOMMOKqpYV+CZrKmwdk3iPb5FNcRr6XIwtBN7E PliKdPz4P9Ne14eEOZFU+akDPTkrH05FcA7qkFcpmXxJhf6cKwXLTaxgcX3RiJ1ilLNhX6auRyTe Scm7040drI6ymsmriXro5NgMKY65Pjwy+697f1faWlvlHdXuvMl5fqlJfTVxxQ479x2kjV/iJUWR H57E/4odtBo6SCWf8C3yW/YtEtZn2cLoojftsVNVbbQmHznCekk7QpblUmlxyvKcaQGiZPOVPyys KnJkW2msXvUyLF569OvP2EuYVJ70Gxrg7Za3cDs3y6SvlzlSFjflFJVl4uMSCIAACIAACIBAaxNo ZgWLOek1a0H71gibcLsheRnGc4+P0ukC0Rsvi9G1t6z3+p4wE3SPX3+efU1c8wl15VP/9Crd+J7a lCunfzZMz/3TcU5jOf1vNyfonVe2qfQW/MCYJNOHUtT/5O01LrHSSouwulGTdZ+CRU36GcBm3okm 7u5Eo3nw1twXO1tzh6Wr44fVd5RM+nxwu2kn59efYUuTDzqWJma+pu8dj28WLXDZowIrjH55qp3e fTNPQc8W6PWzrlH+OWGF9Swd3s5WWLbihZdqneWlWh6LnLJJV7yoWH2oj+v38xXrVyuTgg6GzczU zlJ8Uvi66V/bgIKFJ3rOdsW8PIJ9GYyE+jLQSgxzAmfKpC0y/G++PaH0DyPfxDe20dBd/1Ffc4+G P/NZ2sjWG+UnXVq28uF8yauJJPus+Ff2WVHF0CC2SU7/9AxvAexLK+Tn0pX/njpuLLOOUeVffmI4 eS/7x/mSsJq5kabZgW21y648Iqm8qi+rGV9N1KtSsPBk/0e8NfepWe/SEzNBecxL/Va9P0brr/Yu u5GXxbfK26ckMMNEHZdVJJiR2Pnw6I+mqZ1libHypFD4DRVZNmJlSanwa3qWy7P5S46zZ3NZjkhC ycfHQ//8HUpcJs76PsYWxaqNssPa8Ucm6bjIp9KndAldf9u7abXbRmW5VFocX54z+6eSzccuLKwS QbWVYD9uqF4NXzV9R1hZdI1h62pY83SyE+yUcoKtpIo+YHmlBV65pXbRCeAKCIAACIAACIBASxNo ZgWLeFN+w5XBmcUvd/4xfe3rZSxYDMsEVXkVtlh+na07Pu1adwineJ9/foJuuFrmXaJX2G/I65dd p3aZUekaB4Un2anqR/W+KOJSfc5kjUTn9JCVDp99o7sLE9E69i/SFbq1Me8i1PMFGn1+NXU9eo/h 4FUrLUyFhBRRKVh81hNq0h+x89OrP+DtkG/ZbScTWudqeQorWEq8RMj3xnbi479D33qcyB/XVArQ h+6h3aluWrnCqdNXf/ItdgZ7hxTdu7xI5ceX73yS0r1xFc5zwLtavfp8hgq0it55zSr3UomeueaN 9CArUG56/P+hjo/K8zrmK71/TMkvl2m/OmjNR5p1uHXXbGGGfnWyRH/AfmGETxjTqklsQx665I79 3Ayynxtni23evavwJO14UwNObs2tTtlCYuh/fpESlxuTHy71zNNP0Vv/5IdO+Q3Hmh4gamJW5k2+ GUGF57fz/gkXhyu9NEkbr3rA8cHy97zz0G3RyorB//JZewcS/+TXzC5wbEzMQrcZFk55X/41LVm5 gtrZYeicf4zyp7PfpA72rRL2UZZDfLHcEi4q/BvvpnSK6DLe5cfnJ0Qov+QktK6yKiuBKus2rCD1 npN5R7W7MukqRUKFuHr74gglFi/xuYiX+IiPWuLj5quUGOL3mo2UO3Kjd2tvtozZ/5EvqS3L50IJ IMtltnd5zlxio2TzlV+1Kd95u0iqXZZZ8uSWvaYv5rDzDY7Tatp2B1l7r1bRTR81oUoqVnjN8ALO dt7Zyf8x48711tL+vPAbBEAABEAABEBgERJoKgULv+0vnMzQQ1d/0HZaetPjv6CPvHcFzQofLOLt /8kpyj70FUqnxOSUP2vYCuPnIVYYvFPLvbxTi20k4ITk/8s4dj3Lu8a0yV1jOChbd+y+e7VrebCU Ztny497PsuKE83uI8ws+cjmZHOu9me7+sndD1nXf/yV1fdzrDFaJtBAHJ0dp88qbVc4r70xR150J ehvv7PPbwnF6hbdElst1RKBPsb+NG11F0+tnpui/feqdlP6xsGJ4lXfdYcety1wlFNfdL7+zhb72 Zfbxwktm9qQ66W0rnNefetLPy2229FHX3R30Nr5UeDlDz/XdpeuT81v3/V9Qx4dW0e8u4wBCkVJi x7g/3u0qYOJ014vfp3de3mYrB0SbeP3McfpvWxyZNv/4l/Sf3sPbC6vJaYGeYf8sD7K86sPbmdLz bvtRJ6P9t4gggtHnt7PMQjnDbamImP8AAEAASURBVFFwyD4+yFs1OxMgoZDbffYXrvNdrYQScTdx eW78KDuzdTHNctwRZviYLVOSd6a6x7O0SMRp6GMoh8TOSV13rKc3sCLoVy8dpudSX6HH3L6zjpU/ XbbyhxVCN7NCSDK6pY9233+7UkQVXhylx9bcrHZbkjsjNbpN88yPhuitH3He0Ivy9qS/SLez9cXS c7+m8Yef9i2bYBP/X93Ob/qdnqccXxq78gzxrjxiGYXYlWfpsjfazjmXLPP1VGPST7y8YuTon9J6 VgyUeOvh0UeeYYuBCY2ed8/J8bbRy9207AtsATDzyizRsiINdt5N23l5QeyvP0Mj297B7VRHNZ2D 6rN8pCaSfLxhI2XT6+ytY2de4fwfe4a2fNXNv+K2sZ5Uo38Iedmqw/6IvsTL8eQuRp3pJPXe+CbH aoIveRy/mnLyte4HtlH3rf/RUfqcm6WZl0/Q8IOjdMd9wspFfD5Oxf+1zms9YqZRQ1kLpxwnrIUX jtBVfzLEabMC7ugddJ0zlNi5USVnvk6o6v/3cLqECi9MuHnfQJncRlrBZZYff92WWN68uD+JD/fx qe89Sh/4khhfbuS4G4y4PFk3dq1SiggRb8NHKPPAf6KYus7bAv/oJ3TVRxwFo9+RrSeuiM/jT/of 19HKf/dGWlqaoZ717lbJ4tKGEKey4nwNnxLvunX422657H4RsxUPSsEi65eVEUo2ce7vuX1znxXx R/+2jzb+LW/TbJy3RShxe3pl2m2XV9NI9jbuk9q5bg1ihgY1dytL/rCHt6y+lLd5f5Gu/w99zjbg YVtDG+NEjP3g9H7h3XT9lSwTL0WbfOoZWvsR0S7FJ2zpkXMF/4MACIAACIAACFzABJpGwfL/ZulB fkv+TNV1Eedtgp80tgk2IvI2u/fyNrvPG6eI7qX+c92hSyb0MglPhOAP39IXf4BX+m6m5J1eBUt9 vk78Kc/tb/9SqKjU1/AE/c7tztbGpoNcHZ6tGc4+SSsv1jv56Gvsa+Uh3mnoE0K5ZGzhbAYoc2zv aHP1DFtO/HvXckIHXnn/L2j3HTEqK5Or0CBWLjx39yfo/q9760Wkdu0tMV5G5ihbAhY5rHQbZKWb Y7Wh8w49uvP79FBvh6t48ypYZPiVH0rQW+g4PfdjrdyZH+Ubs76Yt8uWGUd8e6x9qi3rlu9T/3c6 7D7UqILF9ptRjTPVNc6OHaIYtiXE5f/Cjjrvtq1MIormnualKb/hZTiyHbhnD9+7m274Ek/0qvyY DlGH2Wplo9w6ukx8v8WBGbSa/GtesmBmoI71MiZ1quyB13qg9PwRWrpWbwVcLmo3L7HoDVliUXNZ jSUd5fKztwUOqdvycaKu1sbJU7dVy+vkbVp/KEWER6y3U2LTpXT8sUln8m9fC1rwhMf1JOT+iLPv kT/1+R4JC1fm3MlJuugPHwgESP3Pb9L65x51tqR2rw7leLlSgbeQvkq3m9TTW2jLjalAfOnfRVqC eQJU8iXkCVzhBytLtr/hbuLXI/YntuFqVpJIxSAvseJy+K3nyLR8KZO8uTtTmWC4BAIgAAIgAAIg cKERaBoFy/+Xp2c+ztYGj5evATFRXfOhDlr3KZ6wKkuFYJxjfVvo7jvlg16Muv7pSVoX4U/l9Z/z 8qD3bAkm4juzkpeL7I5aLiLCnhqnBy/7oFYSbUnR/r7b59ZCwSdT3T/ZkuLpnXfRQ6mg4mHlLfdQ x86t9M6r9Wtj01+JzjNJ97MFxlvIXEKir3r8rZzl/Nj3yEPS+sgNtvKWJH2qp5sueWY7bwOs6+vO lyZ4lyOhrHizvfxHp6qX3px+8it050d3m5dCHc6KALOneGvkF2fodbaIuWRZO/3B1TF6y6XHaZB9 vwglSkDBIiKxcub57+yme++Uj+fipPzEaN3dW2ndLQm6wuNnh2Vmi5BvneJwz8doJU+VXpFR1Ddv 3/zje2jdB+fJson9D41+WVgGeet25Ydupxs+0UHX37w+uE0tl/WXD+2lwc/uDpf3JyzvOi1v4woW AYPfCD/8FK39c6+cYgLd949xav8ZW7J8VSuk0jwZ6lgpzP53kq/WFVl9EGcHoH8a4gB0lsbvFW/j XWsRGYEtm9Lf2kjvv/h/0Fvf/bA861kiM/ngw7T2M754KqQ+SPLWuT0hW+c6IX5Do/cO0U3+/LnM yW+8mzbeyj45LrtEJ9bA0eQ3H6C1f6n5lU2KLQtyP/QtNWGLl/33PG5YqhgprLmaej53AyU+drVt pWBcMQ5rLCvvJrOFd5MZMFIIPaxxS+7QNIyTh5nTDVVy6vnHb1Dyxt9zYhemaeOb95CzL5uRYMRh 7/g3qHudE7fE49vSqx5mGwj+sBJxkrf99X/i226j3q/coPygyOtawcJWMv/8n2jmicO0/3ujvKTT DcFtufeuG2nrre/wWhXJBGr5Pst18qZgnYhlNfFTz9DSdz/qpuZacxRepLV/6FqHsPXRyNQnaXi1 P75eFjia3E03CcsW4xNn/0gjIf6RjCC1HXK72r5+N+2VfOzYb6d0Zht1rInwxcNtf4Db/hZlpWVm yWPFkY9TxzVuOzAv4RgEQAAEQAAEQAAEmkfBYs19ZfBk2l5exB4ihb+J8/WZPeusF1DLZ85XxvXk w0t7Tp+cod9y3Ddc3EZvXNFuLLGpJ8HycYQPkNfPOmEuaZvfvMpLwldP8XKpy8RyqRjddfIXtGZF RAyxPO1UntUBZFupXLJsOf1um880wowq2t3Fus3NMuPflpYwX17SxMsJ2i7Viisz2pwfiyVUBW6L 3PbfsISXVZURWeVtL7vK02/sOmJlVNvyUHnnRsHi5iqWnZz6jfPjYl5KsSJi0qOEnIMD9ncyc8ZZ +iGWFLWF+FqYg1yik+B2UDjLZRbLS5ZcwgqvuVGqRGfYwBWW064fllO0JZtXLfIuprI2gKnWqKWz 7JTXZUrcBwoFbo+CK/v/oLbfo6ghRitYvFZHdlsSQpzHe12tZV648LN0/MVTVFqylB2Pn6P2K1dE 8vXIKMaJV35Np3gpk/gsufT3abVayuUJiR8gAAIgAAIgAAIg4BBoaQULKhkEogiwxcbEHWwdkxIB wnYnioqI84LAnCpYgBQEQKB6AmppUnD5UPWJICQIgAAIgAAIgAAIgMC8EICCZV6wItFmIlCYpB98 WSx9WUV/sCzPryHb6dWv79Y+eny7HjWT6M0qCxQszVozkKuVCRTYwfDo9w7QZndZTU+aHQALR7Js YdF2xTvYGet5sP5qZcAoGwiAAAiAAAiAAAg0SgAKlkYJIn6zE5h98Vv0qTV3hIvJOx7d/3g3vaWa 5TPhKVyQZ6FguSCrHYVeSAK8vfkW9j8U7aMmZDenhZQXeYMACIAACIAACIDAhUgACpYLsdYvsDIL B66PDlL2peM0a7vHWUJtV66mK97zfrri6vYLDMbcFBcKlrnhiFRAoBYChx88SN99ia1V/JHYT87y 966j5G286xY+IAACIAACIAACIAACC0cACpaFY4+cQWCxEoCCZbHWHOQGARAAARAAARAAARAAARCY NwLNomCZtwIiYRAAARAAARAAARAAARAAARAAARAAARBoEQIXWfxpkbKgGCAAAiAAAiAAAiAAAiAA AiAAAiAAAiCwIASgYFkQ7MgUBEAABEAABEAABEAABEAABEAABECglQhAwdJKtYmygAAIgAAIgAAI gAAIgAAIgAAIgAAILAgBKFgWBDsyBQEQAAEQAAEQAAEQAAEQAAEQAAEQaCUCULC0Um2iLCAAAiAA AiAAAiAAAiAAAiAAAiAAAgtCAAqWBcGOTEEABEAABEAABEAABEAABEAABEAABFqJABQsrVSbKAsI gAAIgAAIgAAIgAAIgAAIgAAIgMCCEICCZUGwI1MQAAEQAAEQAAEQAAEQAAEQAAEQAIFWIgAFSyvV JsoCAiAAAiAAAiAAAiAAAiAAAiAAAiCwIASgYFkQ7MgUBEAABEAABEAABEAABEAABEAABECglQhA wdJKtYmygAAIgAAIgAAIgAAIgAAIgAAIgAAILAgBKFgWBDsyBQEQAAEQAAEQAAEQAAEQAAEQAAEQ aCUCULC0Um2iLCAAAiAAAiAAAiAAAiAAAiAAAiAAAgtCAAqWBcGOTEEABEAABEAABEAABEAABEAA BEAABFqJABQsrVSbKAsIgAAIgAAIgAAIgAAIgAAIgAAIgMCCEICCZUGwI1MQAAEQAAEQAAEQAAEQ AAEQAAEQAIFWIgAFSyvVJsoCAiAAAiAAAiAAAiAAAiAAAiAAAiCwIASgYFkQ7MgUBEAABEAABEAA BEAABEAABEAABECglQhAwdJKtYmygAAIgAAIgAAIgAAIgAAIgAAIgAAILAgBKFgWBDsyBQEQAAEQ AAEQAAEQAAEQAAEQAAEQaCUCULC0Um2iLCAAAiAAAiAAAiAAAiAAAiAAAiAAAgtCAAqWBcGOTEEA BEAABEAABEAABEAABEAABEAABFqJABQsrVSbKAsIgAAIgAAIgAAIgAAIgAAIgAAIgMCCEICCZUGw I1MQAAEQAAEQAAEQAAEQAAEQAAEQAIFWIgAFSyvVJsoCAiAAAiAAAiAAAiAAAiAAAiAAAiCwIASg YFkQ7MgUBEAABEAABEAABEAABEAABEAABECglQhAwdJKtYmygAAIgAAIgAAIgAAIgAAIgAAIgAAI LAgBKFgWBDsyBQEQAAEQAAEQAAEQAAEQAAEQAAEQaCUCULC0Um2iLCAAAiAAAiAAAiAAAiAAAiAA AiAAAgtCAAqWBcGOTEEABEAABEAABEAABEAABEAABEAABFqJABQsrVSbKAsIgAAIgAAIgAAIgAAI gAAIgAAIgMCCEICCZUGwI1MQAAEQAAEQAAEQAAEQAAEQAAEQAIFWIgAFSyvV5gVelsLJGSoqBkup /bI29QsHVRA4V6KZU3knYIlo6cp2aru4initFOQcUYk5LLl4CVGNZS+VGBp/6olbN0KWtcQyc660 hEXGBwRAAARAAARAAARAAARAYOEIQMGycOxbJ2d7gsfFqXFCOpcASi8M0NJ3bfEkmZoqUueV8zDr 5EltoeBMpokn4m1t85CHpyT8Q2Q3z9n4Gcb7szTStdovSev9PjtDw9/bTwN/sZtGjdJ17hmie7Yl qL1Cuy69PE53/NkHaGBSRo5R36E0bb2xAjuh0HpliiafPUzDjwzQwFOTlD5apI4/qlzRIs+9O7bT zsdUpkSxTkrvT1LHdaukIPgGARAAARAAARAAARAAARA4jwSgYDmPsCOzOjVO2/9iPxXalocGaVvW RsvbV9N1H1xP62NNNnk6N0VbLrmKBqiTsrMpWl1hMhpawLk4eXKU1r79JjKmm5TiyWpnFZPVqrM/ N0Oj9+2lm7641xclTr0He6j7wzHf+bn5OfXIFrqqgwkPZil1a4VJeyNZvjxMF12xUaWQYAXLUIsr WEovj9L1V3jbjQJgH3RT9rVeWr3Me1b+Kr00SEtXb5Y/Pd/dXF+9EfVVeoHjvSsYr5o2W3h2Ly2/ frsnL/NHfM8Ejdx1vXkKxyAAAiAAAiAAAiAAAiAAAueDgIXPghMoHu2zuK6r+4t1W5nTCy6yFmA2 ayVs2RNWpqhPL9hRMePKQxZPVudOjNMTVmelOupKW/nZuctSppQ90Gm3DVZ4yFPz+F200puctnh+ 8pvHolSRdLY/ofpdfFfays7kreJrOWtoV1ydpx1j4SnN5qykahMxK30kZ+VPZKyemO7LQyfCo+bG e9z0Y1ZcpVFFm+X+ptth3BrK5OwMijMZq3eDzndO2354EXAWBEAABEAABEAABEAABEDAR4B8v/Fz IQgUc9bE+Jg15k6khbKlu3/IGhPn+G/oQK9nEkaxPiu/EHKG5akmfAkrO4f6jLCsqjqn5KlislpV ghyI0+w2JsGJPUNW7jUuLCtTxIS611VI2EqyrqFqU606HBQsVaOqOWC231GkxHb5lSha0UTUGdq2 80e0YrRn3OiR+QnVX2N7JiJlKnIbKgqF3Oy0al+VFCPFo2ml+En5NZpFrXyJ92ci88UFEAABEAAB EAABEAABEACB+SHQ8gqW4kzWSu9JWvENMSsWc/7iGzqt3gNjVq4ZFAJmvRoTrfSUeUEcF62hHTE9 uQqxzqi7rPzGfoyVOJ2CESsSbE4bElbPvpTVu0O84U9YYxFv4i2e1NVtwTKbt8YGe60E56steGJW 546UlTlRoXKEzMNpq3dXj9Wzq9fq609bE1M8yTUYVpqs+glH/c4e0FYOnQfCrEjyVrpLWw+wH41g UqxEG+vvUWUVjOObuq2+4TErcyhtdXd1Wn0Hp4Px+EwjCpbc0TGuw04r7rZ9O9+upJU+lOUWFfbR ioXOQZaH6yhzaMhK7euzeve4nI86VhNhse1zddRr9iC3NZE+59MnvgddBYFIi9umaiNcju59Y3On YMxPWxOHmUWI5dH0oGM5JNq/X5chyjmm+mOP5Scytku2ab4WkraHnepDlZWCxSmpYImFyjR0AVkf eRjiBwiAAAiAAAiAAAiAAAg0AYGWVrBM9HcbE3c9AdaTeZ7QjPunRgtYK5WsL2ZGVHn8yoO6yzoz ZitVTCZhx578WIlhLoMIC6/ObegLnWDm+U28UOaocCHHnRFv4bMHe8vGk2l6ZK63Wg2FDVFv9MQ+ b3D0WbHkM5XLasscSymlR+6gXEJSnpGI1xvWhnn5SqpLTvKj0uhkxZlfzaIVLJJj6PemPmvaH5UZ 11evRavPX/+b0lbuxJiyBPHLMCd1W6FNDCmlWbc1HVCSaE5B6xfmMC7baBWWXZX6vSnnMalgEfVu WM2IMKc1L/bXY8bCMQiAAAiAAAiAAAiAAAiAwHkg0LIKlsw+bXUgJmc9bLGSPZGzcscyVnqX91rf Ed9E5TyAD82i0kTrRLiCpZGyjm2Tk++4lWKrhnyRly3kc1bmYJ9HAeKZ0PIbd9NvhH/y6/3NE0z/ 5NQohwibYN8XmWPsv+I05zvszbd72GvVMT3sVZrF2Rqjb1+v1W34n5D5e2QOBV7FSUMBlQi1XpFp 6Ak3kWG1YEyIbbk2dFtptloZY6uQHqkAkT47WKkgdRZy6YosS7nveECuvJXy8EiwxUrGys3krGxm zOoxlzRR3Mp4mr9ZDtk22Gpkl7AsSXraBFHSq3hopF4Pj1jpA2krtUtajci8xXfMSiprKud8ekqS kvzn9ltbinB+YT5YDMVbaLtQliZkpY9VkLVSvzeL5vH7Qmz1lLH7bO7oiOGbhawo3y9mUjgGARAA ARAAARAAARAAARCYWwKtqWDhSbGekHaGOoXNH9Fvgu0J8dxyrS81Y6KVPuZPgpehbNMWCSNyyU5D ZdWT6fi+EJ8N7NjVWf7DEznfGokiK0NyQmE1NabCpHnpSJ4n8fZ5cU38eSbvokw6T1FH6aOBAJb1 munzxPB/8VrGUOzErRGxJMj4TI9rnxgi7blQsJg+L0KX/hj5y6U8eklJ3uqTyhOWJymXvZhxDiZ1 W92gFSzWbNHhx5zH9rgKQXaimzud9/I94WUgks4dMtKMcLybMfz9eBUI3vqJbeM8TQUZL9lJq6Ux rBxTjne98WqqV4OH5VdIdaU8S/nsdjdTQWFhplfPcV47ShbKHdXXzLSMZT2agQ5QzOi2WLEdGv2+ YliRBfcP2S/1OKcVUimvxkwLhSMQAAEQAAEQAAEQAAEQAIF5JdCSChbtOyGoGDBpZowdRKqa2JiR 5+PYmGgRTyxtJ7eH+M0+++7wWIwYlg6NldWcFCeslPAHMjXNlg55tibh3VR4Yl08nWUfFfyW3Jxk m2VXMrMiJCqMGd6YmNKGlJ2u7exTOPyUf6xc0JY1WlGiFRhcrxFWR1nlN0PHM7Ov9di0ZKjURrR8 rmUHL9mQy6BiYVYQrjBjO9zJccxQsBiCynRDLSWMcM4h++pRS1vYd8hrgQDuiaKVUpYs5jIWs00E fYs4kfNWr1IcudY6DdSrKaHJO7ZjRFn0mGHm9ZgtU/TOQGz5dihiCaFq96aSSUuWP6yXeFVqN8KJ stwZqGJYzqI4NaTaVZiCJTmM5UG6JnAEAiAAAiAAAiAAAiAAAuePQEsqWOSE1N79o9yk33hbXsk6 4bxUiTHRCps4iXPxbSlr2pg0N1rW/GHpK0K/AffmHbd6ByeiJ7pKZnOSXoaWsXTCm09U/lpRossa 5hPDzXOOt2n2WLBUWJailTuOU9Sq47JCKXskY2VPh1tmyHKHWUoESRsKEkMRFwxnWVo5Z1gJGRZG 5RQ6UiZlrdNAvZqyKQVLrIy/GzPCXB77fAuFWnXJ/FS7D1ewqHJUY0llpFVRwWLsUES8vCt9eNpW hOaPTVhJY1lY7+GgZZMUHd8gAAIgAAIgAAIgAAIgAALzQ6DFFSzd5a0qjg2p5Rnz7dOhquozJlqJ HX1Wqj9l797Sx/4nhg5N8HKb4ARcT3TrL2s+M2R1KouECEVHYBtbt0RK5uoULMWjKcVcKFhikfnK 5VB6ByNd1jKTbyWPVsxUxT4qkOFXxN5VJyocnx/ZJtk5CiBzkt1I+5LlrlnB4nO26xdd+7MxrY+0 gqZaBYvYnruRejXlUswqKIfMOHNyzBY4puVKmONabz6aU5gippiR7Tx8ByJPWjW0WZ0uL6/zK/w4 HbmdeJhMnjzxAwRAAARAAARAAARAAARAYM4JtKaCRS39iVljp6OZ5ccNM36fj5HoWPN4xZhoBbdp Ds8322BZc0d4CRI7yhSqm+Jr7N9D+FCx/ahMW5lx3j5YKUBMKwdDFiWz31mqEcY8NN7Ad/oc2JrB wo71dslxayLiBb1pNVLRGiAsE/85VT5WnsT6oncRYssZtYxLKgcMC6nugxFLTWR+ZSytpIKlukkz T/yVJUPUEh8n0wm1lbCpBNCKA9o2IqULfOttiF3FWgP1aiauFCymPxozwHwcn84oxYRQ+iX2TVSV i1qKxe3Cr/rUjqcrKD5FTkYbq9RmdX8nayzQB/JWD8tvW4bx8ju/TJ5C5bPWUH+vvTV2apC3vS7T /jzx8AMEQAAEQAAEQAAEQAAEQCCSQEsqWMy3vMRv8UMnGjypkW97hal9tK+KSHZzf8GYaAXeTkfk 1lhZ2Q+Hq0Dx79Yjs8vs0ZYkoToollk63Ow7GkK6mLemj2atnFzWZJQxsAuNzNT9zh3NsB8a7f8l ZziEDfXPwTusaN8gIW/4felX+zOzL66sbqJ8cozt0mHU8gxjpxmxlGYiQtmXOeA6pd02FCqSVLAI nzUhhNmx8LSVndIKHNO3UHfEdr3Cj4daouVJ11Cw8GQ9bAtose20iiuVSQ3Uq6fQcqmRTNdzcR5+ sONk2X5Fmfy8hAJyiHdgCuNutsehY4Zs5k4/ZZRUKobBrlK/zx2SSuEw5bHhG6dcvp526SpkKlg7 KVlxAAIgAAIgAAIgAAIgAAIgEEmgJRUsbIvh3aZ2U5+VMXYe8W9pWp1lQCTDxi+IHWOE1YixI0/3 MCsW3J168lI5EZpTI2X1TqZ7eJcbcxWScHDbo6whkt7dZKQsxuSQNvRaWZEAb/Wcm8p4t9w1JnDa V4mwCum2xnj3IUu8Qec/sUX0BG/VrKxBxCRfanb8E8NNPdYEKxbybHmTPcLLnOTbe/c7foAnxnPx Zt43CRe7AakJdzFnDRnKFYqx417Jhr9znm2l2WfGeNaRiRlN85bJpt8MirDa0L5SmMVBJ77YTSdz MOVZ2qUm+T55E3tGDAUX+3vhLbiVgoRZ9Rm7zog675V1HnOUa517hqzssWlr+ljWGuv3bpNtKgTq rlfmZO8+xc6Vs4ekT6CkleXfckcqe/vwsv3AgF71obf9CyXYGPvCsZ1Lj/NW2szXcVLMClhV4Ubi 5q5WsR5LLJUSY4+pbItyxix2iXLK7O33naIPluv3J0zFGPc3yUQ4hja2pi9rHca7g5n9y2kL5jIx o4w4BAEQAAEQAAEQAAEQAAEQqJpAiypYuPw8+dEWKu5bWt8E3J5YiG1sq8Y1PwH9/ivMya9zXMap qxCp7rL6J5gOp9iGhJXYIC1XnHOdEZYQIvsJZeUSzdkbn7f6VTvdRMeRZVeTSM7LXAIU5KTTkrv3 CIVH2NxYyF3Lp9LOLY4srBSQE16VuHfCHS2z9jWjosqDvN6NKDq+dwlXtZw6WQklP8Up6TeEOaql YZqpP+/gbjX11Wvl9u/KMEd1qcrr8wfkL5/+bS6hkrGdb+3HJoQTWyRFtT293C0knhqnwvu9Xp7l xI1vSvh2FXJ3dvKKqn+Zy9lUXmX8GumYOAIBEAABEAABEAABEAABEChDoHUVLKLQs3l+4570TT7k hIa3JWZrgqb4GM529aROysnfm7xWEaEy11VWVrAIawV7Mh2L5nSoEqe8NbKn02MV4ZQjbiX3pK3M ifBpprCkCL5Jd8od7+qxhg6ztUZYYWe8O6ZIZmKHpYnDaW+aZSa5YUmXPcd+K3q7vIonmbew8ijn xyLHcplLUWQ8sTyt90BlHxj5oyMeaxUZP96VtNJiCUuYpc5rWSu9IxFSL6JNJa2xKZ9q0dcO47vS 1ohcvqQm4hx3Q0hcA1zN9erLV5Yt8D2XdSnkzWcCVk+BPO1yu9tuG2U0DzOD7hIvg1FsW3nF7fRw ME4gb14m5ashN9uiNRFWL5y/vctYaKcxJWal6D6zv8as1GG9xMwbEr9AAARAAARAAARAAARAAASq JXCRCMgP9q39OVeiwpk85c+KYpZoSdtyar+0rTXLXGtZSyUqXbyEllzs4CidLVCpJH6XKH+OauPE 4Qscn/ibliyhtmVLqmJcODVj1w1H4XhLaXlbm5KnXAKlMzM0w9mJeEvb2jm/cqHn7prI97jI2P20 r1pddd4FjpuXMi9bTm1t1TGSeRHzLZT4F9fXkmXVceIKpRlu/yKa+G/5pTXme57rVZV1ER2Uzhyn qeNcsaJe/t0qWn152/xLXyrQ1NRxWtK+gkrcHttWraL2WtqT6PtuX5X9f/6FRg4gAAIgAAIgAAIg AAIg0LoELgwFS+vWH0oGAiAAAiAAAiAAAiAAAiAAAiAAAiDQBASgYGmCSoAIIAACIAACIAACIAAC IAACIAACIAACi5sAFCyLu/4gPQiAAAiAAAiAAAiAAAiAAAiAAAiAQBMQgIKlCSoBIoAACIAACIAA CIAACIAACIAACIAACCxuAlCwLO76g/QgAAIgAAIgAAIgAAIgAAIgAAIgAAJNQAAKliaoBIgAAiAA AiAAAiAAAiAAAiAAAiAAAiCwuAlAwbK46w/SgwAIgAAIgAAIgAAIgAAIgAAIgAAINAEBKFiaoBIg AgiAAAiAAAiAAAiAAAiAAAiAAAiAwOImAAXL4q4/SA8CIAACIAACIAACIAACIAACIAACINAEBKBg aYJKgAggAAIgAAIgAAIgAAIgAAIgAAIgAAKLmwAULIu7/iA9CIAACIAACIAACIAACIAACIAACIBA ExCAgqUJKgEigAAIgAAIgAAIgAAIgAAIgAAIgAAILG4CULAs7vqD9CAAAiAAAiAAAiAAAiAAAiAA AiAAAk1AAAqWJqgEiAACIAACIAACIAACIAACIAACIAACILC4CUDBsrjrD9KDAAiAAAiAAAiAAAiA AAiAAAiAAAg0AQEoWJqgEiACCIAACIAACIAACIAACIAACIAACIDA4iYABcvirj9IDwIgAAIgAAIg AAIgAAIgAAIgAAIg0AQEoGBpgkqACCAAAiAAAiAAAiAAAiAAAiAAAiAAAoubABQsi7v+ID0IgAAI gAAIgAAIgAAIgAAIgAAIgEATEICCpQkqASKAAAiAAAiAAAiAAAiAAAiAAAiAAAgsbgJQsCzu+oP0 IAACIAACIAACIAACIAACIAACIAACTUAACpYmqASIAAIgAAIgAAIgAAIgAAIgAAIgAAIgsLgJQMGy uOsP0oMACIAACIAACIAACIAACIAACIAACDQBAShYmqASIAIIgAAIgAAIgAAIgAAIgAAIgAAIgMDi JgAFy+KuP0gPAiAAAiAAAiAAAiAAAiAAAiAAAiDQBASgYGmCSoAIIAACIAACIAACIAACIAACIAAC IAACi5sAFCyLu/4gPQiAAAiAAAiAAAiAAAiAAAiAAAiAQBMQgIKlCSoBIoAACIAACIAACIAACIAA CIAACIAACCxuAlCwLO76g/QgAAIgAAIgAAIgAAIgAAIgAAIgAAJNQAAKliaoBIgAAiAAAiAAAiAA AiAAAiAAAiAAAiCwuAlAwbK46w/SgwAIgAAIgAAIgAAIgAAIgAAIgAAINAEBKFiaoBIgAgiAAAiA AAiAAAiAAAiAAAiAAAiAwOImAAXL4q4/SA8CIAACIAACIAACIAACIAACIAACINAEBKBgaYJKgAgg AAIgAAIgAAIgAAIgAAIgAAIgAAKLmwAULIu7/iA9CIAACIAACIAACIAACIAACIAACIBAExCAgqUJ KgEigAAIgAAIgAAIgAAIgAAIgAAIgAAILG4CULAs7vqD9CAAAiAAAiAAAiAAAiAAAiAAAiAAAk1A AAqWJqgEiAACTU+gxBIuaXopIeBiIHDOFfLixSBsgzJeSGVtEBWiV0EA43AVkBAEBHwEMA77gOAn CIDAfBOAgmW+CSN9EDjPBAqnZqgoHyiWtVN7W2MCjP7VRXTTfZxG1xBZ/YnGEmvC2DMnZwJSLb20 ndoqKZTOFWjmlWJA8bR8RTstuRCUBwFqVZw4OUwXvX2jHTB9rEgdl1eCXEWazRrkQiprs9ZBC8nV 6uNwC1UVitJMBDAON1NtQBYQuGAIQMFywVQ1CqoIsPLBfhHYipPg0hTdtPQqGpWFjaWpmOmo3/jk 3AztvuSttNNOr5OysylaXQ23c0z44uafPM88sZ3emtgraanv2L4MZb4QU7/DDkY/zYqnB4NX+jJF 2hpr/rIHJa/iTIP1OvP0bnrrf3Zb04EspW5bXUWmizPIhVTWxVlDi0jqesfhRooIa5lG6CFukxDA ONwkFQExQOACIwAFSxNU+OTDu6nnR8dpeailQRu1vWUJrVp5FV2/IUGxy1p04nbe6qFEg3+2lDY/ RpSe4jfoV7YYz3NTtP2Sq0ipDDaxguUfGlCwUIH2XrScttv100M5K0ntlerqpUG6aPVmoobzrpRR 49dLk4O0dC3L6vsk+rM01FV+8j/54BZa++kBX0yi1NEidf5Ri7UrUco5qNfCs7tp+fWOgiV5KEc9 N1ZsTQG+i+VEM5d18uGdfM855dxzCkTrt91DHdf56uLUYdr5N9+lUzbwPNFbNlLv7g4KvU01caW0 xv21jnG4gTqZemQLXdUxQJ2DrAS9tfw42EA2iAoC806gmcdhu/DnjtP+z2+nSVpelkW+0EZb/66X 1l9mBDs7RXv/ai9NGafEoQjbuauH4iHPt6UXRmnnN4f5yc755JfFqHfPVlrlvjibeXaA7rjvWc98 xJ/31BN7aecjU54wIrW2Kzqo56719b/Qc2XCFwi0BAELnwUmULRSMbK4MVX1lxzOLrC8iz37opXe 5LDmifBiL0yk/NkDCac9bUhbjZYyO562+vb1Wenx6tpecSo9Z3lHFnCuL8w6CWb7HW6sYKk+Bzsu 9+MNrd2u5qReX8ta6f4Ut6e0lX2tesSLMmTTljXsntNj5XyQx3bEfPekuJVpdDDx5TH/P8PKGn2v beb7a63jcCNsswc67bqvaRxsJEPEBYH5ItC047Bb4GPu81IVc4DE4LSHUvFon2+MNsa2TeHPftl9 /nGdrNieCZVu2HUxP+lVgz+PqWVk5ReXKi0cgMCFTIAu5MI3TdnzOSs7lbWGdsXtwTK2jScf/Dt7 lP8yE1Z6X7dnEB050TSSL0JBLhQFi/OATHOgYKm1kudkIl5rpnMUvv6JReu3q8Vcr3PUPFonmddy VtqnQPE8GM9mrU7PQ3TCmphZpA/OuL/W3G7rHwdrzgoRQOCCJ5A9MmaNHXL/BvXzfnf/kDU27p4f z1h590WQAjZbtLKH+Tr/9XrGa6FoiVljMyqkPuCxP8P5Jd3wMfcF75CcV5yedmRRcsSsvoMTVt4Y /osnsk6Ygz2euYn9onjHmM4LRyBwARNo+SVCpVNTNPxwmtI/HaUZx9aZ2lespfW3dlDHpvXU3kSW /Mcf3kLv+OQAJdg3wZDPN0HpBV7K8C5nKUPYdduc6swUDX5vgNKP7KXRSfsMj7FxSn5uK229NU7t y9xzIV+Flw7T6H9/lo6fKtGSJW3UfmWM3n/j9dRemqT93xxn278lVOI12ev/61aKXTxFAw+OUmEJ w+OTqz7YSYmYYzheenmcBp7gzMU19nRS4gUlHZ/roPYwvx3sJHT8sQHaz/Uz/JQSmDp3sLyf2xy9 HIr9QEz+dJjSD6Zp/OVRNq2M8b92Wv+xOK1eMkP7v7ibNvLyg2To8gO9RGhel3KcYm4PMzeXkeB3 /IkB2ivKGeukkb+/h1a9Mkzbv3qHU1exBKUHBqjD5RhSRTWdmuK2dBW3JeGYtsiOaY8/N06Tz0/R TIErket39TXX0/rrVkeack79aIBGXyqw+E4HKXE9t1+ToI73r6ooh2qrG3h50mgjy5MqZqUDlGZo /KlR+2/y58eZqdOeYpu6afu2rbz8obLcIjHJrZolQjpzcVR7u2pkbJqZHKfvPryfhp4ZpslJbv+x dlq7IU4dt1xPp57kfpFfRd1f28r9wScljxGjT4zS6NPjlHl5huMKTjFKbNtM3Z/fSteXcTpbd70W nPGi5LYle1wotVPiCx20yiefV1rn18wL4zT46CDXbYakO+L2a+K0edNmStwYbMOT3M/GX+ZxTHha umw9bd7QRqPf3E/pJ8btdhHb0Enb70pW1ZbD5Cl7ro6yFp4bpoFnjjtDBa2ixG3raeYpHivkuMhj eM+2burm81XgKiueefE4LwN5By8DkZ/4ngyN3OX4HSo9t5+WvvsOecle7mfxUkPvp0RTfF8d/Qn3 u0mum6eIx2IejXks23xXN99zrvfKy+P9KN+fpkpcCns84Xvw+5fT1LOH6fDPJ+kUj03i3rPqmvUU fx/Xa9g9wytATb8W8v5KZ3l8+hHfq14+RaIfrLgsRus38PPHmXHaz/dL5zbRRvGuTlptrMFqZBwW Y8Tgw4OUfibD/Zx7OVftqnUbKc6Dwui3t1PpY2M08pX1oQzrHweJCtxfB77H/e0+Hpvc1EWf28rP IZs/HPO2CXHd7TPieUK07xKvXbiui8eiFTItWQZuWzye9+7aSeuvNCC5eVT7NcP9bdDub+KZRrS5 ErfLnfZ9OLapl9L7Omjmsb20/S/22vLHNvXQwLeSFLs0mEPNZXWTKJ2cpOFHhvhZjfuPWzftl3O7 //BqmvnRftp9djPlDnaHPjfVX6819ld/cetsw2K8n+LntYFvp2nvY9I7XIzb+kba2nU7xa/1LU30 51vP70U0DgeKx0uGtlzyDhIjc3rK4mXsgRChJ4Y/vZY2PjjJXLuJHuQ5AIeK9/OY3hXuS+74I9t5 /FeLyYNLupUcCfa9NxTue+9lXg5+hZiXxKm7i2gvzwuIEpR5bYhiZeYboQXASRBoNQKtrFya6Nea YK63oKaVz6XG/YbRC0ek7Fuj4oSSP8xsNzuYVNcjy3okpKyzOSvVFTQZdNKIWZ3uchqZZmxf1ipm vGaJ8X0ZBS0TYn7ITj/VdXmQP5q2eNgvK3Nnv05XxrNY3t4qllTFfUs8RnY41kGyHNHfCWvstMqt 7oMoM8vofN03Dvm6s/RElG2pfH6d1tixYN1YvKioL6xuYqno5UYnRirWp5QlYZijeoSu98fstMWP FGXbktlGy2UjuYX1sXLxBLNalp7VPTbN5q30tqj+6mUQ6HcnhsoyEvXTd8TXAOegXv3jhWwHAfn8 gMuOTbKs3IZPGG14NlN9OwwbX/wy1Pi79rLWsIQlwuS7RhFVcNnWeebttoukNe2+IQ0sDwqxhBvZ Jusg4ntDyvK0pjBT+MixnMfh0LFJiV/zgSxvaN+er/srS5k92Fux38k+oc3wRfHqGIddKmO7ZJ1G 1I0YL311mgt7Gx0xrvaGPjflraGK99lua8J3fw3rM+mjOWtij7vM1S9DufuQW/7or/LLG2Q9BL97 vW2Zf9VTViFXbrya9pAIXY5XT71KFjX3VxmRv+tuw/mMlYzs427b7EpbOb9lhpF3PYdhbUrUafQ9 Z+HG4UD5DOvBqpexz4ypMWbsdNHKqP7frcZ0fz5yPDTbeu9hY8RWciSsrHGLNdNR94ltY1YxP6Hu vd3DIXMNMyKOQeACINCyS4Qy+7w3554DY1b2RM7KHctY6V3ea4FJxQJVvBzw2EIlIIEyz+ebhF95 kDtoKldiVs/gmDU9k7fyM7zsyLe8aMjz0BpUViS2Ja2eHe7yEt+DTfLAiJUV4y+bGI4NpqxO98Zp PrAWj/GSpv40//WowTZwk+BJmzmoJ3alrcyxnJU/zaaLw30qngjTPexdc2qWtbt/zMq9VrSKr+Wt 6cyI1W3cyE2ZxINqLX5uPKbygZqo8kSe2R/oU4xEWQS/9B4v29iONLPUZpadvvJWmVsgmGxLHs7b etj3RY+VMDiJ62FLzqbHh6yUqMfBtNUjFXBlJnjFoylPnZr5Bo59D/YB4Ws9wQ8CcdlWY51Wapj7 +rFpK3Morc8Lc1nfg31YNpKbt/2EhfSfq17BUv/YVLSGurwTpu493H7YhHjI6G9Scenvd8UpXUex rh5riE2Op4+xqe8Bc/zw+uKYk3p9bZr7QspKH6gwLniQ5pVPG6f9JKz0oYyVm+HllJkxq8ej+GXf IMZz4fThEatvl+xn7kRzQ9Ia4fKafY3fulkTRjxP9vX+qKOs9pjJ/VLWmyxv6uCYNcFtmDdGV32r 168Aq1dOjifbeiebofeafqnkg3Ws20rJ8SrQZ7m9uz6H2DbC6uE0MlPTdt0k1XmyejwTcX7wP8jj yabg5J8tE6yeXd1Gf3XKHDY21VtkWd7zd38Vk2k9tot6jXclrd49PAYbdSrHR3HfzvkmMrWOwzab GX1/jW1LWVl+FigWi/azT58cy0X+vvE821/tSwguR8gzincC38k+u7i/ns5buakJy5MvdVtZc0LN fWZEjA08RshnCslEfMc2Jfle1KuZ+eSutT3kWZ60p7/FrdTBEdUHZN7O/Vo/K6aP6ZzqLisrjeXS DOL+NcaKJFE3+Rlm4HlWC5nU1lmvjtT19FcnZt1tmF98qLLa7a3HGstMW/l83soeGfI8r7GlrYY7 F0eLaBwOFFeOv8zMfw8PhHVPSN9xFOtzFIHSDx6n4VGaGAnI8bB7kO+Le2TfT2pll5IjpC2KdIoZ 1Sf7jjgDV1o+n0g5jPxwCAIXGoHWVLAY2lyiTisTMrHKHzEdS3knFQvVCOSAF981ZE2f4IdV8cB6 NMOTJ3MCRNaQcaM3BzniB5dMiOPIIluLyIcG86EqOygnIfywtaHXUZ7IwvODgOdNOT/U+D/yjX3o ZFQNzv6bhJ6ICpnSR0NmOOyUTFskdHq058p5Kw/gvmdRFi9n9bkP97zNrldcVsLkWMEmlE4yTCff WIRSR5xXf/wwOpcfyahTPZCyskdOQDa4N0POUIYLZVmHQLItOfXO7cLnPyFjWjwFJk/eDKdlO6kQ Ls+T3xzzyx6Sb+i47/FvxdblHFhH7M2url9FkTe/uQl8+KFUTlyreViR3GqvB92uy+bTwNiUP2JY jsWSHqWCXe5i1vO2MEyOHCue8iFjRO6QHGOCb07ntF4jxwVvzWl5eGziN5xhbSbjOuK027h/3bdh LRHf5V0Tnj+iFU2pEOs6ryQN/KqyrE4Ohs+TWK9+yBUXX9MPsn7legPSaQXLIPv6GnbuBbE9PCZm HD7xPayoHHatQMP6Pivap0+EjZd6EhkmrxpPxKSL789eS5WiNbbPvC+FO2qsp9yyb5+v+6vlsazz W+QUrYl+o5wh91d/GRW3sLowAuv7PSseTUWGG2ZCvnzyW4KwPwd7rOZ74pi0HhHWBUJJYt4jQ+pc 5+n2V0MeeZhVPh3IClNyiXDyPiifV1KHjTfhQj7xIiakTDKP6r91f0tLZ/fcz6SiXlk8ch+WyjA5 njZUVh6jZXph1hT5w3KMDzqU1vnWWK8SSj39tYE2rJ7VuJ/r5x8pjPjme6ackItnwflyjtrk47BJ xD6uSV4RQ4+3+gVd3uqTL9IiFJJyPEwc4JeYrCyRbV/1TW6rjh+ucAWLvkdrKxnzGWXe6jMADCdA oDkJtKSCRT2I8KAddhOTVZFxdwwRN3N585TXFuJbDnjy4SLsu+eQ16JD33SFZQsrFfghpGhbdehv q6gHYF4f6ZqeGhN9fsj1vFFShc/r5TiBhzo9oQydjEbdJIwHDBIm5Pyw5Je3yGUY2yYevp0/s27M m3ZSvDXNZO232nl+CLQnjsW8lTnMb+bDnvvtcmm55/8GEJaXPqe58Tn3QUOfYy5+5Y/nIddQCvF5 /6RZt6WYNRLm6IxZTLhOlcUb6FBnaG47UGkF2oBqKN4D+fYk4sbuDTxXv9jZG1vd9GzrtBKbEvZf Z5fzVjysHUXlKstq1kNUWO95Xa9me/WGsaxGxiZtHl6mvoy3nKFy8FgwNpyyurscRoJVp7Ba2ybf YIU/TNnlmIt6jRoXPKBMSx0er0IUQk5wHsOUJYtXbm3xJ8c7IwOWQU5yQhkZQRs6rKqsbg5G2OA9 S7et2ttldAlUWxcP2HlpYh6z4u6DeYonPKq9RvT93NExK8WWJ7LPJbo6reSuHv2w7luqKaSR+Ypx RzlW9ImpTM/NsUkqAMqMg0oREKIo1/nqe4scG+T33N1fefw2XmxEKfLkuO9fruPDYf9U8kfUhYyj 2z4/E+xIWWNH+H4o7hHiHik8VTLH6UyGrUYjb5KqjtRkSyYe8a3eoNvPXJwuW2UE7uumcjm0DLqd C+uykWMhCvOI/Gs+rfqb8eyjzhnPgyHnGiorpyfHHmKrOmFFmGWlkVBiifqx+HkoP5WxJtjSw/+Z i3qttb/W34a5LuWLJPHMye0u0B64evUknZVuIWOFn0Fdv0PqMDIdI+z5GocDshgyVHN/0lam3ntd XlnPhT8vyPFEcpe/bctOcc9VbdV7b3Xk1fUr4zvnjTmD/6VHoKA4AQKtTaAlFSx6oDBunmH1aLzl VG8xwsKdp3NabvZ9wg+q8kGXfVDaygbxwOv/eKxQXIWEfFgM/3YHYUPRod7W+BPn39PyrVPggUg/ DHkHWDeRqJuEnKRVJWtQwWKdHlMWCeHl42VFvGxiOojKFUzLXc3NKwRJDafC8tLnTG6y7vW52pY1 +S12ZHqmxVJAcKMuyrFQaQXaQCBF+4R6EKwyfHgq1Z8VD4HSSiWqTYjz5cooc5Nl1fUgr1T61vVa Lh+ZvnhzH67UdPMJjE06/bJ1ytGFh/8MP6D7u0A1fpqEAjZqvfWc1GvUuODBW31ZlQJA8DQKrGQN LQ+/3XMf/svVlUeken5UVVY34QphM/scBVjt7TJacNkWnTTZ34eaEIlxt9vetlktyfT3ZbYyrOhb gftcmLwy33JKBT1p0P3WPFeunzvXghYAKl9W2sz7/ZWx6zYY3dfVBNPPN6TalPwVwwaX/vp5xbt6 rQnTd5EvP5lXWP35goqSqhcE/nwif4eWQff7qGUNwbzrPKP6mzHeqXO6zdllM5fPzUFZJ5R/jAhF 34ZuK21a7qgiNlCvdfbXutuwwTKyDfieAcOs3VTRGzkwZKk43lcIOx/jcKBoFWTwh9fKaB5vWbnd s4P/dvVa5lJN++WrL2Kgj5vL12zlyHS0BYupLOV7bC/nKxTrPXukJaxo2zzXiHw54hMGP0GgBQm0 uILFt9bXX4HHtNPH+bdm8Gce/K0GPLWcxLIyhhlxbNtIIJL5NkXcyCInmtJckJcC2Q7FDAUL7fIt pzFyUetvAw9E+mEo9CEs4ibhf0iWW8QFb8JynT6bVsvt46RcpzNWr7mW3HejdtLicsrwnm8td8Wb rSdePT/C8tLnTG6q7tVbHA7nmfBEPIy5ZfcryWR65Sbj+uHJfKAMllOlFWgDwbDijEr3fFiwmA8F zCKxo4/f2DpWTdP8JnDsgPZtUU19y7KadRNeSv9ZXa/l8pHpiwlseQWLf2zS6ZerU79U6rfP71Fy n+Mzw/Fpwj4JlF8qY8KhIjsHc1KvEeOCNyujrBXW5k/LJSw+hZWSNVTBotMvV1demer4VVVZ3XQr hJXtpvZ2GS23P02trOKxZteEE1EqYX192eODgn1k2P58hGXJsazHb0yYvDLfcu24eFj7LpF15L93 BO8Z5hgZrWAxrTLm7f7K9DxtMGJZS0623yrGVsWtirDCGfyQ9J8Ten8UrKL9Usm8wuov2KK4P3nu VfLebdaHcyyfT/zL9pw0db+c9xdeqr8Z4506Z94PtUxOO5ybsmaGe6Of1dz66hkPsTCqs17r7a91 t2Hz+VKURz5/Btqibis9h8Kf2ILtrcYzofUakUaFsLX1i4g8Kp2uIIMnuuEHpfx4qJfxyPhhZckf lsu7Y1b6yITrQ8foI25k/7wjKm84u5W08X0hEmhNBYta+hP9ACEqW5vQ8Q11PtfiV9mywgY88w2K GMT8b3Y8ax6PVZmRCGaureVJjPHy15OI0o4HHur0g0boQ1jUTYI9jcu1nnq9qCfLsj+KJ9hJsXAG KB5Y2QzZ9g8hHuxd55e9XXKpQ9SaXv3ANP/OjXVecpJg1qfJLazus+wQsq8/xQ7+KvztYzNwny8b mR6R3hnED9bT/uU6dH8g/q3SCrSBkMB8Sj2UGT5mwkM2flblJfqGx6GmTFu+hTEfmuW14Lcsq1k3 wVBhZ8LqOhhOP5jUOjaZy2ai61Tl6JvQ6aV1rLAMWzKmdhgKPkzJNBXrRuo1alyQmdjfemwhKu8f S78N9ppHK1mhYPGQ1T90e1JtvThtpXiJXSc7QJZ+yzRHrgfZpozJU4L9tIR9pDNmlbYRSPaxcmNT 7lBQwWKx4/A0j3UVx0MxXrJTe7+vDpmvVybdb+f0/srl1eyCztodHIZFQhVjq5S/nOWPna5wGsvO yW2/W7wcSPkZ43ukUDqn9+jdFU1lk1FFasz3K+7NMOZxRjnJDE7kzHDlj3Vd6Ptl+Rh1X1XjkDHe qXPmvSIoU2NldRw9j7g7OhbZ4at4drH/jrHD8cFe9XwUUEDWW68N9Nf627DhA6SCkrzuOqw2Ymi9 RkSuEFb2Qe8YEpFWvacryGAmqyzg+D4nnEpnDk9YE/KPlwaaTt39c4fwsuj2rpUmRh8RmRsvtewN KjgflSfnnTnCTuilwhXObs3qwvEFRqAlFSxF10mfPUBEKQ94ENOOVPltVxOYsqkBz7BgsdujZ1mM 1xTeMpYSUIiFi2rPvL1rlge+sSN6ba98CBackgf1eRnHdAYZ9lCndkMJcTirTMs5bc/DknHzKPeA LWTIsYPfMb5pmA/KaqeDrqA1jy13RmrgffnKQgkTX9fkN85bTgc+Yp3/sSzvwhSlcgrEKHNC56Xf yOlz5sNtZN2XSb3cJZmeqNv4HvdttBmBHfo5DszEm8VoE3YRRaXle4ttJmce64cy76RXhinmeSeY o7yERU7Y5IU6vnVewTfWIrnssDZZrcZKTZbVrJvqxNL1Wi6fRsYm9bZb1KnfibMUcobfOrlvC80d w2S5xC4DwZbNk221vWp0W9CsG6hXo/+X42T6x+pmJ6xhn+KUtvIR/pw85VLjIj8chrQzOQaUkyEs z5rOVVlWO80KYWX91d4uoyTW7bVsmtKCRSiqJEdDVrl7hJmLqBepRA9LW5bFHpt8DojtdNj8XMYv t2TNzLOaY5lvQKZ5ur8K55M93Fft5xD+7hnO6DGPlUV9yn8Qh6lFwVJhHNaWPhHKDt7KXMoUtSwx 79rfAAAkf0lEQVRDsgr0Kxe02PUmO6UtDkzrJ//Of5664bE/w7uehft/0W1yXvulEEi1YWO8U+fM lzNBmRoqK1scyLbt2axAQTK25va1ibrr1ShX7f21/jYsx1jb19IxVcDAQZ6XtI4d4p0vQwx2AoHr OWGUv2K7qhBW9ovAGFKPXFFxKsigo2k/inF2Th7+MRRdvnEjsiw+a1f/GKzbIe/CFzFvKh7Rz+EV mYcLjrMgsOgJtKSCRVgJqJ1axAPOpj7PLiq5oyPG5LLMZOV8VS87Zs2Znvu3DdlOz8wJqDaF52VA 7nXhEM20iBAPTc62jO5Ug687WzXrSaa42UljHT1hch4ChUO8DE98c/ZbLmOHA8HQd7MXOcsBWuSb 2DPCWybzSd6tZ8Kz7SsrOvhtDRubqI/Hb4y7VaFdFpZXTL4neKtm+RAi0u6VAvvyjPP2ztPCaZ/8 sBJpRC11CN9+2MsrYY1MCcdy/JaPb/Ijxla3YgnHtM1XJl77d/501up1Nfliu1Lh5M3MX5hJS/El S/Nc7Tk6McS21WoXiJhrgivW3HPdTvMuMplDKY95sv9hwd6RRzqSNNul2KXKsytQxBORmtyKduGU UciUPTKit3zmeq3HgsnPxGzDsS7Rz8WWpLxtNzvf9C8js3eN4jeGTr9xUxJvEMPK6t89I8Rppsmp 7O5UspLtLBsYm0yrM+YX25bmLVi5TYl+c3rat92yV8GoLViY+z62ALOdDnKdjKcDW6OmM+wQ0yOz y6qeeuU+qfiKN7VTY8rJo38XL4+jZmPnHM/4IkTh/po9KHfbcMauPnOfZh5stGKNnWVyH1djqejr vJOY7Je9h7IBB9FuaWv/qresQql7dEj1SSGTOV6KMVH2Z7Gzj6i7Rj9FY2wSY3tO9AvfR7xd1zuC xa0xyZEnAMpRJytnR+RWs8K60L8sRfQjTkfx5zzkWCfq1f7bwNu3ireu4o0rL+lT5/l6mO8An5iV f/J4sBD3VyGYR6Hqljd0WWzI/dUcXzzyVxiHzTGRmG3Gs+uP6DuacfdBrSQxQZpKhN6D3B7tMYaV Iwe9WykrJYExKRT1193P7VROvkT7Fls1K0faot4NRW/IDn/JYe6X0sk7O3917p2mhA0c2/LIcUg4 ABXpc3pGGXpEH7Tv/1rBos4Z4WouqydunJdheF805HkcUM8+vhdmddcr59lIf623DXvk5efOlGLK rMXzwOEhj58QilQS1FjXi2gcliVTGxr47pHdrJS1rbSFE2TzGUS0YWMn1AS/hLCdJMsExTeHEX1o ZIc7zvJYPcFjgd2ueUyU9xSy5xN8bzZ2YdSWoSKutmAp5qfZ35Jc1sXKSZbJc9/mbG2rrCm9VXxn /wSHafyeZRYNxyCwGAi0qIKF0fMDurZQkQNMyDc/AAYfLc9n1fENXJrTyQdO+e156PJNzDiM8nJe bVlFujwpM4e6aeNhy3ywDRz7tN82IX7zFwgnZXe/5Zpr8mwJma/BKR77qpAPapxp4OFc5BOL8y4W emmQLVOU5RKnodeZhrQHKT+3C5NTrS3CtDbQjOL8Flg/sDnnHWeS0+aWs7yDgqFTqi1rfphSD2iy LGW+Yzt8y8OMSbSWO5qTXznjCMue5MvkKdOdmzcbhtf6KvIUeat+43nwjC6jlNdjiaXe7FeOZz6g 2Hyq7a9hY9OxkarqN7B0w/OWvhqZw9pgrfXqb+uV8jWsJBiUuYOFrIOw784Dxts7nxJKhpdOoE1F k7wmdk2ou7+p3ll/WU1LQiWTHC8j2pmnLSoZqjvwTnx0nXisGSLyjblWfxN75EO2jq9kD+mHkr+Q MHQMD4vD96rG780Le38V5c1n0uF9NpbQ5z33eo7UwDgcXr8xe6cndT+2eRvWG0JQ88O7SnnDhtUz xzdukkUuZ7k2YF7TVmn8XBPpn8ObZ1+ZZaym6JWOR4ytgZVMMb7f++8HrpWstsRgedx+WV9ZWTLO Q1uO6vLFeTc3tamB2xfSxwy4HLWRem2kvwqedbVhjpc9oJejKdYhfV1c01a+Isd6P4tnHFYlVMtz dXuIYuUoRKPLaI7hgXsdPyeLPh27f8hQuHnzVPcVj28XV8ESOSZpBYxo3/7nz/gGca/QL3ZVuXEA Ai1OoHUVLKLiWJM91p+MeFBIWKnxcNPz813nY2q7XO9gF3AEl/cqjTw3YC7ryL6omxnvmrArZU3w G8iwT3EmY/XtSHgejuKbHE/2efmg7X8AdBMSb1zU2xFpLcFWKSOHx6xu88GJteTexwW++fJbaP9g LG8scfYDMHSY3yL5BNY+LPhGYaZv3LST/PbMXFbkS8L+mT0Y5mSOOQknqfwGv9FP2FsfaRWjllYJ mTc5SxvMJVUUq8LHRpSA/gkmv8Ec4beOqo4UJ27//EYp8GEfOcGw3nYp60h8h/s94VTZBN70hyPj xDZ0Wr3Ch46hNAvIUOsJ3iGhT71V0bLG2PnmxDHetttwFO2YK8tWpXeTkfJFf/MbfNPZ8ukaOMUM /xWybI2MTewrQzul1eUVsovdQYSlQdinyG+Vwh7uEzvYEozfdOktj0WaEU54a6xXT1tXbc8rs2Iu HXCbwnPdpn1jkwrP9RssKytvzaUXbp5y2cL0QdOaz5UjLF9ThiqP6y1rxqNcdWXi8dL+sCP24ESX 22KYH50q5bRC0+QlLKaTSc8yHV1fkiNP9/gNqM/KUbBmpUH6MFtBHkl57ic6nqFgYQVijq1eUjs6 PWWM2fee4JLVaovnD7fQ91dbHlasZzMT1tjBEWuEl0PIXb6UIt5/f21gHC5OOeztyZS8J/v6Xnxb ysqGDxMKX15Y+obcY+NdSSt9yFjupGLwgVj65LFU0W1HvAjp6R+yssabchF1ZFs1yjre0tuncDCz reXYez9w5bOVKd77QaLfUdyO7NDyxXYYS5PrKKuYgIr7q92nI+pGbN/s96kmytdYvdbfXxXbWtuw G1G0o+6Il4jieSA1zBYO8pasMqv/YNGMw7KI/MIl7L6s7nNG3027lpoTe7zP6zKs+Tw2bSyPltfF d/fw/+XbMU72Ue99JXdQzifcFxD8kib02dC8f3L7Thry6nwjnickA3yDQAsSuEiUiTtBa3/Olahw Jk/5s6KYJVrStpzaL21rzTJzWWdO5bmUREv4b+my5dTWJo6q/JzjcBfrsKWXBmnp6s3EZuRUHO2w 09RX9VHhVIGWCKYl5rushvw4icKpGbtulohoS5bS8rY2WmLIoHPhIy5f6dwS57oIw/kVzoo8ifIF ouUsQ2RcT0LOj1KhwOnx8cVLqE3IHZVvSNzFdspT1lraRCMFFX2vwK2RuS5ZwnVTW9OoKedSwWlH ItLStnauz5qiL0zgRsamUoFmzhQduS92+00VfEV/K9ptnuPU2F8UpPNYr3ae3M9neAwX45r4b/ml NY5rSnAczCkBow1We6+ZengLXfXJgeA9RbRJ8WnmMZjbfUP3V6eE6v/x5Fr6wNcmKbZjjDK716vz jR6UxD1RDLaCpeyr4v5WyBOJsbGKcULJcLZAYgi3x/BlVd5fOY7gZA/4LIPdNmp8LlD5N/tBjWX1 1g0PZxy/VCraY3KlPuSN695ba6nXOvprJfzVtmFxf545I9tl9ferSvnj+vwRsJ8Z5bPx/GWDlEGg JQlcGAqWlqy681SolwfpoitYwbIpTdY/dJynTJENCIAACIBAKxI4/sgWekcHK1gu8HtKYXKQlq/l eyt/eFcSGupa3YrVjTK1MAG04RauXBQNBECgIQJQsDSErxUjl2jy6XGaKbGViHjh9coobfz0Xl5Z 0U1D39hM170vRu21vP1qRUQoEwiAAAiAQM0Ejk+O08DaD9BuO2ac0oe6aQUfs4ESrbpuPa2+tOYk F0WEqUd2084nMrTqilVUOL2EViybpN33jSrZ2R8VdVyJG6sCgoOmI4A23HRVAoFAAASamAAULE1c OQshWumFAVr6ri2RWbOTQ8p8AW/aIgHhAgiAAAiAQJDAyWG66O0bg+flmT0Zsu5i7xQt9ymxUmkp bZkML1jPwWlKfnhV+EWcBYGmIIA23BTVACFAAAQWDQEoWBZNVZ0nQc9O0d6/2UszFPRRU2AfNokv 9lD8crxpO0+1gWxAAARAoDUInJuhwa9+hTLFsHtLgdZ39VLHtcFrrVD4wgtsufMDtgzNC2cm7Jpk eTtdteY6ev/7rqf21ixyK1QbymAQQBs2YOAQBEAABCoQgIKlAiBcBgEQAAEQAAEQAAEQAAEQAAEQ AAEQAIFKBKBgqUQI10EABEAABEAABEAABEAABEAABEAABECgAgEoWCoAwmUQAAEQAAEQAAEQAAEQ AAEQAAEQAAEQqEQACpZKhHAdBEAABEAABEAABEAABEAABEAABEAABCoQgIKlAiBcBgEQAAEQAAEQ AAEQAAEQAAEQAAEQAIFKBKBgqUQI188PgXNuNhefn+wuyFzA+IKs9rKFFpuaYFOwsohwEQRAAARA AARAAARAAASqJQAFS7WkEG7+CJw7TtsveQft5Rw6B6cpdeuquvIqnJyhooq5lNovw/6XEsfME9vp rQlBuJuys720GoosieaC/R79q4vopvu4+F1DZPUnLlgOKDgIgAAIgAAIgAAIgAAIzBUBKFjmiuQ8 pFMqFKjEr5eXLBF/85BBsyR5apzWtn+AJoU8m9JU/IeOml+ql14YoKXv2uIpUWqqSJ1Xtgi4Bi0N xpNr6QNfswlTmrl0tAoXT41fQD/YGsluEvUqys7N0O5L3ko7bWSdrHRLQel2ATUfFBUEQAAEQAAE QAAEQGB+CEDBMj9c60/1XIHGH9lP2z+501E4yJRicUqsGKXhp/hEFysh+mtXQsikmu77DCtY3uIq WHaMkbV7fe0inhyltW+/ycMsdZQVLH+0+BUsU49soas6Bti6J8vWPatrZ8MxDt+zlm74G0fBMjZj 0foVdSWDSE1BoESDf7aUNj9GDSjLCrT3ouW03S5PD+WsJLU3RdkgBAiAAAiAAAiAAAiAAAgsXgJQ sDRT3Z2ZpO1vWWsvlSkr1gZWsIy2kIKFhFJpiKbOEK2+cTOtb8S6ojRJG5eupWEG2DIKlodZwfLJ AUr0Z2moqz4FS+mlcUo/PUV06WrafOv6mi2EyrZHXDzPBLSCpZE2PvXTQRp/MU/Lr15PHe+vr12d 54IjOxAAARAAARAAARAAARBoagJQsDRL9ZSmaMvSq2jAlSexZ4j6Ppeg9mW8FKBwnEa/uZ02/o1Q G/CnzmU0TuQW//8cc7zE4djI5LOZKE3NgYKlmcoDWRolMDcKlkalQHwQAAEQAAEQAAEQAAEQAAEv AShYvDwW7Je5hCM5nKWej/nfKOtJFVGSpmd7aJXP/0Lp1BQNP5ym9E9HaeaUU5T2FWtp/a0d1LFp PbX7VssUnhumgWeO2/5dSrSKEretp5mnBmgvpzH8FC8n4WVJPdu6qZvP+6IqTqWTkzTM1ifpR0Zp VESJEbVfvp7iH15NMz/aT7vPbqbcwW5q98lKvBRq9HsDNFVi/zJuaiV2KhH7WCetv1yeUdkED87O 0PjTP6XJF4/bfmraVrRT7H1xuv7yvHKYG6VgKbwwTgPf20/p+4bVkqLYhk7a+rmttPnDMSWPyrQw RQMPjlKBHeEIyUoFouu6ttL1vMzGSWuQ0s9kaHJykmKbuql31062wvE62BXhhn48TqM/naTjp2bs sFxa6t6znfPtoFWsSIv61KtgKbwwSgM/nrJ9+NhpC8ArrqPO264PljGQeYmmnh6m9GNpGv35jHu1 ndauY2uH/9pB6//It6CEfXoMf3uQuDUxoBK1v7eD4m85TgPf2stsmDO3jfimHur+Wnd0/Z4r0eRP Oc8H0zT+8ijXTYz/tdP6j8Vp9ZIZ2v/F3bTxUI6SN/ryDshe24m627DIRizpe2yA9ss+Y2cdo84d W7leN1Pssui2XDrFfYfLmn6C24VoO9x5Vl0TZwujjdTGS94G/3ueEn/VQ/GARZceC6LaeBSBqR8N 0OhLBdUmSqKurkmwBUsVjqVL3OceG6TBR8Ypw23Y+bRT/NbNtPm2BK1e4SsrW+QNfG+cStxvRNO7 jsO1nxil/fdx/T7m1G/nju2U/Ovy7T+qLDgPAiAAAiAAAiAAAiAAAk1HwMJn4QmcHrNYL2Fx47DY OsUqRkiUH+9RYfK+MBP93c41mU7Id2o8Z8QqWqmYm2dIWFsWeT5Cptx4b8U8iRJWJqxAxYwus8yH v+P7MoaM4YfZg9XkSxZPPn0J5K2hHfEKMndbE6e90YqZvkCc9NGcNbEnEThvc4ulPHXICqbwcKrc cSvjq9DcQbeuVZjouur11KuWPbsvFpIv5+XHoqM4RzMTVnelfLtSVm5WRyweTYXkFS5zKkyA2ZzV W0V7jPdndaZzcNRIG84fTYe2YbPvdPaHt+fMgUptwmFn9oeRim1X8k5YY7427KAqWn1h9eprr2FY c4dTVZR1wtPus/1h7U/KaH7zGPFaWK44BwIgAAIgAAIgAAIgAAKLiwAtLnFbU9oiT9TkpKz3sG+m bRaZJ6HpXd1Wz4EJ86yV2eed6PccGLOyJ3JW7liGw3uv9R3R6RePTVjpfT2+iVPCSh0csyYOpS3e uFXLZcSzM2dZkvJ6rNsaY4VDsVi08jPT1sg+c/KYsLKhE/qiNTGYtlIH0lb6QMrqdCfX7GfEUzb/ j+lhM21WyHQlrb59vVb3Bi2rZOlXsIxsM8N0WunxjJU7nbdyUxNWX5c5Gey2sobywHqNy+STU+Yh vmObklaqv1fz8imksv1aqdO5K2WNZbLW9BTXjTFhju0a8xTVjGPmFXYcPxDOzK7ffsGXOe/qdOsy qj7c7F/LWHFZr+J7U48tb24mZ2XGvW2CNqQs3Zry1sRw2urZ5HJ06zO+g8t7hNuZ2Q5jfUY8J9/c waRqa939Y1butaJVfC1vTWdGrG5D8VKpfXggVvrRSBs+MaLkFXWS2JW2MsdyVv40cxru8/Sp7uFp jyTTg742vK3XGjo0Zo0N637Axix2+rq8NShEWR7eKcqTp/wxPT7EbZXbBPe9Htnmfe1VhpXf+YxX eSbLmjuRtcYGvYpAUyHk9Js+1bdl2032j1iZI2PcVnR/jO8JV0RJGfANAiAAAiAAAiAAAiAAAouB ABQsTVBL2UE5+SVr6ESNAs2MGRO9TisT8uY6f0QrcIh6LNOOxbKyVqecUMd6PVYJFk+2pZIlYDlQ zKprfSEWCfnD0uqjCosJLnLanWzpCWUIB8/kP26NTOnpvQg9PS7zdCZupoLFVGLxLkyBCb6InzUm vokIpYWUU04WU4cNmrNFVmrxJNtUzoiE3fNF/3m+NLbDVUiwssIzJRZxhJKMJ+xj0lKG5bYVQuK8 +vMyENmFfo7JNlBewaLk4TYRbn2Rt9JdemKcPGSUnzOeNtpyj++aVgQGrZqyB1xFICtfPBzswuSs PleBFqvCwim0/GEn627DRdVeRTtIHw2pg9eyhhVQp1Yy5icMBVbMSvtNl7j0I7JNcNqe/sAKJ1Hv +Zms4tE5mLGVOro9cNuYCZEnpPyqrjZEW81ZPFr0yPGBv1N+RatIN5/RYwjFLN6lyvPRfSZujXnG t7yVkkoWf/v3pIAfIAACIAACIAACIAACILA4CEDB0gT1lD0gFSw8EQuZhJcTUU2SePITpuiQcTP9 2pLFVDxYs1rBEoyvJ5KeiZ5IlONJ5QttSFpDbA2SZeWCUADk+c/icuTZSmMi4317L+XxfpfJxwio OXFZwyZ6HNZUVpnlzBrl7xOTWra2KdpWEsa3qawKnXRqOdmjiDVyLKgKMMT1HBZ5UjzU32N1bkpY if+/vTNmbWPZ4vg+SOFAChtucfMx9DGiMpBPYPIBjDuru7gKqoKrkCqgdEphUBNQOrlwoSKFUgT8 ijzsC7mwhheQIYG9Z1Y7M+esZlfaxA4ufoJcaaWdmTO/OTJ3/jpzTvlvvzg8Oo6RNy1RBH7eTaKP GajhYvlpC4FF+YKLTmmcnRLe6kfavK3J9i02BIFF/HjwalzMJcrHRc04X8rd8ZFlXszP5sXFdtpB A4Xa2z/rw0qYKaN4xNfXfEkEsqmKmPK+GI75uXnWBKhoXYwOWxM2y5uiHzZFqsS+ml/FtWoRWIIw J2JPi7i1VFEu1k+jrSa6pTIrrHuL/zfPgE8gAAEIQAACEIAABCBwvwggsNyD9QibDNl0jT93Myhs krIN4ozaKI10bhK1qfabQG3B/OXqeMuawCI3zf7Sx2piVIOP7sieHBYjHeGhOzav4yYsNY6/Nc71 sLhoEqIkt4sXfuJ8pH8VdRHsE96NrzcILK1HubzB5bNEfBxs4OTsSI636sjPu42NGTJxsZXAooQD u0le7zDwrG2Mva114aXsQSIdVsePElE0Og9Rw7ocvhgVF42qz7qN27zzUz4chKIW/6nNwftiFPqE QZMPO8P/L0eNziU6JTnf+H3x/W4z1/o9Ya1afC/6TfOxo7Jf9XfE+k60NeW/+XkVddZiQ91uriEA AQhAAAIQgAAEIHBfCSCw3IOV0b/+Hn/o9hN92CRltbwh9Xl9HgcxwfzqrTZGqc2a7z+1OXJDzN8N Tb6JlGCxeU7tmzA/FW9Llg2TR3zK+5Lzkf5NjpZmwcMnG+7XcqKsbIh2GpHKG5h4tglunxYn7yQ/ jov0+XJR5aHwR4Saowj8vJvWIDHs2ltxo5wQN/zdit3+23ReF3/r2AtWcmxJawDe1qRgFPpvsOHr vBj6vCA1gSL6lRxj80bc0nNXH64n9PX5UqKNXnjxfiZJZ6ujMYHPJkG0dW7RD1Pf2dam6sNgS4u4 Ef1GBJa2iK3vF+FIlPWdaGvKf0P/LTYok3kJAQhAAAIQgAAEIACBe00AgeU+LI8SP2zi0M3GxV/E JfdBIv+K70EfTTBVXMKmN1V1R47cVMeX1jdHy2J+Oiom56vt7jKX/BBypKP899klvxzGXBO1KAdv U3xu34T5+2KkT7+YNehQOteK3nzOX/hEsy3RL36gxudop+678XaRHkL+iScnNr9N1ejyXXU8rGWD 6dcgdcSieWz7SdjISlWndNJhuV9FsNST7tre8ljxp3aUyNvaVWBZfpGkv28lua2L6iiTJTsRauVP i/lUhBe/fhsiKayhG65+0odVHpX9WgLbDQNKjpqY4HZjvqXGCJfoV01H5TbZ4T5vXauqAy0mtQql KgLJHmuKtq7/DZGl9tFALf5fmvJdkii/fV0MXwyL4ctRsWj5W1eZzhMEIAABCEAAAhCAAAR+OwEE lt+OPDWgbEJ8RID8cp9OLirtllJF6Ohp0ZOcJ76sqY5+yZ6PTTRBGElElFh2V5LO6pKoSmAxkS1V Y78Js2H/zhZ/3KPpWJMqCbtp86SEiLVxwiQk3aaqNNM7mqzP9bst9avno3PV1Ku6qCEkcYyrljOV ijApBSduFnXfpr25iPcnq6RIItSBr5DTIkL5NUjmNZHxXOWmxacNcR1+I9saOSFJR1WkT9McF6qS U130CZxT8wm+tn48JlRNej4xBMPFPJbm3k7cCi2bX/ysD4d5uEiVQfNxNRn58uO8mEp+opD4+EuM JMtEdEt5WSF+PDpYCUppX1V+9TIRaeQSJH+WSlVXOrZoHUPwq9Ra+dt1vh0XJZfsclmMVb6Zei4n LzImv9veL9tsEFtsBTDHfb+VuzefZwhAAAIQgAAEIAABCPxOAggsv5N221i1sq+9g9fF/EtelT6W iJA3tpzyScijIuVb1aY4e3ZSzNXG6vLjRFX4kLLGOlGl24h9HIcjPsP3Cxc8EB5LERt8BZv+C4ku 0AkhzCazX4zOLwpdJSeXfkO534P1TXMequDYqihOJHKVc0JVlK/KIHUMoTyOISWEZyIs5FJdZXE+ NvN0n/ffzKNNxt6sWJUCrqbqOLhSzdWmdnXUQ1WzSVRvGbxbxOotkojVJTldf8hGOKxNrzgRvrmL zvh6UUb4+ONIq/GkApRUfykTutY6CqKFzGl4KmskkQ1LVw74NJb1dX2Y/D0uosgzln4X76NAMZKS 2rmLNqo+1+tmBLtyPMVQBL7JS5+Q2W1ypRqQEuuWkjdk7CvgPBlKlIFiIvO+/DSt8uO4ClBS1ltF aITNvls3KXl8YXwtLyaqzPPEVKKpwepyaXyimw/rZMpZVabcJXZ2/9z3ZialmoP/O46q0pYRC3qD YlqxcGWp51IeXbez0SB+clFgcWtQVtMSH86lbPJEEilHv7LRWku15qY6lQgnzve8P1zK3x390Amy nbAxEf/xD5e8+USJw/UIPPe5L+fu/obk+nvivrfeL52/uOpHyif8GCIhxogpYbn6vtxmJFMciVcQ gAAEIAABCEAAAhD4FQIILL9C75bb5nNf6SVuIvxmQj+7jYraukpCzLmKUGlpWytPHPJoqE1L1quq x/hflvVn8jpED5jNaRyzLxVy+j4qo2pbz91w8TZWNNLzanqtIyn0EaCm+937YZPp5yNrtdySr2t/ GHKQiIBVm0/TuFH0io6Rn0Vho6mdeV/ZG3rJp3E+FVPTpnxPlQKWtfGJftfvi2sVPqtFD+hy1eGe xLimxLCOzFD3+mgGH8Vg+lNz1QJLuKfXl4pL8WhQ+X5TlFaA1eHFL/iw2/TrqLNgs5p7fE8iP5QQ VYhQeLyNTzUcK3Mz3MqvdH4cleQ62pXwhcp+G22yZaJmJ9QobSYcfzNMqrLtDT7aJCitfwfbj0R2 8AJuhQAEIAABCEAAAhCAwK0RQGC5NZS31NFX94twbVNZbVB6ErEx/ah2MHpIyVEwfTVo2Ig/LV5/ WD9KMA/lodVG62C86lXywgSRImyQ+sX0qhq02iCV9/R8Mk/Vj2sjR5lS9obKIaHfWjvzvhrTz/dq VgxCZEhs2z94XczObARAJvMxYlQufE2kSmyfyYb+WEoEm8gLGXOyTRWgrCcRJGYkb22xOD1JsOwV gzcziSSZ2cibur1VL7mLREpsyvvPB8XovYoyKe/Pi5Nnal6G5/r7TrCrP3KJNhk8S6/r0yPJgVF3 QxH59tfGiUwmPrJF3aPHjbmERBxLzNOJAoNXEgGRjHCoW7/l9S/4sB/Bra2OONHiRf/5cTE+k4gj f7N5XhazWlRaaOuqbyW+r6a5XCxOUwmme8X+0Ukxnccok7Kd5I3pIroNP9Tau/E+jBr6EF9OrE1a 0BysqieJyOQjW8K8ZY1T4zr7L89eh8gVd//+q1k5Lf4DAQhAAAIQgAAEIACB+0TgP84Y+R9WHveN wLfr7L//u8puxK6dB7vZ3p+Ps91HWxj54ya7/ifP8m/u3ptsZ3cve/zH7hYNu99y803639nJsgfS 9oeMJjbf3Cyzpbx++Ggv292Vz+7wcfPPVXZ1LXxkmIe7W/Lx9oitV3/nq8Zif2nvozu0V9alHM+N v/Mwe7wra+K4dX2I3dfOKaTtzqNd8Y2uHXS7361pXnIqvSnb+0M43wUm4XPzY2c1HzenG/Fj51/i 87ms8Z748F3M9bZ8+Prvq/I753zRre+erO9W9vrvq3xnXNOH8n3d7eiHN9fyvZP22YOdVdu79ony eydrI0Nm8j2/q7Vx3ZuH85HS98VP7sIHzWBcQAACEIAABCAAAQhAoDsBBJbuzGgBAQhAAAIQgAAE IAABCEAAAhCAAAQMAQQWg4MLCEAAAhCAAAQgAAEIQAACEIAABCDQnQACS3dmtIAABCAAAQhAAAIQ gAAEIAABCEAAAoYAAovBwQUEIAABCEAAAhCAAAQgAAEIQAACEOhOAIGlOzNaQAACEIAABCAAAQhA AAIQgAAEIAABQwCBxeDgAgIQgAAEIAABCEAAAhCAAAQgAAEIdCeAwNKdGS0gAAEIQAACEIAABCAA AQhAAAIQgIAhgMBicHABAQhAAAIQgAAEIAABCEAAAhCAAAS6E0Bg6c6MFhCAAAQgAAEIQAACEIAA BCAAAQhAwBBAYDE4uIAABCAAAQhAAAIQgAAEIAABCEAAAt0JILB0Z0YLCEAAAhCAAAQgAAEIQAAC EIAABCBgCCCwGBxcQAACEIAABCAAAQhAAAIQgAAEIACB7gQQWLozowUEIAABCEAAAhCAAAQgAAEI QAACEDAEEFgMDi4gAAEIQAACEIAABCAAAQhAAAIQgEB3Aggs3ZnRAgIQgAAEIAABCEAAAhCAAAQg AAEIGAIILAYHFxCAAAQgAAEIQAACEIAABCAAAQhAoDsBBJbuzGgBAQhAAAIQgAAEIAABCEAAAhCA AAQMAQQWg4MLCEAAAhCAAAQgAAEIQAACEIAABCDQnQACS3dmtIAABCAAAQhAAAIQgAAEIAABCEAA AoYAAovBwQUEIAABCEAAAhCAAAQgAAEIQAACEOhOAIGlOzNaQAACEIAABCAAAQhAAAIQgAAEIAAB QwCBxeDgAgIQgAAEIAABCEAAAhCAAAQgAAEIdCeAwNKdGS0gAAEIQAACEIAABCAAAQhAAAIQgIAh 8C9+JfblbXKzzQAAAABJRU5ErkJggg== --Apple-Mail=_6418C101-1B75-4C30-A4F7-426EA3C4C131-- --Apple-Mail=_44BEC05A-0408-44AB-9227-C223FAEB6B2A-- From nobody Thu Oct 4 08:56: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 68E30130E65; Thu, 4 Oct 2018 08:56:09 -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.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153866856937.4457.4817614021620950019@ietfa.amsl.com> Date: Thu, 04 Oct 2018 08:56:09 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-pubsub-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 15:56:10 -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 : Publish/Subscribe Functionality for LISP Authors : Alberto Rodriguez-Natal Vina Ermagan Johnson Leong Fabio Maino Albert Cabellos-Aparicio Sharon Barkai Dino Farinacci Mohamed Boucadair Christian Jacquenet Stefano Secci Filename : draft-ietf-lisp-pubsub-01.txt Pages : 12 Date : 2018-10-04 Abstract: This document specifies an extension to the use of Map-Request to enable Publish/Subscribe (PubSub) operation for LISP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-pubsub/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-pubsub-01 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-pubsub-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 5 06:38:46 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54CF130E2A for ; Fri, 5 Oct 2018 06:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrHQSGK-v_PX for ; Fri, 5 Oct 2018 06:38:40 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89FC130DC6 for ; Fri, 5 Oct 2018 06:38:39 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id r83-v6so11647564ljr.7 for ; Fri, 05 Oct 2018 06:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L+bvfaqzZ2G8pXJxrRiHMosvdhWrpweVJsrbOBkNOBg=; b=EDUfkM8ICqT7DEljbKciZurxzujk38ur3Zp/jKwqSdbrRxB7zQvPF6ACBmmbxaCAoZ /0h5JdSUhQJntNuDR5niSZJ9TxjhxgNBGAzR3R45qLi+yCQIL8E6J0a9JcenVjoMVD4X IuA1iJrq9+0bYT5EbQWyiM8wwHFS4VWoxiKRcw//nbML7Q84M43mF8ILRGch1EBDIvvi wVBg5d3fpJq4vfqwJb2vzKnW5AFhmh76RFtW1gW1cIA8GfhY3PTL2fn4aJDUH14adMG6 XkVu3emB3c0N9qAcyF51dpz3RAorfntl9ORjbwhl9roMFvZWpoc0MkfSDASpQWtosl5S mgXQ== 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=L+bvfaqzZ2G8pXJxrRiHMosvdhWrpweVJsrbOBkNOBg=; b=EgFnfAy0L5Tlu62D1DcZP6J4UCllbv9g0DU5+jaK4tPwjuMJV0Znm0OyYc0Vh9js1y 2uDnPO9MNTRkRu7S6Xi6KMmunJ2GOaY+1wDGofRp9eRSgPMP9FprqWtaIFtYu/YwBnxL EuHZ6vgRm1awGiJ3Bl16KOVk7FLthErS1E4WgW17N6FdJ8PRYUQKAjv3YwlGN4dyaISG PbDvC/JWlQKJr+jq/tzsLhKFz+lbEPGSWnyPIDLk3ISg4GGA9x1/sfcyKm70AcROv+E9 0AhbzL50yS5cWQDqwmDFuSWckHmD3XT2C+M+WUgVvJDCOkR2DYJp9QbQEk8D6CLXRF5o fN6A== X-Gm-Message-State: ABuFfoiheAL0Z2JIkNniIC6Rz68xrJCxayNimDnP5/UqYJRqsbhJlHHk Lsq8E+sKDRoODkW04Nvq+Te87WrRbKDr86GT0suLHQ== X-Google-Smtp-Source: ACcGV61RwMrxl34dbEAjZcH1qslruyu72SVMqtDYfLsI4cg6GH5KGMxJis3hh9231UKsssXtwaO6euFwQlF3ax6OF2A= X-Received: by 2002:a2e:2a43:: with SMTP id q64-v6mr7146018ljq.153.1538746718070; Fri, 05 Oct 2018 06:38:38 -0700 (PDT) MIME-Version: 1.0 References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> <27454678-1FED-43EC-9D65-72F18487E619@gmail.com> In-Reply-To: <27454678-1FED-43EC-9D65-72F18487E619@gmail.com> From: Eric Rescorla Date: Fri, 5 Oct 2018 06:38:01 -0700 Message-ID: To: Dino Farinacci Cc: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="00000000000087bf2505777b6323" Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 13:38:44 -0000 --00000000000087bf2505777b6323 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 1, 2018 at 11:39 AM Dino Farinacci wrote: > > > > > > IMPORTANT > > > S 5.2. > > >> s: This is the SMR-invoked bit. This bit is set to 1 when an xT= R > is > > >> sending a Map-Request in response to a received SMR-based Map= - > > >> Request. > > >> > > >> m: This is the LISP mobile-node m-bit. This bit is set by xTRs > that > > >> operate as a mobile node as defined in [I-D.ietf-lisp-mn]. > > > > > > This would appear to create a normative reference to this document. T= o > > > avoid that, you need to specify how I behave if I receive it but I > > > don't implement lisp-mn. > > > > I am find making it a normative reference but need the lisp-chairs to > comment. I am not sure what the implications of that are. > > > > Me neither. Seems like it could go either way. My only interest is that > the protocol be unambiguous. > > We are working through removing normative references to working group > drafts. > OK. > > > S 5.5. > > >> is being mapped from a multicast destination EID. > > >> > > >> 5.5. EID-to-RLOC UDP Map-Reply Message > > >> > > >> A Map-Reply returns an EID-Prefix with a prefix length that is > less > > >> than or equal to the EID being requested. The EID being > requested is > > > > > > How do I behave if I receive an EID-Prefix that is less than any of m= y > > > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16 > > > and someone asks me for 10.0.0.0/8? > > > > > I think I'm still unclear on this point. > > The spec says you cache it. That is all you can do. But it means the > sender of the Map-Reply is not spec conformant. That means RLOCs are used > for the coarser EID-prefix. > Sorry, cache it? My question is how to respond to the case where the Map-Request has this property. > > > Also, when you talk about prefix > > > length, I assume you mean the length fo the mask? > > > > Yes, this is explained later in this section. Was that not helpful?? > > > > I found it a bit confusing. It seems to me like there are two lengths > involved here: > > > > - The length of the field (4 or 16) > > - The parts of the field that are significant (i.e., the mask) > > In routing, as you know, the mask-length is always the same as the > prefix-length. It is the number of bits in the mask. > > > I had thought that "prefix length" referred to the former, but it seems > like here it > > refers to the latter. > > The length of the address is defined by the 16-bit AFI that precedes the > address. > I agree, but the text refers to this as the prefix and it has a length, which is the length of the encoded field, not the length of the mask, as seen in this excerpt: EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFI], the length varies and for the LCAF AFI the format is defined in [RFC8060]. When a Map- > > > S 5.6. > > >> Authentication Data: This is the message digest used from the > output > > >> of the MAC algorithm. The entire Map-Register payload is > > >> authenticated with this field preset to 0. After the MAC is > > >> computed, it is placed in this field. Implementations of thi= s > > >> specification MUST include support for HMAC-SHA-1-96 [RFC2404= ], > > >> and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. > > > > > > What prevents replay attacks here? I'm guessing it's the Map-Version- > > > Number, but as I understand it, I can set this to 0. > > > > Well there are many. The nonce can change for each Map-Register sent. > Same for Map-Version number as well as the key-id. > > > > I think you need to describe the precise process of replay prevention > here. > > Not addressing any security issues right now until we have the conference > call. I agree with you and believe we have solutions, we just haven=E2=80= =99t > documented them clearly. And understand why your line of questioning. > Sure, Let's pick this up later. > > > > S 6.1. > > >> receives an SMR-based Map-Request and the source is not in the > > >> Locator-Set for the stored Map-Cache entry, then the responding > Map- > > >> Request MUST be sent with an EID destination to the mapping > database > > >> system. Since the mapping database system is a more secure way = to > > >> reach an authoritative ETR, it will deliver the Map-Request to t= he > > >> authoritative source of the mapping data. > > > > > > If I'm understanding this correctly, this allows an ETR to prevent an > > > ITR from learning that it is no longer the appropriate ETR for a > > > prefix. The way this attack works is that before the topology shift, = I > > > send SMRs, thus causing Map-Requests, which, because my entry is > > > cached, refresh the cache on the ITR past the topology shift. I can > > > keep doing this indefinitely. Am I missing something > > > > Well if the ETR is being spoofed, then there is Map-Request load, but i= t > won=E2=80=99t corrupt the ITR=E2=80=99s map-cache. The ITR always sends a= verifying > Map-Request to the mapping system to get the latest and authenticated > RLOC-set for the mapping. Rate-limiting is necessary so each SMR received > DOES NOT result in a Map-Requerst to the mapping system. > > > > I'm probably just confused here: SMRs go through the mapping system, no= t > directly? If so, I agree that this wont' work. > > SMRs are sent from an xTR that changes its RLOC set to xTRs that might > have EID-prefixes cached. It tells those caching xTRs to do a lookup to t= he > mapping system. So the Map-Request, with S-bit set (an SMR) are sent > directly from xTR to xTR. > Sorry, I misspoke, but i think I get your point. This sounds fine. > > > > > S 5. > > >> \ | UDP Length | UDP Checksum > | > > >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >> | > | > > >> | LISP Message > | > > >> | > | > > >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > What do these two diagrams correspond to? v4 and v6? This needs > > > explanation. > > > > It is th entire IP packet sent as a LISP control-message. The header > before the diagrams indicate they are UDP packets. > > > > A caption would probably help. > > The beginning of the section shows an IPv4 UDP packet format as well as a > IPv6 UDP packet format. > Agreed. I'm just saying you should put in a caption on each of them. > > > > > S 5.2. > > >> receipt. > > >> > > >> L: This is the local-xtr bit. It is used by an xTR in a LISP > site to > > >> tell other xTRs in the same site that it is part of the > RLOC-set > > >> for the LISP site. The L-bit is set to 1 when the RLOC is th= e > > >> sender's IP address. > > > > > > Is the xTR supposed to filter this on exiting the site. > > > > Nope. > > > > Won't this cause problems on ingress to another site? > > No, I don=E2=80=99t think so. But you have to write more words to let me = know what > you are thinking about. > I'm not sure I understand well enough, but it just seems like if you have a bit that says "this is local" that then appears on another network where it's not local, that might cause problems. But if you say it doesn't, then OK > > > > S 5.3. > > >> originating Map-Request source. If the RLOC is not in the > Locator- > > >> Set, then the ETR MUST send the "verifying Map-Request" to the > > >> "piggybacked" EID. Doing this forces the "verifying Map-Request= " > to > > >> go through the mapping database system to reach the authoritativ= e > > >> source of information about that EID, guarding against > RLOC-spoofing > > >> in the "piggybacked" mapping data. > > > > > > This text here doesn't seem compatible with either of the two cases > > > listed in "EID-prefix" above. > > > > I don=E2=80=99t understand the comment Eric. Maybe because I can=E2=80= =99t find the > exact reference to EID-prefix where you think there is a conflict. Please > cite for me. Thanks. > > > > This does seem to have been assigned to the wrong text. > > > > I am referring to: > > > > " A Map-Reply returns an EID-Prefix with a prefix length that is less > > than or equal to the EID being requested. The EID being requested i= s > > either from the destination field of an IP header of a Data-Probe or > > the EID record of a Map-Request. The RLOCs in the Map-Reply are > > " > > > > versus > > > > " EID-Prefix: This prefix is 4 octets for an IPv4 address family and > > 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 > > or 2, respectively. For other AFIs [AFI], the length varies and > > for the LCAF AFI the format is defined in [RFC8060]. When a Map- > > " > > > > This is just the question of whether "prefix length" refers to the fiel= d > or > > the significant bits of the field. > > Prefix-length =3D mask-length =3D number-of-bits-in-mask =3D value-after-= /. > OK, but then this second excerpt seems contradictory. We have an EID-Prefix field which has a different length which is dictated by the AFI only. > > > S 8.3. > > >> of the mapping database protocols. > > >> > > >> 8.3. Map-Server Processing > > >> > > >> Once a Map-Server has EID-Prefixes registered by its client ETRs= , > it > > >> can accept and process Map-Requests for them. > > > > > > This section is confusing because the introduction says that this > > > function is only performed by Map-Resolvers: > > > ' > > > "The LISP Mapping Service defines two new types of LISP-speaking > > > devices: the Map-Resolver, which accepts Map-Requests from an > > > Ingress > > > Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a > > > mapping database; and the Map-Server, which learns authoritative > > > EID- > > > to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes > > > them in a database.=E2=80=9D > > > > The document does cover the operation of a Map-Resolver and a > Map-Server. Some functions are performed only by Map-Resolvers only and > other different functions are performed by Map-Servers only. > > > > I am not sure what you don=E2=80=99t understand. > > > > Sure: As I understand it, Map Resolvers process Map Requests, and Map > Servers do not (that's what the quoted text seems to say). However, this > sentence talks about a Map Server processing a Map Request. That's where= I > am confused. > > Here is a brief scenario: > > (1) ITR sends Map-Request to a Map-Resolver. > (2) Map-Resolver =E2=80=9Cfinds=E2=80=9D the Map-Server where the EID cou= ld be registered. > That is the mapping database transport system, two examples are LISP-ALT > and LISP-DDT. > (3) The Map-Resolver in the case of LISP-DDT, will have a referral-cache > and know which map-server is authoriative for the EID-prefix the > Map-Request EID is for. > (4) The Map-Resolver forwards the Map-Request to that Map-Server. > > And hence Map-Servers process Map-Requests. The Map-Server can proxy-repl= y > with the RLOC-set cached in its site-cache or forward to one or more ETRs > (described by the RLOC-set) so they can map-reply. > Sure, this seems reasonable, but then perhaps the text above could be revised, because it reads like Map Resolvers process these requests and therefore implies that Map-Servers do not. -Ekr > Most of the above is described in the LISP-DDT RFC. For LISP-ALT, the > map-resovler forwards the Map-Request across a tunneled topology where BG= P > is used to tell you where EID-prefixes are registered to what Map-Servers= . > That tunneled toplogy is used for the sole purpose to forward Map-Request= s. > No data-plane involved there. > > Dino > > > --00000000000087bf2505777b6323 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 1, 2018 at 11:39 AM Dino Farinacci <farinacci@gmail.com> wrote:
> >
> > IMPORTANT
> > S 5.2.
> >>=C2=A0 =C2=A0 =C2=A0s: This is the SMR-invoked bit.=C2=A0 This= bit is set to 1 when an xTR is
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sending a Map-Request in response = to a received SMR-based Map-
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Request.
> >>
> >>=C2=A0 =C2=A0 =C2=A0m: This is the LISP mobile-node m-bit.=C2= =A0 This bit is set by xTRs that
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 operate as a mobile node as define= d in [I-D.ietf-lisp-mn].
> >
> > This would appear to create a normative reference to this documen= t. To
> > avoid that, you need to specify how I behave if I receive it but = I
> > don't implement lisp-mn.
>
> I am find making it a normative reference but need the lisp-chairs to = comment. I am not sure what the implications of that are.
>
> Me neither. Seems like it could go either way. My only interest is tha= t the protocol be unambiguous.

We are working through removing normative references to working group draft= s.

OK.

=C2=A0=
> > S 5.5.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 is being mapped from a multicast d= estination EID.
> >>
> >>=C2=A0 5.5.=C2=A0 EID-to-RLOC UDP Map-Reply Message
> >>
> >>=C2=A0 =C2=A0 =C2=A0A Map-Reply returns an EID-Prefix with a p= refix length that is less
> >>=C2=A0 =C2=A0 =C2=A0than or equal to the EID being requested.= =C2=A0 The EID being requested is
> >
> > How do I behave if I receive an EID-Prefix that is less than any = of my
> > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16
> > and someone asks me for 10.0.0.0/8?

>
> I think I'm still unclear on this point.

The spec says you cache it. That is all you can do. But it means the sender= of the Map-Reply is not spec conformant. That means RLOCs are used for the= coarser EID-prefix.

Sorry, cache it? M= y question is how to respond to the case where the Map-Request has this pro= perty.


>
> Also, when you talk about prefix
> > length, I assume you mean the length fo the mask?
>
> Yes, this is explained later in this section. Was that not helpful?? >
> I found it a bit confusing. It seems to me like there are two lengths = involved here:
>
> - The length of the field (4 or 16)
> - The parts of the field that are significant (i.e., the mask)

In routing, as you know, the mask-length is always the same as the prefix-l= ength. It is the number of bits in the mask.


> I had thought that "prefix length" referred to the former, b= ut it seems like here it
> refers to the latter.

The length of the address is defined by the 16-bit AFI that precedes the ad= dress.

I agree, but the text refers to = this as the prefix and it has a length, which is the length of the encoded = field, not the length of the mask, as seen in this excerpt:
<= br>
=C2=A0=C2=A0 EID-Prefix:=C2=A0 This prefix is 4 octets for an= IPv4 address family and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16 octets for an= IPv6 address family when the EID-Prefix-AFI is 1
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 or 2, respectively.=C2=A0 For other AFIs [AFI], the length varies= and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for the LCAF AFI the format is defin= ed in [RFC8060].=C2=A0 When a Map-


<= div>

> > S 5.6.
> >>=C2=A0 =C2=A0 =C2=A0Authentication Data:=C2=A0 This is the mes= sage digest used from the output
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the MAC algorithm.=C2=A0 The en= tire Map-Register payload is
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticated with this field pres= et to 0.=C2=A0 After the MAC is
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 computed, it is placed in this fie= ld.=C2=A0 Implementations of this
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 specification MUST include support= for HMAC-SHA-1-96 [RFC2404],
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 and support for HMAC-SHA-256-128 [= RFC4868] is RECOMMENDED.
> >
> > What prevents replay attacks here? I'm guessing it's the = Map-Version-
> > Number, but as I understand it, I can set this to 0.
>
> Well there are many. The nonce can change for each Map-Register sent. = Same for Map-Version number as well as the key-id.
>
> I think you need to describe the precise process of replay prevention = here.

Not addressing any security issues right now until we have the conference c= all. I agree with you and believe we have solutions, we just haven=E2=80=99= t documented them clearly. And understand why your line of questioning.
=

Sure, Let's pick this up later.=C2=A0<= /div>


>
> > S 6.1.
> >>=C2=A0 =C2=A0 =C2=A0receives an SMR-based Map-Request and the = source is not in the
> >>=C2=A0 =C2=A0 =C2=A0Locator-Set for the stored Map-Cache entry= , then the responding Map-
> >>=C2=A0 =C2=A0 =C2=A0Request MUST be sent with an EID destinati= on to the mapping database
> >>=C2=A0 =C2=A0 =C2=A0system.=C2=A0 Since the mapping database s= ystem is a more secure way to
> >>=C2=A0 =C2=A0 =C2=A0reach an authoritative ETR, it will delive= r the Map-Request to the
> >>=C2=A0 =C2=A0 =C2=A0authoritative source of the mapping data.<= br> > >
> > If I'm understanding this correctly, this allows an ETR to pr= event an
> > ITR from learning that it is no longer the appropriate ETR for a<= br> > > prefix. The way this attack works is that before the topology shi= ft, I
> > send SMRs, thus causing Map-Requests, which, because my entry is<= br> > > cached, refresh the cache on the ITR past the topology shift. I c= an
> > keep doing this indefinitely. Am I missing something
>
> Well if the ETR is being spoofed, then there is Map-Request load, but = it won=E2=80=99t corrupt the ITR=E2=80=99s map-cache. The ITR always sends = a verifying Map-Request to the mapping system to get the latest and authent= icated RLOC-set for the mapping. Rate-limiting is necessary so each SMR rec= eived DOES NOT result in a Map-Requerst to the mapping system.
>
> I'm probably just confused here: SMRs go through the mapping syste= m, not directly? If so, I agree that this wont' work.

SMRs are sent from an xTR that changes its RLOC set to xTRs that might have= EID-prefixes cached. It tells those caching xTRs to do a lookup to the map= ping system. So the Map-Request, with S-bit set (an SMR) are sent directly = from xTR to xTR.

Sorry, I misspoke, but= i think I get your point. This sounds fine.


>
> > S 5.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0\ |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0UDP Length=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 UDP Checksum=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LISP Message= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > What do these two diagrams correspond to? v4 and v6? This needs > > explanation.
>
> It is th entire IP packet sent as a LISP control-message. The header b= efore the diagrams indicate they are UDP packets.
>
> A caption would probably help.

The beginning of the section shows an IPv4 UDP packet format as well as a I= Pv6 UDP packet format.

Agreed. I'm = just saying you should put in a caption on each of them.


> >
> > S 5.2.
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 receipt.
> >>
> >>=C2=A0 =C2=A0 =C2=A0L: This is the local-xtr bit.=C2=A0 It is = used by an xTR in a LISP site to
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 tell other xTRs in the same site t= hat it is part of the RLOC-set
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for the LISP site.=C2=A0 The L-bit= is set to 1 when the RLOC is the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sender's IP address.
> >
> > Is the xTR supposed to filter this on exiting the site.
>
> Nope.
>
> Won't this cause problems on ingress to another site?

No, I don=E2=80=99t think so. But you have to write more words to let me kn= ow what you are thinking about.

I'm= not sure I understand well enough, but it just seems like if you have a bi= t that says "this is local" that then appears on another network = where it's not local, that might cause problems. But if you say it does= n't, then OK


>=C2=A0
> > S 5.3.
> >>=C2=A0 =C2=A0 =C2=A0originating Map-Request source.=C2=A0 If t= he RLOC is not in the Locator-
> >>=C2=A0 =C2=A0 =C2=A0Set, then the ETR MUST send the "veri= fying Map-Request" to the
> >>=C2=A0 =C2=A0 =C2=A0"piggybacked" EID.=C2=A0 Doing t= his forces the "verifying Map-Request" to
> >>=C2=A0 =C2=A0 =C2=A0go through the mapping database system to = reach the authoritative
> >>=C2=A0 =C2=A0 =C2=A0source of information about that EID, guar= ding against RLOC-spoofing
> >>=C2=A0 =C2=A0 =C2=A0in the "piggybacked" mapping dat= a.
> >
> > This text here doesn't seem compatible with either of the two= cases
> > listed in "EID-prefix" above.
>
> I don=E2=80=99t understand the comment Eric. Maybe because I can=E2=80= =99t find the exact reference to EID-prefix where you think there is a conf= lict. Please cite for me. Thanks.
>
> This does seem to have been assigned to the wrong text.
>
> I am referring to:
>
> "=C2=A0 =C2=A0A Map-Reply returns an EID-Prefix with a prefix len= gth that is less
>=C2=A0 =C2=A0 than or equal to the EID being requested.=C2=A0 The EID b= eing requested is
>=C2=A0 =C2=A0 either from the destination field of an IP header of a Da= ta-Probe or
>=C2=A0 =C2=A0 the EID record of a Map-Request.=C2=A0 The RLOCs in the M= ap-Reply are
> "
>
> versus
>
> "=C2=A0 =C2=A0EID-Prefix:=C2=A0 This prefix is 4 octets for an IP= v4 address family and
>=C2=A0 =C2=A0 =C2=A0 =C2=A016 octets for an IPv6 address family when th= e EID-Prefix-AFI is 1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0or 2, respectively.=C2=A0 For other AFIs [AF= I], the length varies and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for the LCAF AFI the format is defined in [R= FC8060].=C2=A0 When a Map-
> "
>
> This is just the question of whether "prefix length" refers = to the field or
> the significant bits of the field.

Prefix-length =3D mask-length =3D number-of-bits-in-mask =3D value-after-/.=

OK, but then this second excerpt seems= contradictory. We have an EID-Prefix field which has a different length wh= ich is dictated by the AFI only.


> > S 8.3.
> >>=C2=A0 =C2=A0 =C2=A0of the mapping database protocols.
> >>
> >>=C2=A0 8.3.=C2=A0 Map-Server Processing
> >>
> >>=C2=A0 =C2=A0 =C2=A0Once a Map-Server has EID-Prefixes registe= red by its client ETRs, it
> >>=C2=A0 =C2=A0 =C2=A0can accept and process Map-Requests for th= em.
> >
> > This section is confusing because the introduction says that this=
> > function is only performed by Map-Resolvers:
> > '
> > "The LISP Mapping Service defines two new types of LISP-spea= king
> >=C2=A0 =C2=A0devices: the Map-Resolver, which accepts Map-Requests= from an
> > Ingress
> >=C2=A0 =C2=A0Tunnel Router (ITR) and "resolves" the EID-= to-RLOC mapping using a
> >=C2=A0 =C2=A0mapping database; and the Map-Server, which learns au= thoritative
> > EID-
> >=C2=A0 =C2=A0to-RLOC mappings from an Egress Tunnel Router (ETR) a= nd publishes
> >=C2=A0 =C2=A0them in a database.=E2=80=9D
>
> The document does cover the operation of a Map-Resolver and a Map-Serv= er. Some functions are performed only by Map-Resolvers only and other diffe= rent functions are performed by Map-Servers only.
>
> I am not sure what you don=E2=80=99t understand.
>
> Sure: As I understand it, Map Resolvers process Map Requests, and Map = Servers do not (that's what the quoted text seems to say). However, thi= s sentence talks about a Map Server processing a Map Request.=C2=A0 That= 9;s where I am confused.

Here is a brief scenario:

(1) ITR sends Map-Request to a Map-Resolver.
(2) Map-Resolver =E2=80=9Cfinds=E2=80=9D the Map-Server where the EID could= be registered. That is the mapping database transport system, two examples= are LISP-ALT and LISP-DDT.
(3) The Map-Resolver in the case of LISP-DDT, will have a referral-cache an= d know which map-server is authoriative for the EID-prefix the Map-Request = EID is for.
(4) The Map-Resolver forwards the Map-Request to that Map-Server.

And hence Map-Servers process Map-Requests. The Map-Server can proxy-reply = with the RLOC-set cached in its site-cache or forward to one or more ETRs (= described by the RLOC-set) so they can map-reply.

=
Sure, this seems reasonable, but then perhaps the text above cou= ld be revised, because it reads like Map Resolvers process these requests a= nd therefore implies that Map-Servers do not.

-Ekr=


Most of the above is described in the LISP-DDT RFC. For LISP-ALT, the map-r= esovler forwards the Map-Request across a tunneled topology where BGP is us= ed to tell you where EID-prefixes are registered to what Map-Servers. That = tunneled toplogy is used for the sole purpose to forward Map-Requests. No d= ata-plane involved there.

Dino


--00000000000087bf2505777b6323-- From nobody Sun Oct 7 14:58:39 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB4312777C for ; Sun, 7 Oct 2018 14:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 Y4isucf6hlMV for ; Sun, 7 Oct 2018 14:58:34 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA7F127332 for ; Sun, 7 Oct 2018 14:58:33 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id a13-v6so18723938wrt.5 for ; Sun, 07 Oct 2018 14:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:references:to:date; bh=1PGhPy76LhOIL4MFoDmRHouGv6ObWioRriMPcaZoPkU=; b=hyb+prO1aBlkTh2HyY04mHJzygjWR1hvua7II9Yhi0Sk/EAu8UbW3HNg9NX+41IdTo ZsISZ2+ZHrrzAX4ehjPi+N0nNs8DozIKZkN10wLyJrKmU5xQl7LXitOZAO2OphAv5c5w U3VFzSJ9tMqt2HCZSEL09nqHC1AQrf1rxHq+xxEjHSiJALNKvOE2FzDt0dAC6mvR/8yU dujAXIjn2f8u6bmOgAlVXoru1wBbpxbOp0WImrU3NR6YRO5LY2Gh42A1CTw/XyRhRhNW RoCGAGb1xOZvkIhMZACi6DjzSHHLpPyY0j9gIAsbqdJsnvizhmDkCCm6kV2h0jSPhSQN LL4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=1PGhPy76LhOIL4MFoDmRHouGv6ObWioRriMPcaZoPkU=; b=Joo5j/ail5MlxLIfV7gUKJbF+Buafu1373FY1OJszoC133uxA37jPtICxpStSFjoBY fMR5mxeqORntSmam+lyO9O9GKybNbgVzkI6XlNWhHPJil76ASDr/jWK7piGNG621rapN wRuyhVay2CXI3Z3cP7yfesUyAeTvnc0TMj74fHp7LgYpX6ve71MGPWtkQKJEBd8cB7xV 8qQjgmdWugKK6BioW0VVt7tQ3RP+Z6FIKPn1EC3KHazgmkwWT5mzkdRThuXl/OS5NQF3 meag0MhxkuBmAzxn/p7XhWPB05oUz6AbIoLUEgrEENhkN5oJ6YgE3JTbIvOwv15qDvtm iRXQ== X-Gm-Message-State: ABuFfoiyq3DfIVkcoLsJPnDdVq6lbBHLOn6CV8dLAl+kkkK8j3cAJ8UX 7Wrmnh0BojQdq89+7ulc+2JgOQc3CxQ= X-Google-Smtp-Source: ACcGV62fCgCDDIJrtsbuiU/d6Ht+3M7fAj7zuu8iSie1D2z3Sap10yUWvfaVSyUY0kdBPRwKbBMbVg== X-Received: by 2002:a5d:4101:: with SMTP id l1-v6mr15423358wrp.45.1538949511552; Sun, 07 Oct 2018 14:58:31 -0700 (PDT) Received: from [192.168.21.212] (dmz02.dagstuhl.de. [192.76.146.51]) by smtp.gmail.com with ESMTPSA id y19-v6sm6597467wra.60.2018.10.07.14.58.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Oct 2018 14:58:29 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_6BDC1DA4-72B8-45DE-B491-9A1C72E6C253" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Message-Id: <1B08CE0F-6AA0-49C1-8A36-F562844F83DD@gigix.net> References: <153877793727.1026.1146854495726676148.idtracker@ietfa.amsl.com> To: "lisp@ietf.org list" Date: Sun, 7 Oct 2018 23:58:28 +0200 X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: [lisp] [Call for Agenda Items] IETF 103 Preliminary Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 21:58:38 -0000 --Apple-Mail=_6BDC1DA4-72B8-45DE-B491-9A1C72E6C253 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Folks, The preliminary agenda has been published. We will meet Monday Morning 5 November. While the agenda is still subject to changes it is time to think about = presentation slots. Please send your requests for agenda items (Presenter=E2=80=99s name, = title, slot duration)=20 to lisp-chairs@tools.ietf.org Ciao L. > Begin forwarded message: >=20 > From: IETF Agenda > Subject: [Recentattendees] IETF 103 Preliminary Agenda > Date: 6 October 2018 at 00:18:57 CEST > To: "IETF Announcement List" > Cc: recentattendees@ietf.org, ietf@ietf.org, 103all@ietf.org > Reply-To: agenda@ietf.org >=20 > IETF 103 > Bangkok, Thailand > November 3-9, 2018 > Hosts: Huawei and Cisco >=20 > The IETF 103 Preliminary Agenda has been posted. The final agenda will = be published on Friday, October 12, 2018.=20 >=20 > https://datatracker.ietf.org/meeting/103/agenda.html > https://datatracker.ietf.org/meeting/103/agenda.txt >=20 >=20 > IETF 103 Information: https://www.ietf.org/how/meetings/103/ > Register online at: https://www.ietf.org/how/meetings/register/ >=20 > Don=E2=80=99t forget to register for these exciting IETF 103 events! >=20 > Hackathon=20 > Signup: = https://www.ietf.org/registration/ietf103/hackathonregistration.py > More information: = https://www.ietf.org/how/runningcode/hackathons/103-hackathon/ > Keep up to date by subscribing to:=20 > https://www.ietf.org/mailman/listinfo/hackathon >=20 > Code Sprint > Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103SprintSignUp > More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103Sprint >=20 > _______________________________________________ > Recentattendees mailing list > Recentattendees@ietf.org > https://www.ietf.org/mailman/listinfo/recentattendees --Apple-Mail=_6BDC1DA4-72B8-45DE-B491-9A1C72E6C253 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Folks,

The = preliminary agenda has been published.
We will meet = Monday Morning 5 November.

While the agenda is still subject to changes it is time to = think about presentation slots.

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

Ciao

L.

Begin = forwarded message:

From: = IETF Agenda <agenda@ietf.org>
Subject: = [Recentattendees] = IETF 103 Preliminary Agenda
Date: = 6 October 2018 at 00:18:57 = CEST
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: recentattendees@ietf.org, ietf@ietf.org, 103all@ietf.org
Reply-To: = agenda@ietf.org

IETF 103
Bangkok, Thailand
November= 3-9, 2018
Hosts: Huawei and Cisco

The IETF 103 Preliminary Agenda has been posted. The final = agenda will be published on Friday, October 12, 2018.

https://datatracker.ietf.org/meeting/103/agenda.html
https://datatracker.ietf.org/meeting/103/agenda.txt


IETF 103 Information: = https://www.ietf.org/how/meetings/103/
Register online at: = https://www.ietf.org/how/meetings/register/

Don=E2=80=99t forget to register for these exciting IETF 103 = events!

Hackathon
Signup: = https://www.ietf.org/registration/ietf103/hackathonregistration.py
= More information: = https://www.ietf.org/how/runningcode/hackathons/103-hackathon/
= Keep up to date by subscribing to:
= https://www.ietf.org/mailman/listinfo/hackathon

Code Sprint
Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103SprintSignUp
= More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103Sprint

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

= --Apple-Mail=_6BDC1DA4-72B8-45DE-B491-9A1C72E6C253-- From nobody Mon Oct 8 00:52:04 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2F612F295 for ; Mon, 8 Oct 2018 00:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 XqUUJfNWP4fk for ; Mon, 8 Oct 2018 00:52:00 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7AE812F1A6 for ; Mon, 8 Oct 2018 00:51:59 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id z204-v6so7260814wmc.5 for ; Mon, 08 Oct 2018 00:51:59 -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=mHA8znQRNNQH3Jv2vEHjRX7irfy4ksEN20FmrHDrK4c=; b=cpUjGdHbwSvX5Db48zd90p6qfr2/7nWbekonP9PlLERCku1rUKwXwwbloc2Ay2pkLa jdJ7xLrym5jNTLCZWQofvGiTF+xFCJgZJUCrHIZhkyfQhaCsFwe+5LCRgB1APKKfpm+t XKApqTOdLxG2bLsxmZRRTWV8351JXOZhTU9jjKTTu7dYq5czT8QUPOwYVebepohOzlUb X8QH6yv5xW0WpSeHSNyAs+opVhUFNMaSCBe7dPgmsU0LzQTrvEXDoE100DKVQd27qvxj QCJpt082VXZDfGjiFyvXExMOMdNB37TLIq1iFBXhBBPyx1Yl6sAT5I74yQ2hIfJlS05+ X34Q== 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=mHA8znQRNNQH3Jv2vEHjRX7irfy4ksEN20FmrHDrK4c=; b=ui68cZHG0xyisAnXSDkBm4P3px8lPNOwuGjvJ4WupsgRIhcloGAAeEAYQHff3l79tc 9cH6+vMX4hO87MiYCFFQU+ilvekWKyOErB3W8/dPfgITpk6eG/EJY6q9bJe8YrQbILOK oCnbu4BlwIKE3rPg62NIwu0aH2ta2Eybt31sCkUO6aHlI96dCSAEiWyu6hv40jzsHqzg nuRSpDmdFg/KzffRYbTcyNc9mJgdKGecbNk7wo2iz9Am1YZPW3M1aavAiqDM0LfmO17k OnST8Ron2n/IGNsIi8M4S4h2O7u2JdFJED9ffjNYAAtjlsjg3fBT1cEV/iieP1gk0tIb b+HA== X-Gm-Message-State: ABuFfojeW2d2mb7ZChac+lK6TU/EIs9S8kb4rqZHGVg2Xf4X4vS+YsgZ fHXMPJdP+hyiNsmqQ/yBn0LUxuSrKH9+KS/H X-Google-Smtp-Source: ACcGV61ftQPrdAnxPFwY9gJIt5dBSxMVzuXDAXswMS8NTjSeNINhNbS+rg0KZnPSEUOSsYloUHPyXA== X-Received: by 2002:a1c:2384:: with SMTP id j126-v6mr14298817wmj.124.1538985117591; Mon, 08 Oct 2018 00:51:57 -0700 (PDT) Received: from [192.168.21.212] (dmz02.dagstuhl.de. [192.76.146.51]) by smtp.gmail.com with ESMTPSA id r128-v6sm6871064wma.40.2018.10.08.00.51.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Oct 2018 00:51:55 -0700 (PDT) From: Luigi Iannone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_67B2B96B-91DB-4ED6-AC52-65262A704F59" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 8 Oct 2018 09:51:54 +0200 In-Reply-To: <44201301-8E2D-4649-8483-5418A8CFC138@gigix.net> Cc: lisp-chairs@ietf.org, "BRUNGARD, DEBORAH A" To: "lisp@ietf.org list" References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> <44201301-8E2D-4649-8483-5418A8CFC138@gigix.net> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] WGLC fo draft-ietf-lisp-rfc8113bis-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 07:52:02 -0000 --Apple-Mail=_67B2B96B-91DB-4ED6-AC52-65262A704F59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Folks, WG Last Call for 8113bis has been out for more than a week and we did = not receive any feedback. Remember that silence is NOT consensus. Please ALL , thake 5 minutes to read this very short document and send feedback on = whether or not you think the document is ready to be published. Thanks Luigi > On 27 Sep 2018, at 11:02, Luigi Iannone wrote: >=20 > Well, >=20 > Authors were pretty quick =E2=80=A6 >=20 > This email open the one week WG Last Call for the document = draft-ietf-lisp-rfc8113bis-00.txt >=20 > Please review this WG document and let the WG know if you agree that = it is ready for handing to the AD. > If you have objections, please state your reasons why, and explain = what it would take to address your concerns. >=20 > Ciao >=20 > L. >=20 >> On 27 Sep 2018, at 10:22, Luigi Iannone > wrote: >>=20 >> All, >>=20 >> one week is over and we received several email in support adoption of = this document. >>=20 >> Because of such consensus the authors are invited to submit a = document named draft-ietf-lisp-rfc8113bis-00.txt. >>=20 >> As soon as the new document is available we will start the WG Last = Call, as already said in my previous mail. >>=20 >> Ciao >>=20 >> L. >>=20 >>=20 >>> On 19 Sep 2018, at 17:04, Luigi Iannone > wrote: >>>=20 >>> Folks, >>>=20 >>> here is another piece of the work done in our WG that needs to be = moved to PS. >>>=20 >>> It is the updated version of RFC 8113, nothing changed just updated = coherently with the current status of the other documents. >>>=20 >>> Because this documents is really really short we will have just one = week adoption call followed be one week WG Last Call. >>>=20 >>> This email officially starts the one week call for adoption. >>>=20 >>> Please spend 10 minutes having a look at the document and send an = email on whether you agree or not to adopt it. >>>=20 >>> Thanks >>>=20 >>> Ciao >>>=20 >>> Luigi >>>=20 >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> From: internet-drafts@ietf.org >>>> Subject: I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt >>>> Date: 19 September 2018 at 16:49:31 CEST >>>> To: > >>>> Reply-To: internet-drafts@ietf.org = >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>=20 >>>>=20 >>>> Title : Locator/ID Separation Protocol (LISP): = Shared Extension Message & IANA Registry for Packet Type Allocations >>>> Authors : Mohamed Boucadair >>>> Christian Jacquenet >>>> Filename : draft-boucadair-lisp-rfc8113bis-01.txt >>>> Pages : 5 >>>> Date : 2018-09-19 >>>>=20 >>>> Abstract: >>>> This document specifies a Locator/ID Separation Protocol (LISP) >>>> shared message type for defining future extensions and conducting >>>> experiments without consuming a LISP packet type codepoint for = each >>>> extension. >>>>=20 >>>> This document obsoletes RFC 8113. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/ = >>>>=20 >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01 = >>>> = https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01 = = >>>>=20 >>>> A diff from the previous version is available at: >>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc8113bis-01 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >>=20 >=20 --Apple-Mail=_67B2B96B-91DB-4ED6-AC52-65262A704F59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Folks,

WG = Last Call for 8113bis has been out for more than a week and we did not = receive any feedback.

Remember that silence is NOT consensus.

Please ALL ,
thake 5 minutes to read this very short document and send = feedback on whether or not you think the document is ready to be = published.

Thanks

Luigi

On 27 Sep 2018, at 11:02, Luigi = Iannone <ggx@gigix.net> wrote:

Well,
Authors were pretty quick = =E2=80=A6

This = email open the one week WG Last Call for the = document draft-ietf-lisp-rfc8113bis-00.txt

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

Ciao

L.

On 27 = Sep 2018, at 10:22, Luigi Iannone <ggx@gigix.net> wrote:

All,

one week is over and we received = several email in support adoption of this document.

Because of such = consensus the authors are invited to submit a document named = draft-ietf-lisp-rfc8113bis-00.txt.

As soon as the new document is = available we will start the WG Last Call, as already said in my previous = mail.

Ciao

L.


On 19 = Sep 2018, at 17:04, Luigi Iannone <ggx@gigix.net> wrote:

Folks,

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

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

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

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

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

Thanks

Ciao

Luigi


Begin forwarded message:

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


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


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

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

  This = document obsoletes RFC 8113.


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

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

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


Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

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

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




= --Apple-Mail=_67B2B96B-91DB-4ED6-AC52-65262A704F59-- From nobody Mon Oct 8 09:35:20 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEF9130E8E; Mon, 8 Oct 2018 09:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mTp60SC3bg-L; Mon, 8 Oct 2018 09:35:14 -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 AF5CA130DC0; Mon, 8 Oct 2018 09:35:14 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id f29-v6so5756392pff.5; Mon, 08 Oct 2018 09:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yVSW9WM2fWECHmQ+mCZwbaxF1YgeCCSvakEZhgIHu3A=; b=XYAtplviM1aFvcw4tVytMl68VdUSIJG2hbQThuJ3QPxxk4X5gaodlg305SeaQkq6jL XjGE9g7/fwAFHV+UW3O5X5EWJeW8q7WTJ4XczGXDMcb3mmelyRSGhpGNdMoPotrC9ap0 4YcN+QM9rfJzQFF/UiZNzjASCIbqFatFqogSgnK4GsoItnvRPY5FYWsw9rSy1wRz4uE+ QYhrQWrZxzYVOQY+laaZmpasx4P/VrAXgYw79nxudmUiz5nMrQEmH6GmEX3S7n7QRXJl 3CoGgB5gA6blL3V5wu+fffkqdSYuh9jEufAwhiM3uu1BP2YyGDOGBsdJ7CUkiEQLfZzr PmMA== 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=yVSW9WM2fWECHmQ+mCZwbaxF1YgeCCSvakEZhgIHu3A=; b=SEPP/nvcHrTeeh57V/mi1h5dxHT9t9CwA4FZQ0/Mqm/h7yxMPA8B0nwjVAPXNEodwN +p3fFRsgh9t+hjdCjJlrugWNuLlO2LiHoSpvV+zsKQ+f5+AtjMareaihDTxfWd+DsamU EUrz2HFxlnSa5as8xytcjWt8kamy9RNrSV6g59VXmcKwpv76ILCHROaD4HPFpb/PMjMO 0uU8413Nun+iuMa0dYHoyUjfVWTDKcXh7omP7xTwdKbgVHXESz/N0lk7HwjNsL8QOm9z QNv4/drZxJKcZfMrms/ZeKdwHjWnaJXqZKTlatNhbsw9l+ijC4mjm6mlBus8VOYEefnK k6yg== X-Gm-Message-State: ABuFfoisjDfJINlCwAxOGFocR5e1N7pjCcPCgNuPru6EjvFfxL0wkIGF nxq8WIsGP8TD3JNWBhG+Qgw= X-Google-Smtp-Source: ACcGV61R8Jd/Tvza2/wBu2lv6xcxZtdSlsi4zUkUdjSlYjbeFwL1Ofp5/gs+g7sXA855U4ofpZ5FBA== X-Received: by 2002:a62:1906:: with SMTP id 6-v6mr26575308pfz.9.1539016514232; Mon, 08 Oct 2018 09:35:14 -0700 (PDT) Received: from [10.31.79.225] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id f193-v6sm29204890pfc.74.2018.10.08.09.35.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Oct 2018 09:35:13 -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, 8 Oct 2018 09:35:11 -0700 Cc: "lisp@ietf.org list" , lisp-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <156C1EC6-2351-421D-BEFE-049FB6B38837@gmail.com> References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> <44201301-8E2D-4649-8483-5418A8CFC138@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] WGLC fo draft-ietf-lisp-rfc8113bis-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 16:35:19 -0000 I believe it 8113bis is ready to be published. Dino > On Oct 8, 2018, at 12:51 AM, Luigi Iannone wrote: >=20 > Folks, >=20 > WG Last Call for 8113bis has been out for more than a week and we did = not receive any feedback. >=20 > Remember that silence is NOT consensus. >=20 > Please ALL , > thake 5 minutes to read this very short document and send feedback on = whether or not you think the document is ready to be published. >=20 > Thanks >=20 > Luigi >=20 >> On 27 Sep 2018, at 11:02, Luigi Iannone wrote: >>=20 >> Well, >>=20 >> Authors were pretty quick =E2=80=A6 >>=20 >> This email open the one week WG Last Call for the document = draft-ietf-lisp-rfc8113bis-00.txt >>=20 >> Please review this WG document and let the WG know if you agree that = it is ready for handing to the AD. >> If you have objections, please state your reasons why, and explain = what it would take to address your concerns. >>=20 >> Ciao >>=20 >> L. >>=20 >>> On 27 Sep 2018, at 10:22, Luigi Iannone wrote: >>>=20 >>> All, >>>=20 >>> one week is over and we received several email in support adoption = of this document. >>>=20 >>> Because of such consensus the authors are invited to submit a = document named draft-ietf-lisp-rfc8113bis-00.txt. >>>=20 >>> As soon as the new document is available we will start the WG Last = Call, as already said in my previous mail. >>>=20 >>> Ciao >>>=20 >>> L. >>>=20 >>>=20 >>>> On 19 Sep 2018, at 17:04, Luigi Iannone wrote: >>>>=20 >>>> Folks, >>>>=20 >>>> here is another piece of the work done in our WG that needs to be = moved to PS. >>>>=20 >>>> It is the updated version of RFC 8113, nothing changed just updated = coherently with the current status of the other documents. >>>>=20 >>>> Because this documents is really really short we will have just one = week adoption call followed be one week WG Last Call. >>>>=20 >>>> This email officially starts the one week call for adoption. >>>>=20 >>>> Please spend 10 minutes having a look at the document and send an = email on whether you agree or not to adopt it. >>>>=20 >>>> Thanks >>>>=20 >>>> Ciao >>>>=20 >>>> Luigi >>>>=20 >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Subject: I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt >>>>> Date: 19 September 2018 at 16:49:31 CEST >>>>> To: >>>>> Reply-To: internet-drafts@ietf.org >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>>=20 >>>>>=20 >>>>> Title : Locator/ID Separation Protocol (LISP): = Shared Extension Message & IANA Registry for Packet Type Allocations >>>>> Authors : Mohamed Boucadair >>>>> Christian Jacquenet >>>>> Filename : draft-boucadair-lisp-rfc8113bis-01.txt >>>>> Pages : 5 >>>>> Date : 2018-09-19 >>>>>=20 >>>>> Abstract: >>>>> This document specifies a Locator/ID Separation Protocol (LISP) >>>>> shared message type for defining future extensions and = conducting >>>>> experiments without consuming a LISP packet type codepoint for = each >>>>> extension. >>>>>=20 >>>>> This document obsoletes RFC 8113. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/ >>>>>=20 >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01 >>>>> = https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc8113bis-01 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of = submission >>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Oct 8 17:15:26 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 605A713104E; Mon, 8 Oct 2018 17:15:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153904412529.18486.17773166736533494150@ietfa.amsl.com> Date: Mon, 08 Oct 2018 17:15:25 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-vendor-lcaf-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 00:15:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : Vendor Specific LISP Canonical Address Format (LCAF) Authors : Alberto Rodriguez-Natal Vina Ermagan Anton Smirnov Vrushali Ashtaputre Dino Farinacci Filename : draft-ietf-lisp-vendor-lcaf-03.txt Pages : 6 Date : 2018-10-08 Abstract: This document describes a new LISP Canonical Address Format (LCAF), the Vendor Specific LCAF. This LCAF enables organizations to have internal encodings for LCAF addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-vendor-lcaf/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-vendor-lcaf-03 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-vendor-lcaf-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-vendor-lcaf-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 8 17:41: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 3ADA9130F63; Mon, 8 Oct 2018 17:41: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 cIl6_D1jod61; Mon, 8 Oct 2018 17:41:43 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 53146130E16; Mon, 8 Oct 2018 17:41:43 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id n31-v6so8567389pgm.7; Mon, 08 Oct 2018 17:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GZRGvQPg1O4U2hVrc6hRozdPaqsLDvkHbn8vHOg3T2s=; b=tQJXNTA2Rfs83+LTIN3slS8hZo1oxsrr7Bt7s7zzn2h3prfKBsSRhDe1Tw7Mo85C22 KFRlq3D9GLQR/Cc7IeLro2pExeZ4WjEogIsLVcc5dJP33YUapcySu55L+8x4pJdl5tYQ DD3uNhGZ2wDPJavmY+kxFeaHl6JsC7Exxemtxys0MRXZJPzdhmbIzgUkcCs9rcEsbgDY BcxmEPknL5TK3BOnHQUG5t5SM/+haW410z8qwP/w2Y/w/+bD3IUc8t9sHS+45MdsB8l4 DshfQeKcQsujTXe0uHZG+NtcZ9323iUYovHad2/m8G8ZW4Fl3f1dVGG58QURobfouT+R y6Uw== 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=GZRGvQPg1O4U2hVrc6hRozdPaqsLDvkHbn8vHOg3T2s=; b=V2DFC5fwMp/WZB6Q8VZzldtq3sO9Y4WjZ/PTTMfbtMXoLueb0qn2YC9BiyOnbFag/Z tpS9IZ5E2yyytISC10lquSTNI4uNRMLwSv829+NexTn0fX6vi1fd1P3B4VTZ4OU8KmtW 0ymk3mDZHPLMlphXrjFOWHhjsGe4Slu62ZfXTlaAiDhijTyCSsFsyr4KnDUCATdcr/F3 P+FCEX9bkxycCQXzLKvFM7FV5yj1h5Af+eqrhmRMAXIQ81LhqlSGOeYV8DGDJ/Qtqi6c 4ZzOR/nAVGiOrLspjoJgklNv4PiQtSghxTje5MGFRO1m/jgYJ7EVs4LLsGykGdbkh2QZ 04tA== X-Gm-Message-State: ABuFfojOwkCWANiBWGOatruHqVcffRn4Lc6w5qqfKTOSCqWQug6rkvUZ LUFq91vcOoTRWbfPY/KWPsztaQtR X-Google-Smtp-Source: ACcGV61XuaaSPvSpP7Q12fmcFZ7RIJOPh6PJ+xFTGfoL2AwbfW/Q/l7pbp1vUISdVaevoyb/ydx8aA== X-Received: by 2002:a62:2458:: with SMTP id r85-v6mr27944386pfj.30.1539045702606; Mon, 08 Oct 2018 17:41:42 -0700 (PDT) Received: from ?IPv6:2603:3024:151c:55f0:6c34:62cc:9f7d:1f1d? ([2603:3024:151c:55f0:6c34:62cc:9f7d:1f1d]) by smtp.gmail.com with ESMTPSA id b3-v6sm25939486pfb.151.2018.10.08.17.41.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Oct 2018 17:41:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Mon, 8 Oct 2018 17:41:39 -0700 Cc: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <923B651B-873C-434D-91BC-2727E8130258@gmail.com> References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> <27454678-1FED-43EC-9D65-72F18487E619@gmail.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 00:41:47 -0000 Sorry the delay Eric. >=20 > > > S 5.5. > > >> is being mapped from a multicast destination EID. > > >>=20 > > >> 5.5. EID-to-RLOC UDP Map-Reply Message > > >>=20 > > >> A Map-Reply returns an EID-Prefix with a prefix length that = is less > > >> than or equal to the EID being requested. The EID being = requested is > > >=20 > > > How do I behave if I receive an EID-Prefix that is less than any = of my > > > mappings. So, I might have mappings for 10.1.0.0/16 and = 10.2.0.0/16 > > > and someone asks me for 10.0.0.0/8? >=20 > >=20 > > I think I'm still unclear on this point. >=20 > The spec says you cache it. That is all you can do. But it means the = sender of the Map-Reply is not spec conformant. That means RLOCs are = used for the coarser EID-prefix. >=20 > Sorry, cache it? My question is how to respond to the case where the = Map-Request has this property. I thought you were referring to the Map-Reply. If a Map-Request is sent = for 10.0.0.0/8 a replier needs to return in a Map-Reply /8, if it is = registered in the mapping system as well as all more specifics. That is = seldom done since a Map-Request is triggered for a destination EID in an = IP packet, but a =E2=80=9Clig=E2=80=9D client to ask to see if the = coarser prefix exists. > >=20 > > Also, when you talk about prefix > > > length, I assume you mean the length fo the mask? > >=20 > > Yes, this is explained later in this section. Was that not helpful?? > >=20 > > I found it a bit confusing. It seems to me like there are two = lengths involved here: > >=20 > > - The length of the field (4 or 16) > > - The parts of the field that are significant (i.e., the mask) >=20 > In routing, as you know, the mask-length is always the same as the = prefix-length. It is the number of bits in the mask. >=20 >=20 > > I had thought that "prefix length" referred to the former, but it = seems like here it > > refers to the latter. >=20 > The length of the address is defined by the 16-bit AFI that precedes = the address. >=20 > I agree, but the text refers to this as the prefix and it has a = length, which is the length of the encoded field, not the length of the = mask, as seen in this excerpt: >=20 > EID-Prefix: This prefix is 4 octets for an IPv4 address family and > 16 octets for an IPv6 address family when the EID-Prefix-AFI is = 1 > or 2, respectively. For other AFIs [AFI], the length varies and > for the LCAF AFI the format is defined in [RFC8060]. When a = Map- I will make this more clear. Thanks for the comment. Fixed in the = section you cite and make it more clear the different of =E2=80=9Caddress = length=E2=80=9D and =E2=80=9Cmask length=E2=80=9D in the = =E2=80=9CEID-Prefix=E2=80=9D definition. > >=20 > > > S 5. > > >> \ | UDP Length | UDP Checksum = | > > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >> | = | > > >> | LISP Message = | > > >> | = | > > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > > What do these two diagrams correspond to? v4 and v6? This needs > > > explanation. > >=20 > > It is th entire IP packet sent as a LISP control-message. The header = before the diagrams indicate they are UDP packets. > >=20 > > A caption would probably help. >=20 > The beginning of the section shows an IPv4 UDP packet format as well = as a IPv6 UDP packet format. >=20 > Agreed. I'm just saying you should put in a caption on each of them. Done. > > =20 > > > S 5.3. > > >> originating Map-Request source. If the RLOC is not in the = Locator- > > >> Set, then the ETR MUST send the "verifying Map-Request" to = the > > >> "piggybacked" EID. Doing this forces the "verifying = Map-Request" to > > >> go through the mapping database system to reach the = authoritative > > >> source of information about that EID, guarding against = RLOC-spoofing > > >> in the "piggybacked" mapping data. > > >=20 > > > This text here doesn't seem compatible with either of the two = cases > > > listed in "EID-prefix" above. > >=20 > > I don=E2=80=99t understand the comment Eric. Maybe because I can=E2=80= =99t find the exact reference to EID-prefix where you think there is a = conflict. Please cite for me. Thanks. > >=20 > > This does seem to have been assigned to the wrong text. > >=20 > > I am referring to: > >=20 > > " A Map-Reply returns an EID-Prefix with a prefix length that is = less > > than or equal to the EID being requested. The EID being = requested is > > either from the destination field of an IP header of a Data-Probe = or > > the EID record of a Map-Request. The RLOCs in the Map-Reply are > > " > >=20 > > versus > >=20 > > " EID-Prefix: This prefix is 4 octets for an IPv4 address family = and > > 16 octets for an IPv6 address family when the EID-Prefix-AFI = is 1 > > or 2, respectively. For other AFIs [AFI], the length varies = and > > for the LCAF AFI the format is defined in [RFC8060]. When a = Map- > > " > >=20 > > This is just the question of whether "prefix length" refers to the = field or > > the significant bits of the field. >=20 > Prefix-length =3D mask-length =3D number-of-bits-in-mask =3D = value-after-/. >=20 > OK, but then this second excerpt seems contradictory. We have an = EID-Prefix field which has a different length which is dictated by the = AFI only. It is not contracdictory. Let me explain, if I have a map-cache entry = 10.0.0.0/8 and I want to query the mapping system, then I send a = Map-Request for 10.0.0.0/8. What comes back in the Map-Reply is the /8 = and more specifics if they are registered. The definition section is saying what is in a Map-Request and the other = section that is describing behavior when a Map-Reply is returned. > > > S 8.3. > > >> of the mapping database protocols. > > >>=20 > > >> 8.3. Map-Server Processing > > >>=20 > > >> Once a Map-Server has EID-Prefixes registered by its client = ETRs, it > > >> can accept and process Map-Requests for them. > > >=20 > > > This section is confusing because the introduction says that this > > > function is only performed by Map-Resolvers: > > > ' > > > "The LISP Mapping Service defines two new types of LISP-speaking > > > devices: the Map-Resolver, which accepts Map-Requests from an > > > Ingress > > > Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using = a=20 > > > mapping database; and the Map-Server, which learns authoritative > > > EID- > > > to-RLOC mappings from an Egress Tunnel Router (ETR) and = publishes > > > them in a database.=E2=80=9D > >=20 > > The document does cover the operation of a Map-Resolver and a = Map-Server. Some functions are performed only by Map-Resolvers only and = other different functions are performed by Map-Servers only. > >=20 > > I am not sure what you don=E2=80=99t understand. > >=20 > > Sure: As I understand it, Map Resolvers process Map Requests, and = Map Servers do not (that's what the quoted text seems to say). However, = this sentence talks about a Map Server processing a Map Request. That's = where I am confused. >=20 > Here is a brief scenario: >=20 > (1) ITR sends Map-Request to a Map-Resolver. > (2) Map-Resolver =E2=80=9Cfinds=E2=80=9D the Map-Server where the EID = could be registered. That is the mapping database transport system, two = examples are LISP-ALT and LISP-DDT. > (3) The Map-Resolver in the case of LISP-DDT, will have a = referral-cache and know which map-server is authoriative for the = EID-prefix the Map-Request EID is for. > (4) The Map-Resolver forwards the Map-Request to that Map-Server. >=20 > And hence Map-Servers process Map-Requests. The Map-Server can = proxy-reply with the RLOC-set cached in its site-cache or forward to one = or more ETRs (described by the RLOC-set) so they can map-reply. >=20 > Sure, this seems reasonable, but then perhaps the text above could be = revised, because it reads like Map Resolvers process these requests and = therefore implies that Map-Servers do not. In the intro we are trying to explain at high-level the service = interface. But since Map-Resolvers forward Map-Requests to Map-Servers, = they process them to. But its through indirection. Dino From nobody Mon Oct 8 19:04:43 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E696131103; Mon, 8 Oct 2018 19:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OTZAvce_Ng8; Mon, 8 Oct 2018 19:04:30 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BABC01310DC; Mon, 8 Oct 2018 19:04:29 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id r8-v6so1290ljc.10; Mon, 08 Oct 2018 19:04: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=AHGHVpmqu4YGrHUVP3DjyNP/TBTBoRllQZcFVwHr+xU=; b=H+7AI9ZDfsE/VWeI0aYQofonQ3vKNVQRR6wsz2K8bNQNLM5UQO9VGjEwj27MoXvUuE xU+iouO/1WQMaPSYNEvTXJyJh5Y430F5p0sefL/r/RhZAeKTfnw1t/WncnzQXjk7eABY dm0hIx0vwPNAzIFSWOFm0645vgOvHUCjajQr5csRts293a/5IhcyUcAHP4yMi89+tTMU RIIdYNHgB+s+N+tlen7cIYM4iTlhT0lQYYc3V9fZ/lMw0KibwBGzLOYhZOhzelNuHO3x E1tH52Pc0j5MZD/DBV0F/iEPHITNZMNdzRkM904jkjsGDod022scXvcdV35Eca2UBSvd mhtg== 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=AHGHVpmqu4YGrHUVP3DjyNP/TBTBoRllQZcFVwHr+xU=; b=orTvFUR+zBtHKpjvdS71r3nYizYijvwlj3lEhuuz+4O4lcvSs8caNQyQE7ySIOZ6gz umxBf2Un4A5egZUtbACbQ4whE070u03vZnnjE78lJf04T2j4UN98abaeyKL75F/opyh9 zDW6sLATZZZ3HGcJj7tJVbgwQ92pmUy+xpBTHsdxO3H0P34A7hqXv//JjkpiLTJ4Dwmw huswwbaojAjkFL3vHJnhtDE7RwomTA87JAf7Rojv/A4iLdnqvlwUWEUP185Id23F/+ak LpA+E79jDYUY0McY+RSYSM0Q7pN6LnsXnx3rmxO/jm+cXV08JE07yjSP6dgKF2pwUalf dYzQ== X-Gm-Message-State: ABuFfohTjkDnridDa4gn2p37vwhDakD1TicFKBeMKwgF8E5XPt2yKYWt t8t56CYM8EGPugxCRfzm1Y7yIZLewHZT7GdqfqGdJA== X-Google-Smtp-Source: ACcGV61/VIrIfIsYWLgpT1ULdAgRbWR+q7FybU3fJ0UdhkvJBELNQIJKfEGYNAYIlhmCJdlX/gqUznkl5KXa219Ghb4= X-Received: by 2002:a2e:3918:: with SMTP id g24-v6mr1808145lja.113.1539050667668; Mon, 08 Oct 2018 19:04:27 -0700 (PDT) MIME-Version: 1.0 References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> <44201301-8E2D-4649-8483-5418A8CFC138@gigix.net> In-Reply-To: From: Alberto Rodriguez-Natal Date: Mon, 8 Oct 2018 19:04:15 -0700 Message-ID: To: Luigi Iannone Cc: "lisp@ietf.org list" , lisp-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000567a3c0577c228a3" Archived-At: Subject: Re: [lisp] WGLC fo draft-ietf-lisp-rfc8113bis-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 02:04:42 -0000 --000000000000567a3c0577c228a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The document is ready for publication. Thanks, Alberto On Mon, Oct 8, 2018 at 12:52 AM Luigi Iannone wrote: > Folks, > > WG Last Call for 8113bis has been out for more than a week and we did not > receive any feedback. > > Remember that silence is NOT consensus. > > Please ALL , > thake 5 minutes to read this very short document and send feedback on > whether or not you think the document is ready to be published. > > Thanks > > Luigi > > On 27 Sep 2018, at 11:02, Luigi Iannone wrote: > > Well, > > Authors were pretty quick =E2=80=A6 > > This email open the one week WG Last Call for the > document draft-ietf-lisp-rfc8113bis-00.txt > > Please review this WG document and let the WG know if you agree that it i= s > ready for handing to the AD. > If you have objections, please state your reasons why, and explain what i= t > would take to address your concerns. > > Ciao > > L. > > On 27 Sep 2018, at 10:22, Luigi Iannone wrote: > > All, > > one week is over and we received several email in support adoption of thi= s > document. > > Because of such consensus the authors are invited to submit a document > named draft-ietf-lisp-rfc8113bis-00.txt. > > As soon as the new document is available we will start the WG Last Call, > as already said in my previous mail. > > Ciao > > L. > > > On 19 Sep 2018, at 17:04, Luigi Iannone wrote: > > Folks, > > here is another piece of the work done in our WG that needs to be moved t= o > PS. > > It is the updated version of RFC 8113, nothing changed just updated > coherently with the current status of the other documents. > > Because this documents is really really short we will have just one week > adoption call followed be one week WG Last Call. > > This email officially starts the one week call for adoption. > > Please spend 10 minutes having a look at the document and send an email o= n > whether you agree or not to adopt it. > > Thanks > > Ciao > > Luigi > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt* > *Date: *19 September 2018 at 16:49:31 CEST > *To: * > *Reply-To: *internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Locator/ID Separation Protocol (LISP): Shared > Extension Message & IANA Registry for Packet Type Allocations > Authors : Mohamed Boucadair > Christian Jacquenet > Filename : draft-boucadair-lisp-rfc8113bis-01.txt > Pages : 5 > Date : 2018-09-19 > > Abstract: > This document specifies a Locator/ID Separation Protocol (LISP) > shared message type for defining future extensions and conducting > experiments without consuming a LISP packet type codepoint for each > extension. > > This document obsoletes RFC 8113. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01 > https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc8113bis-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --000000000000567a3c0577c228a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The document is ready for publication.

=
Thanks,
Alberto

On Mon, Oct 8, 2018 at 12:52 AM Luigi Iannone <= ggx@gigix.net> wrote:
Folks,

WG Last Call for 8113bis has bee= n out for more than a week and we did not receive any feedback.
<= br>
Remember that silence is NOT consensus.

<= div>Please ALL ,
thake 5 minutes to read this very short document= and send feedback on whether or not you think the document is ready to be = published.

Thanks

Luigi

On 27 Sep 2018, at 11:02, Luigi I= annone <ggx@gigix.net= > wrote:

Well,

Authors were pretty quick =E2=80=A6
This email open the one week WG Last Call for the document=C2= =A0draft-ietf-lisp-rfc8113bis-00.txt

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

<= div>Ciao

L.

On 27 Sep 2018, at 10:22, Luigi Iannone <ggx@gigix.net> wrote:

All,

one week = is over and we received several email in support adoption of this document.=

Because of such consensus the authors are invited= to submit a document named draft-ietf-lisp-rfc8113bis-00.txt.
As soon as the new document is available we will start the WG = Last Call, as already said in my previous mail.

Ci= ao

L.


On 19 Sep 2018, at 17:04, Luigi Iannone <ggx@gigix.net> wrote:

Folks,

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

It is the updated version of RFC 8113, nothing c= hanged just updated coherently with the current status of the other documen= ts.

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

This email officially starts the one week call fo= r adoption.

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

Thanks

Ciao
Luigi


Begin forwarded message:

Subject:= I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt<= /b>
Date: 19 September 2018 at 16:49:31 CEST


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


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= : Locator/ID Separation Protocol (LISP): Shared Extension Message & IAN= A Registry for Packet Type Allocations
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0Authors =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Moham= ed Boucadair
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Christian Jacquenet
Filename =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: draft-boucadair-lisp-rfc8113bis-01.txt Pages =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0: 5
Date =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2018-09-19

Abstract:
=C2=A0=C2= =A0This document specifies a Locator/ID Separation Protocol (LISP)
=C2= =A0=C2=A0shared message type for defining future extensions and conducting<= br> =C2=A0=C2=A0experiments without consuming a LISP packet type codepoint = for each
=C2=A0=C2=A0extension.

=C2=A0=C2=A0This document obsol= etes RFC 8113.


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

There are also htmlized versions available at:=
https://tools.ietf.org/html/draft-boucadair-lisp-rfc8= 113bis-01
https://datatracker.ietf.org/d= oc/html/draft-boucadair-lisp-rfc8113bis-01

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


Please= note that it may take a couple of minutes from the time of submission
u= ntil 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/
<= br>_______________________________________________
I-D-Announce mailing = list
I-D-Anno= unce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announ= ce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt

<= /div>



________________= _______________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
--000000000000567a3c0577c228a3-- From nobody Tue Oct 9 06:37: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 7942B131320 for ; Tue, 9 Oct 2018 06:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vehf6Zsmb8hq for ; Tue, 9 Oct 2018 06:37:07 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 D0283131323 for ; Tue, 9 Oct 2018 06:37:03 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id v7-v6so1574160ljg.5 for ; Tue, 09 Oct 2018 06:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5ycSl6GDfaMXQ/cK5diWdHz3IEsDlzSxPLERBl9hAkw=; b=WNfKBJwkkcWo0S5ND/FS/6NkFDpEf0lc6yINysAPOhqvmnLkJ1uSVdb94FGYBKNrXa H9M3ezxl+qW7RU8R1/fgQ4ePOovzhETPKSnL9pN+WRv+R8KFi+2L46GEznK3dLMlwJjJ Xto9ya2zDt1KP7uGFTMTmkaC/BC7tw/Zg9gkOxY2eo/YRXWVoUlvtS4HZFzyPtvBIZBB SBrqnaHnGCh1PWtzVAzGpHYhiR1vJ0c72T9ncIh8RQTa42hiNWpyWVns5beDTdcoLN50 B8KKWXP/96p1JcMQIIGGjd2wp/fh9yjzsy37Jx9D+UmMmHonLrnP7yvEcgtE3KSCrzUj zIrA== 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=5ycSl6GDfaMXQ/cK5diWdHz3IEsDlzSxPLERBl9hAkw=; b=N1N9cZYqsuajJXHMlbHlQ7FhTNogD+Kn7p+tiCYtas7EXa8o9ymktspsDvxUmGkUNw bRGZkXU3rVupkBDSIpGORHUXQvcnsJuU9qRkqX8GDYDCa5b317HpODz9OAR8JYHAyFKe 0D1vF2bnEB1gtf8KgiLPwXiyLD/cRhSVgJGFPvgRKHdQid4V5mTKJhwmek3KS6pal3Db Uwh2bYAoaRwSQKXxI4LQPjP98mCl39p7RTugm7//aNmqDoejrCz+d3x3zVeDYVmPZECc EuhpTiPuSP3avf36Gja7dyzAFmLXVNQeTLDlT5vXrS7fnelg1dit+lEnsTJ9RCkor+Po bu7w== X-Gm-Message-State: ABuFfogSSG/ic0ClvrswDPWPZGSNEWbRxAK9lS86vxmAVDNJz7Nrq6jL NEDF0KA/8BrfrnGecaszbaahS8u8MWKJCF/LB7rK7w== X-Google-Smtp-Source: ACcGV62LHHxBftp9F+ThMFBiTdSOgJkiczUKDXsdHJx7blzJZl2QtOWVchEPeuaKh2f0kVJM/kMquAcWoOx7Ytiz16A= X-Received: by 2002:a2e:544f:: with SMTP id y15-v6mr19170937ljd.51.1539092221681; Tue, 09 Oct 2018 06:37:01 -0700 (PDT) MIME-Version: 1.0 References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> <27454678-1FED-43EC-9D65-72F18487E619@gmail.com> <923B651B-873C-434D-91BC-2727E8130258@gmail.com> In-Reply-To: <923B651B-873C-434D-91BC-2727E8130258@gmail.com> From: Eric Rescorla Date: Tue, 9 Oct 2018 06:36:28 -0700 Message-ID: To: Dino Farinacci Cc: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="00000000000026cb020577cbd526" Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 13:37:10 -0000 --00000000000026cb020577cbd526 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 8, 2018 at 5:41 PM Dino Farinacci wrote: > Sorry the delay Eric. > > > > > > > S 5.5. > > > >> is being mapped from a multicast destination EID. > > > >> > > > >> 5.5. EID-to-RLOC UDP Map-Reply Message > > > >> > > > >> A Map-Reply returns an EID-Prefix with a prefix length that is > less > > > >> than or equal to the EID being requested. The EID being > requested is > > > > > > > > How do I behave if I receive an EID-Prefix that is less than any of > my > > > > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16 > > > > and someone asks me for 10.0.0.0/8? > > > > > > > > I think I'm still unclear on this point. > > > > The spec says you cache it. That is all you can do. But it means the > sender of the Map-Reply is not spec conformant. That means RLOCs are used > for the coarser EID-prefix. > > > > Sorry, cache it? My question is how to respond to the case where the > Map-Request has this property. > > I thought you were referring to the Map-Reply. If a Map-Request is sent > for 10.0.0.0/8 a replier needs to return in a Map-Reply /8, if it is > registered in the mapping system as well as all more specifics. That is > seldom done since a Map-Request is triggered for a destination EID in an = IP > packet, but a =E2=80=9Clig=E2=80=9D client to ask to see if the coarser p= refix exists. > OK. Thanks. > > > > > > > Also, when you talk about prefix > > > > length, I assume you mean the length fo the mask? > > > > > > Yes, this is explained later in this section. Was that not helpful?? > > > > > > I found it a bit confusing. It seems to me like there are two lengths > involved here: > > > > > > - The length of the field (4 or 16) > > > - The parts of the field that are significant (i.e., the mask) > > > > In routing, as you know, the mask-length is always the same as the > prefix-length. It is the number of bits in the mask. > > > > > > > I had thought that "prefix length" referred to the former, but it > seems like here it > > > refers to the latter. > > > > The length of the address is defined by the 16-bit AFI that precedes th= e > address. > > > > I agree, but the text refers to this as the prefix and it has a length, > which is the length of the encoded field, not the length of the mask, as > seen in this excerpt: > > > > EID-Prefix: This prefix is 4 octets for an IPv4 address family and > > 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 > > or 2, respectively. For other AFIs [AFI], the length varies and > > for the LCAF AFI the format is defined in [RFC8060]. When a Map- > > I will make this more clear. Thanks for the comment. Fixed in the section > you cite and make it more clear the different of =E2=80=9Caddress length= =E2=80=9D and =E2=80=9Cmask > length=E2=80=9D in the =E2=80=9CEID-Prefix=E2=80=9D definition. > Sounds good. > > > > S 5.3. > > > >> originating Map-Request source. If the RLOC is not in the > Locator- > > > >> Set, then the ETR MUST send the "verifying Map-Request" to the > > > >> "piggybacked" EID. Doing this forces the "verifying > Map-Request" to > > > >> go through the mapping database system to reach the > authoritative > > > >> source of information about that EID, guarding against > RLOC-spoofing > > > >> in the "piggybacked" mapping data. > > > > > > > > This text here doesn't seem compatible with either of the two cases > > > > listed in "EID-prefix" above. > > > > > > I don=E2=80=99t understand the comment Eric. Maybe because I can=E2= =80=99t find the > exact reference to EID-prefix where you think there is a conflict. Please > cite for me. Thanks. > > > > > > This does seem to have been assigned to the wrong text. > > > > > > I am referring to: > > > > > > " A Map-Reply returns an EID-Prefix with a prefix length that is le= ss > > > than or equal to the EID being requested. The EID being requested > is > > > either from the destination field of an IP header of a Data-Probe = or > > > the EID record of a Map-Request. The RLOCs in the Map-Reply are > > > " > > > > > > versus > > > > > > " EID-Prefix: This prefix is 4 octets for an IPv4 address family a= nd > > > 16 octets for an IPv6 address family when the EID-Prefix-AFI is= 1 > > > or 2, respectively. For other AFIs [AFI], the length varies an= d > > > for the LCAF AFI the format is defined in [RFC8060]. When a Ma= p- > > > " > > > > > > This is just the question of whether "prefix length" refers to the > field or > > > the significant bits of the field. > > > > Prefix-length =3D mask-length =3D number-of-bits-in-mask =3D value-afte= r-/. > > > > OK, but then this second excerpt seems contradictory. We have an > EID-Prefix field which has a different length which is dictated by the AF= I > only. > > It is not contracdictory. Let me explain, if I have a map-cache entry > 10.0.0.0/8 and I want to query the mapping system, then I send a > Map-Request for 10.0.0.0/8. What comes back in the Map-Reply is the /8 > and more specifics if they are registered. > > The definition section is saying what is in a Map-Request and the other > section that is describing behavior when a Map-Reply is returned. > OK. I'm going to assume that the changes you note above fixed my confusion here as well. > > > > S 8.3. > > > >> of the mapping database protocols. > > > >> > > > >> 8.3. Map-Server Processing > > > >> > > > >> Once a Map-Server has EID-Prefixes registered by its client > ETRs, it > > > >> can accept and process Map-Requests for them. > > > > > > > > This section is confusing because the introduction says that this > > > > function is only performed by Map-Resolvers: > > > > ' > > > > "The LISP Mapping Service defines two new types of LISP-speaking > > > > devices: the Map-Resolver, which accepts Map-Requests from an > > > > Ingress > > > > Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using = a > > > > mapping database; and the Map-Server, which learns authoritative > > > > EID- > > > > to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes > > > > them in a database.=E2=80=9D > > > > > > The document does cover the operation of a Map-Resolver and a > Map-Server. Some functions are performed only by Map-Resolvers only and > other different functions are performed by Map-Servers only. > > > > > > I am not sure what you don=E2=80=99t understand. > > > > > > Sure: As I understand it, Map Resolvers process Map Requests, and Map > Servers do not (that's what the quoted text seems to say). However, this > sentence talks about a Map Server processing a Map Request. That's where= I > am confused. > > > > Here is a brief scenario: > > > > (1) ITR sends Map-Request to a Map-Resolver. > > (2) Map-Resolver =E2=80=9Cfinds=E2=80=9D the Map-Server where the EID c= ould be > registered. That is the mapping database transport system, two examples a= re > LISP-ALT and LISP-DDT. > > (3) The Map-Resolver in the case of LISP-DDT, will have a referral-cach= e > and know which map-server is authoriative for the EID-prefix the > Map-Request EID is for. > > (4) The Map-Resolver forwards the Map-Request to that Map-Server. > > > > And hence Map-Servers process Map-Requests. The Map-Server can > proxy-reply with the RLOC-set cached in its site-cache or forward to one = or > more ETRs (described by the RLOC-set) so they can map-reply. > > > > Sure, this seems reasonable, but then perhaps the text above could be > revised, because it reads like Map Resolvers process these requests and > therefore implies that Map-Servers do not. > > In the intro we are trying to explain at high-level the service interface= . > But since Map-Resolvers forward Map-Requests to Map-Servers, they process > them to. But its through indirection. > OK, thanks. -Ekr Dino > > > --00000000000026cb020577cbd526 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Oct 8, 2018 at 5:41 PM Dino Farinacci <farinacci@gmail.com> wrote:
Sorry the delay Eric.

>
> > > S 5.5.
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 is being mapped from a multic= ast destination EID.
> > >>
> > >>=C2=A0 5.5.=C2=A0 EID-to-RLOC UDP Map-Reply Message
> > >>
> > >>=C2=A0 =C2=A0 =C2=A0A Map-Reply returns an EID-Prefix wit= h a prefix length that is less
> > >>=C2=A0 =C2=A0 =C2=A0than or equal to the EID being reques= ted.=C2=A0 The EID being requested is
> > >
> > > How do I behave if I receive an EID-Prefix that is less than= any of my
> > > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16
> > > and someone asks me for 10.0.0.0/8?
>
> >
> > I think I'm still unclear on this point.
>
> The spec says you cache it. That is all you can do. But it means the s= ender of the Map-Reply is not spec conformant. That means RLOCs are used fo= r the coarser EID-prefix.
>
> Sorry, cache it? My question is how to respond to the case where the M= ap-Request has this property.

I thought you were referring to the Map-Reply. If a Map-Request is sent for= 10.0.0.= 0/8 a replier needs to return in a Map-Reply /8, if it is registered in= the mapping system as well as all more specifics. That is seldom done sinc= e a Map-Request is triggered for a destination EID in an IP packet, but a = =E2=80=9Clig=E2=80=9D client to ask to see if the coarser prefix exists.

OK. Thanks.

> >
> > Also, when you talk about prefix
> > > length, I assume you mean the length fo the mask?
> >
> > Yes, this is explained later in this section. Was that not helpfu= l??
> >
> > I found it a bit confusing. It seems to me like there are two len= gths involved here:
> >
> > - The length of the field (4 or 16)
> > - The parts of the field that are significant (i.e., the mask) >
> In routing, as you know, the mask-length is always the same as the pre= fix-length. It is the number of bits in the mask.
>
>
> > I had thought that "prefix length" referred to the form= er, but it seems like here it
> > refers to the latter.
>
> The length of the address is defined by the 16-bit AFI that precedes t= he address.
>
> I agree, but the text refers to this as the prefix and it has a length= , which is the length of the encoded field, not the length of the mask, as = seen in this excerpt:
>
>=C2=A0 =C2=A0 EID-Prefix:=C2=A0 This prefix is 4 octets for an IPv4 add= ress family and
>=C2=A0 =C2=A0 =C2=A0 =C2=A016 octets for an IPv6 address family when th= e EID-Prefix-AFI is 1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0or 2, respectively.=C2=A0 For other AFIs [AF= I], the length varies and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for the LCAF AFI the format is defined in [R= FC8060].=C2=A0 When a Map-

I will make this more clear. Thanks for the comment. Fixed in the section y= ou cite and make it more clear the different of =E2=80=9Caddress length=E2= =80=9D and =E2=80=9Cmask length=E2=80=9D in the =E2=80=9CEID-Prefix=E2=80= =9D definition.

Sounds good.
=

> > > S 5.3.
> > >>=C2=A0 =C2=A0 =C2=A0originating Map-Request source.=C2=A0= If the RLOC is not in the Locator-
> > >>=C2=A0 =C2=A0 =C2=A0Set, then the ETR MUST send the "= ;verifying Map-Request" to the
> > >>=C2=A0 =C2=A0 =C2=A0"piggybacked" EID.=C2=A0 Do= ing this forces the "verifying Map-Request" to
> > >>=C2=A0 =C2=A0 =C2=A0go through the mapping database syste= m to reach the authoritative
> > >>=C2=A0 =C2=A0 =C2=A0source of information about that EID,= guarding against RLOC-spoofing
> > >>=C2=A0 =C2=A0 =C2=A0in the "piggybacked" mappin= g data.
> > >
> > > This text here doesn't seem compatible with either of th= e two cases
> > > listed in "EID-prefix" above.
> >
> > I don=E2=80=99t understand the comment Eric. Maybe because I can= =E2=80=99t find the exact reference to EID-prefix where you think there is = a conflict. Please cite for me. Thanks.
> >
> > This does seem to have been assigned to the wrong text.
> >
> > I am referring to:
> >
> > "=C2=A0 =C2=A0A Map-Reply returns an EID-Prefix with a prefi= x length that is less
> >=C2=A0 =C2=A0 than or equal to the EID being requested.=C2=A0 The = EID being requested is
> >=C2=A0 =C2=A0 either from the destination field of an IP header of= a Data-Probe or
> >=C2=A0 =C2=A0 the EID record of a Map-Request.=C2=A0 The RLOCs in = the Map-Reply are
> > "
> >
> > versus
> >
> > "=C2=A0 =C2=A0EID-Prefix:=C2=A0 This prefix is 4 octets for = an IPv4 address family and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A016 octets for an IPv6 address family wh= en the EID-Prefix-AFI is 1
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0or 2, respectively.=C2=A0 For other AFI= s [AFI], the length varies and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0for the LCAF AFI the format is defined = in [RFC8060].=C2=A0 When a Map-
> > "
> >
> > This is just the question of whether "prefix length" re= fers to the field or
> > the significant bits of the field.
>
> Prefix-length =3D mask-length =3D number-of-bits-in-mask =3D value-aft= er-/.
>
> OK, but then this second excerpt seems contradictory. We have an EID-P= refix field which has a different length which is dictated by the AFI only.=

It is not contracdictory. Let me explain, if I have a map-cache entry 10.0.0.0/8 and I want to query the mapping system, then I send a Map-Request for 10.0.0.0/8<= /a>. What comes back in the Map-Reply is the /8 and more specifics if they = are registered.

The definition section is saying what is in a Map-Request and the other sec= tion that is describing behavior when a Map-Reply is returned.

OK. I'm going to assume that the changes you no= te above fixed my confusion here as well.



> > > S 8.3.
> > >>=C2=A0 =C2=A0 =C2=A0of the mapping database protocols. > > >>
> > >>=C2=A0 8.3.=C2=A0 Map-Server Processing
> > >>
> > >>=C2=A0 =C2=A0 =C2=A0Once a Map-Server has EID-Prefixes re= gistered by its client ETRs, it
> > >>=C2=A0 =C2=A0 =C2=A0can accept and process Map-Requests f= or them.
> > >
> > > This section is confusing because the introduction says that= this
> > > function is only performed by Map-Resolvers:
> > > '
> > > "The LISP Mapping Service defines two new types of LISP= -speaking
> > >=C2=A0 =C2=A0devices: the Map-Resolver, which accepts Map-Req= uests from an
> > > Ingress
> > >=C2=A0 =C2=A0Tunnel Router (ITR) and "resolves" the= EID-to-RLOC mapping using a
> > >=C2=A0 =C2=A0mapping database; and the Map-Server, which lear= ns authoritative
> > > EID-
> > >=C2=A0 =C2=A0to-RLOC mappings from an Egress Tunnel Router (E= TR) and publishes
> > >=C2=A0 =C2=A0them in a database.=E2=80=9D
> >
> > The document does cover the operation of a Map-Resolver and a Map= -Server. Some functions are performed only by Map-Resolvers only and other = different functions are performed by Map-Servers only.
> >
> > I am not sure what you don=E2=80=99t understand.
> >
> > Sure: As I understand it, Map Resolvers process Map Requests, and= Map Servers do not (that's what the quoted text seems to say). However= , this sentence talks about a Map Server processing a Map Request.=C2=A0 Th= at's where I am confused.
>
> Here is a brief scenario:
>
> (1) ITR sends Map-Request to a Map-Resolver.
> (2) Map-Resolver =E2=80=9Cfinds=E2=80=9D the Map-Server where the EID = could be registered. That is the mapping database transport system, two exa= mples are LISP-ALT and LISP-DDT.
> (3) The Map-Resolver in the case of LISP-DDT, will have a referral-cac= he and know which map-server is authoriative for the EID-prefix the Map-Req= uest EID is for.
> (4) The Map-Resolver forwards the Map-Request to that Map-Server.
>
> And hence Map-Servers process Map-Requests. The Map-Server can proxy-r= eply with the RLOC-set cached in its site-cache or forward to one or more E= TRs (described by the RLOC-set) so they can map-reply.
>
> Sure, this seems reasonable, but then perhaps the text above could be = revised, because it reads like Map Resolvers process these requests and the= refore implies that Map-Servers do not.

In the intro we are trying to explain at high-level the service interface. = But since Map-Resolvers forward Map-Requests to Map-Servers, they process t= hem to. But its through indirection.

OK= , thanks.

-Ekr

Dino


--00000000000026cb020577cbd526-- From nobody Tue Oct 9 08:55:50 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAA6131342; Tue, 9 Oct 2018 08:55:40 -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 ndCo5jMDOGpb; Tue, 9 Oct 2018 08:55:35 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513DA13127A; Tue, 9 Oct 2018 08:55:35 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id r9-v6so1023637pgv.6; Tue, 09 Oct 2018 08:55:35 -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=2maAhIgnUFjC2+TzBibVFhr3p4GqibGUier6K5R7sck=; b=X3uvqGqWu9GSaoURlGGVz1I+QL5n8rVPHaaArJ2kNyf2zf96JADO6AsyXkqCQ48irH PX/eyRJKnr/FqTHVNR6oJam3dKCYQsblBQWlZzr4Nc4go4dCgGNfcNq8swtXCLflB+VB BJyVJLj9QBYVkB62/cI000s9ypjv5Lk0TvicYVVCzHYEsBxIydadIzniCnjL1oHTIZ11 jthjdGv0lBarxoqcZwKK4fVCWJnqtbNQPFdiqeWjxZujaAqxr90E/oCSUVv6TtnrYsxM jcLf/95s0rVZ5TpJFqNOEiRLq74OTx3qifmZBYtU7XUf0DYmO4BvH82hKdU7qIuizj7I 2jkA== 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=2maAhIgnUFjC2+TzBibVFhr3p4GqibGUier6K5R7sck=; b=JgvVJFW/ksvqkB0CQYNBvVld9gBbG+XJHJCXEl8zDrN2CACF1p2P6ZSjU0bU693hh+ R0u3qZws08cqODjxGnYMAc17i1pGt5yShas/byE7K446mZo7jbZXVORjgLYwsAjnIKXD RP6kQ9HEVaxD2IsRF8mEtuXLgDkgI2Otay1+BE30xum9qYwYxPADbJDAE+x3vEtG3xx6 ri2EnHWqKxvcBPwSx9EEx060O48RkKNu5wY3dYFJkMpIKRSIIyrxbj6OYNu2mVq+JsSX rkNx85Ghht6jFZfcWRrb4jycVu0FREfl9tb8or9hdkt0IjWD+1X3b3iq6ffNfZB0lsUS +TJg== X-Gm-Message-State: ABuFfoiRXETZSQ6nOviWArJ5LqgvarScdQUnD8eCdGUeLjz7tIgxsWCx yub8vnX3gJHljm5sK2X8e3Y= X-Google-Smtp-Source: ACcGV60N2S4X2KqHv0ENY68/XvDRYSSZt+bBU0m78zw4am9qmgauOpm0G7XUkPShwPypJsgNKcmXjg== X-Received: by 2002:a63:d917:: with SMTP id r23-v6mr26645785pgg.0.1539100534813; Tue, 09 Oct 2018 08:55:34 -0700 (PDT) Received: from [10.31.79.225] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id c21-v6sm34157185pfe.93.2018.10.09.08.55.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Oct 2018 08:55:33 -0700 (PDT) From: Dino Farinacci Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_14DC9AB9-7CB9-4F68-B240-585328C77428" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 9 Oct 2018 08:55:32 -0700 In-Reply-To: Cc: IESG , draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, "lisp@ietf.org list" To: Eric Rescorla References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> <27454678-1FED-43EC-9D65-72F18487E619@gmail.com> <923B651B-873C-434D-91BC-2727E8130258@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 15:55:41 -0000 --Apple-Mail=_14DC9AB9-7CB9-4F68-B240-585328C77428 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here are the changes I put in. And starting to address security. A bunch = of LISP co-authors had a conference call last week and awe are preparing = text to address security issues you and Ben have raised. Cheers, Dino --Apple-Mail=_14DC9AB9-7CB9-4F68-B240-585328C77428 Content-Disposition: attachment; filename=rfcdiff-6833bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6833bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-17.txt - = draft-ietf-lisp-rfc6833bis-18.txt=20 =20 =20 =20 =20 =20 =20 = =
< draft-ietf-lisp-rfc6833bis-17.txt  =  draft-ietf-lisp-rfc6833bis-18.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: April = 6, 2019 = UPC/BarcelonaTech Expires: April = 11, 2019 = UPC/BarcelonaTech
= October 3, 2018 = October 8, 2018
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-17 = = draft-ietf-lisp-rfc6833bis-18
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = Control-Plane service interface and communicating with By using this Control-Plane service interface and = communicating with
=
skipping to = change at = page 1, line 47 =C2=B6 = skipping to change at page 1, line 47 =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 April 6, = 2019. This Internet-Draft will = expire on April 11, 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 27 =C2=B6 = skipping to change at page 2, line 27 =C2=B6
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
described in = the Simplified BSD License. = described in the Simplified BSD License.
=
Table of = Contents Table of Contents
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. = Requirements Notation . . . . . . . . . . . . . . . . . . . . = 4 2. Requirements Notation . . . . = . . . . . . . . . . . . . . . . 4
3. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
4. Basic = Overview . . . . . . . . . . . . . . . . . . . . . . . 6 = 4. Basic Overview . . . . . . . . . . . . = . . . . . . . . . . . 6
5. LISP IPv4 = and IPv6 Control-Plane Packet Formats . . . . . . . 8 = 5. LISP IPv4 and IPv6 Control-Plane Packet = Formats . . . . . . . 8
5.1. LISP = Control Packet Type Allocations . . . . . . . . . . 10 5.1. = LISP Control Packet Type Allocations . . . . . . . . . . 11
5.2. = Map-Request Message Format . . . . . . . . . . . . . . . 11 5.2. = Map-Request Message Format . . . . . . . . . . . . . . . 12
5.3. = EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 14 5.3. = EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 15
5.4. = Map-Reply Message Format . . . . . . . . . . . . . . . . 16 5.4. = Map-Reply Message Format . . . . . . . . . . . . . . . . 17
5.5. = EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 20 5.5. = EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 21
5.6. = Map-Register Message Format . . . . . . . . . . . . . . . 23 5.6. = Map-Register Message Format . . . . . . . . . . . . . . . 24
5.7. = Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 26 5.7. = Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 27
5.8. = Encapsulated Control Message Format . . . . . . . . . . . 28 5.8. = Encapsulated Control Message Format . . . . . . . . . . . 29
6. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 30 6. = Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 31
6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 30 6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 31
7. Routing = Locator Reachability . . . . . . . . . . . . . . . . 31 7. = Routing Locator Reachability . . . . . . . . . . . . . . . . 32
7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 33 7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 34
8. = Interactions with Other LISP Components . . . . . . . . . . . 34 8. = Interactions with Other LISP Components . . . . . . . . . . . 35
8.1. ITR = EID-to-RLOC Mapping Resolution . . . . . . . . . . . 34 8.1. = ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 35
8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 35 8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 36
8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 37 8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 38
8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 38 8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 39
8.4.1. = Anycast Operation . . . . . . . . . . . . . . . . . . 38 = 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 39
9. Security = Considerations . . . . . . . . . . . . . . . . . . . 39 9. = Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. Changes = since RFC 6833 . . . . . . . . . . . . . . . . . . . 40 10. = Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 41
11. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 40 11. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11.1. = LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 41 11.1. = LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 42
11.2. = LISP Packet Type Codes . . . . . . . . . . . . . . . . . 41 11.2. = LISP Packet Type Codes . . . . . . . . . . . . . . . . . 42
11.3. = LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 41 11.3. = LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 42
11.4. = LISP Address Type Codes . . . . . . . . . . . . . . . . 42 11.4. = LISP Address Type Codes . . . . . . . . . . . . . . . . 43
11.5. = LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 42 11.5. = LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 43
11.6. = LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 43 11.6. = LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 44
12. = References . . . . . . . . . . . . . . . . . . . . . . . . . 46 12. = References . . . . . . . . . . . . . . . . . . . . . . . . . 47
12.1. = Normative References . . . . . . . . . . . . . . . . . . 46 12.1. = Normative References . . . . . . . . . . . . . . . . . . 47
12.2. = Informative References . . . . . . . . . . . . . . . . . 46 12.2. = Informative References . . . . . . . . . . . . . . . . . 47
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 51 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 52
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 51 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 52
B.1. = Changes to draft-ietf-lisp-rfc6833bis-17 = . . . . . . . . 51 B.1. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . = 52
B.2. = Changes to draft-ietf-lisp-rfc6833bis-16 = . . . . . . . . 51 B.2. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . = 52
B.3. = Changes to draft-ietf-lisp-rfc6833bis-15 = . . . . . . . . 51 B.3. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . = 52
B.4. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 52 B.4. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . = 53
B.5. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 52 B.5. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . = 53
B.6. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 52 B.6. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . = 53
B.7. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 52 B.7. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . = 53
B.8. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 52 B.8. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . = 53
B.9. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 52 B.9. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . = 53
B.10. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 53 B.10. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . = 54
B.11. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 53 B.11. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . = 54
B.12. = Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 53 B.12. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . = 54
B.13. = Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 54 B.13. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . = 55
B.14. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 54 B.14. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . = 55
B.15. = Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 54 B.15. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . = 55
B.16. = Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 54 B.16. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . = 55
B.17. = Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 55 B.17. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . = 56
B.18. = Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 55 B.18. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . = 56
B.19. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 55 B.19. = Changes to draft-ietf-lisp-rfc6833bis-00 . . . . = . . . . 56
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 B.20. Changes to = draft-farinacci-lisp-rfc6833bis-00 . . . . . . 56
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 57
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol = [I-D.ietf-lisp-rfc6830bis] (see
also = [I-D.ietf-lisp-introduction]) specifies an architecture and = also [I-D.ietf-lisp-introduction]) specifies = an architecture and
mechanism for = dynamic tunneling by logically separating the addresses = mechanism for dynamic tunneling by logically = separating the addresses
currently used = by IP in two separate name spaces: Endpoint IDs currently used by IP in two separate name spaces: = Endpoint IDs
(EIDs), used = within sites; and Routing Locators (RLOCs), used on the = (EIDs), used within sites; and Routing = Locators (RLOCs), used on the
transit = networks that make up the Internet infrastructure. To transit networks that make up the Internet = infrastructure. To
achieve this = separation, LISP defines protocol mechanisms for mapping = achieve this separation, LISP defines = protocol mechanisms for mapping
=
skipping to = change at = page 8, line 31 =C2=B6 = skipping to change at page 8, line 31 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port | Dest Port | / | Source Port | Dest = Port |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
| = LISP Message | | LISP Message = |
| = | | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
= IPv4 UDP LISP Control Message
= =
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| = Traffic Class | Flow Label | = |Version| Traffic Class | Flow = Label |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Payload Length | Next Header=3D17| Hop Limit | = | Payload Length | Next = Header=3D17| Hop Limit |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
+ = + + = +
| = | | = |
=
skipping to = change at = page 9, line 15 =C2=B6 = skipping to change at page 9, line 37 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port | Dest Port | / | Source Port | Dest = Port |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
| = LISP Message | | LISP Message = |
| = | | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
= IPv6 UDP LISP Control Message
= =
When a UDP = Map-Request, Map-Register, or Map-Notify (when used as a = When a UDP Map-Request, Map-Register, or = Map-Notify (when used as a
notification = message) are sent, the UDP source port is chosen by the = notification message) are sent, the UDP = source port is chosen by the
sender and the = destination UDP port number is set to 4342. When a sender and the destination UDP port number is set to = 4342. When a
UDP Map-Reply, = Map-Notify (when used as an acknowledgement to a Map- UDP Map-Reply, Map-Notify (when used as an = acknowledgement to a Map-
Register), or = Map-Notify-Ack are sent, the source UDP port number is Register), or Map-Notify-Ack are sent, the source UDP = port number is
set to 4342 = and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is = copied from the
source port of = either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking = data packet.
= Implementations MUST be prepared to accept packets when either = the Implementations MUST be = prepared to accept packets when either the
source port or = destination UDP port is set to 4342 due to NATs source port or destination UDP port is set to 4342 = due to NATs
changing port = number values. changing port number = values.
=
skipping to = change at = page 13, line 30 =C2=B6 = skipping to change at page 14, line = 30 =C2=B6
ITR-RLOC = Address: This is used to give the ETR the option of ITR-RLOC Address: This is used to give the ETR the = option of
selecting = the destination address from any address family for the = selecting the destination address from = any address family for the
Map-Reply = message. This address MUST be a routable RLOC address Map-Reply message. This address MUST be a = routable RLOC address
of the = sender of the Map-Request message. = of the sender of the Map-Request message.
=
EID mask-len: = This is the mask length for the EID-Prefix. EID mask-len: This is the mask length for the = EID-Prefix.
=
= EID-Prefix-AFI: This is the address family of the EID-Prefix = EID-Prefix-AFI: This is the address family = of the EID-Prefix
according = to [AFI] and [RFC8060]. = according to [AFI] and [RFC8060].
=
EID-Prefix: = This prefix is 4 octets for an IPv4 address family and EID-Prefix: This prefix address length is 4 octets for an IPv4
16 octets = for an IPv6 address family when the EID-Prefix-AFI is 1 = address family and 16 octets for an IPv6 = address family when the
or 2, = respectively. For other AFIs [AFI], the length varies and = EID-Prefix-AFI is 1 or 2, respectively. = For other AFIs [AFI], the
for the = LCAF AFI the format is defined in [RFC8060]. When a Map- = address length varies and for the LCAF AFI = the format is defined
Request is sent by an ITR because a data = packet is received for a in = [RFC8060]. When a Map-Request is sent by = an ITR because a data
= destination where there is no mapping entry, the EID-Prefix is = set packet is received for a = destination where there is no mapping
to the = destination IP address of the data packet, and the 'EID = entry, the EID-Prefix is set to the = destination IP address of the
mask-len' = is set to 32 or 128 for IPv4 or IPv6, respectively. data packet, and the 'EID mask-len' is set to 32 = or 128 for IPv4
When an = xTR wants to query a site about the status of a mapping it = or IPv6, respectively. When an xTR = wants to query a site about
already = has cached, the EID-Prefix used in the Map-Request has the = the status of a mapping it already has = cached, the EID-Prefix used
same = mask length as the EID-Prefix returned = from the site when it in the = Map-Request has the same mask-length as = the EID-Prefix
sent a = Map-Reply message. returned = from the site when it sent a Map-Reply message.
=
Map-Reply = Record: When the M-bit is set, this field is the size of a = Map-Reply Record: When the M-bit is set, = this field is the size of a
single = "Record" in the Map-Reply format. This Map-Reply record = single "Record" in the Map-Reply format. = This Map-Reply record
contains = the EID-to-RLOC mapping entry associated with the Source = contains the EID-to-RLOC mapping entry = associated with the Source
EID. This = allows the ETR that will receive this Map-Request to EID. This allows the ETR that will receive this = Map-Request to
cache the = data if it chooses to do so. = cache the data if it chooses to do so.
=
5.3. EID-to-RLOC = UDP Map-Request Message 5.3. = EID-to-RLOC UDP Map-Request Message
=
A Map-Request = is sent from an ITR when it needs a mapping for an EID, = A Map-Request is sent from an ITR when it = needs a mapping for an EID,
=
skipping to = change at = page 20, line 17 =C2=B6 = skipping to change at page 21, line = 17 =C2=B6
= encapsulated packet can be an anycast address as well. The = source encapsulated packet can = be an anycast address as well. The source
or = destination RLOC MUST NOT be the broadcast address or destination RLOC MUST NOT be the broadcast = address
= (255.255.255.255 or any subnet broadcast address known to the = (255.255.255.255 or any subnet broadcast = address known to the
router) and = MUST NOT be a link-local multicast address. The router) and MUST NOT be a link-local multicast = address. The
source RLOC = MUST NOT be a multicast address. The destination RLOC source RLOC MUST NOT be a multicast address. The = destination RLOC
SHOULD be a = multicast address if it is being mapped from a SHOULD be a multicast address if it is being = mapped from a
multicast = destination EID. multicast = destination EID.
=
5.5. EID-to-RLOC = UDP Map-Reply Message 5.5. = EID-to-RLOC UDP Map-Reply Message
=
A Map-Reply = returns an EID-Prefix with a prefix length = that is less A Map-Reply returns = an EID-Prefix with a mask-length that is = less
than or equal = to the EID being requested. The EID being requested is = than or equal to the EID being requested. = The EID being requested is
either from = the destination field of an IP header of a Data-Probe or = either from the destination field of an IP = header of a Data-Probe or
the EID record = of a Map-Request. The RLOCs in the Map-Reply are the EID record of a Map-Request. The RLOCs in the = Map-Reply are
routable IP = addresses of all ETRs for the LISP site. Each RLOC routable IP addresses of all ETRs for the LISP site. = Each RLOC
conveys status = reachability but does not convey path reachability conveys status reachability but does not convey path = reachability
from a = requester's perspective. Separate testing of path from a requester's perspective. Separate testing of = path
reachability = is required. See RLOC-reachability Section 7.1 for reachability is required. See RLOC-reachability = Section 7.1 for
= details. details.
=
Note that a = Map-Reply MAY contain different EID-Prefix granularity Note that a Map-Reply MAY contain different = EID-Prefix granularity
(prefix + = length) than the Map-Request that triggers = it. This might (prefix + mask-length) than the Map-Request that triggers = it. This
occur if a = Map-Request were for a prefix that had been returned by an = might occur if a Map-Request were for a = prefix that had been returned
earlier = Map-Reply. In such a case, the requester updates its cache = by an earlier Map-Reply. In such a case, = the requester updates its
with the new = prefix information and granularity. For example, a cache with the new prefix information and = granularity. For example,
requester = with two cached EID-Prefixes that are covered by a Map- = a requester with two cached EID-Prefixes = that are covered by a Map-
Reply = containing one less-specific prefix replaces the entry with the = Reply containing one less-specific prefix = replaces the entry with the
less-specific = EID-Prefix. Note that the reverse, replacement of one less-specific EID-Prefix. Note that the reverse, = replacement of one
less-specific = prefix with multiple more-specific prefixes, can also less-specific prefix with multiple more-specific = prefixes, can also
occur, not by = removing the less-specific prefix but rather by adding occur, not by removing the less-specific prefix but = rather by adding
the = more-specific prefixes that, during a lookup, will override the = the more-specific prefixes that, during a = lookup, will override the
less-specific = prefix. less-specific = prefix.
=
When an EID = moves out of a LISP site [I-D.ietf-lisp-eid-mobility], When an EID moves out of a LISP site = [I-D.ietf-lisp-eid-mobility],
the database = mapping system may have overlapping EID-prefixes. Or the database mapping system may have overlapping = EID-prefixes. Or
when a LISP = site is configured with multiple sets of ETRs that when a LISP site is configured with multiple sets of = ETRs that
support = different EID-prefix lengths, the database = mapping system may support = different EID-prefix mask-lengths, the = database mapping
have = overlapping EID-prefixes. When overlapping EID-prefixes exist, system may have overlapping EID-prefixes. When = overlapping EID-
a = Map-Request with an EID that best matches any EID-Prefix MUST be prefixes exist, a = Map-Request with an EID that best matches any EID-
returned in = a single Map-Reply message. For instance, if an ETR had = Prefix MUST = be returned in a single Map-Reply message. For instance,
database = mapping entries for EID-Prefixes: = if an ETR had database mapping entries for EID-Prefixes:
=
= 2001:db8::/16 = 2001:db8::/16
= 2001:db8:1::/24 = 2001:db8:1::/24
= 2001:db8:1:1::/32 = 2001:db8:1:1::/32
= 2001:db8:1:2::/32 = 2001:db8:1:2::/32
=
A Map-Request = for EID 2001:db8:1:1::1 would cause a Map-Reply with a A Map-Request for EID 2001:db8:1:1::1 would cause a = Map-Reply with a
record count = of 1 to be returned with a mapping record EID-Prefix of = record count of 1 to be returned with a = mapping record EID-Prefix of
= 2001:db8:1:1::/32. = 2001:db8:1:1::/32.
=
=
skipping to = change at = page 24, line 39 =C2=B6 = skipping to change at page 25, line = 39 =C2=B6
requesting = a Map-Notify message to be returned in response to requesting a Map-Notify message to be returned in = response to
sending a = Map-Register message. The Map-Notify message sent by a = sending a Map-Register message. The = Map-Notify message sent by a
Map-Server = is used to acknowledge receipt of a Map-Register Map-Server is used to acknowledge receipt of a = Map-Register
= message. message.
=
Record Count: = This is the number of records in this Map-Register Record Count: This is the number of records in this = Map-Register
message. A = record is comprised of that portion of the packet message. A record is comprised of that portion of = the packet
labeled = 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of = times equal to
Record = Count. Record Count.
=
Nonce: This = 8-octet 'Nonce' field is set to 0 in = Map-Register Nonce: This = 8-octet 'Nonce' field is incremented each time a = Map-
messages if no Map-Notify message is expected to acknowledge it. Register message is = sent. When a Map-Register acknowledgement = is
Since the = Map-Register message is authenticated, the 'Nonce' field = requested, the = nonce is returned by Map-Servers in Map-Notify
is not currently used for any security function but may = be in the messages. Since the entire Map-Register message is = authenticated,
future as part of an anti-replay = solution. the 'Nonce' = field serves to protect against Map-Register = replay
= = attacks.
=
Key ID: This = is a configured key-id value that corresponds to a Key ID: This is a configured key-id value that = corresponds to a
= shared-secret password that is used to authenticate the sender. = shared-secret password that is used to = authenticate the sender.
Multiple = shared-secrets can be used to roll over keys in a non- Multiple shared-secrets can be used to roll over = keys in a non-
disruptive = way. disruptive way.
=
Algorithm ID: = This is the configured Message Authentication Code Algorithm ID: This is the configured Message = Authentication Code
(MAC) = algorithm value used for the authentication function. See = (MAC) algorithm value used for the = authentication function. See
Algorithm = ID Numbers in the Section 11.5 for codepoint Algorithm ID Numbers in the Section 11.5 for = codepoint
= assignments. = assignments.
=
skipping to = change at = page 46, line 17 =C2=B6 = skipping to change at page 47, line = 17 =C2=B6
12.1. Normative = References 12.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-22 = (work in progress), = (LISP)", draft-ietf-lisp-rfc6830bis-23 = (work in progress),
= October 2018. October = 2018.
=
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
skipping = to change at page 47, line = 36 =C2=B6 = skipping to change at page 48, line = 36 =C2=B6
= gpe-06 (work in progress), September 2018. gpe-06 (work in progress), September = 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-03 (work = in progress), Mobile = Node", draft-ietf-lisp-mn-04 (work in = progress),
= October 2018. October = 2018.
=
= [I-D.ietf-lisp-pubsub] = [I-D.ietf-lisp-pubsub]
= Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., = Rodriguez-Natal, A., Ermagan, V., = Leong, J., Maino, F.,
= Cabellos-Aparicio, A., Barkai, S., Farinacci, D., Cabellos-Aparicio, A., Barkai, S., = Farinacci, D.,
= Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ Boucadair, M., Jacquenet, C., and S. = Secci, "Publish/
= Subscribe Functionality for LISP", draft-ietf-lisp- Subscribe Functionality for LISP", = draft-ietf-lisp-
= pubsub-00 (work in progress), April = 2018. pubsub-01 (work in progress), October 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] = [I-D.ietf-nvo3-vxlan-gpe]
= Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol = Maino, F., Kreeger, L., and U. = Elzur, "Generic Protocol
= Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work = Extension for VXLAN", = draft-ietf-nvo3-vxlan-gpe-06 (work
in = progress), April 2018. = in progress), April 2018.
=
skipping = to change at page 51, line = 19 =C2=B6 = skipping to change at page 52, line = 19 =C2=B6
Fabio Maino, = and members of the lisp@ietf.org mailing list for their = Fabio Maino, and members of the = lisp@ietf.org mailing list for their
feedback and = helpful suggestions. feedback and = helpful suggestions.
=
Special thanks = are due to Noel Chiappa for his extensive work and Special thanks are due to Noel Chiappa for his = extensive work and
thought about = caching in Map-Resolvers. thought = about caching in Map-Resolvers.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6833bis-17 B.1. = Changes to draft-ietf-lisp-rfc6833bis-18
=
= o Posted mid = October 2018.
=
= o Fixed comments = from Eric after more email clarity.
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-17
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Changes to = reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th = Telechat.
=
o Added all = flag bit definitions as request for allocation in IANA o Added all flag bit definitions as request for = allocation in IANA
= Considersations section. = Considersations section.
=
o Added an = applicability statement in section 1 to address security = o Added an applicability statement in = section 1 to address security
concerns = from Telechat. concerns from = Telechat.
=
o Moved m-bit = description and IANA request to draft-ietf-lisp-mn. o Moved m-bit description and IANA request to = draft-ietf-lisp-mn.
=
o Moved I-bit = description and IANA request to draft-ietf-lisp- o Moved I-bit description and IANA request to = draft-ietf-lisp-
= pubsub. pubsub.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-16 B.3. Changes to = draft-ietf-lisp-rfc6833bis-16
=
o Posted = Late-September 2018. o Posted = Late-September 2018.
=
o Re-wrote = Security Considerations section. Thanks Albert. o Re-wrote Security Considerations section. Thanks = Albert.
=
o Added = Alvaro text to be more clear about IANA actions. o Added Alvaro text to be more clear about IANA = actions.
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-15 B.4. Changes to = draft-ietf-lisp-rfc6833bis-15
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Colin and Mirja. = o Changes to reflect comments from Colin and Mirja.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-14 B.5. Changes to = draft-ietf-lisp-rfc6833bis-14
=
o Posted = September 2018. o Posted September = 2018.
=
o Changes to = reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, = and Secdir
= reviews. reviews.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-13 B.6. Changes to = draft-ietf-lisp-rfc6833bis-13
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-12 B.7. 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.7. Changes to = draft-ietf-lisp-rfc6833bis-11 B.8. 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.8. Changes to = draft-ietf-lisp-rfc6833bis-10 B.9. 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.9. Changes to = draft-ietf-lisp-rfc6833bis-09 B.10. 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.10. Changes to = draft-ietf-lisp-rfc6833bis-08 B.11. 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.11. Changes to = draft-ietf-lisp-rfc6833bis-07 B.12. 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 53, line = 45 =C2=B6 = skipping to change at page 55, 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.12. Changes to = draft-ietf-lisp-rfc6833bis-06 B.13. 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.13. Changes to = draft-ietf-lisp-rfc6833bis-05 B.14. 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.14. Changes to = draft-ietf-lisp-rfc6833bis-04 B.15. 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.15. Changes to = draft-ietf-lisp-rfc6833bis-03 B.16. 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.16. Changes to = draft-ietf-lisp-rfc6833bis-02 B.17. 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.17. Changes to = draft-ietf-lisp-rfc6833bis-01 B.18. 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.18. Changes to = draft-ietf-lisp-rfc6833bis-00 B.19. 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.19. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.20. 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. 33 change blocks. 
106 lines changed or = deleted 118 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=_14DC9AB9-7CB9-4F68-B240-585328C77428 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 9, 2018, at 6:36 AM, Eric Rescorla wrote: >=20 >=20 >=20 > On Mon, Oct 8, 2018 at 5:41 PM Dino Farinacci = wrote: > Sorry the delay Eric. >=20 > >=20 > > > > S 5.5. > > > >> is being mapped from a multicast destination EID. > > > >>=20 > > > >> 5.5. EID-to-RLOC UDP Map-Reply Message > > > >>=20 > > > >> A Map-Reply returns an EID-Prefix with a prefix length that = is less > > > >> than or equal to the EID being requested. The EID being = requested is > > > >=20 > > > > How do I behave if I receive an EID-Prefix that is less than any = of my > > > > mappings. So, I might have mappings for 10.1.0.0/16 and = 10.2.0.0/16 > > > > and someone asks me for 10.0.0.0/8? > >=20 > > >=20 > > > I think I'm still unclear on this point. > >=20 > > The spec says you cache it. That is all you can do. But it means the = sender of the Map-Reply is not spec conformant. That means RLOCs are = used for the coarser EID-prefix. > >=20 > > Sorry, cache it? My question is how to respond to the case where the = Map-Request has this property. >=20 > I thought you were referring to the Map-Reply. If a Map-Request is = sent for 10.0.0.0/8 a replier needs to return in a Map-Reply /8, if it = is registered in the mapping system as well as all more specifics. That = is seldom done since a Map-Request is triggered for a destination EID in = an IP packet, but a =E2=80=9Clig=E2=80=9D client to ask to see if the = coarser prefix exists. >=20 > OK. Thanks. >=20 > > >=20 > > > Also, when you talk about prefix > > > > length, I assume you mean the length fo the mask? > > >=20 > > > Yes, this is explained later in this section. Was that not = helpful?? > > >=20 > > > I found it a bit confusing. It seems to me like there are two = lengths involved here: > > >=20 > > > - The length of the field (4 or 16) > > > - The parts of the field that are significant (i.e., the mask) > >=20 > > In routing, as you know, the mask-length is always the same as the = prefix-length. It is the number of bits in the mask. > >=20 > >=20 > > > I had thought that "prefix length" referred to the former, but it = seems like here it > > > refers to the latter. > >=20 > > The length of the address is defined by the 16-bit AFI that precedes = the address. > >=20 > > I agree, but the text refers to this as the prefix and it has a = length, which is the length of the encoded field, not the length of the = mask, as seen in this excerpt: > >=20 > > EID-Prefix: This prefix is 4 octets for an IPv4 address family = and > > 16 octets for an IPv6 address family when the EID-Prefix-AFI = is 1 > > or 2, respectively. For other AFIs [AFI], the length varies = and > > for the LCAF AFI the format is defined in [RFC8060]. When a = Map- >=20 > I will make this more clear. Thanks for the comment. Fixed in the = section you cite and make it more clear the different of =E2=80=9Caddress = length=E2=80=9D and =E2=80=9Cmask length=E2=80=9D in the = =E2=80=9CEID-Prefix=E2=80=9D definition. >=20 > Sounds good. >=20 >=20 > > > > S 5.3. > > > >> originating Map-Request source. If the RLOC is not in the = Locator- > > > >> Set, then the ETR MUST send the "verifying Map-Request" to = the > > > >> "piggybacked" EID. Doing this forces the "verifying = Map-Request" to > > > >> go through the mapping database system to reach the = authoritative > > > >> source of information about that EID, guarding against = RLOC-spoofing > > > >> in the "piggybacked" mapping data. > > > >=20 > > > > This text here doesn't seem compatible with either of the two = cases > > > > listed in "EID-prefix" above. > > >=20 > > > I don=E2=80=99t understand the comment Eric. Maybe because I = can=E2=80=99t find the exact reference to EID-prefix where you think = there is a conflict. Please cite for me. Thanks. > > >=20 > > > This does seem to have been assigned to the wrong text. > > >=20 > > > I am referring to: > > >=20 > > > " A Map-Reply returns an EID-Prefix with a prefix length that is = less > > > than or equal to the EID being requested. The EID being = requested is > > > either from the destination field of an IP header of a = Data-Probe or > > > the EID record of a Map-Request. The RLOCs in the Map-Reply = are > > > " > > >=20 > > > versus > > >=20 > > > " EID-Prefix: This prefix is 4 octets for an IPv4 address = family and > > > 16 octets for an IPv6 address family when the EID-Prefix-AFI = is 1 > > > or 2, respectively. For other AFIs [AFI], the length varies = and > > > for the LCAF AFI the format is defined in [RFC8060]. When a = Map- > > > " > > >=20 > > > This is just the question of whether "prefix length" refers to the = field or > > > the significant bits of the field. > >=20 > > Prefix-length =3D mask-length =3D number-of-bits-in-mask =3D = value-after-/. > >=20 > > OK, but then this second excerpt seems contradictory. We have an = EID-Prefix field which has a different length which is dictated by the = AFI only. >=20 > It is not contracdictory. Let me explain, if I have a map-cache entry = 10.0.0.0/8 and I want to query the mapping system, then I send a = Map-Request for 10.0.0.0/8. What comes back in the Map-Reply is the /8 = and more specifics if they are registered. >=20 > The definition section is saying what is in a Map-Request and the = other section that is describing behavior when a Map-Reply is returned. >=20 > OK. I'm going to assume that the changes you note above fixed my = confusion here as well. >=20 >=20 >=20 > > > > S 8.3. > > > >> of the mapping database protocols. > > > >>=20 > > > >> 8.3. Map-Server Processing > > > >>=20 > > > >> Once a Map-Server has EID-Prefixes registered by its client = ETRs, it > > > >> can accept and process Map-Requests for them. > > > >=20 > > > > This section is confusing because the introduction says that = this > > > > function is only performed by Map-Resolvers: > > > > ' > > > > "The LISP Mapping Service defines two new types of LISP-speaking > > > > devices: the Map-Resolver, which accepts Map-Requests from an > > > > Ingress > > > > Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping = using a=20 > > > > mapping database; and the Map-Server, which learns = authoritative > > > > EID- > > > > to-RLOC mappings from an Egress Tunnel Router (ETR) and = publishes > > > > them in a database.=E2=80=9D > > >=20 > > > The document does cover the operation of a Map-Resolver and a = Map-Server. Some functions are performed only by Map-Resolvers only and = other different functions are performed by Map-Servers only. > > >=20 > > > I am not sure what you don=E2=80=99t understand. > > >=20 > > > Sure: As I understand it, Map Resolvers process Map Requests, and = Map Servers do not (that's what the quoted text seems to say). However, = this sentence talks about a Map Server processing a Map Request. That's = where I am confused. > >=20 > > Here is a brief scenario: > >=20 > > (1) ITR sends Map-Request to a Map-Resolver. > > (2) Map-Resolver =E2=80=9Cfinds=E2=80=9D the Map-Server where the = EID could be registered. That is the mapping database transport system, = two examples are LISP-ALT and LISP-DDT. > > (3) The Map-Resolver in the case of LISP-DDT, will have a = referral-cache and know which map-server is authoriative for the = EID-prefix the Map-Request EID is for. > > (4) The Map-Resolver forwards the Map-Request to that Map-Server. > >=20 > > And hence Map-Servers process Map-Requests. The Map-Server can = proxy-reply with the RLOC-set cached in its site-cache or forward to one = or more ETRs (described by the RLOC-set) so they can map-reply. > >=20 > > Sure, this seems reasonable, but then perhaps the text above could = be revised, because it reads like Map Resolvers process these requests = and therefore implies that Map-Servers do not. >=20 > In the intro we are trying to explain at high-level the service = interface. But since Map-Resolvers forward Map-Requests to Map-Servers, = they process them to. But its through indirection. >=20 > OK, thanks. >=20 > -Ekr >=20 > Dino >=20 >=20 --Apple-Mail=_14DC9AB9-7CB9-4F68-B240-585328C77428-- From nobody Thu Oct 11 15:39: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 B605D128BAC; Thu, 11 Oct 2018 15:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.403 X-Spam-Level: X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_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 Ix0OIDyg2ESt; Thu, 11 Oct 2018 15:39:06 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 5BCF81277C8; Thu, 11 Oct 2018 15:39:05 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id v19-v6so11883559qtg.2; Thu, 11 Oct 2018 15:39:05 -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=DGVppGowMzutFnnnXMnRixMm+KiF+tOx3NW8vfPCsp8=; b=YC7UDmU1lfkp37TnEcdzZGrODiq8V55mkJBObQDSni0ztfPqrUGs7yvd4S+LVztBwr d/Q/fd6VZsZZbRQZmcuDOpIf1uus9j+nh+3SQzYLjA13XXbmdZMrifnJYjsDU6w72FHh lVxCezbA/p9mNBPt45ha+29JchZG+mg0d4puZPbFAT3CIBzteUW08xbTuZFDkMf4ZR16 MtTdZseFn2iSXUftQebfSblT+VM8Wk1VcQeKn2e/55RIM+GlbZ+wDMkHl6Nd1MD48TeC ccG5/hCbYrSN/Xw21A+TUdXambLnrykp0V1ggCv4vjIGvQZckB8NmeYytE1KBdzubasj 4c3Q== 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=DGVppGowMzutFnnnXMnRixMm+KiF+tOx3NW8vfPCsp8=; b=OIzRP+/SmAv0fdjjkIK6ufZ9G9Yy/qtVhFZocx5gX1HT2s448JAVu3nt52C0lXy0b/ 1e924fLcchjsJYFG292oGAWZrHEtZlzwyduUUzX5SnDibfI+BCtFl1A8AzgAJf/O5rje DGAgy1vXDtbkaIDOpyGpRV4V8plAkcfjpBHh1Io34WPS6AdrAR9HcXmS6M07UO5Hsd6a rMZITUIB6AtniIBqz4L1qAnX3ZFkdhcO6qDVtPRDMmNT7tf/FGHtII1afvXeAzd1a3/7 J+7nAGvjajd3h+rtHvn6+nC4sLsCB9XKA2/kCWZUSq9xx7C2ooRn4sMbbmJnX5YvVjvv L/Yg== X-Gm-Message-State: ABuFfoh/XRzOdTWEqsx0TrQX5Fk7xHbd1UzE4PNfGLr0V37wMG4bTsQp p9GS008v3QPZHGBanoF9/JM= X-Google-Smtp-Source: ACcGV60x796RGnS+6K8WTujyUrd7q6aeBbfacJ+1IoVJlJOK1Pcpc1XQOsnTHiN0YX7FeDYB/SDF/w== X-Received: by 2002:ac8:1096:: with SMTP id a22-v6mr3442185qtj.359.1539297544139; Thu, 11 Oct 2018 15:39:04 -0700 (PDT) Received: from dino-macbook.attlocal.net (adsl-108-94-3-15.dsl.pltn13.sbcglobal.net. [108.94.3.15]) by smtp.gmail.com with ESMTPSA id m64-v6sm13440684qkf.18.2018.10.11.15.38.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 15:39:02 -0700 (PDT) From: Dino Farinacci Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_957D466F-84D9-4622-8CF2-82BB56557038" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 11 Oct 2018 15:38:48 -0700 In-Reply-To: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, Albert Cabellos , "BRUNGARD, DEBORAH A" , Fabio Maino , "lisp@ietf.org list" To: Eric Rescorla , Benjamin Kaduk References: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 22:39:16 -0000 --Apple-Mail=_957D466F-84D9-4622-8CF2-82BB56557038 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Eric/Ben, I am following up with responses and changes to address the = security comments in 6830bis. I have both of your comments enclosed and = indented in this email. Eric=E2=80=99s comments come first then Ben=E2=80=99= s second. There are diff files attach for revisions 68830bis-24 and 6833bis-18. = They have not been posted yet. > S 4.1. >> RLOC (outer-header source IP address) in a received LISP = packet. >> Such a cache entry is termed a "glean mapping" and only = contains >> a single RLOC for the EID in question. More complete = information >> about additional RLOCs SHOULD be verified by sending a LISP = Map- >> Request for that EID. Both the ITR and the ETR MAY also >> influence the decision the other makes in selecting an RLOC. >=20 > This seems like it introduces an immediate overclaiming problem. It does not, if the gleaner wants to add this to the cache, it is /32 = EID with the source RLOC. So it is not overclaimed. If the gleaner wants = to verify the mapping, it does a lookup to the mapping system on the = source EID and then can get a coarser EID-prefix with an authorized list = of RLOCs. > S 10. >> When an ETR decapsulates a packet, it will check for any change in >> the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the >> ETR, if acting also as an ITR, will refrain from encapsulating >> packets to an RLOC that is indicated as down. It will only resume >> using that RLOC if the corresponding Locator-Status-Bit returns to = a >> value of 1. Locator-Status-Bits are associated with a Locator-Set >=20 > This seems to enable a pretty obvious denial of service attack in > which you send a message with all LSBs set to 0. The LSBs are a hint and usually used for =E2=80=9Cidling down RLOCs=E2=80=9D= . I will add text that ETR will rate-limit how often it reacts to LSB = changes. And note that its RLOC-probing cache will tell the rule truth = about if the RLOC is reachable. >=20 >=20 > S 10. >> list returned by the last Map-Reply will be set to zero for that >> particular EID-Prefix. Refer to Section 16 for security related >> issues regarding Locator-Status-Bits. >>=20 >> When an ETR decapsulates a packet, it knows that it is reachable = from >> the encapsulating ITR because that is how the packet arrived. In >=20 > It doesn't even know this. It just knows that that's been claimed by > someone who can generate traffic to it. Well this is true, but 6833bis discusses RLOC-reachability and there is = a RLOC-probe cache that will tell the ITR when it last heard from the = RLOC. >=20 >=20 > S 10.1. >> NOT use the lack of return traffic as an indication that the ETR = is >> unreachable. Instead, it MUST use an alternate mechanism to >> determine reachability. >>=20 >> 10.1. Echo Nonce Algorithm >>=20 >=20 > This mechanism seems sufficient to verify unreachability but is not a > secure test of reachability because the nonce is way too short. The nonce can remain the same value for a certain amount of time to = timeout reachability or when it receives the echo to the nonce. The = nonce need not be incremented for every packet. The nonce in the LISP = header is not used for security purposes, even though many want to use = it that way. But as you say, it is too width-short for that. >=20 > S 16. >> Map-Versioning is a Data-Plane mechanism used to signal a peering = xTR >> that a local EID-to-RLOC mapping has been updated, so that the >> peering xTR uses LISP Control-Plane signaling message to retrieve = a >> fresh mapping. This can be used by an attacker to forge the map- >> versioning field of a LISP encapsulated header and force an = excessive >> amount of signaling between xTRs that may overload them. >=20 > Can't I also set a super-high version number, thus gagging updates? It doesn=E2=80=99t matter the value. All that matters is that it changed = and you should do to the mapping system to get an updated RLOC-set. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > S 5.3. >> header. >>=20 >> When doing ETR/PETR decapsulation: >>=20 >> o The inner-header 'Time to Live' field (or 'Hop Limit' field, in >> the case of IPv6) SHOULD be copied from the outer-header 'Time = to >=20 > This should probably be a MUST because there are other protocols that > assume that TTLs get decremented. This was changed in a previous version post your comments. >=20 > S 7.1. >> destination site. The two fragments are reassembled at the >> destination host into the single IP datagram that was originated = by >> the source host. Note that reassembly can happen at the ETR if = the >> encapsulated packet was fragmented at or after the ITR. >>=20 >> This behavior MAY be performed by the ITR only when the source = host >=20 > Nit: I think you want to say MUST be, assuming you mean that you can > perform it only if=E2=80=A6. This was changed in a previous version post your comments. >=20 >=20 > S 7.2. >> 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated = packet >> with the DF bit set to 1, exceeds what the core network can >> deliver, one of the intermediate routers on the path will send = an >> ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/ >> Fragmentation-Needed to the ITR, respectively. The ITR will >> parse the ICMP message to determine which Locator is affected = by >=20 > What if you are in an environment where ICMP is blocked? I replied in previous email. >=20 >=20 > S 9. >> outside of the subset list if it determines that the subset = list >> is unreachable (unless RLOCs are set to a Priority of 255). = Some >> sharing of control exists: the server-side determines the >> destination RLOC list and load distribution while the = client-side >> has the option of using alternatives to this list if RLOCs in = the >> list are unreachable. >=20 > How would you obtain alternative RLOCs? I said in a previous email, you do a lookup in the mapping system. >=20 >=20 > S 10. >> also acting as an ITR and has traffic to return to the = original >> ITR site, it can use this status information to help select an >> RLOC. >>=20 >> 2. When an ETR receives an encapsulated packet from an ITR, the >> source RLOC from the outer header of the packet is likely up. >=20 > What does "is likely up" mean? This was changed in a previous version post your comments. Ben=E2=80=99s comments: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I have grave concerns about the suitability of LISP as a whole, in its > present form, for advancement to the Standards-Track. While some of = my > concerns are not specific to this document, as the core protocol > (data-plane) spec, it seems an appropriate place to attach them to. If you look at 6830bis-24 and 6833bis-18, we think we have addressed = your security concerns. > Section 3 defines the EID-to-RLOC Datbaase: >=20 > EID-to-RLOC Database: The EID-to-RLOC Database is a global > distributed database that contains all known EID-Prefix-to-RLOC > mappings. Each potential ETR typically contains a small piece of > the database: the EID-to-RLOC mappings for the EID-Prefixes > "behind" the router. These map to one of the router's own > globally visible IP addresses. Note that there MAY be transient > conditions when the EID-Prefix for the site and Locator-Set for > each EID-Prefix may not be the same on all ETRs. This has no > negative implications, since a partial set of Locators can be > used. >=20 > No compelling architecture for a trustworthy global distributed = database > has been presented that I've seen so far, and LISP relies heavily on = the > mapping system's database for its functionality. I am concerned that = so > many requirements are placed on the mapping system so as to be in = effect > unimplementable, in which case it would seem that the architecture as = a > whole (that is, for a global Internet-scale system) is not fit for = purpose. The DNS naming system and the BGP routing system are distributed = databases. But in any event, we removed the term =E2=80=9Cglobal=E2=80=9D = from both the data-plane and control-plane documents. > Section 4.1's Step (6) only mentions parsing "to check for format > validity". I think it is appropriate to mention (and refer to) source > authentication checks as well, since bad Map-Reply data can allow all = sorts > of attacks to occur. Well by now you should see that we have them. And one has to be careful = to not have a downgrade attack by continually doing source checks at = data-plane time. > There are some fairly subtle ordering requirements between the order = of > entries in Map-Reply messages and the Locator-Status-Bits in = data-plane It is not subtle. It is explicitly explained in section 10., > The usage of the Instance ID does not seem to be adequately covered; = from > what I've been able to pick up so far it seems that both source and > destination participants must agree on the meaning of an Instance ID, = and They do not have to agree. It is the ITR that decides when a packet = arrives which instance-ID an EID belongs to. This is discuss in quite a = lot of detail in draft-ietf-lisp-vpn. > the source and destination EIDs must be in the same Instance. This = does > not seem like it is compatible with Internet scale, especially if = there are > only 24 usable bits of Instance ID. draft-ietf-lisp-vpn explains how 24-bits can be used in the data-plane = but 32-bits of instance-ID is available in the control-plane. And that = is 32-bits *per* mapping system. ITRs can use other criteria to decide = which of many mapping systems it uses for lookups at data-plane time. > There seems to be a lot of intra-site synchronization requirements, = notably > with respect to Map-Version consistency, the contents and ordering of There is absolutely, and conscienciosuly no *intra* site sync = requirements. > locator sets for EIDs in the site, etc.; the actual hard requirements = for > synchronization within a site should be clearly called out, ideally in = a > single location. >=20 > The security considerations attempt to defer substantially to the > threat-analysis in RFC 7835, which does not really seem like a = complete > threat analysis and does not provide analysis as to what requirements = are > placed on the boundaries between the different components of LISP = (data > plane, control plane, mapping system, various extensions, etc.). The > secdir reviewer had some good thoughts in this space. This should be fixed now in both 6830bis-24 and 6833bis-18. > The security considerations throughout the LISP documents place a = heavy > focus on the risk of over-claiming for routing EID-prefixes. This is = a > real concern, to be clear, but it should not overshadow the risk of an > attacker who is able to move traffic around at will, strip security > protections, cause denial of service, alter data-plane payloads, etc. > Similarly, this document's security considerations call out denial of > service as a risk from Map-Cache insertion/spoofing, but the risks = from an > attacker being able to read and modify the traffic, perhaps even = without > detection, seems a much greater threat to me. This should be fixed now in both 6830bis-24 and 6833bis-18. > I am not convinced that this protocol meets the current IETF = requirements > for the security properties of Standards-Track Protocols without at = least > LISP-SEC as a mandatory-to-implement component, and possibly = additional or > stronger requirements. (I did not do a full analysis of the system in = the > presence of those security mechanisms, since that is not what is being > presented for review.) We have made draft-ietf-lisp-sec mandatory. Or at least, we have asked = the working group and there have been no objections so far. > Having an EID that is associated to user-correlatable devices has = severe > privacy considerations, but I could not find this mentioned anywhere = in all > of the LISP documents I've read so far. This should be fixed now in both 6830bis-24 and 6833bis-18. > The instance ID provides for organizational correlation, another = privacy > exposure. It is an opaque value and even though when LISP-crypto is used the LISP = header does travel in the clear, you do not know who uses it unless you = have access to the mapping system and authorized to do lookups on that = instance-ID. There are many keys required to get access to it (we have a = sort of MFA implemented). > Is there anything different between an "EID-to-RLOC Map-Request" and = just a > "Map-Request"? (Same question for "Map-Reply", too.) I have removed the single occurence of "EID-to-RLOC Map-Request=E2=80=9D = to =E2=80=9CMap-Request=E2=80=9D. > There's a lot of stuff that seems to work best if there is symmetric > bidirectional traffic, with inline signalling of map version and > reachability changes, though clearly everything is designed to also = work > with asymmetric connectivity or unidirectional traffic. It would be = nice > to have a high-level summary in or near the introduction about what = kinds > of behavior/performance differences are expected for bidirectional vs. > unidirectional traffic. Nothing requires one or the other at the data-plane. I would prefer to = not mention this. Because it may introduce comments not covered yet in = the document or are control-plane related that don=E2=80=99t belong in = 6830bis. > Section 2 >=20 > That's not the 8174 boilerplate; it's more than just adding a cite to = the > 2119 boilerplate. This was changed in a previous version post your comments. >=20 > Section 3 >=20 > nit: "An address family that pertains to the Data-Plane." is a = sentence > fragment. >=20 > Ingress Tunnel Router (ITR): An ITR is a router that resides in a > [...] > mapping lookup in the destination address field. Note that this > destination RLOC MAY be an intermediate, proxy device that has > better knowledge of the EID-to-RLOC mapping closer to the >=20 > This doesn't seem like a 2119 MAY is necessary, but rather a statement = of > fact that may not be known to the encapsulating ITR. >=20 > Specifically, when a service provider prepends a LISP header for > Traffic Engineering purposes, the router that does this is also > regarded as an ITR. The outer RLOC the ISP ITR uses can be based > on the outer destination address (the originating ITR's supplied > RLOC) or the inner destination address (the originating host's > supplied EID). >=20 > I'm confused here, perhaps in multiple ways. Are there now *two* LISP > headers on the packet? Is the "outer RLOC the ISP ITR uses" the = source > RLOC or the destination RLOC? >=20 > Negative Mapping Entry: A negative mapping entry, also known as a > negative cache entry, is an EID-to-RLOC entry where an EID-Prefix > is advertised or stored with no RLOCs. That is, the Locator-Set > for the EID-to-RLOC entry is empty or has an encoded Locator count > of 0. >=20 > Is "empty" a distinct representation from "locator count of zero=E2=80=9D= ? All fixed in a previous version post your comments. > Perhaps something of an aside, but the check described for > Route-Returnability is a somewhat weak check, and in some cases could = still > be spoofed. (I don't expect this to surprise anyone, of course, but > perhaps some more qualifiers could be added to the text.) >=20 > Section 4 >=20 > An additional LISP header MAY be prepended to packets by a TE-ITR > when re-routing of the path for a packet is desired. A potential > use-case for this would be an ISP router that needs to perform > Traffic Engineering for packets flowing through its network. In such > a situation, termed "Recursive Tunneling", an ISP transit acts as an > additional ITR, and the RLOC it uses for the new prepended header > would be either a TE-ETR within the ISP (along an intra-ISP traffic > engineered path) or a TE-ETR within another ISP (an inter-ISP traffic > engineered path, where an agreement to build such a path exists). >=20 > "the RLOC it uses for the new prepnded header", again, this is as the > destination RLOC (vs. source RLOC)? Fixed in a previous version post your comments. > Section 4.1 >=20 > o Map-Replies are sent on the underlying routing system topology > using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. >=20 > Just to check my understanding: is the "underlying routing system = topology" > the same as the "underlay"? >=20 > Is step (3) just describing more of what step (2) says is "not = described in > this example=E2=80=9D? All fixed in a previous version post your comments. > Section 5.3 >=20 > The word "nonce" is normally used for something used exactly once. > E.g., with some AEAD algorithms, if the same "nonce" input is used for > different encryptions, the entire security of the system is = compromised. > It would be better to refer to this field with a different term, given > that "the same nonce can be used for a period of time when = encapsulating to > the same ETR". "Uniquifier" or "random value" might be reasonable = choices. We can=E2=80=99t change this. There is too much deployment and = terminology based on it. It is a random number, a relatively small one = but a random number. > Why is there no discussion of the Map-Version or Instance-ID fields > in this section? >=20 > When doing ETR/PETR decapsulation: >=20 > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > the case of IPv6) SHOULD be copied from the outer-header 'Time to > Live' field, when the Time to Live value of the outer header is > less than the Time to Live value of the inner header. Failing to > perform this check can cause the Time to Live of the inner header > to increment across encapsulation/decapsulation cycles. This > check is also performed when doing initial encapsulation, when a > packet comes to an ITR or PITR destined for a LISP site. >=20 > Er, what is "this check" that is also performed for initial = encapsulation? > How are there multiple TTL values to compare? >=20 > o The inner-header 'Differentiated Services Code Point' (DSCP) field > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be > copied from the outer-header DSCP field ('Traffic Class' field, in > the case of IPv6) to the inner-header. >=20 > nit: the first "inner-header" seems like an editing remnant? All fixed in a previous version post your comments. >=20 > Section 7.1 >=20 > How is this stateless if it invovles knowledge about the routers = between > the ITR and all possible ETRs (i.e., a set that could change over = time)? >=20 > Section 8 >=20 > This 32-bit vs 24-bit thing is pretty hokey for a standards-track > specification (yes, I know that LISP-DDT is not standards track at the > moment). Already explained. See draft-ietf-lisp-vpn. It isn=E2=80=99t hokey, we = want to have a large space and not spend the cost of it in the = data-plane. So we have to compress the value. > Section 9 >=20 > Alternatively, RLOC information MAY be gleaned from received tunneled >=20 > What is this an alternative to? The list of four options above? >=20 > packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache > entry, one learned from the source RLOC of a received encapsulated > packet, is only stored and used for a few seconds, pending > verification. Verification is performed by sending a Map-Request to > the source EID (the inner-header IP source address) of the received > encapsulated packet. >=20 > The source EID is some random end system, right? So this relys on = some > magic in the ETR to detect that there's a Map-Request and reply = directly > instead of passing it on to the EID that won't know what to do with = it? I hope by now, you understand this. > Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and > might benefit from an explicit section reference to the other = document. That was fixed. > Section 10 >=20 > What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it > is not marked as well-known at > https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion = is > probably in order. Answered. We have it in the Definition of Terms section. > Again, when we are talking about the internal structure of the = Map-Reply, a > detailed section refernce to 6833bis is useful. >=20 > Modifying LSBs seems like a fine DoS attack vector for an on-path = attacker. >=20 > value of 1. Locator-Status-Bits are associated with a Locator-Set > per EID-Prefix. Therefore, when a Locator becomes unreachable, the > Locator-Status-Bit that corresponds to that Locator's position in the > list returned by the last Map-Reply will be set to zero for that > particular EID-Prefix See comments above to Eric. > Doesn't this imply a stateful relationship between the ordering of > Map-Replys and data-plane traffic? >=20 > Section 10.1 >=20 > Note that "ITR" and "ETR" are relative terms here. Both devices MUST > be implementing both ITR and ETR functionality for the echo nonce > mechanism to operate. Answered previously. I believe you understand this now. > Perhaps they could be given actual names so as to disambiguate which = steps > are performed with ITR vs. ETR role? >=20 > The echo-nonce algorithm is bilateral. That is, if one side sets the > E-bit and the other side is not enabled for echo-noncing, then the > echoing of the nonce does not occur and the requesting side may > erroneously consider the Locator unreachable. An ITR SHOULD only set > the E-bit in an encapsulated data packet when it knows the ETR is > enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- > probe Map-Reply message. >=20 > Why is this even optional? If it was mandatory to use, then there = would > not be a question. But at least clarify that the "this" that is = conveyed > is whether the peer supports the echo-nonce algorithm. (Also, subject = to > downgrade.) It is optional because you can use RLOC-probing in the control-plane. > Section 13 >=20 > When a Locator record is removed from a Locator-Set, ITRs that have > the mapping cached will not use the removed Locator because the xTRs > will set the Locator-Status-Bit to 0. So, even if the Locator is in > the list, it will not be used. For new mapping requests, the xTRs > can set the Locator AFI to 0 (indicating an unspecified address), as > well as setting the corresponding Locator-Status-Bit to 0. This > forces ITRs with old or new mappings to avoid using the removed > Locator. >=20 > The behavior describe here seems like it would be better described as = "when > a Locator is taken out of service" than "removed from a Locator-Set", = since > if it is not in the set at all, it has no index, and no LSB or AFI to = set. > Should actually depopulating it like this be forbidden? Answered above and new text added. > I guess the Map Versioning is supposed to help with this, but we need = to > nail down the semantics more and/or give a clearer reference to it. That was done for you. > Section 13.1 >=20 > An ITR, when it encapsulates packets to ETRs, can convey its own Map- > Version Number. This is known as the Source Map-Version Number. >=20 > Replacing "its own Map-Version Number" with something like "the = Map-Version > numer for the LISP site of which it is a part". Writing this causes = me to > note that the semantics of the Map-Version are unclear, here -- what = is it > scoped to? An EID-Prefix? An RLOC? Oh, you say that in the next > paragraph (EID-Prefix). >=20 > A Map-Version Number can be included in Map-Register messages as > well. This is a good way for the Map-Server to assure that all ETRs > for a site registering to it will be synchronized according to Map- > Version Number. >=20 > Huh? I must be confused how this works. (Also, wouldn't this be = better in > the control plane document which covers Map-Register?) The reference to draft-ietf-lisp-rfc68934bis should help this. > Section 15 >=20 > o When a tunnel-encapsulated packet is received by an ETR, the outer > destination address may not be the address of the router. This > makes it challenging for the control plane to get packets from the > hardware. This may be mitigated by creating special Forwarding > Information Base (FIB) entries for the EID-Prefixes of EIDs served > by the ETR (those for which the router provides an RLOC > translation). These FIB entries are marked with a flag indicating > that Control-Plane processing SHOULD be performed. >=20 > I assume this is just my lack of background showing, but I'm confused = how > it makes sense to mark these for control-plane processing. Isn't the > control plane much slower, and we're not putting all of the LISP = data-plane > traffic onto the slow path? Answered in previous email. I think you understand this now. > Section 18 >=20 > o Data-Plane gleaning for creating map-cache entries has been made > optional. If any ITR implementations depend or assume the remote > ETR is gleaning should not do so. >=20 > nit: this is ungrammatical; "they should not" or "Any ITR = implementations > that depend on or assume that" would fix it. That was fixed pre -24. > Section 19.1 >=20 > Presumably IANA also updated the reference column to point to this > document? Yes, it is now. Thanks all, Dino --Apple-Mail=_957D466F-84D9-4622-8CF2-82BB56557038 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-23.txt - = draft-ietf-lisp-rfc6830bis-24.txt=20 =20 =20 =20 =20 =20 =20 = =
< draft-ietf-lisp-rfc6830bis-23.txt  =  draft-ietf-lisp-rfc6830bis-24.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: April = 6, 2019 = Cisco Systems Expires: April 14, 2019 = Cisco Systems
= A. Cabellos (Ed.) = A. Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= October = 3, 2018 = October = 11, 2018
=
= The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol = (LISP)
= draft-ietf-lisp-rfc6830bis-23 = = draft-ietf-lisp-rfc6830bis-24
=
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 April 6, = 2019. This Internet-Draft will = expire on April 14, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 3, line 6 =C2=B6 = skipping to change at page 3, line 6 =C2=B6
15. Router = Performance Considerations . . . . . . . . . . . . . . 31 = 15. Router Performance Considerations . . . = . . . . . . . . . . . 31
16. Security = Considerations . . . . . . . . . . . . . . . . . . . 32 = 16. Security Considerations . . . . . . . . = . . . . . . . . . . . 32
17. Network = Management Considerations . . . . . . . . . . . . . . 33 = 17. Network Management Considerations . . . = . . . . . . . . . . . 33
18. Changes = since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 = 18. Changes since RFC 6830 . . . . . . . . = . . . . . . . . . . . 33
19. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 34 = 19. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 34
19.1. LISP = UDP Port Numbers . . . . . . . . . . . . . . . . . 34 = 19.1. LISP UDP Port Numbers . . . . . . = . . . . . . . . . . . 34
20. References = . . . . . . . . . . . . . . . . . . . . . . . . . 34 20. References . . . . . . . . . . . . . . . . . . . = . . . . . . 34
20.1. = Normative References . . . . . . . . . . . . . . . . . . 34 = 20.1. Normative References . . . . . . . = . . . . . . . . . . . 34
20.2. = Informative References . . . . . . . . . . . . . . . . . 35 = 20.2. Informative References . . . . . . = . . . . . . . . . . . 35
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 39 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 39 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40
B.1. = Changes to draft-ietf-lisp-rfc6830bis-22 = . . . . . . . . 40 B.1. = Changes to draft-ietf-lisp-rfc6830bis-24 = . . . . . . . . 40
B.2. = Changes to draft-ietf-lisp-rfc6830bis-22 = . . . . . . . . 40 B.2. = Changes to draft-ietf-lisp-rfc6830bis-23 = . . . . . . . . 40
B.3. = Changes to draft-ietf-lisp-rfc6830bis-21 = . . . . . . . . 40 B.3. = Changes to draft-ietf-lisp-rfc6830bis-22 = . . . . . . . . 40
B.4. = Changes to draft-ietf-lisp-rfc6830bis-20 = . . . . . . . . 40 B.4. = Changes to draft-ietf-lisp-rfc6830bis-21 = . . . . . . . . 40
B.5. = Changes to draft-ietf-lisp-rfc6830bis-19 = . . . . . . . . 40 B.5. = Changes to draft-ietf-lisp-rfc6830bis-20 = . . . . . . . . 40
B.6. = Changes to draft-ietf-lisp-rfc6830bis-18 = . . . . . . . . 40 B.6. = Changes to draft-ietf-lisp-rfc6830bis-19 = . . . . . . . . 40
B.7. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 40 B.7. Changes to draft-ietf-lisp-rfc6830bis-18 . . . . . . . . = 41
B.8. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 41 B.8. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 41
B.9. = Changes to draft-ietf-lisp-rfc6830bis-15 = . . . . . . . . 41 B.9. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 41
B.10. = Changes to draft-ietf-lisp-rfc6830bis-14 = . . . . . . . . 41 B.10. = Changes to draft-ietf-lisp-rfc6830bis-15 = . . . . . . . . 41
B.11. = Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 41 B.11. = Changes to draft-ietf-lisp-rfc6830bis-14 = . . . . . . . . 41
B.12. = Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 41 B.12. = Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 41
B.13. = Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 41 B.13. Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . = 42
B.14. = Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 42 B.14. = Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 42
B.15. = Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 42 B.15. = Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 42
B.16. = Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 42 B.16. = Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 42
B.17. = Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 43 B.17. = Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 43
B.18. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 43 B.18. = Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 43
B.19. = Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 43 B.19. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 43
B.20. = Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 43 B.20. = Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 43
B.21. = Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 44 B.21. = Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 44
B.22. = Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 44 B.22. = Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 44
B.23. = Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 44 B.23. = Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 44
B.24. = Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 44 = B.24. Changes to = draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 44
= B.25. = Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 44
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 44
=
1. = Introduction 1. Introduction
=
This document = describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier = Separation Protocol
(LISP). LISP = is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built = around the
fundamental = idea of separating the topological location of a network = fundamental idea of separating the = topological location of a network
attachment = point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. = As a result
LISP creates = two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers = (EIDs), that are
used to = identify end-hosts (e.g., nodes or Virtual Machines) and = used to identify end-hosts (e.g., nodes or = Virtual Machines) and
=
skipping to = change at = page 7, line 45 =C2=B6 = skipping to change at page 7, line 45 =C2=B6
LISP Site: = LISP site is a set of routers in an edge network that are = LISP Site: LISP site is a set of routers in = an edge network that are
under a = single technical administration. LISP routers that reside = under a single technical administration. = LISP routers that reside
in the edge = network are the demarcation points to separate the in the edge network are the demarcation points to = separate the
edge = network from the core network. = edge network from the core network.
=
= Locator-Status-Bits (LSBs): Locator-Status-Bits are present in = the Locator-Status-Bits (LSBs): = Locator-Status-Bits are present in the
LISP = header. They are used by ITRs to inform ETRs about the up/ = LISP header. They are used by ITRs to = inform ETRs about the up/
down status = of all ETRs at the local site. These bits are used as down status of all ETRs at the local site. These = bits are used as
a hint to = convey up/down router status and not path reachability a hint to convey up/down router status and not = path reachability
status. = The LSBs can be verified by use of one of the Locator status. The LSBs can be verified by use of one of = the Locator
= reachability algorithms described in Section 10. reachability algorithms described in Section 10. = An ETR MUST
= rate-limit the = action it takes when it detects changes in the
= = Locator-Status-Bits.
=
Negative = Mapping Entry: A negative mapping entry, also known as a = Negative Mapping Entry: A negative mapping = entry, also known as a
negative = cache entry, is an EID-to-RLOC entry where an EID-Prefix = negative cache entry, is an EID-to-RLOC = entry where an EID-Prefix
is = advertised or stored with no RLOCs. That is, the Locator-Set = is advertised or stored with no RLOCs. = That is, the Locator-Set
for the = EID-to-RLOC entry is empty, one with an encoded Locator = for the EID-to-RLOC entry is empty, one = with an encoded Locator
count of 0. = This type of entry could be used to describe a prefix count of 0. This type of entry could be used to = describe a prefix
from a = non-LISP site, which is explicitly not in the mapping from a non-LISP site, which is explicitly not in = the mapping
database. = There are a set of well-defined actions that are database. There are a set of well-defined actions = that are
encoded in = a Negative Map-Reply. encoded in = a Negative Map-Reply.
=
=
skipping to = change at = page 24, line 36 =C2=B6 = skipping to change at page 24, line = 36 =C2=B6
controls = how traffic is returned and can alternate using an outer- = controls how traffic is returned and can = alternate using an outer-
header = source RLOC, which then can be added to the list the header source RLOC, which then can be added to the = list the
server-side = ETR uses to return traffic. Since no Priority or server-side ETR uses to return traffic. Since no = Priority or
Weights are = provided using this method, the server-side ETR MUST Weights are provided using this method, the = server-side ETR MUST
assume that = each client-side ITR RLOC uses the same best Priority assume that each client-side ITR RLOC uses the = same best Priority
with a = Weight of zero. In addition, since EID-Prefix encoding = with a Weight of zero. In addition, = since EID-Prefix encoding
cannot be = conveyed in data packets, the EID-to-RLOC Cache on cannot be conveyed in data packets, the = EID-to-RLOC Cache on
Tunnel = Routers can grow to be very large. = Tunnel Routers can grow to be very large.
=
Instead of = using the Map-Cache or mapping system, RLOC information = Instead of using the Map-Cache or mapping = system, RLOC information
MAY be = gleaned from received tunneled packets or EID-to-RLOC Map- MAY be gleaned from received tunneled packets or = Map-Request
Request messages. A "gleaned" Map-Cache = entry, one learned from the = messages. A "gleaned" Map-Cache entry, one learned from the = source
source RLOC = of a received encapsulated packet, is only stored and RLOC of a received encapsulated packet, is only = stored and used for a
used for a = few seconds, pending verification. Verification is few seconds, pending verification. Verification is = performed by
performed by = sending a Map-Request to the source EID (the inner- = sending a Map-Request to the source EID (the inner-header IP source
header IP source address) of the received = encapsulated packet. A address) = of the received encapsulated packet. A reply to this
reply to = this "verifying Map-Request" is used to fully populate the = "verifying Map-Request" is used to fully = populate the Map-Cache entry
Map-Cache = entry for the "gleaned" EID and is stored and used for the = for the "gleaned" EID and is stored and = used for the time indicated
time = indicated from the 'TTL' field of a received Map-Reply. When a = from the 'TTL' field of a received = Map-Reply. When a verified Map-
verified = Map-Cache entry is stored, data gleaning = no longer occurs Cache entry is stored, data gleaning no = longer occurs for subsequent
for = subsequent packets that have a source EID that matches the EID- = packets that have a source EID that matches the EID-Prefix of the
Prefix of the verified entry. This = "gleaning" mechanism is OPTIONAL, = verified entry. This "gleaning" mechanism is OPTIONAL, refer to
refer to = Section 16 for security issues regarding this mechanism. = Section 16 for security issues regarding = this mechanism.
=
RLOCs that = appear in EID-to-RLOC Map-Reply messages are assumed to be = RLOCs that appear in EID-to-RLOC Map-Reply = messages are assumed to be
reachable when = the R-bit [I-D.ietf-lisp-rfc6833bis] for the Locator reachable when the R-bit [I-D.ietf-lisp-rfc6833bis] = for the Locator
record is set = to 1. When the R-bit is set to 0, an ITR or PITR MUST record is set to 1. When the R-bit is set to 0, an = ITR or PITR MUST
NOT = encapsulate to the RLOC. Neither the information contained in = a NOT encapsulate to the RLOC. = Neither the information contained in a
Map-Reply nor = that stored in the mapping database system provides Map-Reply nor that stored in the mapping database = system provides
reachability = information for RLOCs. Note that reachability is not reachability information for RLOCs. Note that = reachability is not
part of the = mapping system and is determined using one or more of the = part of the mapping system and is determined = using one or more of the
Routing = Locator reachability algorithms described in the next Routing Locator reachability algorithms described in = the next
= section. section.
=
skipping to = change at = page 34, line 31 =C2=B6 = skipping to change at page 34, line = 31 =C2=B6
20.1. Normative = References 20.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6833bis] = [I-D.ietf-lisp-rfc6833bis]
= Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. = Cabellos-Aparicio,
= "Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) = Control-Plane",
= draft-ietf-lisp-rfc6833bis-16 (work in = progress), draft-ietf-lisp-rfc6833bis-17 (work in = progress), October
= September 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>.
=
[RFC2119] = Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to = Indicate
=
skipping to = change at = page 39, line 17 =C2=B6 = skipping to change at page 39, line = 17 =C2=B6
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.
=
A special and = appreciative thank you goes to Noel Chiappa for A special and appreciative thank you goes to Noel = Chiappa for
providing = architectural impetus over the past decades on separation = providing architectural impetus over the = past decades on separation
of location = and identity, as well as detailed reviews of the LISP of location and identity, as well as detailed reviews = of the LISP
architecture = and documents, coupled with enthusiasm for making LISP a = architecture and documents, coupled with = enthusiasm for making LISP a
practical and = incremental transition for the Internet. practical and incremental transition for the = Internet.
=
The authors = would like to gratefully acknowledge many people who have = The original = authors would like to gratefully acknowledge many people
contributed = discussions and ideas to the making of this proposal. who have contributed discussions and ideas to the = making of this
They include = Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, = proposal. They include Scott Brim, Andrew = Partan, John Zwiebel,
Lixia Zhang, = Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, = Jason Schiller, Lixia Zhang, Dorian Kim, = Peter Schoenmaker, Vijay
David = Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, = Gill, Geoff Huston, David Conrad, Mark = Handley, Ron Bonica, Ted
Chris = Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, = Seely, Mark Townsley, Chris Morrow, Brian = Weis, Dave McGrew, Peter
Eliot Lear, = Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved = Kafle, Olivier
Iannone, = Robin Whittle, Brian Carpenter, Joel Halpern, Terry Bonaventure, Luigi Iannone, Robin Whittle, Brian = Carpenter, Joel
Manderson, = Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van = Halpern, Terry Manderson, Roger Jorgensen, = Ran Atkinson, Stig Venaas,
Beijnum, = Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien = Iljitsch van Beijnum, Roland Bless, Dana = Blair, Bill Lynch, Marc
Saucez, = Damian Lezama, Attilla De Groot, Parantap Lahiri, David = Woolward, Damien Saucez, Damian Lezama, = Attilla De Groot, Parantap
Black, Roque = Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, = Lahiri, David Black, Roque Gagliano, Isidor = Kouvelas, Jesper Skriver,
Margaret = Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari = Fred Templin, Margaret Wasserman, Sam = Hartman, Michael Hofling, Pedro
Arkko, Gregg = Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Marques, Jari Arkko, Gregg Schudel, Srinivas = Subramanian, Amit Jain,
Dhirendra = Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri = Xu Xiaohu, Dhirendra Trivedi, Yakov = Rekhter, John Scudder, John
= Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina = Drake, Dimitri Papadimitriou, Ross Callon, = Selina Heimlich, Job
Ermagan, = Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, = Snijders, Vina Ermagan, Fabio Maino, Victor = Moreno, Chris White,
Alia Atlas, = Florin Coras and Alberto Rodriguez. = Clarence Filsfils, Alia Atlas, Florin Coras and Alberto = Rodriguez.
=
This work = originated in the Routing Research Group (RRG) of the IRTF. = This work originated in the Routing Research = Group (RRG) of the IRTF.
An individual = submission was converted into the IETF LISP working An individual submission was converted into the IETF = LISP working
group document = that became this RFC. group = document that became this RFC.
=
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.
=
= The current authors = would like to give a sincere thank you to the
= people who help put = LISP on standards track in the IETF. They
= include Joel = Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino,
= Scott Bradner, Kyle = Rose, Takeshi Takahashi, Sarah Banks, Pete
= Resnick, Colin = Perkins, Mirja Kuhlewind, Francis Dupont, Benjamin
= Kaduk, Eric = Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper,
= Suresh Krishnan, = Alberto Rodriguez-Natal, Vina Ermagen, Mohamed
= Boucadair, Brian = Trammell, Sabrina Tanamal, and John Drake. The
= contributions they = offered greatly added to the security, scale, and
= robustness of the = LISP architecture and protocols.
= =
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-22 = B.1. Changes to draft-ietf-lisp-rfc6830bis-24
=
= o Posted mid = October 2018.
=
= o Final editorial = changes for Eric and Ben.
=
= B.2. Changes to = draft-ietf-lisp-rfc6830bis-23
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Added an = applicability statement in section 1 to address security = o Added an applicability statement in = section 1 to address security
concerns = from Telechat. concerns from = Telechat.
=
B.2. Changes to = draft-ietf-lisp-rfc6830bis-22 B.3. Changes to = draft-ietf-lisp-rfc6830bis-22
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Changes to = reflect comments post Telechat. o = Changes to reflect comments post Telechat.
=
B.3. Changes to = draft-ietf-lisp-rfc6830bis-21 B.4. Changes to = draft-ietf-lisp-rfc6830bis-21
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o Changes to = reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th = Telechat.
=
B.4. Changes to = draft-ietf-lisp-rfc6830bis-20 B.5. Changes to = draft-ietf-lisp-rfc6830bis-20
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o Fix old = reference to RFC3168, changed to RFC6040. o Fix old reference to RFC3168, changed to = RFC6040.
=
B.5. Changes to = draft-ietf-lisp-rfc6830bis-19 B.6. Changes to = draft-ietf-lisp-rfc6830bis-19
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o More = editorial changes. o More = editorial changes.
=
B.6. Changes to = draft-ietf-lisp-rfc6830bis-18 B.7. Changes to = draft-ietf-lisp-rfc6830bis-18
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Secdir review (Mirja). o Changes to reflect comments from Secdir review = (Mirja).
=
B.7. Changes to = draft-ietf-lisp-rfc6830bis-17 B.8. Changes to = draft-ietf-lisp-rfc6830bis-17
=
o Posted = September 2018. o Posted September = 2018.
=
o Indicate in = the "Changes since RFC 6830" section why the document o Indicate in the "Changes since RFC 6830" section = why the document
has been = shortened in length. has been = shortened in length.
=
o Make = reference to RFC 8085 about UDP congestion control. o Make reference to RFC 8085 about UDP congestion = control.
=
o More = editorial changes from multiple IESG reviews. o More editorial changes from multiple IESG = reviews.
=
B.8. Changes to = draft-ietf-lisp-rfc6830bis-16 B.9. 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.9. Changes to = draft-ietf-lisp-rfc6830bis-15 B.10. Changes to = draft-ietf-lisp-rfc6830bis-15
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6830" so implementers are o Added section "Changes since RFC 6830" so = implementers are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.10. Changes to = draft-ietf-lisp-rfc6830bis-14 B.11. 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.11. Changes to = draft-ietf-lisp-rfc6830bis-13 B.12. 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.12. Changes to = draft-ietf-lisp-rfc6830bis-12 B.13. 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.13. Changes to = draft-ietf-lisp-rfc6830bis-11 B.14. 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.14. Changes to = draft-ietf-lisp-rfc6830bis-10 B.15. 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.15. Changes to = draft-ietf-lisp-rfc6830bis-09 B.16. 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.16. Changes to = draft-ietf-lisp-rfc6830bis-08 B.17. 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.17. Changes to = draft-ietf-lisp-rfc6830bis-07 B.18. 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.18. Changes to = draft-ietf-lisp-rfc6830bis-06 B.19. Changes to = draft-ietf-lisp-rfc6830bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Put RTR = definition before it is used. o = Put RTR definition before it is used.
=
o Rename = references that are now working group drafts. o Rename references that are now working group = drafts.
=
o Remove = "EIDs MUST NOT be used as used by a host to refer to other = o Remove "EIDs MUST NOT be used as used by = a host to refer to other
hosts. = Note that EID blocks MAY LISP RLOCs". = hosts. Note that EID blocks MAY LISP RLOCs".
=
=
skipping to = change at = page 43, line 35 =C2=B6 = skipping to change at page 43, line = 48 =C2=B6
o ETRs may, = rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send = Map-Replies.
=
o Recommend, = rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation = headers to 2.
=
o Reference = VPN draft when introducing Instance-ID. = o Reference VPN draft when introducing Instance-ID.
=
o Indicate = that SMRs can be sent when ITR/ETR are in the same node. = o Indicate that SMRs can be sent when = ITR/ETR are in the same node.
=
o Clarify = when private addresses can be used. = o Clarify when private addresses can be used.
=
B.19. Changes to = draft-ietf-lisp-rfc6830bis-05 B.20. Changes to = draft-ietf-lisp-rfc6830bis-05
=
o Posted = August 2017. o Posted August = 2017.
=
o Make it = clear that a Re-encapsulating Tunnel Router is an RTR. o Make it clear that a Re-encapsulating Tunnel = Router is an RTR.
=
B.20. Changes to = draft-ietf-lisp-rfc6830bis-04 B.21. 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.21. Changes to = draft-ietf-lisp-rfc6830bis-03 B.22. 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.22. Changes to = draft-ietf-lisp-rfc6830bis-02 B.23. 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.23. Changes to = draft-ietf-lisp-rfc6830bis-01 B.24. 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.24. Changes to = draft-ietf-lisp-rfc6830bis-00 B.25. Changes to = draft-ietf-lisp-rfc6830bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6830-00 = individual submission. No other changes made. -rfc6830-00 individual submission. No other = changes made.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
Cisco = Systems Cisco Systems
Tasman = Drive Tasman Drive
San Jose, CA = 95134 San Jose, CA 95134
USA = USA
=
EMail: = farinacci@gmail.com EMail: = farinacci@gmail.com
= =
Vince = Fuller Vince Fuller
Cisco = Systems Cisco Systems
Tasman = Drive Tasman Drive
San Jose, CA = 95134 San Jose, CA 95134
USA = USA
=
EMail: = vince.fuller@gmail.com EMail: = vince.fuller@gmail.com
=
Dave = Meyer Dave Meyer
Cisco = Systems Cisco Systems
 End of changes. 36 change blocks. 
88 lines changed or = deleted 108 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=_957D466F-84D9-4622-8CF2-82BB56557038 Content-Disposition: attachment; filename=rfcdiff-6833bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6833bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-17.txt - = draft-ietf-lisp-rfc6833bis-18.txt=20 =20 =20 =20 =20 =20 =20 = = =
< draft-ietf-lisp-rfc6833bis-17.txt  =  draft-ietf-lisp-rfc6833bis-18.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: April = 6, 2019 = UPC/BarcelonaTech Expires: April = 14, 2019 = UPC/BarcelonaTech
= October 3, 2018 = October 11, 2018
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-17 = = draft-ietf-lisp-rfc6833bis-18
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = Control-Plane service interface and communicating with By using this Control-Plane service interface and = communicating with
=
skipping to = change at = page 1, line 47 =C2=B6 = skipping to change at page 1, line 47 =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 April 6, = 2019. This Internet-Draft will = expire on April 14, 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 27 =C2=B6 = skipping to change at page 2, line 27 =C2=B6
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
described in = the Simplified BSD License. = described in the Simplified BSD License.
=
Table of = Contents Table of Contents
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. = Requirements Notation . . . . . . . . . . . . . . . . . . . . = 4 2. Requirements Notation . . . . = . . . . . . . . . . . . . . . . 4
3. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
4. Basic = Overview . . . . . . . . . . . . . . . . . . . . . . . 6 = 4. Basic Overview . . . . . . . . . . . . = . . . . . . . . . . . 6
5. LISP IPv4 = and IPv6 Control-Plane Packet Formats . . . . . . . 8 = 5. LISP IPv4 and IPv6 Control-Plane Packet = Formats . . . . . . . 8
5.1. LISP = Control Packet Type Allocations . . . . . . . . . . 10 5.1. = LISP Control Packet Type Allocations . . . . . . . . . . 11
5.2. = Map-Request Message Format . . . . . . . . . . . . . . . 11 5.2. = Map-Request Message Format . . . . . . . . . . . . . . . 12
5.3. = EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 14 5.3. = EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 15
5.4. = Map-Reply Message Format . . . . . . . . . . . . . . . . 16 5.4. = Map-Reply Message Format . . . . . . . . . . . . . . . . 17
5.5. = EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 20 5.5. = EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 21
5.6. = Map-Register Message Format . . . . . . . . . . . . . . . 23 5.6. = Map-Register Message Format . . . . . . . . . . . . . . . 24
5.7. = Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 26 5.7. = Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 27
5.8. = Encapsulated Control Message Format . . . . . . . . . . . 28 5.8. = Encapsulated Control Message Format . . . . . . . . . . . 29
6. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 30 6. = Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 31
6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 30 6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 31
7. Routing = Locator Reachability . . . . . . . . . . . . . . . . 31 7. = Routing Locator Reachability . . . . . . . . . . . . . . . . 32
7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 33 7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 34
8. = Interactions with Other LISP Components . . . . . . . . . . . 34 8. = Interactions with Other LISP Components . . . . . . . . . . . 35
8.1. ITR = EID-to-RLOC Mapping Resolution . . . . . . . . . . . 34 8.1. = ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 35
8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 35 8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 36
8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 37 8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 38
8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 38 8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 39
8.4.1. = Anycast Operation . . . . . . . . . . . . . . . . . . 38 = 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 39
9. Security = Considerations . . . . . . . . . . . . . . . . . . . 39 9. = Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. Changes = since RFC 6833 . . . . . . . . . . . . . . . . . . . 40 10. = Privacy Considerations . . . . . . . . . . . . . = . . . . . . 41
11. IANA Considerations . . . . . . . . . . . = . . . . . . . . . . 40 11. Changes since RFC = 6833 . . . . . . . . . . . . . . . . . . . 41
11.1. LISP UDP Port Numbers . . . . . . . = . . . . . . . . . . 41 12. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 42
11.2. LISP Packet Type Codes . . . . . . . = . . . . . . . . . . 41 12.1. LISP UDP Port = Numbers . . . . . . . . . . . . . . . . . 42
11.3. LISP ACT and Flag Fields . . . . . . = . . . . . . . . . . 41 12.2. LISP Packet = Type Codes . . . . . . . . . . . . . . . . . 42
11.4. LISP Address Type Codes . . . . . . = . . . . . . . . . . 42 12.3. LISP ACT and = Flag Fields . . . . . . . . . . . . . . . . 43
11.5. LISP Algorithm ID Numbers . . . . . = . . . . . . . . . . 42 12.4. LISP Address = Type Codes . . . . . . . . . . . . . . . . 43
11.6. LISP Bit Flags . . . . . . . . . . . = . . . . . . . . . . 43 12.5. LISP = Algorithm ID Numbers . . . . . . . . . . . . . . . 44
12. References . . . . . . . . . . . . . . . = . . . . . . . . . . 46 12.6. LISP Bit = Flags . . . . . . . . . . . . . . . . . . . . . 44
12.1. Normative References . . . . . . . . = . . . . . . . . . . 46 13. References . . . = . . . . . . . . . . . . . . . . . . . . . . 47
12.2. Informative References . . . . . . . = . . . . . . . . . . 46 13.1. Normative = References . . . . . . . . . . . . . . . . . . 47
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 51 13.2. Informative References . . . . . . . = . . . . . . . . . . 48
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 51 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 53
B.1. = Changes to draft-ietf-lisp-rfc6833bis-17 = . . . . . . . . 51 Appendix B. Document Change Log . . . . . . . . . = . . . . . . . 53
B.2. = Changes to draft-ietf-lisp-rfc6833bis-16 = . . . . . . . . 51 B.1. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . = 53
B.3. = Changes to draft-ietf-lisp-rfc6833bis-15 = . . . . . . . . 51 B.2. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . = 53
B.4. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 52 B.3. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . = 54
B.5. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 52 B.4. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . = 54
B.6. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 52 B.5. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . = 54
B.7. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 52 B.6. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . = 54
B.8. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 52 B.7. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . = 54
B.9. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 52 B.8. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . = 54
B.10. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 53 B.9. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . = 55
B.11. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 53 B.10. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . = 55
B.12. = Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 53 B.11. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . = 55
B.13. = Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 54 B.12. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . = 55
B.14. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 54 B.13. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . = 56
B.15. = Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 54 B.14. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . = 56
B.16. = Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 54 B.15. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . = 56
B.17. = Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 55 B.16. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . = 57
B.18. = Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 55 B.17. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . = 57
B.19. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 55 B.18. = Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 57
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 B.19. = Changes to draft-ietf-lisp-rfc6833bis-00 . . . . = . . . . 57
= B.20. Changes = to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 57
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 58
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol = [I-D.ietf-lisp-rfc6830bis] (see
also = [I-D.ietf-lisp-introduction]) specifies an architecture and = also [I-D.ietf-lisp-introduction]) specifies = an architecture and
mechanism for = dynamic tunneling by logically separating the addresses = mechanism for dynamic tunneling by logically = separating the addresses
currently used = by IP in two separate name spaces: Endpoint IDs currently used by IP in two separate name spaces: = Endpoint IDs
(EIDs), used = within sites; and Routing Locators (RLOCs), used on the = (EIDs), used within sites; and Routing = Locators (RLOCs), used on the
transit = networks that make up the Internet infrastructure. To transit networks that make up the Internet = infrastructure. To
achieve this = separation, LISP defines protocol mechanisms for mapping = achieve this separation, LISP defines = protocol mechanisms for mapping
=
skipping to = change at = page 8, line 31 =C2=B6 = skipping to change at page 8, line 31 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port | Dest Port | / | Source Port | Dest = Port |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
| = LISP Message | | LISP Message = |
| = | | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
= IPv4 UDP LISP Control Message
= =
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| = Traffic Class | Flow Label | = |Version| Traffic Class | Flow = Label |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Payload Length | Next Header=3D17| Hop Limit | = | Payload Length | Next = Header=3D17| Hop Limit |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
+ = + + = +
| = | | = |
=
skipping to = change at = page 9, line 15 =C2=B6 = skipping to change at page 9, line 37 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port | Dest Port | / | Source Port | Dest = Port |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
| = LISP Message | | LISP Message = |
| = | | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
= IPv6 UDP LISP Control Message
= =
When a UDP = Map-Request, Map-Register, or Map-Notify (when used as a = When a UDP Map-Request, Map-Register, or = Map-Notify (when used as a
notification = message) are sent, the UDP source port is chosen by the = notification message) are sent, the UDP = source port is chosen by the
sender and the = destination UDP port number is set to 4342. When a sender and the destination UDP port number is set to = 4342. When a
UDP Map-Reply, = Map-Notify (when used as an acknowledgement to a Map- UDP Map-Reply, Map-Notify (when used as an = acknowledgement to a Map-
Register), or = Map-Notify-Ack are sent, the source UDP port number is Register), or Map-Notify-Ack are sent, the source UDP = port number is
set to 4342 = and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is = copied from the
source port of = either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking = data packet.
= Implementations MUST be prepared to accept packets when either = the Implementations MUST be = prepared to accept packets when either the
source port or = destination UDP port is set to 4342 due to NATs source port or destination UDP port is set to 4342 = due to NATs
changing port = number values. changing port number = values.
=
skipping to = change at = page 13, line 30 =C2=B6 = skipping to change at page 14, line = 30 =C2=B6
ITR-RLOC = Address: This is used to give the ETR the option of ITR-RLOC Address: This is used to give the ETR the = option of
selecting = the destination address from any address family for the = selecting the destination address from = any address family for the
Map-Reply = message. This address MUST be a routable RLOC address Map-Reply message. This address MUST be a = routable RLOC address
of the = sender of the Map-Request message. = of the sender of the Map-Request message.
=
EID mask-len: = This is the mask length for the EID-Prefix. EID mask-len: This is the mask length for the = EID-Prefix.
=
= EID-Prefix-AFI: This is the address family of the EID-Prefix = EID-Prefix-AFI: This is the address family = of the EID-Prefix
according = to [AFI] and [RFC8060]. = according to [AFI] and [RFC8060].
=
EID-Prefix: = This prefix is 4 octets for an IPv4 address family and EID-Prefix: This prefix address length is 4 octets for an IPv4
16 octets = for an IPv6 address family when the EID-Prefix-AFI is 1 = address family and 16 octets for an IPv6 = address family when the
or 2, = respectively. For other AFIs [AFI], the length varies and = EID-Prefix-AFI is 1 or 2, respectively. = For other AFIs [AFI], the
for the = LCAF AFI the format is defined in [RFC8060]. When a Map- = address length varies and for the LCAF AFI = the format is defined
Request is sent by an ITR because a data = packet is received for a in = [RFC8060]. When a Map-Request is sent by = an ITR because a data
= destination where there is no mapping entry, the EID-Prefix is = set packet is received for a = destination where there is no mapping
to the = destination IP address of the data packet, and the 'EID = entry, the EID-Prefix is set to the = destination IP address of the
mask-len' = is set to 32 or 128 for IPv4 or IPv6, respectively. data packet, and the 'EID mask-len' is set to 32 = or 128 for IPv4
When an = xTR wants to query a site about the status of a mapping it = or IPv6, respectively. When an xTR = wants to query a site about
already = has cached, the EID-Prefix used in the Map-Request has the = the status of a mapping it already has = cached, the EID-Prefix used
same = mask length as the EID-Prefix returned = from the site when it in the = Map-Request has the same mask-length as = the EID-Prefix
sent a = Map-Reply message. returned = from the site when it sent a Map-Reply message.
=
Map-Reply = Record: When the M-bit is set, this field is the size of a = Map-Reply Record: When the M-bit is set, = this field is the size of a
single = "Record" in the Map-Reply format. This Map-Reply record = single "Record" in the Map-Reply format. = This Map-Reply record
contains = the EID-to-RLOC mapping entry associated with the Source = contains the EID-to-RLOC mapping entry = associated with the Source
EID. This = allows the ETR that will receive this Map-Request to EID. This allows the ETR that will receive this = Map-Request to
cache the = data if it chooses to do so. = cache the data if it chooses to do so.
=
5.3. EID-to-RLOC = UDP Map-Request Message 5.3. = EID-to-RLOC UDP Map-Request Message
=
A Map-Request = is sent from an ITR when it needs a mapping for an EID, = A Map-Request is sent from an ITR when it = needs a mapping for an EID,
=
skipping to = change at = page 20, line 17 =C2=B6 = skipping to change at page 21, line = 17 =C2=B6
= encapsulated packet can be an anycast address as well. The = source encapsulated packet can = be an anycast address as well. The source
or = destination RLOC MUST NOT be the broadcast address or destination RLOC MUST NOT be the broadcast = address
= (255.255.255.255 or any subnet broadcast address known to the = (255.255.255.255 or any subnet broadcast = address known to the
router) and = MUST NOT be a link-local multicast address. The router) and MUST NOT be a link-local multicast = address. The
source RLOC = MUST NOT be a multicast address. The destination RLOC source RLOC MUST NOT be a multicast address. The = destination RLOC
SHOULD be a = multicast address if it is being mapped from a SHOULD be a multicast address if it is being = mapped from a
multicast = destination EID. multicast = destination EID.
=
5.5. EID-to-RLOC = UDP Map-Reply Message 5.5. = EID-to-RLOC UDP Map-Reply Message
=
A Map-Reply = returns an EID-Prefix with a prefix length = that is less A Map-Reply returns = an EID-Prefix with a mask-length that is = less
than or equal = to the EID being requested. The EID being requested is = than or equal to the EID being requested. = The EID being requested is
either from = the destination field of an IP header of a Data-Probe or = either from the destination field of an IP = header of a Data-Probe or
the EID record = of a Map-Request. The RLOCs in the Map-Reply are the EID record of a Map-Request. The RLOCs in the = Map-Reply are
routable IP = addresses of all ETRs for the LISP site. Each RLOC routable IP addresses of all ETRs for the LISP site. = Each RLOC
conveys status = reachability but does not convey path reachability conveys status reachability but does not convey path = reachability
from a = requester's perspective. Separate testing of path from a requester's perspective. Separate testing of = path
reachability = is required. See RLOC-reachability Section 7.1 for reachability is required. See RLOC-reachability = Section 7.1 for
= details. details.
=
Note that a = Map-Reply MAY contain different EID-Prefix granularity Note that a Map-Reply MAY contain different = EID-Prefix granularity
(prefix + = length) than the Map-Request that triggers = it. This might (prefix + mask-length) than the Map-Request that triggers = it. This
occur if a = Map-Request were for a prefix that had been returned by an = might occur if a Map-Request were for a = prefix that had been returned
earlier = Map-Reply. In such a case, the requester updates its cache = by an earlier Map-Reply. In such a case, = the requester updates its
with the new = prefix information and granularity. For example, a cache with the new prefix information and = granularity. For example,
requester = with two cached EID-Prefixes that are covered by a Map- = a requester with two cached EID-Prefixes = that are covered by a Map-
Reply = containing one less-specific prefix replaces the entry with the = Reply containing one less-specific prefix = replaces the entry with the
less-specific = EID-Prefix. Note that the reverse, replacement of one less-specific EID-Prefix. Note that the reverse, = replacement of one
less-specific = prefix with multiple more-specific prefixes, can also less-specific prefix with multiple more-specific = prefixes, can also
occur, not by = removing the less-specific prefix but rather by adding occur, not by removing the less-specific prefix but = rather by adding
the = more-specific prefixes that, during a lookup, will override the = the more-specific prefixes that, during a = lookup, will override the
less-specific = prefix. less-specific = prefix.
=
When an EID = moves out of a LISP site [I-D.ietf-lisp-eid-mobility], When an EID moves out of a LISP site = [I-D.ietf-lisp-eid-mobility],
the database = mapping system may have overlapping EID-prefixes. Or the database mapping system may have overlapping = EID-prefixes. Or
when a LISP = site is configured with multiple sets of ETRs that when a LISP site is configured with multiple sets of = ETRs that
support = different EID-prefix lengths, the database = mapping system may support = different EID-prefix mask-lengths, the = database mapping
have = overlapping EID-prefixes. When overlapping EID-prefixes exist, system may have overlapping EID-prefixes. When = overlapping EID-
a = Map-Request with an EID that best matches any EID-Prefix MUST be prefixes exist, a = Map-Request with an EID that best matches any EID-
returned in = a single Map-Reply message. For instance, if an ETR had = Prefix MUST = be returned in a single Map-Reply message. For instance,
database = mapping entries for EID-Prefixes: = if an ETR had database mapping entries for EID-Prefixes:
=
= 2001:db8::/16 = 2001:db8::/16
= 2001:db8:1::/24 = 2001:db8:1::/24
= 2001:db8:1:1::/32 = 2001:db8:1:1::/32
= 2001:db8:1:2::/32 = 2001:db8:1:2::/32
=
A Map-Request = for EID 2001:db8:1:1::1 would cause a Map-Reply with a A Map-Request for EID 2001:db8:1:1::1 would cause a = Map-Reply with a
record count = of 1 to be returned with a mapping record EID-Prefix of = record count of 1 to be returned with a = mapping record EID-Prefix of
= 2001:db8:1:1::/32. = 2001:db8:1:1::/32.
=
=
skipping to = change at = page 24, line 39 =C2=B6 = skipping to change at page 25, line = 39 =C2=B6
requesting = a Map-Notify message to be returned in response to requesting a Map-Notify message to be returned in = response to
sending a = Map-Register message. The Map-Notify message sent by a = sending a Map-Register message. The = Map-Notify message sent by a
Map-Server = is used to acknowledge receipt of a Map-Register Map-Server is used to acknowledge receipt of a = Map-Register
= message. message.
=
Record Count: = This is the number of records in this Map-Register Record Count: This is the number of records in this = Map-Register
message. A = record is comprised of that portion of the packet message. A record is comprised of that portion of = the packet
labeled = 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of = times equal to
Record = Count. Record Count.
=
Nonce: This = 8-octet 'Nonce' field is set to 0 in = Map-Register Nonce: This = 8-octet 'Nonce' field is incremented each time a = Map-
messages if no Map-Notify message is expected to acknowledge it. Register message is = sent. When a Map-Register acknowledgement = is
Since the = Map-Register message is authenticated, the 'Nonce' field = requested, the = nonce is returned by Map-Servers in Map-Notify
is not currently used for any security function but may = be in the messages. Since the entire Map-Register message is = authenticated,
future as part of an anti-replay = solution. the 'Nonce' = field serves to protect against Map-Register = replay
= = attacks.
=
Key ID: This = is a configured key-id value that corresponds to a Key ID: This is a configured key-id value that = corresponds to a
= shared-secret password that is used to authenticate the sender. = shared-secret password that is used to = authenticate the sender.
Multiple = shared-secrets can be used to roll over keys in a non- Multiple shared-secrets can be used to roll over = keys in a non-
disruptive = way. disruptive way.
=
Algorithm ID: = This is the configured Message Authentication Code Algorithm ID: This is the configured Message = Authentication Code
(MAC) = algorithm value used for the authentication function. See = (MAC) algorithm value used for the = authentication function. See
Algorithm = ID Numbers in the Section 11.5 for = codepoint Algorithm ID Numbers = in the Section 12.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 output of the MAC algorithm. The Authentication Data: This is the output of the MAC = algorithm. The
entire = Map-Register payload (from and including the LISP message = entire Map-Register payload (from and = including the LISP message
=
skipping to = change at = page 40, line 5 =C2=B6 = skipping to change at page 41, line 5 =C2=B6
= transport-level integrity and anti-reply protection mechanism such = as transport-level integrity and = anti-reply protection mechanism such as
IPSEC = [RFC6071]. In addition, a compromised ETR can overclaim the = IPSEC [RFC6071]. In addition, a compromised = ETR can overclaim the
prefix it owns = and successfully register it on its corresponding Map- prefix it owns and successfully register it on its = corresponding Map-
Server. To = mitigate this and as noted in Section 8.2, a Map-Server = Server. To mitigate this and as noted in = Section 8.2, a Map-Server
SHOULD verify = that all EID-Prefixes registered by an ETR match the SHOULD verify that all EID-Prefixes registered by an = ETR match the
configuration = stored on the Map-Server. = configuration stored on the Map-Server.
=
A complete = LISP threat analysis has been published in [RFC7835]. A complete LISP threat analysis has been published in = [RFC7835].
Please refer = to it for more detailed security related details. Please refer to it for more detailed security related = details.
=
10. Changes = since RFC 6833 10. Privacy Considerations
=
= As noted by = [RFC6973] privacy is a complex issue that greatly depends
= on the specific = protocol use-case and deployment. As noted in
= section 1.1 of = [I-D.ietf-lisp-rfc6830bis] LISP focuses on use-cases
= where entities = communicate over the public Internet while keeping
= separate addressing = and topology. In what follows we detail the
= privacy threats = introduced by the LISP Control Plane, the analysis is
= based on the = guidelines detailed in [RFC6973].
=
= LISP can use = long-lived identifiers (EIDs) that survive mobility
= events. Such = identifiers bind to the RLOCs of the nodes, which
= represents the = topological location with respect to the specific LISP
= deployments. In = addition, EID-to-RLOC mappings are typically
= considered public = information within the LISP deployment when
= control-plane = messages are not encrypted, and can be eavesdropped
= while Map-Request = messages are sent to the corresponding Map-
= Resolvers or = Map-Register messages to Map-Servers.
=
= In this context, = attackers can correlate the EID with the RLOC and
= track the = corresponding user topological location and/or mobility.
= This can be achieved = by off-path attackers, if they are
= authenticated, by = querying the mapping system. Deployments concerned
= about this threat = can use access control-lists or stronger
= authentication = mechanisms [I-D.ietf-lisp-ecdsa-auth] in the mapping
= system to make sure = that only authorized users can access this
= information (data = minimization). Use of ephemeral EIDs
= = [I-D.ietf-lisp-eid-anonymity] to achieve anonymity is = another
= mechanism to lessen = persistency and identity tracking.
=
= 11. Changes = since RFC 6833
=
For = implementation considerations, the following changes have been = For implementation considerations, the = following changes have been
made to this = document since RFC 6833 was published: = made to this document since RFC 6833 was published:
=
o A = Map-Notify-Ack message is added in this document to provide = o A Map-Notify-Ack message is added in this = document to provide
reliability = for Map-Notify messages. Any receiver of a Map-Notify reliability for Map-Notify messages. Any receiver = of a Map-Notify
message = must respond with a Map-Notify-Ack message. Map-Servers = message must respond with a = Map-Notify-Ack message. Map-Servers
who are = senders of Map-Notify messages, must queue the Map-Notify = who are senders of Map-Notify messages, = must queue the Map-Notify
contents = until they receive a Map-Notify-Ack with the nonce used = contents until they receive a = Map-Notify-Ack with the nonce used
in the = Map-Notify message. Note that implementations for Map- = in the Map-Notify message. Note that = implementations for Map-
=
skipping = to change at page 40, line = 38 =C2=B6 = skipping to change at page 42, line = 20 =C2=B6
=
o The 16-bit = Key-ID field of the Map-Register message has been split = 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. 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 = 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- that appear in Map-Reply, Map-Register, = Map-Notify, and Map-
Notify-Ack = messages. The Drop/Policy-Denied and Drop/Auth-Failure = Notify-Ack messages. The = Drop/Policy-Denied and Drop/Auth-Failure
are the = descriptions for the two new action values. See are the descriptions for the two new action = values. See
Section 5.4 = for details. Section 5.4 for = details.
=
11. IANA Considerations 12. IANA = Considerations
=
This section = provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet = Assigned Numbers
Authority = (IANA) regarding registration of values related to this = Authority (IANA) regarding registration of = values related to this
LISP = Control-Plane specification, in accordance with BCP 26 LISP Control-Plane specification, in accordance with = BCP 26
= [RFC8126]. [RFC8126].
=
There are = three namespaces (listed in the sub-sections below) in LISP = There are three namespaces (listed in the = sub-sections below) in LISP
that have been = registered. that have been = registered.
=
o LISP IANA = registry allocations should not be made for purposes o LISP IANA registry allocations should not be made = for purposes
unrelated = to LISP routing or transport protocols. = unrelated to LISP routing or transport protocols.
=
o The = following policies are used here with the meanings defined in = o The following policies are used here with = the meanings defined in
BCP 26: = "Specification Required", "IETF Review", "Experimental BCP 26: "Specification Required", "IETF Review", = "Experimental
Use", and = "First Come First Served". Use", = and "First Come First Served".
=
11.1. LISP UDP Port Numbers 12.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
=
11.2. LISP Packet Type Codes 12.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 it is requested to replace the [RFC6830] = Type definitions and it is requested to = replace the [RFC6830]
registry = message references with the RFC number assigned to this = registry message references with the RFC = number assigned to this
= document. document.
=
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 by this document. This document = message, message type 5, was added by 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
=
11.3. LISP ACT and Flag Fields 12.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], IANA is Four values have already been allocated by [RFC6830], = IANA is
requested to = replace the [RFC6830] reference for this registry with requested to replace the [RFC6830] reference for this = registry with
the RFC number = assigned to this document and the [RFC6830]. Action the RFC number assigned to this document and the = [RFC6830]. Action
values = references with the RFC number assigned to this document. = values references with the RFC number = assigned to this document.
This = specification changes the name of ACT type 3 value from "Drop" = This 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/ to "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).
=
=
skipping = to change at page 42, line = 23 =C2=B6 = skipping to change at page 43, line = 42 =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.
=
11.4. LISP Address Type Codes 12.4. LISP Address Type = Codes
=
LISP Canonical = Address Format (LCAF) [RFC8060] is an 8-bit field that LISP Canonical Address Format (LCAF) [RFC8060] is an = 8-bit field that
defines = LISP-specific encodings for AFI value 16387. LCAF encodings = defines LISP-specific encodings for AFI = value 16387. LCAF encodings
are used for = specific use-cases where different address types for are used for specific use-cases where different = address types for
EID-records = and RLOC-records are required. = EID-records and RLOC-records are required.
=
The IANA = registry "LISP Canonical Address Format (LCAF) Types" is = The IANA registry "LISP Canonical Address = Format (LCAF) Types" is
used for LCAF = types. The registry for LCAF types use the used for LCAF types. The registry for LCAF types use = the
Specification = Required policy [RFC8126]. Initial values for the Specification Required policy [RFC8126]. Initial = values for the
registry as = well as further information can be found in [RFC8060]. registry as well as further information can be found = in [RFC8060].
=
Therefore, = there is no longer a need for the "LISP Address Type Therefore, there is no longer a need for the "LISP = Address Type
Codes" = registry requested by [RFC6830]. This document requests to = Codes" registry requested by [RFC6830]. = This document requests to
remove = it. remove it.
=
11.5. LISP Algorithm ID Numbers = 12.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.6. LISP Bit Flags 12.6. LISP Bit = Flags
=
This document = asks IANA to create a registry for allocation of bits This document asks IANA to create a registry for = allocation of bits
in several = headers of the LISP control plane, namely in the Map- in several headers of the LISP control plane, namely = in the Map-
Request, = Map-Reply, Map-Register, Encapsulated Control Message (ECM) = Request, Map-Reply, Map-Register, = Encapsulated Control Message (ECM)
messages. Bit = allocations are also requested for EID-records and messages. Bit allocations are also requested for = EID-records and
RLOC-records. = The registry created should be named "LISP Control RLOC-records. The registry created should be named = "LISP Control
Plane Header = Bits". A sub-registry needs to be created per each Plane Header Bits". A sub-registry needs to be = created per each
message and = record. The name of each sub-registry is indicated message and record. The name of each sub-registry is = indicated
below, along = with its format and allocation of bits defined in this below, along with its format and allocation of bits = defined in this
document. Any = additional bits allocation, requires a specification, document. Any additional bits allocation, requires a = specification,
=
skipping = to change at page 46, line = 5 =C2=B6 = skipping to change at page 47, line = 21 =C2=B6
= +-----------+---------------+--------------+----------------------+ = +-----------+---------------+--------------+----------------------+
| Spec Name | = IANA Name | Bit Position | Description | | Spec Name | IANA Name | Bit Position | = Description |
= +-----------+---------------+--------------+----------------------+ = +-----------+---------------+--------------+----------------------+
| L | = rloc-record-L | 13 | Local RLOC Bit | | L | rloc-record-L | 13 | Local = RLOC Bit |
| p | = rloc-record-p | 19 | RLOC-Probe Reply Bit | | p | rloc-record-p | 19 | = RLOC-Probe Reply Bit |
| R | = rloc-record-R | 19 | RLOC Reachable Bit | | R | rloc-record-R | 19 | RLOC = Reachable Bit |
= +-----------+---------------+--------------+----------------------+ = +-----------+---------------+--------------+----------------------+
=
= LISP RLOC-Record Header Bits = LISP RLOC-Record Header Bits
=
12. References 13. References
=
12.1. Normative References 13.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-22 = (work in progress), = (LISP)", draft-ietf-lisp-rfc6830bis-23 = (work in progress),
= October 2018. October = 2018.
=
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
skipping = to change at page 46, line = 48 =C2=B6 = skipping to change at page 48, line = 19 =C2=B6
=
[RFC6071] = Frankel, S. and S. Krishnan, "IP Security (IPsec) and [RFC6071] Frankel, S. and S. Krishnan, "IP Security = (IPsec) and
= Internet Key Exchange (IKE) Document Roadmap", RFC 6071, = Internet Key Exchange (IKE) = Document Roadmap", RFC 6071,
DOI = 10.17487/RFC6071, February 2011, = DOI 10.17487/RFC6071, February 2011,
= <https://www.rfc-editor.org/info/rfc6071>. = <https://www.rfc-editor.org/info/rfc6071>.
=
[RFC8085] = Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. = Shepherd, "UDP Usage
= Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI = 10.17487/RFC8085,
= March 2017, <https://www.rfc-editor.org/info/rfc8085>. = March 2017, = <https://www.rfc-editor.org/info/rfc8085>.
=
12.2. Informative References 13.2. Informative = References
=
[AFI] = IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY = [AFI] IANA, "Address Family Identifier = (AFIs)", ADDRESS FAMILY
= NUMBERS http://www.iana.org/assignments/address-family- = NUMBERS = http://www.iana.org/assignments/address-family-
= numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, = Febuary 2007.
=
= [GTP-3GPP] [GTP-3GPP]
= 3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) = Tunnelling
= Protocol User Plane (GTPv1-U)", TS.29.281 Protocol User Plane (GTPv1-U)", = TS.29.281
= https://portal.3gpp.org/desktopmodules/Specifications/ = https://portal.3gpp.org/desktopmodules/Specifications/
= SpecificationDetails.aspx?specificationId=3D1699, January = = SpecificationDetails.aspx?specificationId=3D1699, January
= 2015. 2015.
=
= [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-ecdsa-auth]
= = Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
= = Authentication and Authorization", draft-ietf-lisp-ecdsa-
= auth-00 = (work in progress), September 2018.
=
= = [I-D.ietf-lisp-eid-anonymity]
= = Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP
= EID = Anonymity", draft-ietf-lisp-eid-anonymity-02 (work in
= = progress), April 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] = [I-D.ietf-lisp-gpe]
= Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. Maino, F., Lemon, J., Agarwal, P., Lewis, = D., and M.
= Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- = Smith, "LISP Generic Protocol = Extension", draft-ietf-lisp-
= gpe-06 (work in progress), September 2018. gpe-06 (work in progress), September = 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-03 (work = in progress), Mobile = Node", draft-ietf-lisp-mn-04 (work in = progress),
= October 2018. October = 2018.
=
= [I-D.ietf-lisp-pubsub] = [I-D.ietf-lisp-pubsub]
= Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., = Rodriguez-Natal, A., Ermagan, V., = Leong, J., Maino, F.,
= Cabellos-Aparicio, A., Barkai, S., Farinacci, D., Cabellos-Aparicio, A., Barkai, S., = Farinacci, D.,
= Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ Boucadair, M., Jacquenet, C., and S. = Secci, "Publish/
= Subscribe Functionality for LISP", draft-ietf-lisp- Subscribe Functionality for LISP", = draft-ietf-lisp-
= pubsub-00 (work in progress), April = 2018. pubsub-01 (work in progress), October 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] = [I-D.ietf-nvo3-vxlan-gpe]
= Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol = Maino, F., Kreeger, L., and U. = Elzur, "Generic Protocol
= Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work = Extension for VXLAN", = draft-ietf-nvo3-vxlan-gpe-06 (work
in = progress), April 2018. = in progress), April 2018.
=
skipping = to change at page 49, line = 26 =C2=B6 = skipping to change at page 51, line = 5 =C2=B6
[RFC6836] = Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and = D. Lewis,
= "Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol = Alternative Logical
= Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, Topology (LISP+ALT)", RFC 6836, DOI = 10.17487/RFC6836,
= January 2013, <https://www.rfc-editor.org/info/rfc6836>. = January 2013, = <https://www.rfc-editor.org/info/rfc6836>.
=
[RFC6837] = Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint = ID (EID) to
= Routing Locator (RLOC) Database", RFC 6837, Routing Locator (RLOC) Database", RFC = 6837,
DOI = 10.17487/RFC6837, January 2013, = DOI 10.17487/RFC6837, January 2013,
= <https://www.rfc-editor.org/info/rfc6837>. = <https://www.rfc-editor.org/info/rfc6837>.
=
= [RFC6973] Cooper, = A., Tschofenig, H., Aboba, B., Peterson, J.,
= Morris, = J., Hansen, M., and R. Smith, "Privacy
= = Considerations for Internet Protocols", RFC 6973,
= DOI = 10.17487/RFC6973, July 2013,
= = <https://www.rfc-editor.org/info/rfc6973>.
= =
[RFC7348] = Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, = [RFC7348] Mahalingam, M., Dutt, D., Duda, = K., Agarwal, P., Kreeger,
L., = Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. = Wright, "Virtual
= eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A = Framework for
= Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks = over Layer 3
= Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, = Networks", RFC 7348, DOI = 10.17487/RFC7348, August 2014,
= <https://www.rfc-editor.org/info/rfc7348>. = <https://www.rfc-editor.org/info/rfc7348>.
=
[RFC7835] = Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID = [RFC7835] Saucez, D., Iannone, L., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Threat Analysis", RFC 7835, Separation Protocol (LISP) Threat = Analysis", RFC 7835,
DOI = 10.17487/RFC7835, April 2016, = DOI 10.17487/RFC7835, April 2016,
=
skipping = to change at page 51, line = 7 =C2=B6 = skipping to change at page 53, line = 7 =C2=B6
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., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., = Ginsberg, L.,
= Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. = Shakir, "Segment
= Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI = 10.17487/RFC8402,
= July 2018, <https://www.rfc-editor.org/info/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 original authors = would like to thank Greg Schudel, Darrel Lewis,
Zwiebel, = Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, = John Zwiebel, Andrew Partan, Dave Meyer, = Isidor Kouvelas, Jesper
Fabio Maino, = and members of the lisp@ietf.org mailing list for their = Skriver, Fabio Maino, and members of the = lisp@ietf.org mailing list
feedback and = helpful suggestions. for their = 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.
=
= The current authors = would like to give a sincere thank you to the
= people who help put = LISP on standards track in the IETF. They
= include Joel = Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino,
= Scott Bradner, Kyle = Rose, Takeshi Takahashi, Sarah Banks, Pete
= Resnick, Colin = Perkins, Mirja Kuhlewind, Francis Dupont, Benjamin
= Kaduk, Eric = Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper,
= Suresh Krishnan, = Alberto Rodriguez-Natal, Vina Ermagen, Mohamed
= Boucadair, Brian = Trammell, Sabrina Tanamal, and John Drake. The
= contributions they = offered greatly added to the security, scale, and
= robustness of the = LISP architecture and protocols.
= =
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-17 B.1. = Changes to draft-ietf-lisp-rfc6833bis-18
=
= o Posted mid = October 2018.
=
= o Fixed comments = from Eric after more email clarity.
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-17
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Changes to = reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th = Telechat.
=
o Added all = flag bit definitions as request for allocation in IANA o Added all flag bit definitions as request for = allocation in IANA
= Considersations section. = Considersations section.
=
o Added an = applicability statement in section 1 to address security = o Added an applicability statement in = section 1 to address security
concerns = from Telechat. concerns from = Telechat.
=
o Moved m-bit = description and IANA request to draft-ietf-lisp-mn. o Moved m-bit description and IANA request to = draft-ietf-lisp-mn.
=
o Moved I-bit = description and IANA request to draft-ietf-lisp- o Moved I-bit description and IANA request to = draft-ietf-lisp-
= pubsub. pubsub.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-16 B.3. Changes to = draft-ietf-lisp-rfc6833bis-16
=
o Posted = Late-September 2018. o Posted = Late-September 2018.
=
o Re-wrote = Security Considerations section. Thanks Albert. o Re-wrote Security Considerations section. Thanks = Albert.
=
o Added = Alvaro text to be more clear about IANA actions. o Added Alvaro text to be more clear about IANA = actions.
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-15 B.4. Changes to = draft-ietf-lisp-rfc6833bis-15
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Colin and Mirja. = o Changes to reflect comments from Colin and Mirja.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-14 B.5. Changes to = draft-ietf-lisp-rfc6833bis-14
=
o Posted = September 2018. o Posted September = 2018.
=
o Changes to = reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, = and Secdir
= reviews. reviews.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-13 B.6. Changes to = draft-ietf-lisp-rfc6833bis-13
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-12 B.7. 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.7. Changes to = draft-ietf-lisp-rfc6833bis-11 B.8. 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.8. Changes to = draft-ietf-lisp-rfc6833bis-10 B.9. 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.9. Changes to = draft-ietf-lisp-rfc6833bis-09 B.10. 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.10. Changes to = draft-ietf-lisp-rfc6833bis-08 B.11. 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.11. Changes to = draft-ietf-lisp-rfc6833bis-07 B.12. 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 53, line = 45 =C2=B6 = skipping to change at page 56, line = 13 =C2=B6
Can use = othe AFIs then IPv4 and IPv6. = Can use othe AFIs then IPv4 and IPv6.
=
o Many = editorial changes to clarify text. = o Many editorial changes to clarify text.
=
o Changed = some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to = capitalized.
=
o Added = definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply = messages.
=
o Ran = document through IDNITs. o Ran = document through IDNITs.
=
B.12. Changes to = draft-ietf-lisp-rfc6833bis-06 B.13. 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.13. Changes to = draft-ietf-lisp-rfc6833bis-05 B.14. 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.14. Changes to = draft-ietf-lisp-rfc6833bis-04 B.15. 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.15. Changes to = draft-ietf-lisp-rfc6833bis-03 B.16. 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.16. Changes to = draft-ietf-lisp-rfc6833bis-02 B.17. 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.17. Changes to = draft-ietf-lisp-rfc6833bis-01 B.18. 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.18. Changes to = draft-ietf-lisp-rfc6833bis-00 B.19. 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.19. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.20. 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. 49 change blocks. 
122 lines changed or = deleted 192 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=_957D466F-84D9-4622-8CF2-82BB56557038 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_957D466F-84D9-4622-8CF2-82BB56557038-- From nobody Fri Oct 12 14:52: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 6C688130EAC; Fri, 12 Oct 2018 14:51:55 -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.86.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153938111537.29189.11434238347347600998@ietfa.amsl.com> Date: Fri, 12 Oct 2018 14:51:55 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-24.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 21:52:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : The Locator/ID Separation Protocol (LISP) Authors : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Albert Cabellos Filename : draft-ietf-lisp-rfc6830bis-24.txt Pages : 45 Date : 2018-10-12 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-24 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-24 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 Oct 12 14:53: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 0715B130E5F; Fri, 12 Oct 2018 14:52:59 -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.86.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153938117896.29245.10936039208077257409@ietfa.amsl.com> Date: Fri, 12 Oct 2018 14:52:59 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-18.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 21:53:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : Locator/ID Separation Protocol (LISP) Control-Plane Authors : Vince Fuller Dino Farinacci Albert Cabellos Filename : draft-ietf-lisp-rfc6833bis-18.txt Pages : 58 Date : 2018-10-12 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, connecting EID addressable nodes of a LISP site, their implementation and operational complexity reduces the overall cost and effort of deploying LISP. This document obsoletes RFC 6830 and 6833. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-18 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 12 19:47: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 C7CA6130DC3 for ; Fri, 12 Oct 2018 19:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbXoYgndzkne for ; Fri, 12 Oct 2018 19:47:42 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 9A302128CF3 for ; Fri, 12 Oct 2018 19:47:41 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id j4-v6so12895390ljc.12 for ; Fri, 12 Oct 2018 19:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d2JG7mDtfRFA7o9sPoIhts1tZfun+5eIc7j97d24H7A=; b=Ezm/PW/g5GgpXB2yI4LbNzXAvhVZILQpSEGHFUZe9TQyykMVAf8OEe1MoZlPYJbX8B G8wb/2t1LGKIWI0FJAcynkWMcBzstDnWScJdghDwbwKPBbNgQu6hFS+7AUML+BacRIgE ul1nYcQSsosyLVqDOQqgCtZ5EZ9Ctts6Xy2nCTl18VU+hye5dQgYmajDhdBWSyH5HNvM sjkGtyuCJ8I+DWydbCGztpiB5k+hQp4FiKE9+MNX07D0E+lP2NZvaNj9kEYhzRY2k0BS ty98D5/KzzwRZ2QuPupEucBYIznZ0mNwCRTdGHUlglHXSFtCMAQkBW00bqBiUXYsyAXY TF5Q== 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=d2JG7mDtfRFA7o9sPoIhts1tZfun+5eIc7j97d24H7A=; b=hzH7PtHLF10hSfhv7wI+HjMQhCHpcqW7uBwZSWy5gviV/yxAlZr5/ZDFTWoJ+T1xnL rj0hvaxYX0MlQOg0M8ULJldENhy60tkAy5itCSHLHHFVh6NeTlbSQPy9yOh2dHHyRJx9 wCnAHz0nI0CkSqtAi2kPzX478LXfghg8ABv6A8VPvnQeeJfrYkTjNj3tTbHDFWM+SiTl RyyNKxhJK+A+Mlmbvv4KjB05NB+4HTrTIcW+XwrBqKlOCmE1kdpWOuOQSvuf6PVlHsq+ vppUjjn1Vg2ihlH8TMFzjcNP8KTq/34/5VT63emY45SlJ0FizGEhk7f1tV2zHF2c+u3H qWWw== X-Gm-Message-State: ABuFfoh2n8lNph1nznpTR3zOQqo93EHlYEmvvZO4c5CV9oxKIX5X834w 4MzY4U8K9ymImPd9wB5pGOOr7m6KCZpZxMC8WQxiXg== X-Google-Smtp-Source: ACcGV60uA8u8g+TryNCBcOocqcsnLl8KS+xLgRmrCKcMbHGYUfQcMfDk/bjGCTanyANW86SEToFbSfubbdfamdXMId8= X-Received: by 2002:a2e:94c4:: with SMTP id r4-v6mr5538378ljh.68.1539398859392; Fri, 12 Oct 2018 19:47:39 -0700 (PDT) MIME-Version: 1.0 References: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Fri, 12 Oct 2018 19:47:02 -0700 Message-ID: To: Dino Farinacci Cc: Benjamin Kaduk , IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, albert.cabellos@gmail.com, "BRUNGARD, DEBORAH A" , fmaino@cisco.com, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="0000000000002e9bb60578133a88" Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 02:47:50 -0000 --0000000000002e9bb60578133a88 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > There are diff files attach for revisions 68830bis-24 and 6833bis-18. They have not been posted yet. > > > S 4.1. > >> RLOC (outer-header source IP address) in a received LISP packet= . > >> Such a cache entry is termed a "glean mapping" and only contain= s > >> a single RLOC for the EID in question. More complete information > >> about additional RLOCs SHOULD be verified by sending a LISP Map= - > >> Request for that EID. Both the ITR and the ETR MAY also > >> influence the decision the other makes in selecting an RLOC. > > > > This seems like it introduces an immediate overclaiming problem. > > It does not, if the gleaner wants to add this to the cache, it is > /32 EID with the source RLOC. So it is not overclaimed. If the > gleaner wants to verify the mapping, it does a lookup to the mapping > system on the source EID and then can get a coarser EID-prefix with > an authorized list of RLOCs. OK, thanks. > > S 10. > >> When an ETR decapsulates a packet, it will check for any change in > >> the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the > >> ETR, if acting also as an ITR, will refrain from encapsulating > >> packets to an RLOC that is indicated as down. It will only resume > >> using that RLOC if the corresponding Locator-Status-Bit returns to = a > >> value of 1. Locator-Status-Bits are associated with a Locator-Set > > > > This seems to enable a pretty obvious denial of service attack in > > which you send a message with all LSBs set to 0. > > The LSBs are a hint and usually used for =E2=80=9Cidling down RLOCs=E2=80= =9D. I will > add text that ETR will rate-limit how often it reacts to LSB > changes. And note that its RLOC-probing cache will tell the rule > truth about if the RLOC is reachable. Sounds good. > > S 10. > >> list returned by the last Map-Reply will be set to zero for that > >> particular EID-Prefix. Refer to Section 16 for security related > >> issues regarding Locator-Status-Bits. > >> > >> When an ETR decapsulates a packet, it knows that it is reachable from > >> the encapsulating ITR because that is how the packet arrived. In > > > > It doesn't even know this. It just knows that that's been claimed by > > someone who can generate traffic to it. > > Well this is true, but 6833bis discusses RLOC-reachability and there > is a RLOC-probe cache that will tell the ITR when it last heard from > the RLOC. Just to be clear, it's not "last heard from" that you need, but rather "last verifiably responded". > > S 16. > >> Map-Versioning is a Data-Plane mechanism used to signal a peering xTR > >> that a local EID-to-RLOC mapping has been updated, so that the > >> peering xTR uses LISP Control-Plane signaling message to retrieve a > >> fresh mapping. This can be used by an attacker to forge the map- > >> versioning field of a LISP encapsulated header and force an excessive > >> amount of signaling between xTRs that may overload them. > > > > Can't I also set a super-high version number, thus gagging updates? > > It doesn=E2=80=99t matter the value. All that matters is that it changed = and you should do to the mapping system to get an updated RLOC-set. Hmm... S 5.1 of 6834-bis suggests that you can just discard it. On Thu, Oct 11, 2018 at 3:39 PM Dino Farinacci wrote: > Eric/Ben, I am following up with responses and changes to address the > security comments in 6830bis. I have both of your comments enclosed and > indented in this email. Eric=E2=80=99s comments come first then Ben=E2=80= =99s second. > > There are diff files attach for revisions 68830bis-24 and 6833bis-18. The= y > have not been posted yet. > > > S 4.1. > >> RLOC (outer-header source IP address) in a received LISP packet= . > >> Such a cache entry is termed a "glean mapping" and only contain= s > >> a single RLOC for the EID in question. More complete informati= on > >> about additional RLOCs SHOULD be verified by sending a LISP Map= - > >> Request for that EID. Both the ITR and the ETR MAY also > >> influence the decision the other makes in selecting an RLOC. > > > > This seems like it introduces an immediate overclaiming problem. > > It does not, if the gleaner wants to add this to the cache, it is /32 EID > with the source RLOC. So it is not overclaimed. If the gleaner wants to > verify the mapping, it does a lookup to the mapping system on the source > EID and then can get a coarser EID-prefix with an authorized list of RLOC= s. > > > S 10. > >> When an ETR decapsulates a packet, it will check for any change in > >> the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the > >> ETR, if acting also as an ITR, will refrain from encapsulating > >> packets to an RLOC that is indicated as down. It will only resume > >> using that RLOC if the corresponding Locator-Status-Bit returns to = a > >> value of 1. Locator-Status-Bits are associated with a Locator-Set > > > > This seems to enable a pretty obvious denial of service attack in > > which you send a message with all LSBs set to 0. > > The LSBs are a hint and usually used for =E2=80=9Cidling down RLOCs=E2=80= =9D. I will add > text that ETR will rate-limit how often it reacts to LSB changes. And not= e > that its RLOC-probing cache will tell the rule truth about if the RLOC is > reachable. > > > > > > > S 10. > >> list returned by the last Map-Reply will be set to zero for that > >> particular EID-Prefix. Refer to Section 16 for security related > >> issues regarding Locator-Status-Bits. > >> > >> When an ETR decapsulates a packet, it knows that it is reachable fr= om > >> the encapsulating ITR because that is how the packet arrived. In > > > > It doesn't even know this. It just knows that that's been claimed by > > someone who can generate traffic to it. > > Well this is true, but 6833bis discusses RLOC-reachability and there is a > RLOC-probe cache that will tell the ITR when it last heard from the RLOC. > > > > > > > S 10.1. > >> NOT use the lack of return traffic as an indication that the ETR is > >> unreachable. Instead, it MUST use an alternate mechanism to > >> determine reachability. > >> > >> 10.1. Echo Nonce Algorithm > >> > > > > This mechanism seems sufficient to verify unreachability but is not a > > secure test of reachability because the nonce is way too short. > > The nonce can remain the same value for a certain amount of time to > timeout reachability or when it receives the echo to the nonce. The nonce > need not be incremented for every packet. The nonce in the LISP header is > not used for security purposes, even though many want to use it that way. > But as you say, it is too width-short for that. > > > > > S 16. > >> Map-Versioning is a Data-Plane mechanism used to signal a peering x= TR > >> that a local EID-to-RLOC mapping has been updated, so that the > >> peering xTR uses LISP Control-Plane signaling message to retrieve a > >> fresh mapping. This can be used by an attacker to forge the map- > >> versioning field of a LISP encapsulated header and force an excessi= ve > >> amount of signaling between xTRs that may overload them. > > > > Can't I also set a super-high version number, thus gagging updates? > > It doesn=E2=80=99t matter the value. All that matters is that it changed = and you > should do to the mapping system to get an updated RLOC-set. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > S 5.3. > >> header. > >> > >> When doing ETR/PETR decapsulation: > >> > >> o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > >> the case of IPv6) SHOULD be copied from the outer-header 'Time t= o > > > > This should probably be a MUST because there are other protocols that > > assume that TTLs get decremented. > > This was changed in a previous version post your comments. > > > > > S 7.1. > >> destination site. The two fragments are reassembled at the > >> destination host into the single IP datagram that was originated by > >> the source host. Note that reassembly can happen at the ETR if the > >> encapsulated packet was fragmented at or after the ITR. > >> > >> This behavior MAY be performed by the ITR only when the source host > > > > Nit: I think you want to say MUST be, assuming you mean that you can > > perform it only if=E2=80=A6. > > This was changed in a previous version post your comments. > > > > > > > S 7.2. > >> 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packe= t > >> with the DF bit set to 1, exceeds what the core network can > >> deliver, one of the intermediate routers on the path will send = an > >> ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/ > >> Fragmentation-Needed to the ITR, respectively. The ITR will > >> parse the ICMP message to determine which Locator is affected b= y > > > > What if you are in an environment where ICMP is blocked? > > I replied in previous email. > > > > > > > S 9. > >> outside of the subset list if it determines that the subset list > >> is unreachable (unless RLOCs are set to a Priority of 255). Som= e > >> sharing of control exists: the server-side determines the > >> destination RLOC list and load distribution while the client-sid= e > >> has the option of using alternatives to this list if RLOCs in th= e > >> list are unreachable. > > > > How would you obtain alternative RLOCs? > > I said in a previous email, you do a lookup in the mapping system. > > > > > > > S 10. > >> also acting as an ITR and has traffic to return to the original > >> ITR site, it can use this status information to help select an > >> RLOC. > >> > >> 2. When an ETR receives an encapsulated packet from an ITR, the > >> source RLOC from the outer header of the packet is likely up. > > > > What does "is likely up" mean? > > > This was changed in a previous version post your comments. > > Ben=E2=80=99s comments: > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have grave concerns about the suitability of LISP as a whole, in its > > present form, for advancement to the Standards-Track. While some of my > > concerns are not specific to this document, as the core protocol > > (data-plane) spec, it seems an appropriate place to attach them to. > > If you look at 6830bis-24 and 6833bis-18, we think we have addressed your > security concerns. > > > Section 3 defines the EID-to-RLOC Datbaase: > > > > EID-to-RLOC Database: The EID-to-RLOC Database is a global > > distributed database that contains all known EID-Prefix-to-RLOC > > mappings. Each potential ETR typically contains a small piece of > > the database: the EID-to-RLOC mappings for the EID-Prefixes > > "behind" the router. These map to one of the router's own > > globally visible IP addresses. Note that there MAY be transient > > conditions when the EID-Prefix for the site and Locator-Set for > > each EID-Prefix may not be the same on all ETRs. This has no > > negative implications, since a partial set of Locators can be > > used. > > > > No compelling architecture for a trustworthy global distributed databas= e > > has been presented that I've seen so far, and LISP relies heavily on th= e > > mapping system's database for its functionality. I am concerned that s= o > > many requirements are placed on the mapping system so as to be in effec= t > > unimplementable, in which case it would seem that the architecture as a > > whole (that is, for a global Internet-scale system) is not fit for > purpose. > > The DNS naming system and the BGP routing system are distributed > databases. But in any event, we removed the term =E2=80=9Cglobal=E2=80=9D= from both the > data-plane and control-plane documents. > > > Section 4.1's Step (6) only mentions parsing "to check for format > > validity". I think it is appropriate to mention (and refer to) source > > authentication checks as well, since bad Map-Reply data can allow all > sorts > > of attacks to occur. > > Well by now you should see that we have them. And one has to be careful t= o > not have a downgrade attack by continually doing source checks at > data-plane time. > > > There are some fairly subtle ordering requirements between the order of > > entries in Map-Reply messages and the Locator-Status-Bits in data-plane > > It is not subtle. It is explicitly explained in section 10., > > > The usage of the Instance ID does not seem to be adequately covered; fr= om > > what I've been able to pick up so far it seems that both source and > > destination participants must agree on the meaning of an Instance ID, a= nd > > They do not have to agree. It is the ITR that decides when a packet > arrives which instance-ID an EID belongs to. This is discuss in quite a l= ot > of detail in draft-ietf-lisp-vpn. > > > the source and destination EIDs must be in the same Instance. This doe= s > > not seem like it is compatible with Internet scale, especially if there > are > > only 24 usable bits of Instance ID. > > draft-ietf-lisp-vpn explains how 24-bits can be used in the data-plane bu= t > 32-bits of instance-ID is available in the control-plane. And that is > 32-bits *per* mapping system. ITRs can use other criteria to decide which > of many mapping systems it uses for lookups at data-plane time. > > > There seems to be a lot of intra-site synchronization requirements, > notably > > with respect to Map-Version consistency, the contents and ordering of > > There is absolutely, and conscienciosuly no *intra* site sync requirement= s. > > > locator sets for EIDs in the site, etc.; the actual hard requirements f= or > > synchronization within a site should be clearly called out, ideally in = a > > single location. > > > > The security considerations attempt to defer substantially to the > > threat-analysis in RFC 7835, which does not really seem like a complete > > threat analysis and does not provide analysis as to what requirements a= re > > placed on the boundaries between the different components of LISP (data > > plane, control plane, mapping system, various extensions, etc.). The > > secdir reviewer had some good thoughts in this space. > > This should be fixed now in both 6830bis-24 and 6833bis-18. > > > The security considerations throughout the LISP documents place a heavy > > focus on the risk of over-claiming for routing EID-prefixes. This is a > > real concern, to be clear, but it should not overshadow the risk of an > > attacker who is able to move traffic around at will, strip security > > protections, cause denial of service, alter data-plane payloads, etc. > > Similarly, this document's security considerations call out denial of > > service as a risk from Map-Cache insertion/spoofing, but the risks from > an > > attacker being able to read and modify the traffic, perhaps even withou= t > > detection, seems a much greater threat to me. > > This should be fixed now in both 6830bis-24 and 6833bis-18. > > > I am not convinced that this protocol meets the current IETF requiremen= ts > > for the security properties of Standards-Track Protocols without at lea= st > > LISP-SEC as a mandatory-to-implement component, and possibly additional > or > > stronger requirements. (I did not do a full analysis of the system in > the > > presence of those security mechanisms, since that is not what is being > > presented for review.) > > We have made draft-ietf-lisp-sec mandatory. Or at least, we have asked th= e > working group and there have been no objections so far. > > > Having an EID that is associated to user-correlatable devices has sever= e > > privacy considerations, but I could not find this mentioned anywhere in > all > > of the LISP documents I've read so far. > > This should be fixed now in both 6830bis-24 and 6833bis-18. > > > The instance ID provides for organizational correlation, another privac= y > > exposure. > > It is an opaque value and even though when LISP-crypto is used the LISP > header does travel in the clear, you do not know who uses it unless you > have access to the mapping system and authorized to do lookups on that > instance-ID. There are many keys required to get access to it (we have a > sort of MFA implemented). > > > Is there anything different between an "EID-to-RLOC Map-Request" and > just a > > "Map-Request"? (Same question for "Map-Reply", too.) > > I have removed the single occurence of "EID-to-RLOC Map-Request=E2=80=9D = to > =E2=80=9CMap-Request=E2=80=9D. > > > There's a lot of stuff that seems to work best if there is symmetric > > bidirectional traffic, with inline signalling of map version and > > reachability changes, though clearly everything is designed to also wor= k > > with asymmetric connectivity or unidirectional traffic. It would be ni= ce > > to have a high-level summary in or near the introduction about what kin= ds > > of behavior/performance differences are expected for bidirectional vs. > > unidirectional traffic. > > Nothing requires one or the other at the data-plane. I would prefer to no= t > mention this. Because it may introduce comments not covered yet in the > document or are control-plane related that don=E2=80=99t belong in 6830bi= s. > > > Section 2 > > > > That's not the 8174 boilerplate; it's more than just adding a cite to t= he > > 2119 boilerplate. > > This was changed in a previous version post your comments. > > > > > Section 3 > > > > nit: "An address family that pertains to the Data-Plane." is a sentence > > fragment. > > > > Ingress Tunnel Router (ITR): An ITR is a router that resides in a > > [...] > > mapping lookup in the destination address field. Note that this > > destination RLOC MAY be an intermediate, proxy device that has > > better knowledge of the EID-to-RLOC mapping closer to the > > > > This doesn't seem like a 2119 MAY is necessary, but rather a statement = of > > fact that may not be known to the encapsulating ITR. > > > > Specifically, when a service provider prepends a LISP header for > > Traffic Engineering purposes, the router that does this is also > > regarded as an ITR. The outer RLOC the ISP ITR uses can be based > > on the outer destination address (the originating ITR's supplied > > RLOC) or the inner destination address (the originating host's > > supplied EID). > > > > I'm confused here, perhaps in multiple ways. Are there now *two* LISP > > headers on the packet? Is the "outer RLOC the ISP ITR uses" the source > > RLOC or the destination RLOC? > > > > Negative Mapping Entry: A negative mapping entry, also known as a > > negative cache entry, is an EID-to-RLOC entry where an EID-Prefix > > is advertised or stored with no RLOCs. That is, the Locator-Set > > for the EID-to-RLOC entry is empty or has an encoded Locator count > > of 0. > > > > Is "empty" a distinct representation from "locator count of zero=E2=80= =9D? > > All fixed in a previous version post your comments. > > > Perhaps something of an aside, but the check described for > > Route-Returnability is a somewhat weak check, and in some cases could > still > > be spoofed. (I don't expect this to surprise anyone, of course, but > > perhaps some more qualifiers could be added to the text.) > > > > Section 4 > > > > An additional LISP header MAY be prepended to packets by a TE-ITR > > when re-routing of the path for a packet is desired. A potential > > use-case for this would be an ISP router that needs to perform > > Traffic Engineering for packets flowing through its network. In such > > a situation, termed "Recursive Tunneling", an ISP transit acts as an > > additional ITR, and the RLOC it uses for the new prepended header > > would be either a TE-ETR within the ISP (along an intra-ISP traffic > > engineered path) or a TE-ETR within another ISP (an inter-ISP traffic > > engineered path, where an agreement to build such a path exists). > > > > "the RLOC it uses for the new prepnded header", again, this is as the > > destination RLOC (vs. source RLOC)? > > Fixed in a previous version post your comments. > > > Section 4.1 > > > > o Map-Replies are sent on the underlying routing system topology > > using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. > > > > Just to check my understanding: is the "underlying routing system > topology" > > the same as the "underlay"? > > > > Is step (3) just describing more of what step (2) says is "not describe= d > in > > this example=E2=80=9D? > > All fixed in a previous version post your comments. > > > Section 5.3 > > > > The word "nonce" is normally used for something used exactly once. > > E.g., with some AEAD algorithms, if the same "nonce" input is used for > > different encryptions, the entire security of the system is compromised= . > > It would be better to refer to this field with a different term, given > > that "the same nonce can be used for a period of time when encapsulatin= g > to > > the same ETR". "Uniquifier" or "random value" might be reasonable > choices. > > We can=E2=80=99t change this. There is too much deployment and terminolog= y based > on it. It is a random number, a relatively small one but a random number. > > > Why is there no discussion of the Map-Version or Instance-ID fields > > in this section? > > > > When doing ETR/PETR decapsulation: > > > > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > > the case of IPv6) SHOULD be copied from the outer-header 'Time to > > Live' field, when the Time to Live value of the outer header is > > less than the Time to Live value of the inner header. Failing to > > perform this check can cause the Time to Live of the inner header > > to increment across encapsulation/decapsulation cycles. This > > check is also performed when doing initial encapsulation, when a > > packet comes to an ITR or PITR destined for a LISP site. > > > > Er, what is "this check" that is also performed for initial > encapsulation? > > How are there multiple TTL values to compare? > > > > o The inner-header 'Differentiated Services Code Point' (DSCP) field > > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be > > copied from the outer-header DSCP field ('Traffic Class' field, in > > the case of IPv6) to the inner-header. > > > > nit: the first "inner-header" seems like an editing remnant? > > All fixed in a previous version post your comments. > > > > > Section 7.1 > > > > How is this stateless if it invovles knowledge about the routers betwee= n > > the ITR and all possible ETRs (i.e., a set that could change over time)= ? > > > > Section 8 > > > > This 32-bit vs 24-bit thing is pretty hokey for a standards-track > > specification (yes, I know that LISP-DDT is not standards track at the > > moment). > > Already explained. See draft-ietf-lisp-vpn. It isn=E2=80=99t hokey, we wa= nt to > have a large space and not spend the cost of it in the data-plane. So we > have to compress the value. > > > Section 9 > > > > Alternatively, RLOC information MAY be gleaned from received tunneled > > > > What is this an alternative to? The list of four options above? > > > > packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache > > entry, one learned from the source RLOC of a received encapsulated > > packet, is only stored and used for a few seconds, pending > > verification. Verification is performed by sending a Map-Request to > > the source EID (the inner-header IP source address) of the received > > encapsulated packet. > > > > The source EID is some random end system, right? So this relys on some > > magic in the ETR to detect that there's a Map-Request and reply directl= y > > instead of passing it on to the EID that won't know what to do with it? > > I hope by now, you understand this. > > > Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and > > might benefit from an explicit section reference to the other document. > > That was fixed. > > > Section 10 > > > > What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it > > is not marked as well-known at > > https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion > is > > probably in order. > > Answered. We have it in the Definition of Terms section. > > > Again, when we are talking about the internal structure of the > Map-Reply, a > > detailed section refernce to 6833bis is useful. > > > > Modifying LSBs seems like a fine DoS attack vector for an on-path > attacker. > > > > value of 1. Locator-Status-Bits are associated with a Locator-Set > > per EID-Prefix. Therefore, when a Locator becomes unreachable, the > > Locator-Status-Bit that corresponds to that Locator's position in the > > list returned by the last Map-Reply will be set to zero for that > > particular EID-Prefix > > See comments above to Eric. > > > Doesn't this imply a stateful relationship between the ordering of > > Map-Replys and data-plane traffic? > > > > Section 10.1 > > > > Note that "ITR" and "ETR" are relative terms here. Both devices MUST > > be implementing both ITR and ETR functionality for the echo nonce > > mechanism to operate. > > Answered previously. I believe you understand this now. > > > Perhaps they could be given actual names so as to disambiguate which > steps > > are performed with ITR vs. ETR role? > > > > The echo-nonce algorithm is bilateral. That is, if one side sets the > > E-bit and the other side is not enabled for echo-noncing, then the > > echoing of the nonce does not occur and the requesting side may > > erroneously consider the Locator unreachable. An ITR SHOULD only set > > the E-bit in an encapsulated data packet when it knows the ETR is > > enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- > > probe Map-Reply message. > > > > Why is this even optional? If it was mandatory to use, then there woul= d > > not be a question. But at least clarify that the "this" that is convey= ed > > is whether the peer supports the echo-nonce algorithm. (Also, subject = to > > downgrade.) > > It is optional because you can use RLOC-probing in the control-plane. > > > Section 13 > > > > When a Locator record is removed from a Locator-Set, ITRs that have > > the mapping cached will not use the removed Locator because the xTRs > > will set the Locator-Status-Bit to 0. So, even if the Locator is in > > the list, it will not be used. For new mapping requests, the xTRs > > can set the Locator AFI to 0 (indicating an unspecified address), as > > well as setting the corresponding Locator-Status-Bit to 0. This > > forces ITRs with old or new mappings to avoid using the removed > > Locator. > > > > The behavior describe here seems like it would be better described as > "when > > a Locator is taken out of service" than "removed from a Locator-Set", > since > > if it is not in the set at all, it has no index, and no LSB or AFI to > set. > > Should actually depopulating it like this be forbidden? > > Answered above and new text added. > > > I guess the Map Versioning is supposed to help with this, but we need t= o > > nail down the semantics more and/or give a clearer reference to it. > > That was done for you. > > > Section 13.1 > > > > An ITR, when it encapsulates packets to ETRs, can convey its own Map- > > Version Number. This is known as the Source Map-Version Number. > > > > Replacing "its own Map-Version Number" with something like "the > Map-Version > > numer for the LISP site of which it is a part". Writing this causes me > to > > note that the semantics of the Map-Version are unclear, here -- what is > it > > scoped to? An EID-Prefix? An RLOC? Oh, you say that in the next > > paragraph (EID-Prefix). > > > > A Map-Version Number can be included in Map-Register messages as > > well. This is a good way for the Map-Server to assure that all ETRs > > for a site registering to it will be synchronized according to Map- > > Version Number. > > > > Huh? I must be confused how this works. (Also, wouldn't this be bette= r > in > > the control plane document which covers Map-Register?) > > The reference to draft-ietf-lisp-rfc68934bis should help this. > > > Section 15 > > > > o When a tunnel-encapsulated packet is received by an ETR, the outer > > destination address may not be the address of the router. This > > makes it challenging for the control plane to get packets from the > > hardware. This may be mitigated by creating special Forwarding > > Information Base (FIB) entries for the EID-Prefixes of EIDs served > > by the ETR (those for which the router provides an RLOC > > translation). These FIB entries are marked with a flag indicating > > that Control-Plane processing SHOULD be performed. > > > > I assume this is just my lack of background showing, but I'm confused h= ow > > it makes sense to mark these for control-plane processing. Isn't the > > control plane much slower, and we're not putting all of the LISP > data-plane > > traffic onto the slow path? > > Answered in previous email. I think you understand this now. > > > Section 18 > > > > o Data-Plane gleaning for creating map-cache entries has been made > > optional. If any ITR implementations depend or assume the remote > > ETR is gleaning should not do so. > > > > nit: this is ungrammatical; "they should not" or "Any ITR implementatio= ns > > that depend on or assume that" would fix it. > > That was fixed pre -24. > > > Section 19.1 > > > > Presumably IANA also updated the reference column to point to this > > document? > > Yes, it is now. > > Thanks all, > Dino > > > > --0000000000002e9bb60578133a88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> There are diff files attach for revi= sions 68830bis-24 and 6833bis-18. They have not been posted yet.
> > > S 4.1.
> >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 RLOC (outer-header source IP address) in a received LISP packet.
>= ; >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Such a cache entry is = termed a "glean mapping" and only contains
> >>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a single RLOC for the EID in question.= =C2=A0 More complete information
> >>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 about additional RLOCs SHOULD be verified by sending a L= ISP Map-
> >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Request= for that EID.=C2=A0 Both the ITR and the ETR MAY also
> >>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 influence the decision the other ma= kes in selecting an RLOC.
> >
> > This seems like it int= roduces an immediate overclaiming problem.
>
> It does not, if= the gleaner wants to add this to the cache, it is
> /32 EID with the= source RLOC. So it is not overclaimed. If the
> gleaner wants to ver= ify the mapping, it does a lookup to the mapping
> system on the sour= ce EID and then can get a coarser EID-prefix with
> an authorized lis= t of RLOCs.

OK, thanks.


> > S 10.
> >>= =C2=A0=C2=A0=C2=A0 When an ETR decapsulates a packet, it will check for any= change in
> >>=C2=A0=C2=A0=C2=A0 the 'Locator-Status-Bits&= #39; field.=C2=A0 When a bit goes from 1 to 0, the
> >>=C2=A0= =C2=A0=C2=A0 ETR, if acting also as an ITR, will refrain from encapsulating=
> >>=C2=A0=C2=A0=C2=A0 packets to an RLOC that is indicated as= down.=C2=A0 It will only resume
> >>=C2=A0=C2=A0=C2=A0 using t= hat RLOC if the corresponding Locator-Status-Bit returns to a
> >&= gt;=C2=A0=C2=A0=C2=A0 value of 1.=C2=A0 Locator-Status-Bits are associated = with a Locator-Set
> >
> > This seems to enable a pretty= obvious denial of service attack in
> > which you send=C2=A0 a me= ssage with all LSBs set to 0.
>
> The LSBs are a hint and usua= lly used for =E2=80=9Cidling down RLOCs=E2=80=9D. I will
> add text t= hat ETR will rate-limit how often it reacts to LSB
> changes. And not= e that its RLOC-probing cache will tell the rule
> truth about if the= RLOC is reachable.

Sounds good.


> > S 10.
> = >>=C2=A0=C2=A0=C2=A0 list returned by the last Map-Reply will be set = to zero for that
> >>=C2=A0=C2=A0=C2=A0 particular EID-Prefix.= =C2=A0 Refer to Section 16 for security related
> >>=C2=A0=C2= =A0=C2=A0 issues regarding Locator-Status-Bits.
> >>
> &= gt;>=C2=A0=C2=A0=C2=A0 When an ETR decapsulates a packet, it knows that = it is reachable from
> >>=C2=A0=C2=A0=C2=A0 the encapsulating I= TR because that is how the packet arrived.=C2=A0 In
> >
> &= gt; It doesn't even know this. It just knows that that's been claim= ed by
> > someone who can generate traffic to it.
>
>= Well this is true, but 6833bis discusses RLOC-reachability and there
&g= t; is a RLOC-probe cache that will tell the ITR when it last heard from
= > the RLOC.

Just to be clear, it's not "last heard from&= quot; that you need, but
rather "last verifiably responded".

> > S 16.
> >>=C2=A0=C2=A0=C2=A0 Map-Versioning= is a Data-Plane mechanism used to signal a peering xTR
> >>=C2= =A0=C2=A0=C2=A0 that a local EID-to-RLOC mapping has been updated, so that = the
> >>=C2=A0=C2=A0=C2=A0 peering xTR uses LISP Control-Plane = signaling message to retrieve a
> >>=C2=A0=C2=A0=C2=A0 fresh ma= pping.=C2=A0 This can be used by an attacker to forge the map-
> >= >=C2=A0=C2=A0=C2=A0 versioning field of a LISP encapsulated header and f= orce an excessive
> >>=C2=A0=C2=A0=C2=A0 amount of signaling be= tween xTRs that may overload them.
> >
> > Can't I a= lso set a super-high version number, thus gagging updates?
>
>= It doesn=E2=80=99t matter the value. All that matters is that it changed a= nd you should do to the mapping system to get an updated RLOC-set.

H= mm... S 5.1 of 6834-bis suggests that you can just discard it.


= =C2=A0

Eric/Ben, I am following up with responses and changes to address= the security comments in 6830bis. I have both of your comments enclosed an= d indented in this email. Eric=E2=80=99s comments come first then Ben=E2=80= =99s second.

There are diff files attach for revisions 68830bis-24 and 6833bis-18. They = have not been posted yet.

> S 4.1.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 RLOC (outer-header source IP address) i= n a received LISP packet.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Such a cache entry is termed a "gl= ean mapping" and only contains
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 a single RLOC for the EID in question.= =C2=A0 More complete information
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 about additional RLOCs SHOULD be verifi= ed by sending a LISP Map-
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Request for that EID.=C2=A0 Both the IT= R and the ETR MAY also
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 influence the decision the other makes = in selecting an RLOC.
>
> This seems like it introduces an immediate overclaiming problem.

It does not, if the gleaner wants to add this to the cache, it is /32 EID w= ith the source RLOC. So it is not overclaimed. If the gleaner wants to veri= fy the mapping, it does a lookup to the mapping system on the source EID an= d then can get a coarser EID-prefix with an authorized list of RLOCs.

> S 10.
>>=C2=A0 =C2=A0 When an ETR decapsulates a packet, it will check for = any change in
>>=C2=A0 =C2=A0 the 'Locator-Status-Bits' field.=C2=A0 When a= bit goes from 1 to 0, the
>>=C2=A0 =C2=A0 ETR, if acting also as an ITR, will refrain from enca= psulating
>>=C2=A0 =C2=A0 packets to an RLOC that is indicated as down.=C2=A0 I= t will only resume
>>=C2=A0 =C2=A0 using that RLOC if the corresponding Locator-Status-B= it returns to a
>>=C2=A0 =C2=A0 value of 1.=C2=A0 Locator-Status-Bits are associated = with a Locator-Set
>
> This seems to enable a pretty obvious denial of service attack in
> which you send=C2=A0 a message with all LSBs set to 0.

The LSBs are a hint and usually used for =E2=80=9Cidling down RLOCs=E2=80= =9D. I will add text that ETR will rate-limit how often it reacts to LSB ch= anges. And note that its RLOC-probing cache will tell the rule truth about = if the RLOC is reachable.

>
>
> S 10.
>>=C2=A0 =C2=A0 list returned by the last Map-Reply will be set to ze= ro for that
>>=C2=A0 =C2=A0 particular EID-Prefix.=C2=A0 Refer to Section 16 for = security related
>>=C2=A0 =C2=A0 issues regarding Locator-Status-Bits.
>>
>>=C2=A0 =C2=A0 When an ETR decapsulates a packet, it knows that it i= s reachable from
>>=C2=A0 =C2=A0 the encapsulating ITR because that is how the packet = arrived.=C2=A0 In
>
> It doesn't even know this. It just knows that that's been clai= med by
> someone who can generate traffic to it.

Well this is true, but 6833bis discusses RLOC-reachability and there is a R= LOC-probe cache that will tell the ITR when it last heard from the RLOC.
>
>
> S 10.1.
>>=C2=A0 =C2=A0 NOT use the lack of return traffic as an indication t= hat the ETR is
>>=C2=A0 =C2=A0 unreachable.=C2=A0 Instead, it MUST use an alternate = mechanism to
>>=C2=A0 =C2=A0 determine reachability.
>>
>> 10.1.=C2=A0 Echo Nonce Algorithm
>>
>
> This mechanism seems sufficient to verify unreachability but is not a<= br> > secure test of reachability because the nonce is way too short.

The nonce can remain the same value for a certain amount of time to timeout= reachability or when it receives the echo to the nonce. The nonce need not= be incremented for every packet. The nonce in the LISP header is not used = for security purposes, even though many want to use it that way. But as you= say, it is too width-short for that.

>
> S 16.
>>=C2=A0 =C2=A0 Map-Versioning is a Data-Plane mechanism used to sign= al a peering xTR
>>=C2=A0 =C2=A0 that a local EID-to-RLOC mapping has been updated, so= that the
>>=C2=A0 =C2=A0 peering xTR uses LISP Control-Plane signaling message= to retrieve a
>>=C2=A0 =C2=A0 fresh mapping.=C2=A0 This can be used by an attacker = to forge the map-
>>=C2=A0 =C2=A0 versioning field of a LISP encapsulated header and fo= rce an excessive
>>=C2=A0 =C2=A0 amount of signaling between xTRs that may overload th= em.
>
> Can't I also set a super-high version number, thus gagging updates= ?

It doesn=E2=80=99t matter the value. All that matters is that it changed an= d you should do to the mapping system to get an updated RLOC-set.

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> S 5.3.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0header.
>>
>>=C2=A0 =C2=A0 When doing ETR/PETR decapsulation:
>>
>>=C2=A0 =C2=A0 o=C2=A0 The inner-header 'Time to Live' field= (or 'Hop Limit' field, in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0the case of IPv6) SHOULD be copied from = the outer-header 'Time to
>
> This should probably be a MUST because there are other protocols that<= br> > assume that TTLs get decremented.

This was changed in a previous version post your comments.

>
> S 7.1.
>>=C2=A0 =C2=A0 destination site.=C2=A0 The two fragments are reassem= bled at the
>>=C2=A0 =C2=A0 destination host into the single IP datagram that was= originated by
>>=C2=A0 =C2=A0 the source host.=C2=A0 Note that reassembly can happe= n at the ETR if the
>>=C2=A0 =C2=A0 encapsulated packet was fragmented at or after the IT= R.
>>
>>=C2=A0 =C2=A0 This behavior MAY be performed by the ITR only when t= he source host
>
> Nit: I think you want to say MUST be, assuming you mean that you can > perform it only if=E2=80=A6.

This was changed in a previous version post your comments.

>
>
> S 7.2.
>>=C2=A0 =C2=A0 2.=C2=A0 When an IPv6-encapsulated packet, or an IPv4= -encapsulated packet
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 with the DF bit set to 1, exceeds what = the core network can
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 deliver, one of the intermediate router= s on the path will send an
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ICMPv6 "Packet Too Big" messa= ge or an ICMPv4 Unreachable/
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Fragmentation-Needed to the ITR, respec= tively.=C2=A0 The ITR will
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 parse the ICMP message to determine whi= ch Locator is affected by
>
> What if you are in an environment where ICMP is blocked?

I replied in previous email.

>
>
> S 9.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0outside of the subset list if it determi= nes that the subset list
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0is unreachable (unless RLOCs are set to = a Priority of 255).=C2=A0 Some
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0sharing of control exists: the server-si= de determines the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0destination RLOC list and load distribut= ion while the client-side
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0has the option of using alternatives to = this list if RLOCs in the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0list are unreachable.
>
> How would you obtain alternative RLOCs?

I said in a previous email, you do a lookup in the mapping system.

>
>
> S 10.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 also acting as an ITR and has traffic t= o return to the original
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ITR site, it can use this status inform= ation to help select an
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 RLOC.
>>
>>=C2=A0 =C2=A0 2.=C2=A0 When an ETR receives an encapsulated packet = from an ITR, the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 source RLOC from the outer header of th= e packet is likely up.
>
> What does "is likely up" mean?


This was changed in a previous version post your comments.

Ben=E2=80=99s comments:

> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I have grave concerns about the suitability of LISP as a whole, in its=
> present form, for advancement to the Standards-Track.=C2=A0 While some= of my
> concerns are not specific to this document, as the core protocol
> (data-plane) spec, it seems an appropriate place to attach them to.
If you look at 6830bis-24 and 6833bis-18, we think we have addressed your s= ecurity concerns.

> Section 3 defines the EID-to-RLOC Datbaase:
>
>=C2=A0 EID-to-RLOC Database:=C2=A0 =C2=A0The EID-to-RLOC Database is a = global
>=C2=A0 =C2=A0 =C2=A0distributed database that contains all known EID-Pr= efix-to-RLOC
>=C2=A0 =C2=A0 =C2=A0mappings.=C2=A0 Each potential ETR typically contai= ns a small piece of
>=C2=A0 =C2=A0 =C2=A0the database: the EID-to-RLOC mappings for the EID-= Prefixes
>=C2=A0 =C2=A0 =C2=A0"behind" the router.=C2=A0 These map to o= ne of the router's own
>=C2=A0 =C2=A0 =C2=A0globally visible IP addresses.=C2=A0 Note that ther= e MAY be transient
>=C2=A0 =C2=A0 =C2=A0conditions when the EID-Prefix for the site and Loc= ator-Set for
>=C2=A0 =C2=A0 =C2=A0each EID-Prefix may not be the same on all ETRs.=C2= =A0 This has no
>=C2=A0 =C2=A0 =C2=A0negative implications, since a partial set of Locat= ors can be
>=C2=A0 =C2=A0 =C2=A0used.
>
> No compelling architecture for a trustworthy global distributed databa= se
> has been presented that I've seen so far, and LISP relies heavily = on the
> mapping system's database for its functionality.=C2=A0 I am concer= ned that so
> many requirements are placed on the mapping system so as to be in effe= ct
> unimplementable, in which case it would seem that the architecture as = a
> whole (that is, for a global Internet-scale system) is not fit for pur= pose.

The DNS naming system and the BGP routing system are distributed databases.= But in any event, we removed the term =E2=80=9Cglobal=E2=80=9D from both t= he data-plane and control-plane documents.

> Section 4.1's Step (6) only mentions parsing "to check for fo= rmat
> validity".=C2=A0 I think it is appropriate to mention (and refer = to) source
> authentication checks as well, since bad Map-Reply data can allow all = sorts
> of attacks to occur.

Well by now you should see that we have them. And one has to be careful to = not have a downgrade attack by continually doing source checks at data-plan= e time.

> There are some fairly subtle ordering requirements between the order o= f
> entries in Map-Reply messages and the Locator-Status-Bits in data-plan= e

It is not subtle. It is explicitly explained in section 10.,

> The usage of the Instance ID does not seem to be adequately covered; f= rom
> what I've been able to pick up so far it seems that both source an= d
> destination participants must agree on the meaning of an Instance ID, = and

They do not have to agree. It is the ITR that decides when a packet arrives= which instance-ID an EID belongs to. This is discuss in quite a lot of det= ail in draft-ietf-lisp-vpn.

> the source and destination EIDs must be in the same Instance.=C2=A0 Th= is does
> not seem like it is compatible with Internet scale, especially if ther= e are
> only 24 usable bits of Instance ID.

draft-ietf-lisp-vpn explains how 24-bits can be used in the data-plane but = 32-bits of instance-ID is available in the control-plane. And that is 32-bi= ts *per* mapping system. ITRs can use other criteria to decide which of man= y mapping systems it uses for lookups at data-plane time.

> There seems to be a lot of intra-site synchronization requirements, no= tably
> with respect to Map-Version consistency, the contents and ordering of<= br>
There is absolutely, and conscienciosuly no *intra* site sync requirements.=

> locator sets for EIDs in the site, etc.; the actual hard requirements = for
> synchronization within a site should be clearly called out, ideally in= a
> single location.
>
> The security considerations attempt to defer substantially to the
> threat-analysis in RFC 7835, which does not really seem like a complet= e
> threat analysis and does not provide analysis as to what requirements = are
> placed on the boundaries between the different components of LISP (dat= a
> plane, control plane, mapping system, various extensions, etc.).=C2=A0= The
> secdir reviewer had some good thoughts in this space.

This should be fixed now in both 6830bis-24 and 6833bis-18.

> The security considerations throughout the LISP documents place a heav= y
> focus on the risk of over-claiming for routing EID-prefixes.=C2=A0 Thi= s is a
> real concern, to be clear, but it should not overshadow the risk of an=
> attacker who is able to move traffic around at will, strip security > protections, cause denial of service, alter data-plane payloads, etc.<= br> > Similarly, this document's security considerations call out denial= of
> service as a risk from Map-Cache insertion/spoofing, but the risks fro= m an
> attacker being able to read and modify the traffic, perhaps even witho= ut
> detection, seems a much greater threat to me.

This should be fixed now in both 6830bis-24 and 6833bis-18.

> I am not convinced that this protocol meets the current IETF requireme= nts
> for the security properties of Standards-Track Protocols without at le= ast
> LISP-SEC as a mandatory-to-implement component, and possibly additiona= l or
> stronger requirements.=C2=A0 (I did not do a full analysis of the syst= em in the
> presence of those security mechanisms, since that is not what is being=
> presented for review.)

We have made draft-ietf-lisp-sec mandatory. Or at least, we have asked the = working group and there have been no objections so far.

> Having an EID that is associated to user-correlatable devices has seve= re
> privacy considerations, but I could not find this mentioned anywhere i= n all
> of the LISP documents I've read so far.

This should be fixed now in both 6830bis-24 and 6833bis-18.

> The instance ID provides for organizational correlation, another priva= cy
> exposure.

It is an opaque value and even though when LISP-crypto is used the LISP hea= der does travel in the clear, you do not know who uses it unless you have a= ccess to the mapping system and authorized to do lookups on that instance-I= D. There are many keys required to get access to it (we have a sort of MFA = implemented).

> Is there anything different between an "EID-to-RLOC Map-Request&q= uot; and just a
> "Map-Request"?=C2=A0 (Same question for "Map-Reply"= ;, too.)

I have removed the single occurence of "EID-to-RLOC Map-Request=E2=80= =9D to =E2=80=9CMap-Request=E2=80=9D.

> There's a lot of stuff that seems to work best if there is symmetr= ic
> bidirectional traffic, with inline signalling of map version and
> reachability changes, though clearly everything is designed to also wo= rk
> with asymmetric connectivity or unidirectional traffic.=C2=A0 It would= be nice
> to have a high-level summary in or near the introduction about what ki= nds
> of behavior/performance differences are expected for bidirectional vs.=
> unidirectional traffic.

Nothing requires one or the other at the data-plane. I would prefer to not = mention this. Because it may introduce comments not covered yet in the docu= ment or are control-plane related that don=E2=80=99t belong in 6830bis.

> Section 2
>
> That's not the 8174 boilerplate; it's more than just adding a = cite to the
> 2119 boilerplate.

This was changed in a previous version post your comments.

>
> Section 3
>
> nit: "An address family that pertains to the Data-Plane." is= a sentence
> fragment.
>
>=C2=A0 Ingress Tunnel Router (ITR):=C2=A0 =C2=A0An ITR is a router that= resides in a
>=C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0mapping lookup in the destination address field.=C2= =A0 Note that this
>=C2=A0 =C2=A0 =C2=A0destination RLOC MAY be an intermediate, proxy devi= ce that has
>=C2=A0 =C2=A0 =C2=A0better knowledge of the EID-to-RLOC mapping closer = to the
>
> This doesn't seem like a 2119 MAY is necessary, but rather a state= ment of
> fact that may not be known to the encapsulating ITR.
>
>=C2=A0 =C2=A0 =C2=A0Specifically, when a service provider prepends a LI= SP header for
>=C2=A0 =C2=A0 =C2=A0Traffic Engineering purposes, the router that does = this is also
>=C2=A0 =C2=A0 =C2=A0regarded as an ITR.=C2=A0 The outer RLOC the ISP IT= R uses can be based
>=C2=A0 =C2=A0 =C2=A0on the outer destination address (the originating I= TR's supplied
>=C2=A0 =C2=A0 =C2=A0RLOC) or the inner destination address (the origina= ting host's
>=C2=A0 =C2=A0 =C2=A0supplied EID).
>
> I'm confused here, perhaps in multiple ways.=C2=A0 Are there now *= two* LISP
> headers on the packet?=C2=A0 Is the "outer RLOC the ISP ITR uses&= quot; the source
> RLOC or the destination RLOC?
>
>=C2=A0 Negative Mapping Entry:=C2=A0 =C2=A0A negative mapping entry, al= so known as a
>=C2=A0 =C2=A0 =C2=A0negative cache entry, is an EID-to-RLOC entry where= an EID-Prefix
>=C2=A0 =C2=A0 =C2=A0is advertised or stored with no RLOCs.=C2=A0 That i= s, the Locator-Set
>=C2=A0 =C2=A0 =C2=A0for the EID-to-RLOC entry is empty or has an encode= d Locator count
>=C2=A0 =C2=A0 =C2=A0of 0.
>
> Is "empty" a distinct representation from "locator coun= t of zero=E2=80=9D?

All fixed in a previous version post your comments.

> Perhaps something of an aside, but the check described for
> Route-Returnability is a somewhat weak check, and in some cases could = still
> be spoofed.=C2=A0 (I don't expect this to surprise anyone, of cour= se, but
> perhaps some more qualifiers could be added to the text.)
>
> Section 4
>
>=C2=A0 An additional LISP header MAY be prepended to packets by a TE-IT= R
>=C2=A0 when re-routing of the path for a packet is desired.=C2=A0 A pot= ential
>=C2=A0 use-case for this would be an ISP router that needs to perform >=C2=A0 Traffic Engineering for packets flowing through its network.=C2= =A0 In such
>=C2=A0 a situation, termed "Recursive Tunneling", an ISP tran= sit acts as an
>=C2=A0 additional ITR, and the RLOC it uses for the new prepended heade= r
>=C2=A0 would be either a TE-ETR within the ISP (along an intra-ISP traf= fic
>=C2=A0 engineered path) or a TE-ETR within another ISP (an inter-ISP tr= affic
>=C2=A0 engineered path, where an agreement to build such a path exists)= .
>
> "the RLOC it uses for the new prepnded header", again, this = is as the
> destination RLOC (vs. source RLOC)?

Fixed in a previous version post your comments.

> Section 4.1
>
>=C2=A0 o=C2=A0 Map-Replies are sent on the underlying routing system to= pology
>=C2=A0 =C2=A0 =C2=A0using the [I-D.ietf-lisp-rfc6833bis] Control-Plane = protocol.
>
> Just to check my understanding: is the "underlying routing system= topology"
> the same as the "underlay"?
>
> Is step (3) just describing more of what step (2) says is "not de= scribed in
> this example=E2=80=9D?

All fixed in a previous version post your comments.

> Section 5.3
>
> The word "nonce" is normally used for something used exactly= once.
> E.g., with some AEAD algorithms, if the same "nonce" input i= s used for
> different encryptions, the entire security of the system is compromise= d.
> It would be better to refer to this field with a different term, given=
> that "the same nonce can be used for a period of time when encaps= ulating to
> the same ETR".=C2=A0 "Uniquifier" or "random value= " might be reasonable choices.

We can=E2=80=99t change this. There is too much deployment and terminology = based on it. It is a random number, a relatively small one but a random num= ber.

> Why is there no discussion of the Map-Version or Instance-ID fields > in this section?
>
> When doing ETR/PETR decapsulation:
>
>=C2=A0 o=C2=A0 The inner-header 'Time to Live' field (or 'H= op Limit' field, in
>=C2=A0 =C2=A0 =C2=A0the case of IPv6) SHOULD be copied from the outer-h= eader 'Time to
>=C2=A0 =C2=A0 =C2=A0Live' field, when the Time to Live value of the= outer header is
>=C2=A0 =C2=A0 =C2=A0less than the Time to Live value of the inner heade= r.=C2=A0 Failing to
>=C2=A0 =C2=A0 =C2=A0perform this check can cause the Time to Live of th= e inner header
>=C2=A0 =C2=A0 =C2=A0to increment across encapsulation/decapsulation cyc= les.=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0check is also performed when doing initial encapsul= ation, when a
>=C2=A0 =C2=A0 =C2=A0packet comes to an ITR or PITR destined for a LISP = site.
>
> Er, what is "this check" that is also performed for initial = encapsulation?
> How are there multiple TTL values to compare?
>
>=C2=A0 o=C2=A0 The inner-header 'Differentiated Services Code Point= ' (DSCP) field
>=C2=A0 =C2=A0 =C2=A0(or the 'Traffic Class' field, in the case = of IPv6) SHOULD be
>=C2=A0 =C2=A0 =C2=A0copied from the outer-header DSCP field ('Traff= ic Class' field, in
>=C2=A0 =C2=A0 =C2=A0the case of IPv6) to the inner-header.
>
> nit: the first "inner-header" seems like an editing remnant?=

All fixed in a previous version post your comments.

>
> Section 7.1
>
> How is this stateless if it invovles knowledge about the routers betwe= en
> the ITR and all possible ETRs (i.e., a set that could change over time= )?
>
> Section 8
>
> This 32-bit vs 24-bit thing is pretty hokey for a standards-track
> specification (yes, I know that LISP-DDT is not standards track at the=
> moment).

Already explained. See draft-ietf-lisp-vpn. It isn=E2=80=99t hokey, we want= to have a large space and not spend the cost of it in the data-plane. So w= e have to compress the value.

> Section 9
>
>=C2=A0 Alternatively, RLOC information MAY be gleaned from received tun= neled
>
> What is this an alternative to?=C2=A0 The list of four options above?<= br> >
>=C2=A0 packets or EID-to-RLOC Map-Request messages.=C2=A0 A "glean= ed" Map-Cache
>=C2=A0 entry, one learned from the source RLOC of a received encapsulat= ed
>=C2=A0 packet, is only stored and used for a few seconds, pending
>=C2=A0 verification.=C2=A0 Verification is performed by sending a Map-R= equest to
>=C2=A0 the source EID (the inner-header IP source address) of the recei= ved
>=C2=A0 encapsulated packet.
>
> The source EID is some random end system, right?=C2=A0 So this relys o= n some
> magic in the ETR to detect that there's a Map-Request and reply di= rectly
> instead of passing it on to the EID that won't know what to do wit= h it?

I hope by now, you understand this.

> Talking about the "R-bit" of the Map-Reply" is detail f= rom 6833bis and
> might benefit from an explicit section reference to the other document= .

That was fixed.

> Section 10
>
> What is the "CE" of "CE-based ITRs"?=C2=A0 Presuma= bly Customer Edge, but it
> is not marked as well-known at
> https://www.rfc-editor.org/materials/a= bbrev.expansion.txt so expansion is
> probably in order.

Answered. We have it in the Definition of Terms section.

> Again, when we are talking about the internal structure of the Map-Rep= ly, a
> detailed section refernce to 6833bis is useful.
>
> Modifying LSBs seems like a fine DoS attack vector for an on-path atta= cker.
>
>=C2=A0 value of 1.=C2=A0 Locator-Status-Bits are associated with a Loca= tor-Set
>=C2=A0 per EID-Prefix.=C2=A0 Therefore, when a Locator becomes unreacha= ble, the
>=C2=A0 Locator-Status-Bit that corresponds to that Locator's positi= on in the
>=C2=A0 list returned by the last Map-Reply will be set to zero for that=
>=C2=A0 particular EID-Prefix

See comments above to Eric.

> Doesn't this imply a stateful relationship between the ordering of=
> Map-Replys and data-plane traffic?
>
> Section 10.1
>
>=C2=A0 Note that "ITR" and "ETR" are relative terms= here.=C2=A0 Both devices MUST
>=C2=A0 be implementing both ITR and ETR functionality for the echo nonc= e
>=C2=A0 mechanism to operate.

Answered previously. I believe you understand this now.

> Perhaps they could be given actual names so as to disambiguate which s= teps
> are performed with ITR vs. ETR role?
>
>=C2=A0 The echo-nonce algorithm is bilateral.=C2=A0 That is, if one sid= e sets the
>=C2=A0 E-bit and the other side is not enabled for echo-noncing, then t= he
>=C2=A0 echoing of the nonce does not occur and the requesting side may<= br> >=C2=A0 erroneously consider the Locator unreachable.=C2=A0 An ITR SHOUL= D only set
>=C2=A0 the E-bit in an encapsulated data packet when it knows the ETR i= s
>=C2=A0 enabled for echo-noncing.=C2=A0 This is conveyed by the E-bit in= the RLOC-
>=C2=A0 probe Map-Reply message.
>
> Why is this even optional?=C2=A0 If it was mandatory to use, then ther= e would
> not be a question.=C2=A0 But at least clarify that the "this"= ; that is conveyed
> is whether the peer supports the echo-nonce algorithm.=C2=A0 (Also, su= bject to
> downgrade.)

It is optional because you can use RLOC-probing in the control-plane.

> Section 13
>
>=C2=A0 When a Locator record is removed from a Locator-Set, ITRs that h= ave
>=C2=A0 the mapping cached will not use the removed Locator because the = xTRs
>=C2=A0 will set the Locator-Status-Bit to 0.=C2=A0 So, even if the Loca= tor is in
>=C2=A0 the list, it will not be used.=C2=A0 For new mapping requests, t= he xTRs
>=C2=A0 can set the Locator AFI to 0 (indicating an unspecified address)= , as
>=C2=A0 well as setting the corresponding Locator-Status-Bit to 0.=C2=A0= This
>=C2=A0 forces ITRs with old or new mappings to avoid using the removed<= br> >=C2=A0 Locator.
>
> The behavior describe here seems like it would be better described as = "when
> a Locator is taken out of service" than "removed from a Loca= tor-Set", since
> if it is not in the set at all, it has no index, and no LSB or AFI to = set.
> Should actually depopulating it like this be forbidden?

Answered above and new text added.

> I guess the Map Versioning is supposed to help with this, but we need = to
> nail down the semantics more and/or give a clearer reference to it.
That was done for you.

> Section 13.1
>
>=C2=A0 An ITR, when it encapsulates packets to ETRs, can convey its own= Map-
>=C2=A0 Version Number.=C2=A0 This is known as the Source Map-Version Nu= mber.
>
> Replacing "its own Map-Version Number" with something like &= quot;the Map-Version
> numer for the LISP site of which it is a part".=C2=A0 Writing thi= s causes me to
> note that the semantics of the Map-Version are unclear, here -- what i= s it
> scoped to?=C2=A0 An EID-Prefix?=C2=A0 An RLOC?=C2=A0 Oh, you say that = in the next
> paragraph (EID-Prefix).
>
>=C2=A0 A Map-Version Number can be included in Map-Register messages as=
>=C2=A0 well.=C2=A0 This is a good way for the Map-Server to assure that= all ETRs
>=C2=A0 for a site registering to it will be synchronized according to M= ap-
>=C2=A0 Version Number.
>
> Huh?=C2=A0 I must be confused how this works.=C2=A0 (Also, wouldn'= t this be better in
> the control plane document which covers Map-Register?)

The reference to draft-ietf-lisp-rfc68934bis should help this.

> Section 15
>
>=C2=A0 o=C2=A0 When a tunnel-encapsulated packet is received by an ETR,= the outer
>=C2=A0 =C2=A0 =C2=A0destination address may not be the address of the r= outer.=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0makes it challenging for the control plane to get p= ackets from the
>=C2=A0 =C2=A0 =C2=A0hardware.=C2=A0 This may be mitigated by creating s= pecial Forwarding
>=C2=A0 =C2=A0 =C2=A0Information Base (FIB) entries for the EID-Prefixes= of EIDs served
>=C2=A0 =C2=A0 =C2=A0by the ETR (those for which the router provides an = RLOC
>=C2=A0 =C2=A0 =C2=A0translation).=C2=A0 These FIB entries are marked wi= th a flag indicating
>=C2=A0 =C2=A0 =C2=A0that Control-Plane processing SHOULD be performed.<= br> >
> I assume this is just my lack of background showing, but I'm confu= sed how
> it makes sense to mark these for control-plane processing.=C2=A0 Isn&#= 39;t the
> control plane much slower, and we're not putting all of the LISP d= ata-plane
> traffic onto the slow path?

Answered in previous email. I think you understand this now.

> Section 18
>
>=C2=A0 o=C2=A0 Data-Plane gleaning for creating map-cache entries has b= een made
>=C2=A0 =C2=A0 =C2=A0optional.=C2=A0 If any ITR implementations depend o= r assume the remote
>=C2=A0 =C2=A0 =C2=A0ETR is gleaning should not do so.
>
> nit: this is ungrammatical; "they should not" or "Any I= TR implementations
> that depend on or assume that" would fix it.

That was fixed pre -24.

> Section 19.1
>
> Presumably IANA also updated the reference column to point to this
> document?

Yes, it is now.

Thanks all,
Dino



--0000000000002e9bb60578133a88-- From nobody Sun Oct 14 19:20:18 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C8012D4E6; Sun, 14 Oct 2018 19:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy7KrEsxRACH; Sun, 14 Oct 2018 19:20:09 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 E7F15129619; Sun, 14 Oct 2018 19:20:08 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id r9-v6so8858017pff.11; Sun, 14 Oct 2018 19:20:08 -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=1ZS82iD1k3xfpkOZ7ISraVspTcfsWLMPT+jaYTOdx2A=; b=UCGx3Y2sSVuobaU6rpq5clIaKGLS9FLbLuyC/XszQOafitfOQvo3mOgeR1qan78uWM Aw/98J2QTJ5hQbSxHzuUdqaW3+87uEElBlOmsGszQWnCj/tfdkLCXg5Mi6rdOxqMUpF3 rTjU32/6aZGHq3CuztuDheWqEt8jZ14vd1Wxft7JXutwK4YjZ92UQ89azOG/Fp3mkVJm PBCeyjRrDvm6uiOm1Ctp9UzW9qIjMAfbOnoGTOm84+aZpnirNSKiK6xJPUEwAXg3uZd7 IRf4wQfQCyHLDYWGyHG9qhHTU4802bJNnz9OgCMzKSxmhJg+SJhznCd1mB/oOMVEz9oy ZRRA== 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=1ZS82iD1k3xfpkOZ7ISraVspTcfsWLMPT+jaYTOdx2A=; b=rwrVEDyoCBsVUcBbOKvDOW0pj44/ZlOBrhYUIQzuM6/zMjFzfFGAsVbXoVbqvHFaGc nKCAFgiXk6oTrF41fT8lUlSPelI0z1oHM5t7DyCPld5DJ373ae0Q/BcOkslntM3boMD/ gxa6l7sg2UimVjk+4FqScP0xPimzQDHEtVjE7HaefZUSciOovaKb3X4JkC4BVlBQarif VbnYcggN92eD/bDRFPXbMybYw/OFR6BbQ47IRQP5V/3ioaq+/YXUL+Zykr38749y2uKA dtem+IerjudXdD5ozQ5IatgKSHVtJ7piW1l+dzQg7XeVkIZhPKuQ79qDQhS+E7rKO8N0 ydMg== X-Gm-Message-State: ABuFfohBtvP7+Plx4XKvhoIzvwtwETiCKEOvbn2kHkgfXIiWznT1xkSm MLs2PzIhFD+5ivmSewzS0cdJlc88 X-Google-Smtp-Source: ACcGV611zYos7qkruQqY61bYePYeQStOwFKqqaHEd/j+CQznRJKaVH0l5oW8EN9ktu4wi54TLLTejg== X-Received: by 2002:a63:a119:: with SMTP id b25-v6mr14298867pgf.186.1539570008215; Sun, 14 Oct 2018 19:20:08 -0700 (PDT) Received: from ?IPv6:2603:3024:151c:55f0:91a2:7e75:c023:3751? ([2603:3024:151c:55f0:91a2:7e75:c023:3751]) by smtp.gmail.com with ESMTPSA id e64-v6sm11125727pfe.55.2018.10.14.19.20.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Oct 2018 19:20:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (16A404) In-Reply-To: Date: Sun, 14 Oct 2018 19:20:05 -0700 Cc: Benjamin Kaduk , IESG , draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, albert.cabellos@gmail.com, "BRUNGARD, DEBORAH A" , fmaino@cisco.com, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <74F9CFAD-6C2E-4BDB-A56B-0186789EE058@gmail.com> References: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> To: Eric Rescorla Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 02:20:11 -0000 > > Well this is true, but 6833bis discusses RLOC-reachability and there > > is a RLOC-probe cache that will tell the ITR when it last heard from > > the RLOC. >=20 > Just to be clear, it's not "last heard from" that you need, but > rather "last verifiably responded". Right agree.=20 > > > S 16. > > >> Map-Versioning is a Data-Plane mechanism used to signal a peering x= TR > > >> that a local EID-to-RLOC mapping has been updated, so that the > > >> peering xTR uses LISP Control-Plane signaling message to retrieve a= > > >> fresh mapping. This can be used by an attacker to forge the map- > > >> versioning field of a LISP encapsulated header and force an excess= ive > > >> amount of signaling between xTRs that may overload them. > > >=20 > > > Can't I also set a super-high version number, thus gagging updates? > >=20 > > It doesn=E2=80=99t matter the value. All that matters is that it changed= and you should do to the mapping system to get an updated RLOC-set. >=20 > Hmm... S 5.1 of 6834-bis suggests that you can just discard it. Luigi - what do you think. Do we need rewording? Dino= From nobody Mon Oct 15 03:49:11 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EC4130E45 for ; Mon, 15 Oct 2018 03:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 7XrLdNsccELw for ; Mon, 15 Oct 2018 03:49:07 -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 69660130E3E for ; Mon, 15 Oct 2018 03:49:07 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id y11-v6so20718597wrd.4 for ; Mon, 15 Oct 2018 03:49:07 -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=zXzS5CHKGQcRmeta0ZxLw9RCG/JD0tYriYNCjQfRIus=; b=az4LXR2VvPBNVutOyZob+17RNC+GiMp2ajb/IKL3ZKKmjlRBX3eYr1hfbgJnB4ygUE CkvnvR9F/wGjeGbktLgPp/3LyFTnMwYO3affmao+lxg2uUJMIRrY4HXLUguIQDI3v2hY N4+pksus8l5XulIFMUr971HmVkNIFxSgfljzNtqzhN0XlP37nEZfo4Pmkt6vyu3xRJAB b0A/Syz928GIlZr12ARYV/g+Pq66HgH6+WcFVdhcSpVCXLge9iFhMaPSbidXokkDQv9D AfjFGWDw4wdT7G9MscssY2/GDuLPjLG1NEV54s+zIzpe1HquN3Tp1nHgGU5WSk4Nqj3o Ofwg== 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=zXzS5CHKGQcRmeta0ZxLw9RCG/JD0tYriYNCjQfRIus=; b=CU4xUpxripYX2Njm94PS9hE651TH59raJhkFlwMKd5ip0+9nca/uXobs5hJRy3/N/d WOApgU09CX0kHDQve2qXSX8vcpgu1bNuc5ly/cWD/gU4QmamuMtpLCLT+61ZzGb8nhIH CDt7ZNq7YIu3De67Aww1b27Nr5nyQx+LP9dtcJo9exwQW+kiVcE2j1DZeUwq+sRNNQdO yEnt2ua3qQ9ihgm25TVYzVTrkts/p7+bgRoer3lFxezR5UbhPOcObCo2JD1VyA+Ndf4n QRB5dEJbJk777jsMVG7fAlWEctYL+QEeXBTjQ5WiNSmffIuMZs6txZEEuRtO7wpleSjj n5qA== X-Gm-Message-State: ABuFfogTzrM3xRXEh/bSEsaTuDDd7Kq6kPRkYifcjsmfxNProVDcZNfi dIVCDKSj8B1Ns0bQAMYDd0FnZw== X-Google-Smtp-Source: ACcGV63UZhNmODCkk6o8Hqkia5lTUZAL2UZzQEkW3LN16sQFv/1ANWS2xpex/tOxMct/aYsKVKClow== X-Received: by 2002:a5d:698b:: with SMTP id g11-v6mr14939138wru.159.1539600545761; Mon, 15 Oct 2018 03:49:05 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:a9ce:7790:e4b6:8331? ([2001:660:330f:a4:a9ce:7790:e4b6:8331]) by smtp.gmail.com with ESMTPSA id h64-v6sm7627317wmh.27.2018.10.15.03.49.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Oct 2018 03:49:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Luigi Iannone In-Reply-To: <74F9CFAD-6C2E-4BDB-A56B-0186789EE058@gmail.com> Date: Mon, 15 Oct 2018 12:49:01 +0200 Cc: Eric Rescorla , Benjamin Kaduk , IESG , draft-ietf-lisp-rfc6830bis@ietf.org, lisp-chairs@ietf.org, albert.cabellos@gmail.com, "BRUNGARD, DEBORAH A" , fmaino@cisco.com, "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: References: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> <74F9CFAD-6C2E-4BDB-A56B-0186789EE058@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 10:49:10 -0000 Hi, > On 15 Oct 2018, at 04:20, Dino Farinacci wrote: >=20 >>> Well this is true, but 6833bis discusses RLOC-reachability and there >>> is a RLOC-probe cache that will tell the ITR when it last heard from >>> the RLOC. >>=20 >> Just to be clear, it's not "last heard from" that you need, but >> rather "last verifiably responded". >=20 > Right agree.=20 >=20 >>>> S 16. >>>>> Map-Versioning is a Data-Plane mechanism used to signal a = peering xTR >>>>> that a local EID-to-RLOC mapping has been updated, so that the >>>>> peering xTR uses LISP Control-Plane signaling message to = retrieve a >>>>> fresh mapping. This can be used by an attacker to forge the = map- >>>>> versioning field of a LISP encapsulated header and force an = excessive >>>>> amount of signaling between xTRs that may overload them. >>>>=20 >>>> Can't I also set a super-high version number, thus gagging updates? >>>=20 >>> It doesn=E2=80=99t matter the value. All that matters is that it = changed and you should do to the mapping system to get an updated = RLOC-set. >>=20 >> Hmm... S 5.1 of 6834-bis suggests that you can just discard it. This is true if we talk about the destination version number (S5.1 = 6834bis). If you receive a LISP packet carrying a map version number that is = higher that what you registered in the map system then there is ana = issue with the packet. Best option is to discard it. Different think is about source version number. If I receive a packet = with a source Map-Version number higher (does not matter how much = higher, just higher) than the version I have stored in my cache, then I = need to check with the mapping system whether something has really = changed, hence I send a Map-Request. This last action can generate the = attack described above. Concerning the text it self, I think is OK. Or you guys see something = missing or not clearly stated? Ciao L. =20 >=20 > Luigi - what do you think. Do we need rewording? >=20 > Dino From nobody Mon Oct 15 06:14: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 3B8BB130DFB for ; Mon, 15 Oct 2018 06:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNzVOFpnzvTu for ; Mon, 15 Oct 2018 06:13:59 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 DF70D130E62 for ; Mon, 15 Oct 2018 06:13:56 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id n14-v6so2180283lfe.6 for ; Mon, 15 Oct 2018 06:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hu9WqeAccOSnP2LFt/TKBp97WrXjMlm1EPAG/A5B6Gs=; b=gvf0GQmq6zd9xwOL5jPwSCQ3jRL9l96qUsbXvGrVIgEf42obioQW4btFqGrtNXJ+GK Xcg99y1hpxUhLCBi4I5uyTuCTwLsQM6faBaG1R2yoqxTPA8Kg/gDo53YDI8ifU3/Zmri z8UyDE0tg7Cm6MG+A9xiRUlLZqv2CwkU5pJv5EAWRCbqsSmuecWaSnguNYnkNbCbJDCc Dn4Mk/gXUjvF/tsoYdyZXUYdX/tQCH+6g6sR1Mb82FltS1X+7GIwwMrPbV9KY/g88l/y OjOrQOACg4vkJfnECWbJ9BsPm4xp7NI7HMiIjFwcxVM3mY4yN1mzI7LxWU9Y1X3DA9IT W1jQ== 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=Hu9WqeAccOSnP2LFt/TKBp97WrXjMlm1EPAG/A5B6Gs=; b=VRx/2uA/pueEPKzA65J0D8nluroj++YjPkKJprc+2pa3a7d0jYlN2qfsCgOOzJjmt6 K7tuX6dOlLvvLrEf1Yjnn1XwCaJCVlzyEoTZkWddzR7NJ8phcZgGlzvCOxZkVw+XaOg6 Hpk9PBFg/zsRm07RvRJkj4iMi566pa5OUVbgCLVnQ5pxQHHWfo9zuXnNT4ZB0kxA+EB3 pEn2d1CFVNh8zmhq/PVQ8aOMmuHZuNdB7RcVZ74sWXdqPbMxN+Y6h4MvEsBvQETsp0l6 kknLPNpwwVQ7jjaWMbGe50/5exC392s+/4fny6w+dL3lLjLZiRa1Z/qs/AHcGrdHWtzy xcBg== X-Gm-Message-State: ABuFfoi7aP+nzbUsX2x0HzN12xY0CLyZ4LP0m0+yKINpN2VeBBk4gzYK rrklogZF2W0xnm7pZHHkrWAbPjyaLYJauCKU0bx1vQ== X-Google-Smtp-Source: ACcGV625DdZD3PKiAKDqU1Osg/RMCRS5wyBNfr0OH6Ofxn+nblyVNaKJX6eACfvnB9tntK/YE7iIZWAPlOOil4pWJxo= X-Received: by 2002:a19:3bcf:: with SMTP id d76-v6mr9482577lfl.126.1539609234978; Mon, 15 Oct 2018 06:13:54 -0700 (PDT) MIME-Version: 1.0 References: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> <74F9CFAD-6C2E-4BDB-A56B-0186789EE058@gmail.com> In-Reply-To: From: Eric Rescorla Date: Mon, 15 Oct 2018 06:13:17 -0700 Message-ID: To: Luigi Iannone Cc: Dino Farinacci , Benjamin Kaduk , IESG , draft-ietf-lisp-rfc6830bis@ietf.org, lisp-chairs@ietf.org, albert.cabellos@gmail.com, "BRUNGARD, DEBORAH A" , fmaino@cisco.com, "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="0000000000008b4c130578443512" Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 13:14:01 -0000 --0000000000008b4c130578443512 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 15, 2018 at 3:49 AM Luigi Iannone wrote: > Hi, > > > On 15 Oct 2018, at 04:20, Dino Farinacci wrote: > > > >>> Well this is true, but 6833bis discusses RLOC-reachability and there > >>> is a RLOC-probe cache that will tell the ITR when it last heard from > >>> the RLOC. > >> > >> Just to be clear, it's not "last heard from" that you need, but > >> rather "last verifiably responded". > > > > Right agree. > > > >>>> S 16. > >>>>> Map-Versioning is a Data-Plane mechanism used to signal a peering > xTR > >>>>> that a local EID-to-RLOC mapping has been updated, so that the > >>>>> peering xTR uses LISP Control-Plane signaling message to retrieve= a > >>>>> fresh mapping. This can be used by an attacker to forge the map- > >>>>> versioning field of a LISP encapsulated header and force an > excessive > >>>>> amount of signaling between xTRs that may overload them. > >>>> > >>>> Can't I also set a super-high version number, thus gagging updates? > >>> > >>> It doesn=E2=80=99t matter the value. All that matters is that it chan= ged and > you should do to the mapping system to get an updated RLOC-set. > >> > >> Hmm... S 5.1 of 6834-bis suggests that you can just discard it. > > This is true if we talk about the destination version number (S5.1 > 6834bis). > > If you receive a LISP packet carrying a map version number that is higher > that what you registered in the map system then there is ana issue with t= he > packet. Best option is to discard it. > > Different think is about source version number. If I receive a packet wit= h > a source Map-Version number higher (does not matter how much higher, just > higher) than the version I have stored in my cache, then I need to check > with the mapping system whether something has really changed, hence I sen= d > a Map-Request. This last action can generate the attack described above. > The issue is how you handle lower. Because if you discard lower numbers, then an attacker who can get you to accept a high-version can cause you to refuse future updates. -Ekr > Concerning the text it self, I think is OK. Or you guys see something > missing or not clearly stated? > > Ciao > > L. > > > > > > > Luigi - what do you think. Do we need rewording? > > > > Dino > > --0000000000008b4c130578443512 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Oct 15, 2018 at 3:49 AM Luigi Iannone <ggx@gigix.net> wrote:
Hi,<= br>
> On 15 Oct 2018, at 04:20, Dino Farinacci <farinacci@gmail.com> wrote:
>
>>> Well this is true, but 6833bis discusses RLOC-reachability and= there
>>> is a RLOC-probe cache that will tell the ITR when it last hear= d from
>>> the RLOC.
>>
>> Just to be clear, it's not "last heard from" that yo= u need, but
>> rather "last verifiably responded".
>
> Right agree.
>
>>>> S 16.
>>>>>=C2=A0 =C2=A0Map-Versioning is a Data-Plane mechanism u= sed to signal a peering xTR
>>>>>=C2=A0 =C2=A0that a local EID-to-RLOC mapping has been = updated, so that the
>>>>>=C2=A0 =C2=A0peering xTR uses LISP Control-Plane signal= ing message to retrieve a
>>>>>=C2=A0 =C2=A0fresh mapping.=C2=A0 This can be used by a= n attacker to forge the map-
>>>>>=C2=A0 =C2=A0versioning field of a LISP encapsulated he= ader and force an excessive
>>>>>=C2=A0 =C2=A0amount of signaling between xTRs that may = overload them.
>>>>
>>>> Can't I also set a super-high version number, thus gag= ging updates?
>>>
>>> It doesn=E2=80=99t matter the value. All that matters is that = it changed and you should do to the mapping system to get an updated RLOC-s= et.
>>
>> Hmm... S 5.1 of 6834-bis suggests that you can just discard it.
This is true if we talk about the destination version number (S5.1 6834bis)= .

If you receive a LISP packet carrying a map version number that is higher t= hat what you registered in the map system then there is ana issue with the = packet. Best option is to discard it.

Different think is about source version number. If I receive a packet with = a source Map-Version number higher (does not matter how much higher, just h= igher) than the version I have stored in my cache, then I need to check wit= h the mapping system whether something has really changed, hence I send a M= ap-Request. This last action can generate the attack described above.

The issue is how you handle lower.

Because if you discard lower numbers, then an attacker who = can get you to accept a high-version can cause you to refuse future updates= .

-Ekr


Concerning the text it self, I think is OK. Or you guys see something missi= ng or not clearly stated?

Ciao

L.



>
> Luigi - what do you think. Do we need rewording?
>
> Dino

--0000000000008b4c130578443512-- From nobody Mon Oct 15 08:10: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 C4F8B130E8D for ; Mon, 15 Oct 2018 08:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Idg61zT2bqP6 for ; Mon, 15 Oct 2018 08:10:25 -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 2FBEB130E92 for ; Mon, 15 Oct 2018 08:10:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EBEA8442F5A for ; Mon, 15 Oct 2018 08:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1539616224; bh=u1sSCCBXYldW4anSgyfUzqFxfa7EfzamoWLodUmifN8=; h=To:From:Subject:Date:From; b=N9XZFymZ6PoOo90zYoThvRKcKubpWBmU5TVS9i/VZNjAs7MzeMkDv1dLjqFiBGPZC /6fimAx0rUZW31XL1kQWp0hQR5pqLcg3buERos/clWhwWO2qP2+L8+zUT7yYuItWRQ 0LnPGXU/6YRWfebDqNi5Ta+qWD/LIJEs8voCRqnU= 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 8EF37442F55 for ; Mon, 15 Oct 2018 08:10:24 -0700 (PDT) To: "lisp@ietf.org" From: "Joel M. Halpern" Message-ID: <4f777335-7941-49c6-2dd2-75bc6964f5ea@joelhalpern.com> Date: Mon, 15 Oct 2018 11:10:23 -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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] Drafts; and expiration X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 15:10:27 -0000 Reminder that the draft cutoff is Monday. Particularly for expiring drafts which are still in the WG but needed for the advancments process (.e.g LISP-SEC) please refresh before the deadline. Thank you, Joel From nobody Mon Oct 15 08:18: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 310DA1294D0 for ; Mon, 15 Oct 2018 08:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V1e0j9JSHcE for ; Mon, 15 Oct 2018 08:18:24 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD460130E84 for ; Mon, 15 Oct 2018 08:18:23 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id a13-v6so21814183wrt.5 for ; Mon, 15 Oct 2018 08:18:23 -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=mgOBXghonsZnVw9H1979shRg+fZwD6Jior46usGdex8=; b=M+xDY+n1INn/TCYmzfjOWjbTmdpZED3TOwKSFxO4Ph1+fcnJPAwuzpjNMF8IjOvqwc wLGoxoM3dUyUxFtrQ6G8Q3lrbd3hqLrM+okv6zw46RKoYqmh7qc73GGU1pg49jcja9/N l1msdQSQSrDu1AIv3PgNbNk/Lu2gUH6d9Xm0h5xhsDnoY5QHDlj/mnNqgyF0i/lUiNRZ kQEXhwgVZ98iMpZ/n3uHAzV8K/zdilM+p/Bhd5CF0BRe2cXs+VuHAwqIK1o2F2eMUSid kK5I7xkdyehxYgGQGrw0UBjEGswPjZRNbNapI5raDXGy477oZOhBbq+2rH0hDrUDNCG9 u8OQ== 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=mgOBXghonsZnVw9H1979shRg+fZwD6Jior46usGdex8=; b=cS7Tm1KSNOOFn8jcVU9f9QTV5Ogg7wdJFBUk/290AU4zT+6ouFcdPgwdTNMjFieESk DMuNfNE+UD+9fSnE8zc77dh0l4Ta2pFZ+pok9CKz5g9gPOS1jaFJatSqd3NgKiSwVLec IrsR9/7QHckk6Virc3P0e0ZEhPP7WJF7c4lbHlQO0/ZS+ONrypLIu/w2wxKqW/NQyZRb SlZaWXai/VKJF/ln49ntccsXqNn5W1VjQ+oapkvV+sFKmI6/t42U71f7adjGBJIy+LIJ dAr/NWgXaALpOQNNmOt8cYGzUj8T2ykTQhLQgUMud3IIRLcV/h8tFJoLGHYlynFX8s8U L5yQ== X-Gm-Message-State: ABuFfoiZcJYhspzEQ7kEiZxr5jSrrpUW/lwNu9Oa2/BKO/FHLLiM3stt 0mLzv/L8/wzYVhzMhwh1qt0mOg== X-Google-Smtp-Source: ACcGV62VRWGlO7hjQCNsQTV1+8ZzIbi1b7o9YC9odL44w8gjoLI0w6Fx9e4mTqTMXaO2X4SM7TPd4A== X-Received: by 2002:a5d:620b:: with SMTP id y11-v6mr14806785wru.105.1539616702192; Mon, 15 Oct 2018 08:18:22 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:fda3:d27a:939b:2383? ([2001:660:330f:a4:fda3:d27a:939b:2383]) by smtp.gmail.com with ESMTPSA id t3-v6sm9091689wru.47.2018.10.15.08.18.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Oct 2018 08:18:20 -0700 (PDT) From: Luigi Iannone Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AAE46E1B-BF17-4BD5-8338-71553C0E946A" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 15 Oct 2018 17:18:18 +0200 In-Reply-To: Cc: Dino Farinacci , Benjamin Kaduk , IESG , draft-ietf-lisp-rfc6830bis@ietf.org, lisp-chairs@ietf.org, albert.cabellos@gmail.com, "BRUNGARD, DEBORAH A" , fmaino@cisco.com, "lisp@ietf.org list" To: Eric Rescorla References: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> <74F9CFAD-6C2E-4BDB-A56B-0186789EE058@gmail.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 15:18:27 -0000 --Apple-Mail=_AAE46E1B-BF17-4BD5-8338-71553C0E946A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Oct 2018, at 15:13, Eric Rescorla wrote: >=20 >=20 >=20 > On Mon, Oct 15, 2018 at 3:49 AM Luigi Iannone > wrote: > Hi, >=20 > > On 15 Oct 2018, at 04:20, Dino Farinacci > wrote: > >=20 > >>> Well this is true, but 6833bis discusses RLOC-reachability and = there > >>> is a RLOC-probe cache that will tell the ITR when it last heard = from > >>> the RLOC. > >>=20 > >> Just to be clear, it's not "last heard from" that you need, but > >> rather "last verifiably responded". > >=20 > > Right agree.=20 > >=20 > >>>> S 16. > >>>>> Map-Versioning is a Data-Plane mechanism used to signal a = peering xTR > >>>>> that a local EID-to-RLOC mapping has been updated, so that the > >>>>> peering xTR uses LISP Control-Plane signaling message to = retrieve a > >>>>> fresh mapping. This can be used by an attacker to forge the = map- > >>>>> versioning field of a LISP encapsulated header and force an = excessive > >>>>> amount of signaling between xTRs that may overload them. > >>>>=20 > >>>> Can't I also set a super-high version number, thus gagging = updates? > >>>=20 > >>> It doesn=E2=80=99t matter the value. All that matters is that it = changed and you should do to the mapping system to get an updated = RLOC-set. > >>=20 > >> Hmm... S 5.1 of 6834-bis suggests that you can just discard it. >=20 > This is true if we talk about the destination version number (S5.1 = 6834bis). >=20 > If you receive a LISP packet carrying a map version number that is = higher that what you registered in the map system then there is ana = issue with the packet. Best option is to discard it. >=20 > Different think is about source version number. If I receive a packet = with a source Map-Version number higher (does not matter how much = higher, just higher) than the version I have stored in my cache, then I = need to check with the mapping system whether something has really = changed, hence I send a Map-Request. This last action can generate the = attack described above. >=20 > The issue is how you handle lower. >=20 Interesting. I didn=E2=80=99t think about this case=E2=80=A6. > Because if you discard lower numbers, then an attacker who can get you = to accept a high-version can cause you to refuse future updates. True.=20 This all depends on the mapping system actually.=20 If somehow you can get into the control plane and make me think the = version number is higher, than yes. At that point there is a bigger problem, if I could get an hold on the = control plane I would do more than just tempering versions number=E2=80=A6= But this is a different story. What I suggest is that I add specific text about this in the 6834bis = document. Do you agree? I=E2=80=99ll send you the text later on. Ciao L. >=20 > -Ekr >=20 >=20 > Concerning the text it self, I think is OK. Or you guys see something = missing or not clearly stated? >=20 > Ciao >=20 > L. >=20 >=20 >=20 > >=20 > > Luigi - what do you think. Do we need rewording? > >=20 > > Dino --Apple-Mail=_AAE46E1B-BF17-4BD5-8338-71553C0E946A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 15 Oct 2018, at 15:13, Eric Rescorla <ekr@rtfm.com> = wrote:



On Mon, Oct 15, 2018 = at 3:49 AM Luigi Iannone <ggx@gigix.net> wrote:
Hi,

> On 15 Oct 2018, at 04:20, Dino Farinacci <farinacci@gmail.com> wrote:
> 
>>> = Well this is true, but 6833bis discusses RLOC-reachability and there
>>> is a RLOC-probe cache that will tell the ITR = when it last heard from
>>> the RLOC.
>> 
>> Just to be clear, it's not "last heard from" that = you need, but
>> rather "last verifiably = responded".
> 
> Right = agree. 
> 
>>>> S 16.
>>>>> =  Map-Versioning is a Data-Plane mechanism used to signal a peering = xTR
>>>>>   that a local = EID-to-RLOC mapping has been updated, so that the
>>>>>   peering xTR uses LISP = Control-Plane signaling message to retrieve a
>>>>>   fresh mapping.  This = can be used by an attacker to forge the map-
>>>>>   versioning field of a LISP = encapsulated header and force an excessive
>>>>>   amount of signaling between = xTRs that may overload them.
>>>> 
>>>> Can't I also set a super-high version = number, thus gagging updates?
>>> 
>>> = It doesn=E2=80=99t matter the value. All that matters is that it changed = and you should do to the mapping system to get an updated RLOC-set.
>> 
>> Hmm... S 5.1 of 6834-bis suggests that you can just = discard it.

This is true if we talk about = the destination version number (S5.1 6834bis).

If you receive a LISP packet carrying a map version number = that is higher that what you registered in the map system then there is = ana issue with the packet. Best option is to discard it.
Different think is about source version number. If I receive = a packet with a source Map-Version number higher (does not matter how = much higher, just higher) than the version I have stored in my cache, = then I need to check with the mapping system whether something has = really changed, hence I send a Map-Request. This last action can = generate the attack described above.

The issue is how you = handle lower.


Interesting. I didn=E2=80=99t think about this = case=E2=80=A6.



Because if you discard lower numbers, then an attacker who = can get you to accept a high-version can cause you to refuse future = updates.

True. 
This all depends on the = mapping system actually. 
If somehow you can get into the = control plane and make me think the version number is higher, than = yes.
At that point there is a bigger problem, if I could get = an hold on the control plane I would do more than just tempering = versions number=E2=80=A6
But this is a different = story.

What I suggest is that I add = specific text about this in the 6834bis document. Do you = agree?

I=E2=80=99ll send you the = text later on.

Ciao

L.







-Ekr


Concerning the = text it self, I think is OK. Or you guys see something missing or not = clearly stated?

Ciao

L.



> 
> Luigi - what do you think. Do we need rewording?
> 
> = Dino

= --Apple-Mail=_AAE46E1B-BF17-4BD5-8338-71553C0E946A-- From nobody Mon Oct 15 08:57: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 23A88130EA2 for ; Mon, 15 Oct 2018 08:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 k4745IKEERc8 for ; Mon, 15 Oct 2018 08:57:55 -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 F0B3D130E9C for ; Mon, 15 Oct 2018 08:57:54 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id g2-v6so9354585pgu.11 for ; Mon, 15 Oct 2018 08:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:to; bh=JOA9F7ncIBaqoVSFtNJeASC7Dx2rtzk1zDBI4SSDA7A=; b=bAX898BUeL5cEf1qyVdG/Sc4o1YlW81nKdI3JgagoPLASoq1+TmLKY71Od8MtZJElx Nhln/X6m6JYxd4RCJNB6+62KZvPZHhnZUXYeGk5n3hXOVDYT1kvEwSYdaMaAP+F2hGZZ EouJPJAXdpkIWMRBP0gE42+pnt1F9i5tcNvrPxAqOwXnF3i9sbxIWnFuG+rTx/3w1DF0 tjDipspVX9Lrl/9nrDSl4VIoJrBqtYxa1FzpOuxYdE40kbB95wM16L5pz1SsbTPM4peg YIpO7NQB2fHvjpMrzMvoz0leC3ph77FlF8qX8s/bBqie4L/BJGarn7VQD5cffrISJcPQ iN4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:to; bh=JOA9F7ncIBaqoVSFtNJeASC7Dx2rtzk1zDBI4SSDA7A=; b=hlE1C6ChGtSN7ZFORmtLFUVZejR0duY6BuyG6nEnir5vOEtI9derc9me747ngyXYEQ zd3SG6roGFYtABsgeoiV2MaKfuB0PKG2N8HNhjZiUQeLGpW+WhponG2R2fn9d3UhJ7K3 hXh0SIn2u5BY9r5x/8gjjWjO+LVj9bR6WWJ533EmHRLmY9ynz52kBuurgM3nsRZt/hPH UyX09EdwJoP0y1bpPTbETX3b7J4oB51rnyabz2vv3mnWmXjNbgbNL9+An++zIcmpfIOZ BZHC5iR7VvXm9kgP1jeY74B8paasz0XwHG4x0VLPEFFrA14gG4Ef1R063flsGvHb23B1 XeDw== X-Gm-Message-State: ABuFfoiwIeUI2kEz1h3Smd8n13D/gAul/b2cNx0a7jthGRoU5ZTk2xEw dGL5mV4q38S9d/3faE1ZROWY3LaX X-Google-Smtp-Source: ACcGV6031CgEjDnH5Evh6p7oyRG5kiudN63yRta6t1kMTx3bfakxT45G2Qq1q9takfDMYxHYadoE+Q== X-Received: by 2002:a62:1112:: with SMTP id z18-v6mr18154993pfi.200.1539619074242; Mon, 15 Oct 2018 08:57:54 -0700 (PDT) Received: from ?IPv6:2600:380:4753:dd71:c538:5a0a:f8c1:fe72? ([2600:380:4753:dd71:c538:5a0a:f8c1:fe72]) by smtp.gmail.com with ESMTPSA id f193-v6sm16223050pfc.74.2018.10.15.08.57.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Oct 2018 08:57:53 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/alternative; boundary=Apple-Mail-3199F2CA-75A0-4D15-9FEE-A7D3A01222C9 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Mon, 15 Oct 2018 08:57:11 -0700 Message-Id: <16A24153-46B4-43F6-BC6D-2CF4B67D81BF@gmail.com> References: <153960373110.13375.16416581333272540617.idtracker@ietfa.amsl.com> To: lisp@ietf.org X-Mailer: iPhone Mail (16A404) Archived-At: Subject: [lisp] Fwd: Expiration impending: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 15:57:57 -0000 --Apple-Mail-3199F2CA-75A0-4D15-9FEE-A7D3A01222C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I would like to request a WG last call for this document.=20 Dino Begin forwarded message: > Resent-From: > From: IETF Secretariat > Date: October 15, 2018 at 4:42:11 AM PDT > Resent-To: farinacci@gmail.com, padma@huawei.com, Wassim.Haddad@ericsson.c= om > To: > Cc: lisp-chairs@ietf.org, db3546@att.com > Subject: Expiration impending: >=20 > The following draft will expire soon: >=20 > Name: draft-ietf-lisp-eid-anonymity > Title: LISP EID Anonymity > State: I-D Exists > Expires: 2018-10-25 (in 1 week, 2 days) >=20 --Apple-Mail-3199F2CA-75A0-4D15-9FEE-A7D3A01222C9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I w= ould like to request a WG last call for this document. 

Dino

Begin forwarded message:
Resent-From: <alias-bounces@ietf.org>
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Date: October 15, 2= 018 at 4:42:11 AM PDT
Resent-To: farinacci@gmail.com, padma@hua= wei.com, Wassim.Haddad@eri= csson.com
To: <draft-ietf-lisp-eid-anonymity@ietf.org>
Cc: <= a href=3D"mailto:lisp-chairs@ietf.org">lisp-chairs@ietf.org, db3546@att.com
Subject: Expiration i= mpending: <draft-ietf-lisp-eid-anonymity-02.txt>

The following draf= t will expire soon:

Name:    = ; draft-ietf-lisp-eid-anonymity
Title:   &nbs= p;LISP EID Anonymity
State:    I-D Exists
Expires:  2018-10-25 (in 1 week, 2 days)<= br>
= --Apple-Mail-3199F2CA-75A0-4D15-9FEE-A7D3A01222C9-- From nobody Mon Oct 15 11:05:46 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263E0130DC5; Mon, 15 Oct 2018 11:05: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 u6KyjBfguHj8; Mon, 15 Oct 2018 11:05:38 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 0577D127133; Mon, 15 Oct 2018 11:05:38 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id u6-v6so6941415plz.4; Mon, 15 Oct 2018 11:05: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=oHMAn3ZL/ZHH/w5YI/CI9ir/KexRdUF+Ip8ReMpBM8Q=; b=uKWTuYNk7HjmZ5LiSq1sB2b/ZrTPumGb4tsNoW4LTIkVhLwLdeJGA4HBXPv4LbNIFz IHb6jWPouCQaqGxgMB9YHe6dPRXhcRmrYilOetSkPcS7lC/ichuKAXfwehEAjjvTH8LG gTMj1w+biN44kZvlHyp9s8z89I+9nrIVyGTi1qv7cVXiQeZdfAAqFYpVzcTQKlcUtsSd IRrjQXyNxp/AY1x2VPvLB3vK9qel41ViUlI5k4WYoLYa9Klbz3ZnMf4AX8//++JILa9P /wwWnn/XZFRtpX9jGfLZmWYimFKaSbCY/HNabWdQgmyQ1gA1g60Bj0a8FnR6gIWqN9Pe fdjA== 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=oHMAn3ZL/ZHH/w5YI/CI9ir/KexRdUF+Ip8ReMpBM8Q=; b=stKNT/+MRg+GGagCevj0h3ySq8mUcIyhQOnHjTsyx/p9ieBY8J7mrcBfdV63teLrEh 5MQf+Sh9pfxhhxgGXno4QxiEMv/AonGPVF56E6/0fFEuOGzoFmHxGYOdr3Q/8nydknsJ dSD/vsDl9sv88usFUEXzWaWi9FviPMnIong0RFhZmfr/pX0F+6HT0hHHW1QFDCX+HHZv V/tgUleTTkEzxhoekon15sgO0204avP3pzpSIuISOIyducOFPs/z4khSkVVwGPXG+EQ9 tAE4O0VKMW94srt/Pg29I4mrpL2r99Y85C5arOnG4MAMBZqKabszBw4zX7wMkJ4zwiqZ 0Lhg== X-Gm-Message-State: ABuFfoij4kQXS23db5Sww9qcCuhXRs7Crgvqsywd4qDNkzCg1R5dGtD1 FsDHqR19/CRwnnCXUstVvH0= X-Google-Smtp-Source: ACcGV61j/ezsltR6Czb608Ux57AQ3BQ1SzDKUhDzDKjHeMKo/A1WWsd8y6ggxnbdBU9672ogAQL0uQ== X-Received: by 2002:a17:902:6a:: with SMTP id 97-v6mr17296534pla.276.1539626737539; Mon, 15 Oct 2018 11:05:37 -0700 (PDT) Received: from [10.31.79.198] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id v83-v6sm23006846pfa.103.2018.10.15.11.05.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Oct 2018 11:05:36 -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: Mon, 15 Oct 2018 11:05:35 -0700 Cc: Eric Rescorla , Benjamin Kaduk , IESG , draft-ietf-lisp-rfc6830bis@ietf.org, lisp-chairs@ietf.org, Albert Cabellos , "BRUNGARD, DEBORAH A" , Fabio Maino , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <23574088-2D53-4A96-95F6-84FF104D6F57@gmail.com> References: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> <74F9CFAD-6C2E-4BDB-A56B-0186789EE058@gmail.com> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 18:05:39 -0000 > What I suggest is that I add specific text about this in the 6834bis = document. Do you agree? Agree. Dino= From nobody Mon Oct 15 12:05:32 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 1D62F124C04; Mon, 15 Oct 2018 12:05:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153963032608.18616.17376175104684566615@ietfa.amsl.com> Date: Mon, 15 Oct 2018 12:05:26 -0700 Archived-At: Subject: [lisp] I-D Action: draft-farinacci-lisp-geo-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 19:05:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : LISP Geo-Coordinate Use-Cases Author : Dino Farinacci Filename : draft-farinacci-lisp-geo-06.txt Pages : 10 Date : 2018-10-15 Abstract: This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-farinacci-lisp-geo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-farinacci-lisp-geo-06 https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-geo-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-farinacci-lisp-geo-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 15 12:09:03 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 242C5124C04; Mon, 15 Oct 2018 12:08:55 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153963053509.18754.9898091903394739092@ietfa.amsl.com> Date: Mon, 15 Oct 2018 12:08:55 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-te-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 19:08:55 -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 Traffic Engineering Use-Cases Authors : Dino Farinacci Michael Kowal Parantap Lahiri Filename : draft-ietf-lisp-te-03.txt Pages : 17 Date : 2018-10-15 Abstract: This document describes how LISP reencapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-te/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-te-03 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-te-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-te-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 15 12:12:21 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 459CE128BAC; Mon, 15 Oct 2018 12:12:20 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153963074023.29971.1326106013004801926@ietfa.amsl.com> Date: Mon, 15 Oct 2018 12:12:20 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-eid-anonymity-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 19:12:21 -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 EID Anonymity Authors : Dino Farinacci Padma Pillay-Esnault Wassim Haddad Filename : draft-ietf-lisp-eid-anonymity-03.txt Pages : 10 Date : 2018-10-15 Abstract: This specification will describe how ephemeral LISP EIDs can be used to create source anonymity. The idea makes use of frequently changing EIDs much like how a credit-card system uses a different credit-card numbers for each transaction. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-anonymity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-eid-anonymity-03 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-anonymity-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-eid-anonymity-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 18 14:24:13 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B573A12F1AC; Thu, 18 Oct 2018 14:24:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153989784670.22172.17482815240522987929@ietfa.amsl.com> Date: Thu, 18 Oct 2018 14:24:06 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-yang-09.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 21:24:07 -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 YANG Model Authors : Vina Ermagan Alberto Rodriguez-Natal Florin Coras Carl Moberg Reshad Rahman Albert Cabellos-Aparicio Fabio Maino Filename : draft-ietf-lisp-yang-09.txt Pages : 77 Date : 2018-10-18 Abstract: This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-yang-09 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-yang-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-yang-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 18 21:03:39 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 822E91200D7; Thu, 18 Oct 2018 21:03:31 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <153992181151.22217.1222806030007592103@ietfa.amsl.com> Date: Thu, 18 Oct 2018 21:03:31 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-sec-16.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 04:03:32 -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-Security (LISP-SEC) Authors : Fabio Maino Vina Ermagan Albert Cabellos Damien Saucez Filename : draft-ietf-lisp-sec-16.txt Pages : 23 Date : 2018-10-18 Abstract: This memo specifies LISP-SEC, a set of security mechanisms that provides origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-sec-16 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-sec-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-sec-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 Fri Oct 19 12:01: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 21E1513109F; Fri, 19 Oct 2018 11:56:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: lisp@ietf.org, db3546@att.com X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997539505.6592.14309894767835651081.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:35 -0700 Archived-At: Subject: [lisp] lisp - Requested session has been scheduled for IETF 103 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:56:44 -0000 Dear Luigi Iannone, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lisp Session 1 (2:00 requested) Monday, 5 November 2018, Morning Session I 0900-1100 Room Name: Boromphimarn 3 size: 50 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/lisp.ics Request Information: --------------------------------------------------------- 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 Sun Oct 21 18:53: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 B8C71120072; Sun, 21 Oct 2018 18:52:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <154017317770.10776.4553468709213818064@ietfa.amsl.com> Date: Sun, 21 Oct 2018 18:52:57 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-25.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 01:52:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : The Locator/ID Separation Protocol (LISP) Authors : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Albert Cabellos Filename : draft-ietf-lisp-rfc6830bis-25.txt Pages : 46 Date : 2018-10-21 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-25 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-25 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 Sun Oct 21 18:53:56 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 B5E20120072; Sun, 21 Oct 2018 18:53:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <154017323472.10792.14986855431180458829@ietfa.amsl.com> Date: Sun, 21 Oct 2018 18:53:54 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-19.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 01:53:55 -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-19.txt Pages : 58 Date : 2018-10-21 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, connecting EID addressable nodes of a LISP site, their implementation and operational complexity reduces the overall cost and effort of deploying LISP. This document obsoletes RFC 6830 and 6833. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-19 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 22 12:52:34 2018 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A628B12D7EA; Mon, 22 Oct 2018 12:52:31 -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.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <154023795166.13484.11274467177737435027@ietfa.amsl.com> Date: Mon, 22 Oct 2018 12:52:31 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-eid-anonymity-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 19:52:32 -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 EID Anonymity Authors : Dino Farinacci Padma Pillay-Esnault Wassim Haddad Filename : draft-ietf-lisp-eid-anonymity-04.txt Pages : 10 Date : 2018-10-22 Abstract: This specification will describe how ephemeral LISP EIDs can be used to create source anonymity. The idea makes use of frequently changing EIDs much like how a credit-card system uses a different credit-card numbers for each transaction. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-anonymity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-eid-anonymity-04 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-anonymity-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-eid-anonymity-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 23 00:38:03 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387C8130DDB for ; Tue, 23 Oct 2018 00:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7r7zi430vzD for ; Tue, 23 Oct 2018 00:38:00 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC24130EEF for ; Tue, 23 Oct 2018 00:37:59 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 42fQGY65hmz7tZs for ; Tue, 23 Oct 2018 09:37:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 42fQGY5G3Sz2xC0 for ; Tue, 23 Oct 2018 09:37:57 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0415.000; Tue, 23 Oct 2018 09:37:57 +0200 From: To: "lisp@ietf.org" Thread-Topic: "Update RFC6833bis" header when a meaning is associated with a reserved bit Thread-Index: AdRqo05oOv5e0+oORKOieqidjTPDSw== Date: Tue, 23 Oct 2018 07:37:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E0199E9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302E0199E9OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [lisp] "Update RFC6833bis" header when a meaning is associated with a reserved bit X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 07:38:02 -0000 --_000_787AE7BB302AE849A7480A190F8B93302E0199E9OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, In a discussion among the authors of draft-ietf-lisp-pubsub, we discussed w= hether an "Update RFC6833bis" header is needed to be added to the draft. The rationale is the -bis document states, for example, the following: R: This reserved bit MUST be set to 0 on transmit and MUST be ignored on receipt. So, obviously this behavior is to be updated each time a meaning is associa= ted with an unassigned/reserved bit, otherwise an extension will be broken = if that part of the -bis spec is not touched on. An update header is therefore more than appropriate....nevertheless, it see= ms that some old RFCs didn't follow this approach (e.g., RFC8061). The question we have for the WG is which option do we need to follow: updat= e or no update? FWIW, a similar action is needed for other documents, e.g., draft-ietf-lisp= -mn. Thank you. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93302E0199E9OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

In a discussion among the authors of draft-= ietf-lisp-pubsub, we discussed whether an "Update RFC6833bis" hea= der is needed to be added to the draft.

 

The rationale is the -bis document states, for example, the following:

 

   R: This reserved bit MUST be s= et to 0 on transmit and MUST be ignored

      on receipt.<= o:p>

 

So, obviously this behavior is = to be updated each time a meaning is associated with an unassigned/reserved= bit, otherwise an extension will be broken if that part of the –bis spec is not touched on.

 

An update header is therefore more than app= ropriate….nevertheless, it seems that some old RFCs didn’t foll= ow this approach (e.g., RFC8061).

 

The question we have for the WG is which op= tion do we need to follow: update or no update?

 

FWIW, a similar action is needed for other = documents, e.g., draft-ietf-lisp-mn.

 

Thank you.

 

Cheers,

Med

 

--_000_787AE7BB302AE849A7480A190F8B93302E0199E9OPEXCLILMA3corp_-- From nobody Tue Oct 23 00:44: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 8BBDF130E08 for ; Tue, 23 Oct 2018 00:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP-y8Js8ZduP for ; Tue, 23 Oct 2018 00:44:53 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E58130DF1 for ; Tue, 23 Oct 2018 00:44:52 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 42fQQW4H0vz8tVb for ; Tue, 23 Oct 2018 09:44:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 42fQQW3XYlz2xC2 for ; Tue, 23 Oct 2018 09:44:51 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0415.000; Tue, 23 Oct 2018 09:44:51 +0200 From: To: "lisp@ietf.org" Thread-Topic: draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned Thread-Index: AdRqpEd10cZL+uOwTGaba/yk/wtayQ== Date: Tue, 23 Oct 2018 07:44:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302E019A18OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 07:44:55 -0000 --_000_787AE7BB302AE849A7480A190F8B93302E019A18OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dino, all, Apologies for raising this late easy to fix comment: RFC8126 says the following: Unassigned: Not currently assigned, and available for assignment ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ via documented procedures. While it's generally clear that any values that are not registered are unassigned and available for assignment, it is sometimes useful to explicitly specify that situation. Note that this is distinctly different from "Reserved". Reserved: Not assigned and not available for assignment. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Reserved values are held for special uses, such as to extend the namespace when it becomes exhausted. "Reserved" is also sometimes used to designate values that had been assigned but are no longer in use, keeping them set aside as long as other unassigned values are available. Note that this is distinctly different from "Unassigned". This is well handled in Section 5.1, but not in other sections which are us= ing Reserved instead of Unassigned as per RFC8126. It would be appropriate to update the text accordingly. Thank you. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93302E019A18OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dino, all,

 

Apologies for raising this late easy to fix= comment:

 

RFC8126 says the following:

 

      Unassigned:  =
Not currently assigned, and available for assignment

        &=
nbsp;           &nbs=
p;            &=
nbsp;         ^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^


        &=
nbsp;   via documented procedures.  While it's generally cle=
ar that


        &=
nbsp;   any values that are not registered are unassigned and


        &=
nbsp;   available for assignment, it is sometimes useful to<=
/o:p>


        &=
nbsp;   explicitly specify that situation.  Note that this i=
s


        &=
nbsp;   distinctly different from "Reserved".


 


      Reserved:  No=
t assigned and not available for assignment.


        &=
nbsp;           &nbs=
p;             =
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


        &=
nbsp;   Reserved values are held for special uses, such as to ext=
end


        &=
nbsp;   the namespace when it becomes exhausted.  "Rese=
rved" is also


        &=
nbsp;   sometimes used to designate values that had been assigned=



        &=
nbsp;   but are no longer in use, keeping them set aside as long =
as


        &=
nbsp;   other unassigned values are available.  Note that th=
is is


        &=
nbsp;   distinctly different from "Unassigned".


 


This is well handled in Section 5.1, but no=
t in other sections which are using Reserved instead of Unassigned as per R=
FC8126.



 


It would be appropriate to update the text =
accordingly. Thank you.



 


Cheers,


Med
--_000_787AE7BB302AE849A7480A190F8B93302E019A18OPEXCLILMA3corp_-- From nobody Tue Oct 23 06:30:38 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784AB130FC7 for ; Tue, 23 Oct 2018 06:30:31 -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 qUPxMf7CF2-F for ; Tue, 23 Oct 2018 06:30:29 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60893131052 for ; Tue, 23 Oct 2018 06:30:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 03DCE2808EC; Tue, 23 Oct 2018 06:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1540301428; bh=T/xxw1sg9ohBLC/pwrFe6eIIgL67Dh657hoUcUoSv+E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Td+RPMRVTrqpnphhCJFQn+NBUcP8UznSs/IlYKtuEd4ddxuyXA3r09+j1sonhQHVn Y53gedaLR9MV7/XnWzzNh4H5MHNlPKPg31M2FRnCdZo5KSMwugpFCD5wYhOiIdSETA 9YH3uFMfQm9Ur1yIxFFvGt8pHpKLHQdQVM8wvbBg= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 806322808B9; Tue, 23 Oct 2018 06:30:27 -0700 (PDT) To: mohamed.boucadair@orange.com, "lisp@ietf.org" References: <787AE7BB302AE849A7480A190F8B93302E0199E9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: Date: Tue, 23 Oct 2018 09:30:26 -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: <787AE7BB302AE849A7480A190F8B93302E0199E9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] "Update RFC6833bis" header when a meaning is associated with a reserved bit X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 13:30:37 -0000 For everyone's context, this is a topic on which the IETF as a whole and the IESG do not have anything like rough consensus. Some folks think this sort of change should be an "updates", and other folks argue that the point of a registry is that we do not need to "update" the base document. There are many valid arguments on both sides. Yours, Joel On 10/23/18 3:37 AM, mohamed.boucadair@orange.com wrote: > Hi all, > > In a discussion among the authors of draft-ietf-lisp-pubsub, we > discussed whether an "Update RFC6833bis" header is needed to be added to > the draft. > > The rationale is the-bis document states, for example, the following: > >    R: This reserved bit MUST be set to 0 on transmit and MUST be ignored > >       on receipt. > > So, obviously this behavior is to be updated each time a meaning is > associated with an unassigned/reserved bit, otherwise an extension will > be broken if that part of the –bis spec is not touched on. > > An update header is therefore more than appropriate….nevertheless, it > seems that some old RFCs didn’t follow this approach (e.g., RFC8061). > > The question we have for the WG is which option do we need to follow: > update or no update? > > FWIW, a similar action is needed for other documents, e.g., > draft-ietf-lisp-mn. > > Thank you. > > Cheers, > > Med > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Tue Oct 23 09:27: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 7CF25130E1A for ; Tue, 23 Oct 2018 09:27:12 -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 SqRBbEwIJ8CU for ; Tue, 23 Oct 2018 09:27:10 -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 AED1B124408 for ; Tue, 23 Oct 2018 09:27:10 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id l81-v6so945240pfg.3 for ; Tue, 23 Oct 2018 09:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7jsgYBv8MIV2CNAUIsBBMU3QkaH9KpAAYGWeGF4tRxs=; b=tmzpUs0ogLUkuOMwuIzqcXBLHFVuVbkpZNU6N5tfjCYL1YAD+hTl0kTUbMMEEnm2aO EKEVhW6O6hGRWWIpvIBX41qQ8FUqieUZSK43uQesOcLwB6lAkVi/v80aVB8RTeSntmwu UYVtHmQG5vER2JEvhYKNKPaHOARxShUk4//aDwXMXR1hEGteQlNTvYFh1XbsURrmrIDE nf3AfUsQwu8AS4qmFDHN3eIpiPemS0NPli5dBvvjii1HlbhNg6dwsTnXZU5vA/aiKvQH bEdkmi94ONzbEArCYXWW23kopz9i7nAZQPQekobEsDWmsZkn6PaFcvPnzGOTfrL1W5ZQ U3RA== 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=7jsgYBv8MIV2CNAUIsBBMU3QkaH9KpAAYGWeGF4tRxs=; b=Xpj//ggGDZXn8HsgU64lT38XnOCWoU41NekYVsTzo6QZDcmxIDPOTYSYw35bs0mnsN RlSzR7ucZ8B4bFoGPJRPrHUKIx24EJm3HbQHBOUAIfoIB9olcMTVOVgAJhx3C/YPCyqk BvzrdWMBDIupBUIARqq9S5haA1/6KEeN+TjbFJMPnFmvILSguRvqIvlz/0ObQ39vCEfW Cx+fSFeTylbTePLT0CnSjBVRtGFo5eAPISs/yFqEQOeilT0UIkS+awIUQdYBCTjVPIlT Bi0hl+/u5hh+pAF4TBOMDu+cNvq4n1dTUz+WqmSDCUP2RjoMV7DkyDNklFILvwWdm77P bINg== X-Gm-Message-State: ABuFfogN6D2tbIGzt4+o+2d5gAMdfWrRWrNBJaidUYQ3I7dx98pC967B /Ln7JHsWek4wJps4ehGizYY= X-Google-Smtp-Source: ACcGV60IAPqj7s/+0TWP+Oziwdj4sPp0y0zlqP/XefO9CgmexXP/Gj8qx4yECE7JHXSJd2M0xtDyVA== X-Received: by 2002:a62:8685:: with SMTP id x127-v6mr27884230pfd.252.1540312030155; Tue, 23 Oct 2018 09:27:10 -0700 (PDT) Received: from [192.168.241.153] (soln-sr3455.solutionip.com. [70.233.112.2]) by smtp.gmail.com with ESMTPSA id w187-v6sm2775582pfw.3.2018.10.23.09.27.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Oct 2018 09:27:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 23 Oct 2018 09:27:08 -0700 Cc: "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 16:27:13 -0000 I am not sure if we should make this distinction. What does the WG = think? Because fields marked =E2=80=9Creserved=E2=80=9D are obviously = unassigned and don=E2=80=99t know if they will be assigned in the = future.=20 So I am not sure how helpful in making the distinction. Dino > On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com wrote: >=20 > Hi Dino, all, > =20 > Apologies for raising this late easy to fix comment: > =20 > RFC8126 says the following: > =20 > Unassigned: Not currently assigned, and available for = assignment > = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > via documented procedures. While it's generally clear = that > any values that are not registered are unassigned and > available for assignment, it is sometimes useful to > explicitly specify that situation. Note that this is > distinctly different from "Reserved". > =20 > Reserved: Not assigned and not available for assignment. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Reserved values are held for special uses, such as to = extend > the namespace when it becomes exhausted. "Reserved" is = also > sometimes used to designate values that had been assigned > but are no longer in use, keeping them set aside as long = as > other unassigned values are available. Note that this is > distinctly different from "Unassigned". > =20 > This is well handled in Section 5.1, but not in other sections which = are using Reserved instead of Unassigned as per RFC8126. > =20 > It would be appropriate to update the text accordingly. Thank you. > =20 > Cheers, > Med > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Oct 23 10:10:06 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24BA1276D0 for ; Tue, 23 Oct 2018 10:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 f1szYBj7I3L9 for ; Tue, 23 Oct 2018 10:10:02 -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 C5FB9124C04 for ; Tue, 23 Oct 2018 10:10:02 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w9NH9TWp031686; Tue, 23 Oct 2018 13:10:02 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 2na7a2s7gm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Oct 2018 13:10:02 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9NHA0EJ010848; Tue, 23 Oct 2018 13:10:00 -0400 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9NH9tgO010751; Tue, 23 Oct 2018 13:09:56 -0400 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id 15D994039455; Tue, 23 Oct 2018 17:09:55 +0000 (GMT) Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (unknown [130.9.129.149]) by zlp27128.vci.att.com (Service) with ESMTPS id 014D54039446; Tue, 23 Oct 2018 17:09:55 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.89]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0415.000; Tue, 23 Oct 2018 13:09:54 -0400 From: "BRUNGARD, DEBORAH A" To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "lisp@ietf.org" Thread-Topic: [lisp] "Update RFC6833bis" header when a meaning is associated with a reserved bit Thread-Index: AdRqo05oOv5e0+oORKOieqidjTPDSwAUsdYAAAZgV8A= Date: Tue, 23 Oct 2018 17:09:53 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93302E0199E9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.152.195] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-23_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810230137 Archived-At: Subject: Re: [lisp] "Update RFC6833bis" header when a meaning is associated with a reserved bit X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 17:10:05 -0000 As Joel says, there has been no specific definition as each working group h= as different views (which is ok, as each technology is different). Importan= t is the working group does consistently. Now as LISP goes PS, it is good t= o have a common understanding. My personal interpretation is to be conservative with the label, as it does= augment the original document on datatracker, so the reader of the origina= l document will feel they need to read all the associated updates. Whereas = for the new document, it will already have the previous document as normati= ve reference, so the "update" label doesn't necessarily add more informatio= n. An example which I often use, though it may seem obvious, it did have qu= ite some discussion: a new protection capability is added to MPLS. My prefe= rence was to say it was not an update of the base MPLS documents. The advoc= ates of the new capability wanted it to be an update. We decided to say it = was not an update. If say, the protection switching capability used a reser= ved bit (below example), then if one is not implementing protection switchi= ng, it would follow the base spec. If one is implementing protection switch= ing, then it would use the reserved bit assigned to it. And there are many examples not so obvious. Deborah -----Original Message----- From: lisp On Behalf Of Joel M. Halpern Sent: Tuesday, October 23, 2018 9:30 AM To: mohamed.boucadair@orange.com; lisp@ietf.org Subject: Re: [lisp] "Update RFC6833bis" header when a meaning is associated= with a reserved bit For everyone's context, this is a topic on which the IETF as a whole and th= e IESG do not have anything like rough consensus. Some folks think this so= rt of change should be an "updates", and other folks argue that the point o= f a registry is that we do not need to "update" the base document. There are many valid arguments on both sides. Yours, Joel On 10/23/18 3:37 AM, mohamed.boucadair@orange.com wrote: > Hi all, >=20 > In a discussion among the authors of draft-ietf-lisp-pubsub, we=20 > discussed whether an "Update RFC6833bis" header is needed to be added=20 > to the draft. >=20 > The rationale is the-bis document states, for example, the following: >=20 > =A0=A0 R: This reserved bit MUST be set to 0 on transmit and MUST be=20 > ignored >=20 > =A0=A0=A0=A0=A0 on receipt. >=20 > So, obviously this behavior is to be updated each time a meaning is=20 > associated with an unassigned/reserved bit, otherwise an extension=20 > will be broken if that part of the -bis spec is not touched on. >=20 > An update header is therefore more than appropriate..nevertheless, it=20 > seems that some old RFCs didn't follow this approach (e.g., RFC8061). >=20 > The question we have for the WG is which option do we need to follow:=20 > update or no update? >=20 > FWIW, a similar action is needed for other documents, e.g.,=20 > draft-ietf-lisp-mn. >=20 > Thank you. >=20 > Cheers, >=20 > Med >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail > man_listinfo_lisp&d=3DDwIF-g&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi9dM= 7jY > lxXD8w&m=3D6KakRalNM3ilcAkwrGoHtCyhO5cgvdhVTxMRYVsTQCc&s=3D11EjTtLye81bqq= q > zCe9FEoqbYNABObgViOOajHoXdE4&e=3D >=20 _______________________________________________ lisp mailing list lisp@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_lisp&d=3DDwIF-g&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi9dM7jYlx= XD8w&m=3D6KakRalNM3ilcAkwrGoHtCyhO5cgvdhVTxMRYVsTQCc&s=3D11EjTtLye81bqqqzCe= 9FEoqbYNABObgViOOajHoXdE4&e=3D From nobody Wed Oct 24 01:00:43 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDC4130DC0 for ; Wed, 24 Oct 2018 01:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 19smBhi1A8mr for ; Wed, 24 Oct 2018 01:00:34 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F0412F1AC for ; Wed, 24 Oct 2018 01:00:34 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id y16so4478346wrw.3 for ; Wed, 24 Oct 2018 01:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+7wYwSxJh1laxOU2q9QidTuRvsrqhdy7aOYvJXspwcA=; b=QViEFq3AFnvSXUb0kPH1AIXQ3TwjaanoHqeC/PLVp16agPbV2NeZWRjhM1G7wceaA0 4JWtmzHW6JmrxhWPOmxb4iXU+NCmjJ/L5JCBOCfAAtgBra+Zmn664X+jIwsK0j57klxl 623QHGvhta+4VT5T3LaMiJuOBXJviHxDWCHSSUEwptYyGBKhc03S04djNpcrnpwB5h6t +j//RFkH9dLfrkMCVel1GGonoH72CXpNvQ2ACXqPw3wyBuIiu43bEBHZt1I5v6XvcoPM s2WMAIs/qWcNvi7uwQ5hrhyddX+gansQWOv81OOwtw6CJ341qFT2k5PLOzbUHQoYKkGZ /eFQ== 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=+7wYwSxJh1laxOU2q9QidTuRvsrqhdy7aOYvJXspwcA=; b=DQkxvciROyseRTlWvtNOmWDpjomZG2Z1Piy7LiXOGtsV0C1CN5sjMdYoeatS45nd7L JZpehLCW7kUSXWXtP8MqpFLvS0q+fMzrUXMh0enjmTxSdT/hT5GyXmYllawr2rov0yy1 jagubYxjQFiGuJRIcbHq7Q7t6/ReQVPHqqQaFnoAbLPLy3eymrdGHBON9I1B7Z6FyUqC u6HHFujcjijkz7Zh8yh07mba4RvbEn2ZdTQzMqP69v5fBsTnG2vHXPG8DUbUzmKKMjOO eNng0iZjX0hIQMwYbr7u+6dDUGPLUiwngKamkh8b1xxd3G5g/FciPQ8gHELYZ48jj78k TOrw== X-Gm-Message-State: AGRZ1gISWKqfhQhwtgmKG7CzulrHqIqrZvufcqAlmqfJJaP8/L6qTg5m dfTjdeCpsnHUsw2/w6aagpcDFw== X-Google-Smtp-Source: AJdET5e+gj6EHRc3rsaDUU996gn+Un/hU+bOpP26hb6draOZStLj0JTjhnACD/QSo83nt6H8KGGJPQ== X-Received: by 2002:adf:9c0a:: with SMTP id f10-v6mr1737678wrc.93.1540368032726; Wed, 24 Oct 2018 01:00:32 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:1c54:60e7:35f2:a72f? ([2001:660:330f:a4:1c54:60e7:35f2:a72f]) by smtp.gmail.com with ESMTPSA id f2-v6sm638400wrq.14.2018.10.24.01.00.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 01:00:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Luigi Iannone In-Reply-To: Date: Wed, 24 Oct 2018 10:00:35 +0200 Cc: "" , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 08:00:37 -0000 Hi All, disclaimer: this is my personal point of view. I didn=E2=80=99t catch before this part of RFC 8126. Thanks Med from = bringing it up. While I understand Dino=E2=80=99s reply, because I my self as well = always thought =E2=80=9Creserved =3D can be used in the future=E2=80=9D, = I think that Med is right. To be compliant with RFC 8126, and because we may need those = =E2=80=9Creserved=E2=80=9D bits in the future, we better mark them as = =E2=80=9Cunassigned=E2=80=9D. This means changing the text and clearly spell out that this is conform = to RFC 8126 definitions. At the end, it is as simple as adding the following sentence in section = 2 =E2=80=9CRequirements Notation=E2=80=9D: The =E2=80=9CUnassigned=E2=80=9D and =E2=80=9CReserved=E2=80=9D = terminology for bits and fields of=20 messages and headers defined in this documents is the Well-Known=20= Registration Status Terminology defined in Section 6 of = [RFC8126]. Then we just replace =E2=80=9Creserved=E2=80=9D with =E2=80=9Cunassigned=E2= =80=9D throughout the document. Ciao L. =20 > On 23 Oct 2018, at 18:27, Dino Farinacci wrote: >=20 > I am not sure if we should make this distinction. What does the WG = think? Because fields marked =E2=80=9Creserved=E2=80=9D are obviously = unassigned and don=E2=80=99t know if they will be assigned in the = future.=20 >=20 > So I am not sure how helpful in making the distinction. >=20 > Dino >=20 >> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com wrote: >>=20 >> Hi Dino, all, >>=20 >> Apologies for raising this late easy to fix comment: >>=20 >> RFC8126 says the following: >>=20 >> Unassigned: Not currently assigned, and available for = assignment >> = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> via documented procedures. While it's generally clear = that >> any values that are not registered are unassigned and >> available for assignment, it is sometimes useful to >> explicitly specify that situation. Note that this is >> distinctly different from "Reserved". >>=20 >> Reserved: Not assigned and not available for assignment. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Reserved values are held for special uses, such as to = extend >> the namespace when it becomes exhausted. "Reserved" is = also >> sometimes used to designate values that had been assigned >> but are no longer in use, keeping them set aside as long = as >> other unassigned values are available. Note that this is >> distinctly different from "Unassigned". >>=20 >> This is well handled in Section 5.1, but not in other sections which = are using Reserved instead of Unassigned as per RFC8126. >>=20 >> It would be appropriate to update the text accordingly. Thank you. >>=20 >> Cheers, >> Med >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Oct 24 02:24:22 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF28130DD3 for ; Wed, 24 Oct 2018 02:24:16 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHkYB_2vZOb1 for ; Wed, 24 Oct 2018 02:24:14 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749F21277BB for ; Wed, 24 Oct 2018 02:24:14 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 42g4Zh52rZzCrcx; Wed, 24 Oct 2018 11:24:12 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.83]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 42g4Zh4S2jz8sYl; Wed, 24 Oct 2018 11:24:12 +0200 (CEST) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORMAF.corporate.adroot.infra.ftgroup ([fe80::e1dd:62fe:d378:e3f8%21]) with mapi id 14.03.0415.000; Wed, 24 Oct 2018 11:24:12 +0200 From: To: Luigi Iannone , Dino Farinacci CC: "lisp@ietf.org" Thread-Topic: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned Thread-Index: AdRqpEd10cZL+uOwTGaba/yk/wtayQAy1z4NAALI/qA= Date: Wed, 24 Oct 2018 09:24:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> In-Reply-To: <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 09:24:17 -0000 SGkgTHVpZ2ksDQoNCkZ1bGx5IGFncmVlIHRoYXQgY2hhbmdpbmcgdGhlIHRleHQgYW5kIHVwZGF0 aW5nIHRoZSBmaWd1cmVzIHdvdWxkIGJlIGFwcHJvcHJpYXRlLiANCg0KUGxlYXNlIG5vdGUgdGhh dCBhIHNpbWlsYXIgYWN0aW9uIGlzIG5lZWRlZCBmb3IgZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBi aXMtMjQsIGUuZy4sDQoNCiAgIFI6IFRoZSBSLWJpdCBpcyBhIFJlc2VydmVkIGJpdCBmb3IgZnV0 dXJlIHVzZS4gIEl0IE1VU1QgYmUgc2V0IHRvIDANCiAgICAgIG9uIHRyYW5zbWl0IGFuZCBNVVNU IGJlIGlnbm9yZWQgb24gcmVjZWlwdC4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEx1aWdpIElhbm5vbmUgW21haWx0bzpnZ3hAZ2lnaXgu bmV0XQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDI0IG9jdG9icmUgMjAxOCAxMDowMQ0KPiDDgMKg OiBEaW5vIEZhcmluYWNjaQ0KPiBDY8KgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOyBsaXNw QGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbbGlzcF0gZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzNi aXMtMTk6IFJlc2VydmVkL1VuYXNzaWduZWQNCj4gDQo+IEhpIEFsbCwNCj4gDQo+IGRpc2NsYWlt ZXI6IHRoaXMgaXMgbXkgcGVyc29uYWwgcG9pbnQgb2Ygdmlldy4NCj4gDQo+IEkgZGlkbuKAmXQg Y2F0Y2ggYmVmb3JlIHRoaXMgcGFydCBvZiBSRkMgODEyNi4gVGhhbmtzIE1lZCBmcm9tIGJyaW5n aW5nIGl0IHVwLg0KPiANCj4gV2hpbGUgSSB1bmRlcnN0YW5kIERpbm/igJlzIHJlcGx5LCBiZWNh dXNlIEkgbXkgc2VsZiBhcyB3ZWxsIGFsd2F5cyB0aG91Z2h0DQo+IOKAnHJlc2VydmVkID0gY2Fu IGJlIHVzZWQgaW4gdGhlIGZ1dHVyZeKAnSwgSSB0aGluayB0aGF0IE1lZCBpcyByaWdodC4NCj4g DQo+IFRvIGJlIGNvbXBsaWFudCB3aXRoIFJGQyA4MTI2LCBhbmQgYmVjYXVzZSB3ZSBtYXkgbmVl ZCB0aG9zZSDigJxyZXNlcnZlZOKAnSBiaXRzDQo+IGluIHRoZSBmdXR1cmUsIHdlIGJldHRlciBt YXJrIHRoZW0gYXMg4oCcdW5hc3NpZ25lZOKAnS4NCj4gVGhpcyBtZWFucyBjaGFuZ2luZyB0aGUg dGV4dCBhbmQgY2xlYXJseSBzcGVsbCBvdXQgdGhhdCB0aGlzIGlzIGNvbmZvcm0gdG8NCj4gUkZD IDgxMjYgZGVmaW5pdGlvbnMuDQo+IA0KPiBBdCB0aGUgZW5kLCBpdCBpcyBhcyBzaW1wbGUgYXMg YWRkaW5nIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgaW4gc2VjdGlvbiAyDQo+IOKAnFJlcXVpcmVt ZW50cyBOb3RhdGlvbuKAnToNCj4gDQo+IAlUaGUgIOKAnFVuYXNzaWduZWTigJ0gYW5kIOKAnFJl c2VydmVk4oCdIHRlcm1pbm9sb2d5IGZvciBiaXRzIGFuZCBmaWVsZHMgb2YNCj4gCW1lc3NhZ2Vz IGFuZCBoZWFkZXJzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudHMgaXMgdGhlIFdlbGwtS25vd24N Cj4gCVJlZ2lzdHJhdGlvbiBTdGF0dXMgVGVybWlub2xvZ3kgZGVmaW5lZCBpbiBTZWN0aW9uIDYg b2YgW1JGQzgxMjZdLg0KPiANCj4gDQo+IFRoZW4gd2UganVzdCByZXBsYWNlIOKAnHJlc2VydmVk 4oCdIHdpdGgg4oCcdW5hc3NpZ25lZOKAnSB0aHJvdWdob3V0IHRoZSBkb2N1bWVudC4NCj4gDQo+ IENpYW8NCj4gDQo+IEwuDQo+IA0KPiANCj4gDQo+ID4gT24gMjMgT2N0IDIwMTgsIGF0IDE4OjI3 LCBEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2NpQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBJ IGFtIG5vdCBzdXJlIGlmIHdlIHNob3VsZCBtYWtlIHRoaXMgZGlzdGluY3Rpb24uIFdoYXQgZG9l cyB0aGUgV0cgdGhpbms/DQo+IEJlY2F1c2UgZmllbGRzIG1hcmtlZCDigJxyZXNlcnZlZOKAnSBh cmUgb2J2aW91c2x5IHVuYXNzaWduZWQgYW5kIGRvbuKAmXQga25vdyBpZg0KPiB0aGV5IHdpbGwg YmUgYXNzaWduZWQgaW4gdGhlIGZ1dHVyZS4NCj4gPg0KPiA+IFNvIEkgYW0gbm90IHN1cmUgaG93 IGhlbHBmdWwgaW4gbWFraW5nIHRoZSBkaXN0aW5jdGlvbi4NCj4gPg0KPiA+IERpbm8NCj4gPg0K PiA+PiBPbiBPY3QgMjMsIDIwMTgsIGF0IDEyOjQ0IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIHdyb3RlOg0KPiA+Pg0KPiA+PiBIaSBEaW5vLCBhbGwsDQo+ID4+DQo+ID4+IEFwb2xv Z2llcyBmb3IgcmFpc2luZyB0aGlzIGxhdGUgZWFzeSB0byBmaXggY29tbWVudDoNCj4gPj4NCj4g Pj4gUkZDODEyNiBzYXlzIHRoZSBmb2xsb3dpbmc6DQo+ID4+DQo+ID4+ICAgICAgVW5hc3NpZ25l ZDogIE5vdCBjdXJyZW50bHkgYXNzaWduZWQsIGFuZCBhdmFpbGFibGUgZm9yIGFzc2lnbm1lbnQN Cj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXg0KPiA+PiAgICAgICAgICAgIHZpYSBkb2N1bWVudGVkIHByb2Nl ZHVyZXMuICBXaGlsZSBpdCdzIGdlbmVyYWxseSBjbGVhciB0aGF0DQo+ID4+ICAgICAgICAgICAg YW55IHZhbHVlcyB0aGF0IGFyZSBub3QgcmVnaXN0ZXJlZCBhcmUgdW5hc3NpZ25lZCBhbmQNCj4g Pj4gICAgICAgICAgICBhdmFpbGFibGUgZm9yIGFzc2lnbm1lbnQsIGl0IGlzIHNvbWV0aW1lcyB1 c2VmdWwgdG8NCj4gPj4gICAgICAgICAgICBleHBsaWNpdGx5IHNwZWNpZnkgdGhhdCBzaXR1YXRp b24uICBOb3RlIHRoYXQgdGhpcyBpcw0KPiA+PiAgICAgICAgICAgIGRpc3RpbmN0bHkgZGlmZmVy ZW50IGZyb20gIlJlc2VydmVkIi4NCj4gPj4NCj4gPj4gICAgICBSZXNlcnZlZDogIE5vdCBhc3Np Z25lZCBhbmQgbm90IGF2YWlsYWJsZSBmb3IgYXNzaWdubWVudC4NCj4gPj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ID4+ ICAgICAgICAgICAgUmVzZXJ2ZWQgdmFsdWVzIGFyZSBoZWxkIGZvciBzcGVjaWFsIHVzZXMsIHN1 Y2ggYXMgdG8gZXh0ZW5kDQo+ID4+ICAgICAgICAgICAgdGhlIG5hbWVzcGFjZSB3aGVuIGl0IGJl Y29tZXMgZXhoYXVzdGVkLiAgIlJlc2VydmVkIiBpcyBhbHNvDQo+ID4+ICAgICAgICAgICAgc29t ZXRpbWVzIHVzZWQgdG8gZGVzaWduYXRlIHZhbHVlcyB0aGF0IGhhZCBiZWVuIGFzc2lnbmVkDQo+ ID4+ICAgICAgICAgICAgYnV0IGFyZSBubyBsb25nZXIgaW4gdXNlLCBrZWVwaW5nIHRoZW0gc2V0 IGFzaWRlIGFzIGxvbmcgYXMNCj4gPj4gICAgICAgICAgICBvdGhlciB1bmFzc2lnbmVkIHZhbHVl cyBhcmUgYXZhaWxhYmxlLiAgTm90ZSB0aGF0IHRoaXMgaXMNCj4gPj4gICAgICAgICAgICBkaXN0 aW5jdGx5IGRpZmZlcmVudCBmcm9tICJVbmFzc2lnbmVkIi4NCj4gPj4NCj4gPj4gVGhpcyBpcyB3 ZWxsIGhhbmRsZWQgaW4gU2VjdGlvbiA1LjEsIGJ1dCBub3QgaW4gb3RoZXIgc2VjdGlvbnMgd2hp Y2ggYXJlDQo+IHVzaW5nIFJlc2VydmVkIGluc3RlYWQgb2YgVW5hc3NpZ25lZCBhcyBwZXIgUkZD ODEyNi4NCj4gPj4NCj4gPj4gSXQgd291bGQgYmUgYXBwcm9wcmlhdGUgdG8gdXBkYXRlIHRoZSB0 ZXh0IGFjY29yZGluZ2x5LiBUaGFuayB5b3UuDQo+ID4+DQo+ID4+IENoZWVycywNCj4gPj4gTWVk DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+IGxpc3AgbWFpbGluZyBsaXN0DQo+ID4+IGxpc3BAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQo+ID4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGxpc3AgbWFpbGluZyBsaXN0 DQo+ID4gbGlzcEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbGlzcA0KDQo= From nobody Wed Oct 24 04:16: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 32B0F130DC2 for ; Wed, 24 Oct 2018 04:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 JVuE_g1TdYOa for ; Wed, 24 Oct 2018 04:16:12 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 75ECE127333 for ; Wed, 24 Oct 2018 04:16:12 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id r63-v6so4974694wma.4 for ; Wed, 24 Oct 2018 04:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=Cn/7klx5nay/gFr+mMkeDUOGLRnyYtC3kDGWoBZ/ag0=; b=E9Hnmsf3IoYsT8ZWRGIpoBSYfJWOgL08aPgdoE4gWrXkZvsegH6ocH37DIfZ05i8fZ 5Wfti7oN8dAluYKiCzrVtMQE5kSEafyA5O4amz1vREXxLFRFSUDqc/zOx+TgK6j4UTRp msWnIIN5+6QkiZ8ixQWNT6ccrZS/5eVX3Iyk0CBvMQXC1aN655L15NiSstQ4KLigsOYT HfLY2o+x4neLtz70OxRL1SnBI0nDyCdoW81w517iAUtfI9XwBYLy9Q8C6X4r3v+kpWlU eMtPtmDMyaRJrVW7wStr5rij27vyUXIAgx6ycq3MnqOntf8dPm4Ayejrrf8hVGwFBKJh AkMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=Cn/7klx5nay/gFr+mMkeDUOGLRnyYtC3kDGWoBZ/ag0=; b=d8TNn7u7Y7raeuc1HNGoHa5Vzmn4Q4o1XyMPIwEOXyi2iiooPtY7ldLINZHPtDbf8I dwxj6QpwokVo05Fdv2SG6APVQewWHY48YZ9nkTU8ag8KdZ+KeOnsMPYjbPI9oQHtKBle frsk0Wl/eMOvQDVt8QevEfH4t8/IeP0NPEsCZDES172DbqINLL3gOIqLnSjPhhX8IgMX lNbTIf+0YekaZQH5RPDxdG1z/znKieUFU8aYgXP4FeojV6qsthmL8pFxKL7N0RGhkBoF gChrWsQtV5nMJCeipivXGXcGC4iSikNtpEDMCtpIa8YkcfbhaWupM+fw1pUPqK+I2P3m If0g== X-Gm-Message-State: AGRZ1gJlLv7t1p9pGqwfgMc7n3fxGAy+5Tb6h3obRrr0h+3+S7Z0rG2Y 38Rfl9OWSPaUZsIWUIGXuwlXyxRMmHvhVA== X-Google-Smtp-Source: AJdET5e51BLr1OLyPMpQokxA61tt9DqhSPlLdH2wYxKeVPeJzJLvM8M+c5J17GlW2IULoIzWHr9+mA== X-Received: by 2002:a1c:924d:: with SMTP id u74-v6mr2342709wmd.105.1540379770381; Wed, 24 Oct 2018 04:16:10 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:a534:d33b:c242:a64f? ([2001:660:330f:a4:a534:d33b:c242:a64f]) by smtp.gmail.com with ESMTPSA id d5-v6sm3902764wrn.85.2018.10.24.04.16.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 04:16:08 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_ED41DF47-CDEC-4A4B-BB58-EDFA7723B4B6" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Wed, 24 Oct 2018 13:16:06 +0200 References: <153877793727.1026.1146854495726676148.idtracker@ietfa.amsl.com> <1B08CE0F-6AA0-49C1-8A36-F562844F83DD@gigix.net> To: "lisp@ietf.org list" In-Reply-To: <1B08CE0F-6AA0-49C1-8A36-F562844F83DD@gigix.net> Message-Id: <63BE166E-8166-478D-828E-087511AD4D4C@gigix.net> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] [Call for Agenda Items] IETF 103 Preliminary Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 11:16:15 -0000 --Apple-Mail=_ED41DF47-CDEC-4A4B-BB58-EDFA7723B4B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, hereafter the current LISP WG Preliminary Agenda. As you can see we still have more than a hour that is unallocated. Please, if you have anything you want to share with the WG drop an email = to there chairs. Ciao L. CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com ) Luigi Iannone ( ggx AT gigix.net ) SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com ) Padma Pillay-Esnault ( padma.ietf AT gmail.com ) AGENDA Session 1/1 (120 Minutes) =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Monday, November 5, 2018 9:00 - 11:00, Morning Session I, 120 Minutes Room: Boromphimarn 3 - Administration Halpern/Iannone - Blue Sheets - Agenda Bashing - Status reports for WG drafts 5 Minutes (Cumulative Time: 5 Minutes) o WG Items - LISP YANG Model - draft-ietf-lisp-yang-08.txt 10 Minutes (Cumulative Time: 15 Minutes) Reshad Rahman - Update on 6830bis/6833bis documents 20 Minutes (Cumulative Time: 35 Minutes) - LISP EID Anonimity - draft-ietf-lisp-eid-anonymity-04 10 Minutes (Cumulative Time: 45 Minutes) o Non WG Items - Overflow Time/ Discussion 75 Minutes (Cumulative Time: 120 Minutes) > On 7 Oct 2018, at 23:58, Luigi Iannone wrote: >=20 > Folks, >=20 > The preliminary agenda has been published. > We will meet Monday Morning 5 November. >=20 > While the agenda is still subject to changes it is time to think about = presentation slots. >=20 > Please send your requests for agenda items (Presenter=E2=80=99s name, = title, slot duration)=20 > to lisp-chairs@tools.ietf.org >=20 > Ciao >=20 > L. >=20 >> Begin forwarded message: >>=20 >> From: IETF Agenda > >> Subject: [Recentattendees] IETF 103 Preliminary Agenda >> Date: 6 October 2018 at 00:18:57 CEST >> To: "IETF Announcement List" > >> Cc: recentattendees@ietf.org , = ietf@ietf.org , 103all@ietf.org = >> Reply-To: agenda@ietf.org >>=20 >> IETF 103 >> Bangkok, Thailand >> November 3-9, 2018 >> Hosts: Huawei and Cisco >>=20 >> The IETF 103 Preliminary Agenda has been posted. The final agenda = will be published on Friday, October 12, 2018.=20 >>=20 >> https://datatracker.ietf.org/meeting/103/agenda.html = >> https://datatracker.ietf.org/meeting/103/agenda.txt >>=20 >>=20 >> IETF 103 Information: https://www.ietf.org/how/meetings/103/ >> Register online at: https://www.ietf.org/how/meetings/register/ >>=20 >> Don=E2=80=99t forget to register for these exciting IETF 103 events! >>=20 >> Hackathon=20 >> Signup: = https://www.ietf.org/registration/ietf103/hackathonregistration.py >> More information: = https://www.ietf.org/how/runningcode/hackathons/103-hackathon/ >> Keep up to date by subscribing to:=20 >> https://www.ietf.org/mailman/listinfo/hackathon >>=20 >> Code Sprint >> Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103SprintSignUp >> More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103Sprint >>=20 >> _______________________________________________ >> Recentattendees mailing list >> Recentattendees@ietf.org >> https://www.ietf.org/mailman/listinfo/recentattendees >=20 --Apple-Mail=_ED41DF47-CDEC-4A4B-BB58-EDFA7723B4B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = All,

hereafter the = current LISP WG Preliminary Agenda.

As you can see we still have more than = a hour that is unallocated.

Please, if you have anything you want to share with the WG = drop an email to there chairs.

Ciao

L.

CHAIR(s):  Joel Halpern ( jmh AT joelhalpern.com )
                Luigi Iannone ( ggx AT gigix.net )

SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com )
           	   Padma Pillay-Esnault ( padma.ietf AT gmail.com )


AGENDA

Session 1/1 (120 Minutes)
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

Monday, November 5, 2018
9:00 - 11:00, Morning Session I, 120 Minutes
Room: Boromphimarn 3

- Administration
    Halpern/Iannone
    - Blue Sheets
    - Agenda Bashing
    - Status reports for WG drafts
	5 Minutes 	(Cumulative Time: 5 Minutes)



o WG Items

- LISP YANG Model - draft-ietf-lisp-yang-08.txt
  10 Minutes (Cumulative Time: 15 Minutes)
  Reshad Rahman

- Update on 6830bis/6833bis documents
  20 Minutes (Cumulative Time: 35 Minutes)

- LISP EID Anonimity - draft-ietf-lisp-eid-anonymity-04
  10 Minutes (Cumulative Time: 45 Minutes)




o Non WG Items

- Overflow Time/ Discussion
  75 Minutes (Cumulative Time: 120 Minutes)





On 7 Oct = 2018, at 23:58, Luigi Iannone <ggx@gigix.net> wrote:

Folks,

The preliminary agenda = has been published.
We will meet Monday Morning 5 = November.

While = the agenda is still subject to changes it is time to think about = presentation slots.

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

Ciao

L.

Begin = forwarded message:

From: IETF Agenda <agenda@ietf.org>
Subject: [Recentattendees] IETF 103 Preliminary Agenda
Date: 6 October 2018 at 00:18:57 CEST
To: "IETF Announcement List" <ietf-announce@ietf.org>
Cc: recentattendees@ietf.org, ietf@ietf.org, 103all@ietf.org
Reply-To: agenda@ietf.org

IETF 103
Bangkok, Thailand
November= 3-9, 2018
Hosts: Huawei and Cisco

The IETF 103 Preliminary Agenda has been posted. The final = agenda will be published on Friday, October 12, 2018.

https://datatracker.ietf.org/meeting/103/agenda.html
https://datatracker.ietf.org/meeting/103/agenda.txt


IETF 103 Information: = https://www.ietf.org/how/meetings/103/
Register online at: = https://www.ietf.org/how/meetings/register/

Don=E2=80=99t forget to register for these exciting IETF 103 = events!

Hackathon
Signup: = https://www.ietf.org/registration/ietf103/hackathonregistration.py
= More information: = https://www.ietf.org/how/runningcode/hackathons/103-hackathon/
= Keep up to date by subscribing to:
= https://www.ietf.org/mailman/listinfo/hackathon

Code Sprint
Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103SprintSignUp
= More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103Sprint

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


= --Apple-Mail=_ED41DF47-CDEC-4A4B-BB58-EDFA7723B4B6-- From nobody Wed Oct 24 06:15:31 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62AE130E3A for ; Wed, 24 Oct 2018 06:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoOOA1Sv6-w7 for ; Wed, 24 Oct 2018 06:15:24 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6557E130F23 for ; Wed, 24 Oct 2018 06:15:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0B3886C60FA; Wed, 24 Oct 2018 06:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1540386924; bh=G3oHaQxvcMWx8JxLerH5rqrPLPVuVCm9wL2AM1m+zN8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=oij5TgrWoqvihs6rir5EDdWAeNbwxTuzBCjZT8Zx5i+HcMLoydD81zpBOTxQE1m63 zEccw+kvbLtXWZLqKpg3y6Uij3FDcDs3gAU6uh4Pu/2G4ZXgOTcaiFQUlToxs8nq2l GRf6vEGOeuipf6ErKjgfcQ9OxDcqGleARXXOZzAw= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5829B6C60F8; Wed, 24 Oct 2018 06:15:23 -0700 (PDT) To: mohamed.boucadair@orange.com, Luigi Iannone , Dino Farinacci Cc: "lisp@ietf.org" References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: Date: Wed, 24 Oct 2018 09:15:22 -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: <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 13:15:30 -0000 Med, just to be clear. Ar eyou saying that we should change the word Reserved to Unasigned? THe text would read weirdly, but I can live with it. We need to keep the rest of the text, as it is critical for future interoperability. Yours, Joel On 10/24/18 5:24 AM, mohamed.boucadair@orange.com wrote: > Hi Luigi, > > Fully agree that changing the text and updating the figures would be appropriate. > > Please note that a similar action is needed for draft-ietf-lisp-rfc6830bis-24, e.g., > > R: The R-bit is a Reserved bit for future use. It MUST be set to 0 > on transmit and MUST be ignored on receipt. > > Cheers, > Med > >> -----Message d'origine----- >> De : Luigi Iannone [mailto:ggx@gigix.net] >> Envoyé : mercredi 24 octobre 2018 10:01 >> À : Dino Farinacci >> Cc : BOUCADAIR Mohamed TGI/OLN; lisp@ietf.org >> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned >> >> Hi All, >> >> disclaimer: this is my personal point of view. >> >> I didn’t catch before this part of RFC 8126. Thanks Med from bringing it up. >> >> While I understand Dino’s reply, because I my self as well always thought >> “reserved = can be used in the futureâ€, I think that Med is right. >> >> To be compliant with RFC 8126, and because we may need those “reserved†bits >> in the future, we better mark them as “unassignedâ€. >> This means changing the text and clearly spell out that this is conform to >> RFC 8126 definitions. >> >> At the end, it is as simple as adding the following sentence in section 2 >> “Requirements Notationâ€: >> >> The “Unassigned†and “Reserved†terminology for bits and fields of >> messages and headers defined in this documents is the Well-Known >> Registration Status Terminology defined in Section 6 of [RFC8126]. >> >> >> Then we just replace “reserved†with “unassigned†throughout the document. >> >> Ciao >> >> L. >> >> >> >>> On 23 Oct 2018, at 18:27, Dino Farinacci wrote: >>> >>> I am not sure if we should make this distinction. What does the WG think? >> Because fields marked “reserved†are obviously unassigned and don’t know if >> they will be assigned in the future. >>> >>> So I am not sure how helpful in making the distinction. >>> >>> Dino >>> >>>> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com wrote: >>>> >>>> Hi Dino, all, >>>> >>>> Apologies for raising this late easy to fix comment: >>>> >>>> RFC8126 says the following: >>>> >>>> Unassigned: Not currently assigned, and available for assignment >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> via documented procedures. While it's generally clear that >>>> any values that are not registered are unassigned and >>>> available for assignment, it is sometimes useful to >>>> explicitly specify that situation. Note that this is >>>> distinctly different from "Reserved". >>>> >>>> Reserved: Not assigned and not available for assignment. >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> Reserved values are held for special uses, such as to extend >>>> the namespace when it becomes exhausted. "Reserved" is also >>>> sometimes used to designate values that had been assigned >>>> but are no longer in use, keeping them set aside as long as >>>> other unassigned values are available. Note that this is >>>> distinctly different from "Unassigned". >>>> >>>> This is well handled in Section 5.1, but not in other sections which are >> using Reserved instead of Unassigned as per RFC8126. >>>> >>>> It would be appropriate to update the text accordingly. Thank you. >>>> >>>> Cheers, >>>> Med >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Wed Oct 24 06:25: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 A4591127332 for ; Wed, 24 Oct 2018 06:25:30 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3nTFT0Et5DG for ; Wed, 24 Oct 2018 06:25:28 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B57124408 for ; Wed, 24 Oct 2018 06:25:28 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 42g9x2638Sz1ynC; Wed, 24 Oct 2018 15:25:26 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.86]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 42g9x25QHMz8sYX; Wed, 24 Oct 2018 15:25:26 +0200 (CEST) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORMAE.corporate.adroot.infra.ftgroup ([fe80::897f:9a74:3898:db87%21]) with mapi id 14.03.0415.000; Wed, 24 Oct 2018 15:25:26 +0200 From: To: "Joel M. Halpern" , Luigi Iannone , Dino Farinacci CC: "lisp@ietf.org" Thread-Topic: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned Thread-Index: AdRqpEd10cZL+uOwTGaba/yk/wtayQA91of6AAAtk1A= Date: Wed, 24 Oct 2018 13:25:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E02D2AE@OPEXCNORMAD.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 13:25:31 -0000 Sm9lbCwgDQoNCiJpcyBhIFJlc2VydmVkIGJpdCBmb3IgZnV0dXJlIHVzZSIgY29udHJhZGljdHMg d2l0aCBpdHMgZGVmaW5pdGlvbiBpbiBSRkM4MTI2IHdoaWNoIHNheXMgIlJlc2VydmVkOiAgTm90 IGFzc2lnbmVkIGFuZCBub3QgYXZhaWxhYmxlIGZvciBhc3NpZ25tZW50Ii4NCg0KVGhlIHRleHQg c2hvdWxkIGJlIHR3ZWFrZWQgSU1PIHRvIGF2b2lkIHRoYXQuIEZvciBleGFtcGxlLCANCg0KT0xE OiANCiAgICAgIFI6IFRoZSBSLWJpdCBpcyBhIFJlc2VydmVkIGJpdCBmb3IgZnV0dXJlIHVzZS4g IEl0IE1VU1QgYmUgc2V0IHRvIDANCiAgICAgICAgIG9uIHRyYW5zbWl0IGFuZCBNVVNUIGJlIGln bm9yZWQgb24gcmVjZWlwdC4NCk5FVzoNCg0KICAgICAgVTogVGhlIFUtYml0IGlzIHVuYXNzaWdu ZWQgYW5kIGF2YWlsYWJsZSBmb3IgZnV0dXJlIHVzZS4gIEl0IE1VU1QgYmUgc2V0IHRvIDANCiAg ICAgICAgIG9uIHRyYW5zbWl0IGFuZCBNVVNUIGJlIGlnbm9yZWQgb24gcmVjZWlwdC4NCg0KQ2hl ZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEpvZWwg TS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+IEVudm95w6nCoDogbWVy Y3JlZGkgMjQgb2N0b2JyZSAyMDE4IDE1OjE1DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRH SS9PTE47IEx1aWdpIElhbm5vbmU7IERpbm8gRmFyaW5hY2NpDQo+IENjwqA6IGxpc3BAaWV0Zi5v cmcNCj4gT2JqZXTCoDogUmU6IFtsaXNwXSBkcmFmdC1pZXRmLWxpc3AtcmZjNjgzM2Jpcy0xOTog UmVzZXJ2ZWQvVW5hc3NpZ25lZA0KPiANCj4gTWVkLCBqdXN0IHRvIGJlIGNsZWFyLiAgQXIgZXlv dSBzYXlpbmcgdGhhdCB3ZSBzaG91bGQgY2hhbmdlIHRoZSB3b3JkDQo+IFJlc2VydmVkIHRvIFVu YXNpZ25lZD8gIFRIZSB0ZXh0IHdvdWxkIHJlYWQgd2VpcmRseSwgYnV0IEkgY2FuIGxpdmUgd2l0 aA0KPiBpdC4gIFdlIG5lZWQgdG8ga2VlcCB0aGUgcmVzdCBvZiB0aGUgdGV4dCwgYXMgaXQgaXMg Y3JpdGljYWwgZm9yIGZ1dHVyZQ0KPiBpbnRlcm9wZXJhYmlsaXR5Lg0KPiANCj4gWW91cnMsDQo+ IEpvZWwNCj4gDQo+IE9uIDEwLzI0LzE4IDU6MjQgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20gd3JvdGU6DQo+ID4gSGkgTHVpZ2ksDQo+ID4NCj4gPiBGdWxseSBhZ3JlZSB0aGF0IGNo YW5naW5nIHRoZSB0ZXh0IGFuZCB1cGRhdGluZyB0aGUgZmlndXJlcyB3b3VsZCBiZQ0KPiBhcHBy b3ByaWF0ZS4NCj4gPg0KPiA+IFBsZWFzZSBub3RlIHRoYXQgYSBzaW1pbGFyIGFjdGlvbiBpcyBu ZWVkZWQgZm9yIGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMwYmlzLQ0KPiAyNCwgZS5nLiwNCj4gPg0K PiA+ICAgICBSOiBUaGUgUi1iaXQgaXMgYSBSZXNlcnZlZCBiaXQgZm9yIGZ1dHVyZSB1c2UuICBJ dCBNVVNUIGJlIHNldCB0byAwDQo+ID4gICAgICAgIG9uIHRyYW5zbWl0IGFuZCBNVVNUIGJlIGln bm9yZWQgb24gcmVjZWlwdC4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gRGXCoDogTHVpZ2kgSWFubm9uZSBbbWFp bHRvOmdneEBnaWdpeC5uZXRdDQo+ID4+IEVudm95w6nCoDogbWVyY3JlZGkgMjQgb2N0b2JyZSAy MDE4IDEwOjAxDQo+ID4+IMOAwqA6IERpbm8gRmFyaW5hY2NpDQo+ID4+IENjwqA6IEJPVUNBREFJ UiBNb2hhbWVkIFRHSS9PTE47IGxpc3BAaWV0Zi5vcmcNCj4gPj4gT2JqZXTCoDogUmU6IFtsaXNw XSBkcmFmdC1pZXRmLWxpc3AtcmZjNjgzM2Jpcy0xOTogUmVzZXJ2ZWQvVW5hc3NpZ25lZA0KPiA+ Pg0KPiA+PiBIaSBBbGwsDQo+ID4+DQo+ID4+IGRpc2NsYWltZXI6IHRoaXMgaXMgbXkgcGVyc29u YWwgcG9pbnQgb2Ygdmlldy4NCj4gPj4NCj4gPj4gSSBkaWRu4oCZdCBjYXRjaCBiZWZvcmUgdGhp cyBwYXJ0IG9mIFJGQyA4MTI2LiBUaGFua3MgTWVkIGZyb20gYnJpbmdpbmcgaXQNCj4gdXAuDQo+ ID4+DQo+ID4+IFdoaWxlIEkgdW5kZXJzdGFuZCBEaW5v4oCZcyByZXBseSwgYmVjYXVzZSBJIG15 IHNlbGYgYXMgd2VsbCBhbHdheXMgdGhvdWdodA0KPiA+PiDigJxyZXNlcnZlZCA9IGNhbiBiZSB1 c2VkIGluIHRoZSBmdXR1cmXigJ0sIEkgdGhpbmsgdGhhdCBNZWQgaXMgcmlnaHQuDQo+ID4+DQo+ ID4+IFRvIGJlIGNvbXBsaWFudCB3aXRoIFJGQyA4MTI2LCBhbmQgYmVjYXVzZSB3ZSBtYXkgbmVl ZCB0aG9zZSDigJxyZXNlcnZlZOKAnQ0KPiBiaXRzDQo+ID4+IGluIHRoZSBmdXR1cmUsIHdlIGJl dHRlciBtYXJrIHRoZW0gYXMg4oCcdW5hc3NpZ25lZOKAnS4NCj4gPj4gVGhpcyBtZWFucyBjaGFu Z2luZyB0aGUgdGV4dCBhbmQgY2xlYXJseSBzcGVsbCBvdXQgdGhhdCB0aGlzIGlzIGNvbmZvcm0g dG8NCj4gPj4gUkZDIDgxMjYgZGVmaW5pdGlvbnMuDQo+ID4+DQo+ID4+IEF0IHRoZSBlbmQsIGl0 IGlzIGFzIHNpbXBsZSBhcyBhZGRpbmcgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBpbiBzZWN0aW9u IDINCj4gPj4g4oCcUmVxdWlyZW1lbnRzIE5vdGF0aW9u4oCdOg0KPiA+Pg0KPiA+PiAJVGhlICDi gJxVbmFzc2lnbmVk4oCdIGFuZCDigJxSZXNlcnZlZOKAnSB0ZXJtaW5vbG9neSBmb3IgYml0cyBh bmQgZmllbGRzIG9mDQo+ID4+IAltZXNzYWdlcyBhbmQgaGVhZGVycyBkZWZpbmVkIGluIHRoaXMg ZG9jdW1lbnRzIGlzIHRoZSBXZWxsLUtub3duDQo+ID4+IAlSZWdpc3RyYXRpb24gU3RhdHVzIFRl cm1pbm9sb2d5IGRlZmluZWQgaW4gU2VjdGlvbiA2IG9mIFtSRkM4MTI2XS4NCj4gPj4NCj4gPj4N Cj4gPj4gVGhlbiB3ZSBqdXN0IHJlcGxhY2Ug4oCccmVzZXJ2ZWTigJ0gd2l0aCDigJx1bmFzc2ln bmVk4oCdIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50Lg0KPiA+Pg0KPiA+PiBDaWFvDQo+ID4+DQo+ ID4+IEwuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+PiBPbiAyMyBPY3QgMjAxOCwgYXQgMTg6Mjcs IERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPiB3cm90ZToNCj4gPj4+DQo+ID4+ PiBJIGFtIG5vdCBzdXJlIGlmIHdlIHNob3VsZCBtYWtlIHRoaXMgZGlzdGluY3Rpb24uIFdoYXQg ZG9lcyB0aGUgV0cgdGhpbms/DQo+ID4+IEJlY2F1c2UgZmllbGRzIG1hcmtlZCDigJxyZXNlcnZl ZOKAnSBhcmUgb2J2aW91c2x5IHVuYXNzaWduZWQgYW5kIGRvbuKAmXQga25vdw0KPiBpZg0KPiA+ PiB0aGV5IHdpbGwgYmUgYXNzaWduZWQgaW4gdGhlIGZ1dHVyZS4NCj4gPj4+DQo+ID4+PiBTbyBJ IGFtIG5vdCBzdXJlIGhvdyBoZWxwZnVsIGluIG1ha2luZyB0aGUgZGlzdGluY3Rpb24uDQo+ID4+ Pg0KPiA+Pj4gRGlubw0KPiA+Pj4NCj4gPj4+PiBPbiBPY3QgMjMsIDIwMTgsIGF0IDEyOjQ0IEFN LCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4gSGkg RGlubywgYWxsLA0KPiA+Pj4+DQo+ID4+Pj4gQXBvbG9naWVzIGZvciByYWlzaW5nIHRoaXMgbGF0 ZSBlYXN5IHRvIGZpeCBjb21tZW50Og0KPiA+Pj4+DQo+ID4+Pj4gUkZDODEyNiBzYXlzIHRoZSBm b2xsb3dpbmc6DQo+ID4+Pj4NCj4gPj4+PiAgICAgICBVbmFzc2lnbmVkOiAgTm90IGN1cnJlbnRs eSBhc3NpZ25lZCwgYW5kIGF2YWlsYWJsZSBmb3IgYXNzaWdubWVudA0KPiA+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eDQo+ID4+Pj4gICAgICAgICAgICAgdmlhIGRvY3VtZW50ZWQgcHJvY2VkdXJlcy4gIFdo aWxlIGl0J3MgZ2VuZXJhbGx5IGNsZWFyIHRoYXQNCj4gPj4+PiAgICAgICAgICAgICBhbnkgdmFs dWVzIHRoYXQgYXJlIG5vdCByZWdpc3RlcmVkIGFyZSB1bmFzc2lnbmVkIGFuZA0KPiA+Pj4+ICAg ICAgICAgICAgIGF2YWlsYWJsZSBmb3IgYXNzaWdubWVudCwgaXQgaXMgc29tZXRpbWVzIHVzZWZ1 bCB0bw0KPiA+Pj4+ICAgICAgICAgICAgIGV4cGxpY2l0bHkgc3BlY2lmeSB0aGF0IHNpdHVhdGlv bi4gIE5vdGUgdGhhdCB0aGlzIGlzDQo+ID4+Pj4gICAgICAgICAgICAgZGlzdGluY3RseSBkaWZm ZXJlbnQgZnJvbSAiUmVzZXJ2ZWQiLg0KPiA+Pj4+DQo+ID4+Pj4gICAgICAgUmVzZXJ2ZWQ6ICBO b3QgYXNzaWduZWQgYW5kIG5vdCBhdmFpbGFibGUgZm9yIGFzc2lnbm1lbnQuDQo+ID4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXg0KPiA+Pj4+ICAgICAgICAgICAgIFJlc2VydmVkIHZhbHVlcyBhcmUgaGVsZCBmb3Igc3Bl Y2lhbCB1c2VzLCBzdWNoIGFzIHRvIGV4dGVuZA0KPiA+Pj4+ICAgICAgICAgICAgIHRoZSBuYW1l c3BhY2Ugd2hlbiBpdCBiZWNvbWVzIGV4aGF1c3RlZC4gICJSZXNlcnZlZCIgaXMgYWxzbw0KPiA+ Pj4+ICAgICAgICAgICAgIHNvbWV0aW1lcyB1c2VkIHRvIGRlc2lnbmF0ZSB2YWx1ZXMgdGhhdCBo YWQgYmVlbiBhc3NpZ25lZA0KPiA+Pj4+ICAgICAgICAgICAgIGJ1dCBhcmUgbm8gbG9uZ2VyIGlu IHVzZSwga2VlcGluZyB0aGVtIHNldCBhc2lkZSBhcyBsb25nIGFzDQo+ID4+Pj4gICAgICAgICAg ICAgb3RoZXIgdW5hc3NpZ25lZCB2YWx1ZXMgYXJlIGF2YWlsYWJsZS4gIE5vdGUgdGhhdCB0aGlz IGlzDQo+ID4+Pj4gICAgICAgICAgICAgZGlzdGluY3RseSBkaWZmZXJlbnQgZnJvbSAiVW5hc3Np Z25lZCIuDQo+ID4+Pj4NCj4gPj4+PiBUaGlzIGlzIHdlbGwgaGFuZGxlZCBpbiBTZWN0aW9uIDUu MSwgYnV0IG5vdCBpbiBvdGhlciBzZWN0aW9ucyB3aGljaCBhcmUNCj4gPj4gdXNpbmcgUmVzZXJ2 ZWQgaW5zdGVhZCBvZiBVbmFzc2lnbmVkIGFzIHBlciBSRkM4MTI2Lg0KPiA+Pj4+DQo+ID4+Pj4g SXQgd291bGQgYmUgYXBwcm9wcmlhdGUgdG8gdXBkYXRlIHRoZSB0ZXh0IGFjY29yZGluZ2x5LiBU aGFuayB5b3UuDQo+ID4+Pj4NCj4gPj4+PiBDaGVlcnMsDQo+ID4+Pj4gTWVkDQo+ID4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBsaXNw IG1haWxpbmcgbGlzdA0KPiA+Pj4+IGxpc3BAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gbGlzcCBtYWlsaW5nIGxp c3QNCj4gPj4+IGxpc3BAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbGlzcA0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBsaXNwIG1haWxpbmcgbGlzdA0KPiA+IGxpc3BAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCj4gPg0K From nobody Wed Oct 24 06:26: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 251E0128A6E for ; Wed, 24 Oct 2018 06:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTlKtgldZdI7 for ; Wed, 24 Oct 2018 06:26:44 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168ED127332 for ; Wed, 24 Oct 2018 06:26:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D93B66C6498; Wed, 24 Oct 2018 06:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1540387603; bh=iXHQau9n+jon4SxLU0KaptYjgz+tsYZs0iTJBFCX0i0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aOPV2h4GpP4qgonjK0d5h/gC0WPdYYA43rf6nu3BgDw3dnqnsynaxHdXy2RbhLCQg v1r8ygG3c5eyxbg1NqpezAGJ+uo4BrhroJ6l3GbXNzma4Ef0JW2b1M463UETxvd7LQ wB/5ocu0KNIEUTiZtdKsKSIwXw38GOEe3o9SAMRY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 10F526C648B; Wed, 24 Oct 2018 06:26:42 -0700 (PDT) To: mohamed.boucadair@orange.com, "Joel M. Halpern" , Luigi Iannone , Dino Farinacci Cc: "lisp@ietf.org" References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E02D2AE@OPEXCNORMAD.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <1dceb38a-8c41-86dc-f3ff-5ba418c7dbce@joelhalpern.com> Date: Wed, 24 Oct 2018 09:26:41 -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: <787AE7BB302AE849A7480A190F8B93302E02D2AE@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 13:26:46 -0000 As long as we keep the second sentence, I am flexible regarding the wording of the first one. Yours, Joel On 10/24/18 9:25 AM, mohamed.boucadair@orange.com wrote: > Joel, > > "is a Reserved bit for future use" contradicts with its definition in RFC8126 which says "Reserved: Not assigned and not available for assignment". > > The text should be tweaked IMO to avoid that. For example, > > OLD: > R: The R-bit is a Reserved bit for future use. It MUST be set to 0 > on transmit and MUST be ignored on receipt. > NEW: > > U: The U-bit is unassigned and available for future use. It MUST be set to 0 > on transmit and MUST be ignored on receipt. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : mercredi 24 octobre 2018 15:15 >> À : BOUCADAIR Mohamed TGI/OLN; Luigi Iannone; Dino Farinacci >> Cc : lisp@ietf.org >> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned >> >> Med, just to be clear. Ar eyou saying that we should change the word >> Reserved to Unasigned? THe text would read weirdly, but I can live with >> it. We need to keep the rest of the text, as it is critical for future >> interoperability. >> >> Yours, >> Joel >> >> On 10/24/18 5:24 AM, mohamed.boucadair@orange.com wrote: >>> Hi Luigi, >>> >>> Fully agree that changing the text and updating the figures would be >> appropriate. >>> >>> Please note that a similar action is needed for draft-ietf-lisp-rfc6830bis- >> 24, e.g., >>> >>> R: The R-bit is a Reserved bit for future use. It MUST be set to 0 >>> on transmit and MUST be ignored on receipt. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Luigi Iannone [mailto:ggx@gigix.net] >>>> Envoyé : mercredi 24 octobre 2018 10:01 >>>> À : Dino Farinacci >>>> Cc : BOUCADAIR Mohamed TGI/OLN; lisp@ietf.org >>>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned >>>> >>>> Hi All, >>>> >>>> disclaimer: this is my personal point of view. >>>> >>>> I didn’t catch before this part of RFC 8126. Thanks Med from bringing it >> up. >>>> >>>> While I understand Dino’s reply, because I my self as well always thought >>>> “reserved = can be used in the futureâ€, I think that Med is right. >>>> >>>> To be compliant with RFC 8126, and because we may need those “reserved†>> bits >>>> in the future, we better mark them as “unassignedâ€. >>>> This means changing the text and clearly spell out that this is conform to >>>> RFC 8126 definitions. >>>> >>>> At the end, it is as simple as adding the following sentence in section 2 >>>> “Requirements Notationâ€: >>>> >>>> The “Unassigned†and “Reserved†terminology for bits and fields of >>>> messages and headers defined in this documents is the Well-Known >>>> Registration Status Terminology defined in Section 6 of [RFC8126]. >>>> >>>> >>>> Then we just replace “reserved†with “unassigned†throughout the document. >>>> >>>> Ciao >>>> >>>> L. >>>> >>>> >>>> >>>>> On 23 Oct 2018, at 18:27, Dino Farinacci wrote: >>>>> >>>>> I am not sure if we should make this distinction. What does the WG think? >>>> Because fields marked “reserved†are obviously unassigned and don’t know >> if >>>> they will be assigned in the future. >>>>> >>>>> So I am not sure how helpful in making the distinction. >>>>> >>>>> Dino >>>>> >>>>>> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com wrote: >>>>>> >>>>>> Hi Dino, all, >>>>>> >>>>>> Apologies for raising this late easy to fix comment: >>>>>> >>>>>> RFC8126 says the following: >>>>>> >>>>>> Unassigned: Not currently assigned, and available for assignment >>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> via documented procedures. While it's generally clear that >>>>>> any values that are not registered are unassigned and >>>>>> available for assignment, it is sometimes useful to >>>>>> explicitly specify that situation. Note that this is >>>>>> distinctly different from "Reserved". >>>>>> >>>>>> Reserved: Not assigned and not available for assignment. >>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> Reserved values are held for special uses, such as to extend >>>>>> the namespace when it becomes exhausted. "Reserved" is also >>>>>> sometimes used to designate values that had been assigned >>>>>> but are no longer in use, keeping them set aside as long as >>>>>> other unassigned values are available. Note that this is >>>>>> distinctly different from "Unassigned". >>>>>> >>>>>> This is well handled in Section 5.1, but not in other sections which are >>>> using Reserved instead of Unassigned as per RFC8126. >>>>>> >>>>>> It would be appropriate to update the text accordingly. Thank you. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>> From nobody Wed Oct 24 09:29:46 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C3A130DED for ; Wed, 24 Oct 2018 09:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 zW_XO-A6Q3w9 for ; Wed, 24 Oct 2018 09:29:42 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB3612D4E8 for ; Wed, 24 Oct 2018 09:29:42 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id l81-v6so2686330pfg.3 for ; Wed, 24 Oct 2018 09:29: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=HsMlDzh7PdTv9fNRNDRQ7V1L1ETX7CRjsGVaI6wr7dE=; b=jxI28C6U9tJ/8eQx7GXBM1+AYe/zbhVSa4Bd1lSXGJJFMqSs2q3NDsq7Ha21Z93pzI 1qgKVobANqz6aP6uszmR2ilkHI/RiWU7EYz7DeIkpVQxUJpQmT0N8Xde7pS+EHoVH5Qd UirdEL6bUC7RxFrhaDRufe4lm+T2/qRCEsk77j4pemPxErCAE+o5G2fjJnybPJebJN2g lFNjEJN09GQExstThnX/5fR8UM32fycfvpF111SvSs9AFLHTN+Dg/Qda4DzqZgWyEB5M PD/3qWniSbIIfT2SPPcctPYE+OjQQ6PXk7AnHdbeIEBE8xWP/WLF5w2HOidYNL9npCsG PXOg== 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=HsMlDzh7PdTv9fNRNDRQ7V1L1ETX7CRjsGVaI6wr7dE=; b=f+NxlhkZA2MiLFd9iuRD+ZxR7SBDrEFOEQIYrUEmiN8NkpbSlGV2qAzhEH96wexAnY eEAchxDs2RhcTbexYZM2ykDX77TA7DMx9kWTKBoqIEPe0Pi/SdQEXh2XKBKpJ4yaSHKf rMlmfgjz+GrhUYvUeqrX40IxgMnqWbY5HAkVDtQ6GNONtFa818UKtqr3Vvs/TaS2g0tf d42GbKowQ5s4UdwGI9b8Q62yab9HFVwRivXGrktvRrsV1BqgI/dmqwsR7qwMzfFcFo+V AKShvEGykhemkGaPcVwR+U5sCDSos9IUEl2cq31V65bF1yRprLgUzv98PzVD/R8qJfdx CZaw== X-Gm-Message-State: AGRZ1gInXvwFl58a/uSFMvFu4k7aZrWUAK8SLIq1pDVrNEbKg1GYTqox jZ/o75EtfkHZfw3PfSf6Mo435iUQ X-Google-Smtp-Source: AJdET5c9Ns9VnMIMSPDjzCkX62mqlvoVTuF8erPmlcibgcJLAt7Ltu65XOpgk07RLoS9DCGLl9HDGg== X-Received: by 2002:a63:b54f:: with SMTP id u15mr3147159pgo.420.1540398582006; Wed, 24 Oct 2018 09:29:42 -0700 (PDT) Received: from [192.168.243.99] (soln-sr3455.solutionip.com. [70.233.112.2]) by smtp.gmail.com with ESMTPSA id y8-v6sm16202422pfd.168.2018.10.24.09.29.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 09:29:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <63BE166E-8166-478D-828E-087511AD4D4C@gigix.net> Date: Wed, 24 Oct 2018 09:29:40 -0700 Cc: "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <9DD26E9E-967D-4F66-80FF-509E91117105@gmail.com> References: <153877793727.1026.1146854495726676148.idtracker@ietfa.amsl.com> <1B08CE0F-6AA0-49C1-8A36-F562844F83DD@gigix.net> <63BE166E-8166-478D-828E-087511AD4D4C@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] [Call for Agenda Items] IETF 103 Preliminary Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 16:29:45 -0000 I=E2=80=99d like to give an update on draft-ietf-lisp-ecdsa-auth-00. 10 = minutes should do it. Dino > On Oct 24, 2018, at 4:16 AM, Luigi Iannone wrote: >=20 > Hi All, >=20 > hereafter the current LISP WG Preliminary Agenda. >=20 > As you can see we still have more than a hour that is unallocated. >=20 > Please, if you have anything you want to share with the WG drop an = email to there chairs. >=20 > Ciao >=20 > L. >=20 > CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com > ) > Luigi Iannone ( ggx AT=20 > gigix.net > ) >=20 > SECRETARY: Wassim Haddad ( wassim.haddad AT=20 > ericsson.com > ) > Padma Pillay-Esnault ( padma.ietf AT=20 > gmail.com > ) >=20 >=20 > AGENDA >=20 > Session 1/1 (120 Minutes) > =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=20 > Monday, November 5, 2018 > 9:00 - 11:00, Morning Session I, 120 Minutes > Room: Boromphimarn 3 >=20 > - Administration > Halpern/Iannone > - Blue Sheets > - Agenda Bashing > - Status reports for WG drafts > 5 Minutes (Cumulative Time: 5 Minutes) >=20 >=20 >=20 > o WG Items >=20 > - LISP YANG Model - draft-ietf-lisp-yang-08.txt > 10 Minutes (Cumulative Time: 15 Minutes) > Reshad Rahman >=20 > - Update on 6830bis/6833bis documents > 20 Minutes (Cumulative Time: 35 Minutes) >=20 > - LISP EID Anonimity - draft-ietf-lisp-eid-anonymity-04 > 10 Minutes (Cumulative Time: 45 Minutes) >=20 >=20 >=20 >=20 > o Non WG Items >=20 > - Overflow Time/ Discussion > 75 Minutes (Cumulative Time: 120 Minutes) >=20 >=20 >=20 >=20 >=20 >=20 >> On 7 Oct 2018, at 23:58, Luigi Iannone wrote: >>=20 >> Folks, >>=20 >> The preliminary agenda has been published. >> We will meet Monday Morning 5 November. >>=20 >> While the agenda is still subject to changes it is time to think = about presentation slots. >>=20 >> Please send your requests for agenda items (Presenter=E2=80=99s name, = title, slot duration)=20 >> to lisp-chairs@tools.ietf.org >>=20 >> Ciao >>=20 >> L. >>=20 >>> Begin forwarded message: >>>=20 >>> From: IETF Agenda >>> Subject: [Recentattendees] IETF 103 Preliminary Agenda >>> Date: 6 October 2018 at 00:18:57 CEST >>> To: "IETF Announcement List" >>> Cc: recentattendees@ietf.org, ietf@ietf.org, 103all@ietf.org >>> Reply-To: agenda@ietf.org >>>=20 >>> IETF 103 >>> Bangkok, Thailand >>> November 3-9, 2018 >>> Hosts: Huawei and Cisco >>>=20 >>> The IETF 103 Preliminary Agenda has been posted. The final agenda = will be published on Friday, October 12, 2018.=20 >>>=20 >>> https://datatracker.ietf.org/meeting/103/agenda.html >>> https://datatracker.ietf.org/meeting/103/agenda.txt >>>=20 >>>=20 >>> IETF 103 Information: https://www.ietf.org/how/meetings/103/ >>> Register online at: https://www.ietf.org/how/meetings/register/ >>>=20 >>> Don=E2=80=99t forget to register for these exciting IETF 103 events! >>>=20 >>> Hackathon=20 >>> Signup: = https://www.ietf.org/registration/ietf103/hackathonregistration.py >>> More information: = https://www.ietf.org/how/runningcode/hackathons/103-hackathon/ >>> Keep up to date by subscribing to:=20 >>> https://www.ietf.org/mailman/listinfo/hackathon >>>=20 >>> Code Sprint >>> Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103SprintSignUp >>> More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103Sprint >>>=20 >>> _______________________________________________ >>> Recentattendees mailing list >>> Recentattendees@ietf.org >>> https://www.ietf.org/mailman/listinfo/recentattendees >>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Oct 24 13:08:31 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D75124C04 for ; Wed, 24 Oct 2018 13:08:30 -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 5rncjN6e1rgJ for ; Wed, 24 Oct 2018 13:08:28 -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 3956C124BE5 for ; Wed, 24 Oct 2018 13:08:28 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id r64-v6so2954885pfb.13 for ; Wed, 24 Oct 2018 13:08:28 -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=uZmvIdSBTsrf/H0VfFmYh5R89fUKU94FFJOYaggVr1c=; b=KVT3MGnT30/ckfoZ7l7hdodvqgm1Q4OJT8ruDjpaAugttQddccJYbhhOEHvGuu/1hU q2fBD1oZUCqVy9t4L2qf54k5wbwYlViiGDogm7tHnoPqIS+/Jg8IfE5Z+M8d5yjYy5Vb fzH6W9km9PEj0atHPHwgENHQl20+H6BOSUATxAnEX9KgZTrZwqsJ/2+29aPPfAFYugkY lqvf7crCNABinjABps2g1uU/8qb4bbkg3WAyR4hkbJWYABEqNBzlwRK2aoTv+Xseo607 snHUyhDpAvnqjhByuafopcWEF3z+bvYt2aTJlPgW6zt9dOR4q7zoFVaySjA/vhqi6sOu u0fA== 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=uZmvIdSBTsrf/H0VfFmYh5R89fUKU94FFJOYaggVr1c=; b=rWFeudEFKNZEDErVcwKNBPG8JCumPR4MUN1mECeJLzurkQFItnEr7A/g5KxZb3ue0K y9Jqdni2qu/MlCsumAf8eC4PjxtLsdBQUi/XaMtlR3kZhuyeegzkljUd/wVii2VlKyAd Wk4TI2vlFamznCIMv24FsGGt96drbdNnyL7weCJpkfthV9v+TdV/WU9RXcJ+l6+/8NoD ByV7ZTsrWaNHkF1JQSJALXoYf8OktGs+iXdaHc/tj81APzuxtCRDn/cvwfDq+n3896T+ uPaDxmZl6Z6c7LiX6tNxPixRROirX354RAnPhzM6PCxfD6mn3uyYapOTgjN+JRX1Upr/ h5yg== X-Gm-Message-State: AGRZ1gIwTDaLcOwrKKBJr+lp0FaqIpXmyTKYrHneGRMWtTAl7hMjtQd+ IfJ5SLAG9KYPpwRpn6hjEsc= X-Google-Smtp-Source: AJdET5fOmxohCAao4jmNLG45e6XJy6Uv43dJzDyBEar3NFh+KoSXsHW1Kfiow1t5VHcG+RxXQKj/6w== X-Received: by 2002:a65:55ca:: with SMTP id k10mr341067pgs.448.1540411707559; Wed, 24 Oct 2018 13:08:27 -0700 (PDT) Received: from [192.168.243.99] (soln-sr3455.solutionip.com. [70.233.112.2]) by smtp.gmail.com with ESMTPSA id x186-v6sm6829164pfx.152.2018.10.24.13.08.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 13:08:26 -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: <787AE7BB302AE849A7480A190F8B93302E02D2AE@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Date: Wed, 24 Oct 2018 13:08:25 -0700 Cc: "Joel M. Halpern" , Luigi Iannone , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4C25E425-5FB8-4998-87B5-54B20ED21DEA@gmail.com> References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E02D2AE@OPEXCNORMAD.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 20:08:31 -0000 I believe to be crystal clear, we should use the text =E2=80=9Creserved = and unassigned=E2=80=9D everywhere. I do not want to change names of = bits or else they may clash with other fields. Dino > On Oct 24, 2018, at 6:25 AM, mohamed.boucadair@orange.com wrote: >=20 > Joel,=20 >=20 > "is a Reserved bit for future use" contradicts with its definition in = RFC8126 which says "Reserved: Not assigned and not available for = assignment". >=20 > The text should be tweaked IMO to avoid that. For example,=20 >=20 > OLD:=20 > R: The R-bit is a Reserved bit for future use. It MUST be set to = 0 > on transmit and MUST be ignored on receipt. > NEW: >=20 > U: The U-bit is unassigned and available for future use. It MUST = be set to 0 > on transmit and MUST be ignored on receipt. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoy=C3=A9 : mercredi 24 octobre 2018 15:15 >> =C3=80 : BOUCADAIR Mohamed TGI/OLN; Luigi Iannone; Dino Farinacci >> Cc : lisp@ietf.org >> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned >>=20 >> Med, just to be clear. Ar eyou saying that we should change the word >> Reserved to Unasigned? THe text would read weirdly, but I can live = with >> it. We need to keep the rest of the text, as it is critical for = future >> interoperability. >>=20 >> Yours, >> Joel >>=20 >> On 10/24/18 5:24 AM, mohamed.boucadair@orange.com wrote: >>> Hi Luigi, >>>=20 >>> Fully agree that changing the text and updating the figures would be >> appropriate. >>>=20 >>> Please note that a similar action is needed for = draft-ietf-lisp-rfc6830bis- >> 24, e.g., >>>=20 >>> R: The R-bit is a Reserved bit for future use. It MUST be set to = 0 >>> on transmit and MUST be ignored on receipt. >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : Luigi Iannone [mailto:ggx@gigix.net] >>>> Envoy=C3=A9 : mercredi 24 octobre 2018 10:01 >>>> =C3=80 : Dino Farinacci >>>> Cc : BOUCADAIR Mohamed TGI/OLN; lisp@ietf.org >>>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: = Reserved/Unassigned >>>>=20 >>>> Hi All, >>>>=20 >>>> disclaimer: this is my personal point of view. >>>>=20 >>>> I didn=E2=80=99t catch before this part of RFC 8126. Thanks Med = from bringing it >> up. >>>>=20 >>>> While I understand Dino=E2=80=99s reply, because I my self as well = always thought >>>> =E2=80=9Creserved =3D can be used in the future=E2=80=9D, I think = that Med is right. >>>>=20 >>>> To be compliant with RFC 8126, and because we may need those = =E2=80=9Creserved=E2=80=9D >> bits >>>> in the future, we better mark them as =E2=80=9Cunassigned=E2=80=9D. >>>> This means changing the text and clearly spell out that this is = conform to >>>> RFC 8126 definitions. >>>>=20 >>>> At the end, it is as simple as adding the following sentence in = section 2 >>>> =E2=80=9CRequirements Notation=E2=80=9D: >>>>=20 >>>> The =E2=80=9CUnassigned=E2=80=9D and =E2=80=9CReserved=E2=80=9D = terminology for bits and fields of >>>> messages and headers defined in this documents is the Well-Known >>>> Registration Status Terminology defined in Section 6 of = [RFC8126]. >>>>=20 >>>>=20 >>>> Then we just replace =E2=80=9Creserved=E2=80=9D with = =E2=80=9Cunassigned=E2=80=9D throughout the document. >>>>=20 >>>> Ciao >>>>=20 >>>> L. >>>>=20 >>>>=20 >>>>=20 >>>>> On 23 Oct 2018, at 18:27, Dino Farinacci = wrote: >>>>>=20 >>>>> I am not sure if we should make this distinction. What does the WG = think? >>>> Because fields marked =E2=80=9Creserved=E2=80=9D are obviously = unassigned and don=E2=80=99t know >> if >>>> they will be assigned in the future. >>>>>=20 >>>>> So I am not sure how helpful in making the distinction. >>>>>=20 >>>>> Dino >>>>>=20 >>>>>> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com wrote: >>>>>>=20 >>>>>> Hi Dino, all, >>>>>>=20 >>>>>> Apologies for raising this late easy to fix comment: >>>>>>=20 >>>>>> RFC8126 says the following: >>>>>>=20 >>>>>> Unassigned: Not currently assigned, and available for = assignment >>>>>> = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> via documented procedures. While it's generally clear = that >>>>>> any values that are not registered are unassigned and >>>>>> available for assignment, it is sometimes useful to >>>>>> explicitly specify that situation. Note that this is >>>>>> distinctly different from "Reserved". >>>>>>=20 >>>>>> Reserved: Not assigned and not available for assignment. >>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> Reserved values are held for special uses, such as to = extend >>>>>> the namespace when it becomes exhausted. "Reserved" = is also >>>>>> sometimes used to designate values that had been = assigned >>>>>> but are no longer in use, keeping them set aside as = long as >>>>>> other unassigned values are available. Note that this = is >>>>>> distinctly different from "Unassigned". >>>>>>=20 >>>>>> This is well handled in Section 5.1, but not in other sections = which are >>>> using Reserved instead of Unassigned as per RFC8126. >>>>>>=20 >>>>>> It would be appropriate to update the text accordingly. Thank = you. >>>>>>=20 >>>>>> Cheers, >>>>>> Med >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 From nobody Wed Oct 24 20:05: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 42EC6130E95 for ; Wed, 24 Oct 2018 20:05:03 -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 1DxPRgm7oHxE for ; Wed, 24 Oct 2018 20:04:54 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F21B130DCD for ; Wed, 24 Oct 2018 20:04:54 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id 22-v6so3456196pfz.0 for ; Wed, 24 Oct 2018 20:04:54 -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=9QtYE9NI55WOHm7Y96K0RlwgGKPusBEUnPOnjDO7TUM=; b=HuE39vX1OgQsv8LEEFnq3BdM0F/1XzajFrCdCJKqxjk9wSWz9KGGCZ3ATedUWVKOg5 Z1fFiklW0emqS6nRC6vA8FRCZnJlqo19ip+9v5n8AKFei71wbhWT25iv9ibYzTTUGTEG /YTAQPbjRsr6USgUHMpHwbCtH7rZBKlpaK9MMGamzmGvJCl6Tbep+LCXRWTzsoEpK5kX SZS4TYQiLsEG22WflCy0LMtv3N7QUD7Soxw+ZezXei9BYwKENvI+tt4em2omSNFkq0wD i9lR+XEotcZw15Kdz9g6oubDfP5FvIRdkBsHlfv0pKKcWl679QKfThVpfnLXrxxTgxFw ckng== 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=9QtYE9NI55WOHm7Y96K0RlwgGKPusBEUnPOnjDO7TUM=; b=ayfnKEiVnP7XgSddftUb1JbjvYNBXcXOLb015JkLCrjBikHXkrP87eU0/hJxlZPNsF 0s0bLHHFZlfQ/2mvFmprtbZVdugT0BhJ0DX6UJA2C2YFl31cCzwfcxO6r/QMdwX0LFGd cYFDGQGJOF7/wOZv7o7gdEljU21N/EQ8aYMd46B9cnr30Ii0qj+WjqcUGX0r3bVRGBps OVr48XjHl9JqdgsbstUJIKLhm2GkjAxMBEEqIzZCCAtFBI92saV8RUVqxNs3c9R51Jkm 3Fn/4AHZjB99x3dsH4wn+y64+YOKxTYxj9ddT+n+gVCFGISAiiWkQW/TZ3D2Bk+fIbGV 6LTQ== X-Gm-Message-State: AGRZ1gJOr44GIOwZYzeUVWRYAeWVHhtg2Jc9HF0hPi0ZO0iGMYF8rJGD z4k3mww0vR0A9PZN+6JBt28= X-Google-Smtp-Source: AJdET5d7QIEg6Zq+LL9q6tF/yv3Z3kuox5fp31sLry6DhZfqs6hWcMobaGAKKHGujjMWm666u47nmQ== X-Received: by 2002:a63:310:: with SMTP id 16mr4800616pgd.79.1540436693984; Wed, 24 Oct 2018 20:04:53 -0700 (PDT) Received: from ?IPv6:2603:3024:151c:55f0:48b1:93eb:734d:3b9e? ([2603:3024:151c:55f0:48b1:93eb:734d:3b9e]) by smtp.gmail.com with ESMTPSA id l1-v6sm7015637pgm.8.2018.10.24.20.04.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 20:04:52 -0700 (PDT) From: Dino Farinacci Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_96BE765C-1240-4197-8E89-2E9BBC56B3B9" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 24 Oct 2018 20:04:49 -0700 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Cc: Luigi Iannone , "lisp@ietf.org" To: mohamed.boucadair@orange.com References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 03:05:04 -0000 --Apple-Mail=_96BE765C-1240-4197-8E89-2E9BBC56B3B9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii How about these changes? So we can not over complicate this. Dino --Apple-Mail=_96BE765C-1240-4197-8E89-2E9BBC56B3B9 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-25.txt - = draft-ietf-lisp-rfc6830bis-26.txt=20 =20 =20 =20 =20 =20 =20
< draft-ietf-lisp-rfc6830bis-25.txt  =  draft-ietf-lisp-rfc6830bis-26.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: April = 24, 2019 = Cisco Systems Expires: April 27, 2019 Cisco = Systems
= A. Cabellos (Ed.) = A. Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= October 21, 2018 = October 24, 2018
=
= The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol = (LISP)
= draft-ietf-lisp-rfc6830bis-25 = = draft-ietf-lisp-rfc6830bis-26
=
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 April 24, = 2019. This Internet-Draft will = expire on April 27, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 3, line 7 =C2=B6 = skipping to change at page 3, line 7 =C2=B6
16. Security = Considerations . . . . . . . . . . . . . . . . . . . 32 = 16. Security Considerations . . . . . . . . = . . . . . . . . . . . 32
17. Network = Management Considerations . . . . . . . . . . . . . . 33 = 17. Network Management Considerations . . . = . . . . . . . . . . . 33
18. Changes = since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 = 18. Changes since RFC 6830 . . . . . . . . = . . . . . . . . . . . 33
19. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 34 = 19. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 34
19.1. LISP = UDP Port Numbers . . . . . . . . . . . . . . . . . 34 = 19.1. LISP UDP Port Numbers . . . . . . = . . . . . . . . . . . 34
20. References = . . . . . . . . . . . . . . . . . . . . . . . . . 34 20. References . . . . . . . . . . . . . . . . . . . = . . . . . . 34
20.1. = Normative References . . . . . . . . . . . . . . . . . . 34 = 20.1. Normative References . . . . . . . = . . . . . . . . . . . 34
20.2. = Informative References . . . . . . . . . . . . . . . . . 35 = 20.2. Informative References . . . . . . = . . . . . . . . . . . 35
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 39 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 40 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 40
B.1. = Changes to draft-ietf-lisp-rfc6830bis-24 = . . . . . . . . 40 B.1. = Changes to draft-ietf-lisp-rfc6830bis-26 = . . . . . . . . 40
B.2. = Changes to draft-ietf-lisp-rfc6830bis-24 = . . . . . . . . 40 B.2. = Changes to draft-ietf-lisp-rfc6830bis-25 = . . . . . . . . 40
B.3. = Changes to draft-ietf-lisp-rfc6830bis-23 = . . . . . . . . 40 B.3. = Changes to draft-ietf-lisp-rfc6830bis-24 = . . . . . . . . 40
B.4. = Changes to draft-ietf-lisp-rfc6830bis-22 = . . . . . . . . 40 B.4. = Changes to draft-ietf-lisp-rfc6830bis-23 = . . . . . . . . 40
B.5. = Changes to draft-ietf-lisp-rfc6830bis-21 = . . . . . . . . 40 B.5. = Changes to draft-ietf-lisp-rfc6830bis-22 = . . . . . . . . 40
B.6. = Changes to draft-ietf-lisp-rfc6830bis-20 = . . . . . . . . 40 B.6. = Changes to draft-ietf-lisp-rfc6830bis-21 = . . . . . . . . 40
B.7. = Changes to draft-ietf-lisp-rfc6830bis-19 = . . . . . . . . 41 B.7. = Changes to draft-ietf-lisp-rfc6830bis-20 = . . . . . . . . 41
B.8. = Changes to draft-ietf-lisp-rfc6830bis-18 = . . . . . . . . 41 B.8. = Changes to draft-ietf-lisp-rfc6830bis-19 = . . . . . . . . 41
B.9. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 41 B.9. = Changes to draft-ietf-lisp-rfc6830bis-18 = . . . . . . . . 41
B.10. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 41 B.10. = Changes to draft-ietf-lisp-rfc6830bis-17 = . . . . . . . . 41
B.11. = Changes to draft-ietf-lisp-rfc6830bis-15 = . . . . . . . . 41 B.11. = Changes to draft-ietf-lisp-rfc6830bis-16 = . . . . . . . . 41
B.12. = Changes to draft-ietf-lisp-rfc6830bis-14 = . . . . . . . . 41 B.12. = Changes to draft-ietf-lisp-rfc6830bis-15 = . . . . . . . . 41
B.13. = Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 42 B.13. = Changes to draft-ietf-lisp-rfc6830bis-14 = . . . . . . . . 42
B.14. = Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 42 B.14. = Changes to draft-ietf-lisp-rfc6830bis-13 = . . . . . . . . 42
B.15. = Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 42 B.15. = Changes to draft-ietf-lisp-rfc6830bis-12 = . . . . . . . . 42
B.16. = Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 42 B.16. = Changes to draft-ietf-lisp-rfc6830bis-11 = . . . . . . . . 42
B.17. = Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 42 B.17. = Changes to draft-ietf-lisp-rfc6830bis-10 = . . . . . . . . 42
B.18. = Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 43 B.18. = Changes to draft-ietf-lisp-rfc6830bis-09 = . . . . . . . . 43
B.19. = Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 43 B.19. = Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 43
B.20. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 43 B.20. = Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 43
B.21. = Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 44 = B.21. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . = 43
B.22. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 44 B.22. Changes to = draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 44
B.23. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 44 B.23. Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 44
B.24. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 44 B.24. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 44
B.25. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 44 B.25. Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 44
B.26. Changes to draft-ietf-lisp-rfc6830bis-00 = . . . . . . . . 45 B.26. Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 44
= B.27. = Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 45
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 45
=
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 17, line 45 =C2=B6 = skipping to change at page 17, line = 45 =C2=B6
are = transmitted as zero and ignored on receipt. The format of the = are transmitted as zero and ignored on = receipt. The format of the
LISP header = would look like this: LISP = header would look like this:
=
x x x x 1 x = x x x x x x 1 x x x
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= |N|L|E|V|I|R|K|K| Nonce/Map-Version = | |N|L|E|V|I|R|K|K| = Nonce/Map-Version |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Instance ID | LSBs | | Instance ID | = LSBs |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
R: The R-bit = is a Reserved bit for future use. It MUST be set to 0 R: The R-bit is a Reserved and = unassigned bit for future use. It
on = transmit and MUST be ignored on receipt. MUST be set to 0 on transmit and MUST be ignored = on receipt.
=
KK: The = KK-bits are a 2-bit field used when encapsulated packets are = KK: The KK-bits are a 2-bit field used when = encapsulated packets are
encrypted. = The field is set to 00 when the packet is not encrypted. The field is set to 00 when the packet = is not
encrypted. = See [RFC8061] for further information. = encrypted. See [RFC8061] for further information.
=
LISP Nonce: = The LISP 'Nonce' field is a 24-bit value that is LISP Nonce: The LISP 'Nonce' field is a 24-bit value = that is
randomly = generated by an ITR when the N-bit is set to 1. Nonce randomly generated by an ITR when the N-bit is set = to 1. Nonce
generation = algorithms are an implementation matter but are generation algorithms are an implementation matter = but are
required to = generate different nonces when sending to different required to generate different nonces when sending = to different
RLOCs. = However, the same nonce can be used for a period of time = RLOCs. However, the same nonce can be = used for a period of time
=
skipping to = change at = page 34, line 5 =C2=B6 = skipping to change at page 34, line 5 =C2=B6
=
o It is no = longer mandated that a maximum number of 2 LISP headers = 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 = be prepended to a packet. If there is a = application need for more
than 2 LISP = headers, an implementation can support more. However, than 2 LISP headers, an implementation can support = more. However,
it is = RECOMMENDED that a maximum of two LISP headers can be it is RECOMMENDED that a maximum of two LISP = headers can be
prepended = to a packet. prepended to a = packet.
=
o The 3 = reserved flag bits in the LISP header have been allocated = o The 3 reserved flag bits in the LISP = header have been allocated
for = [RFC8061]. The low-order 2 bits of the 3-bit field (now named = for [RFC8061]. The low-order 2 bits of = the 3-bit field (now named
the KK = bits) are used as a key identifier. The 1 remaining bit is = the KK bits) are used as a key = identifier. The 1 remaining bit is
still = documented as reserved. still = documented as reserved and = unassigned.
=
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. = Any ITR implementations that depend on or assume the optional. Any ITR implementations that depend on = or assume the
remote ETR = is gleaning should not do so. This does not create any = remote ETR is gleaning should not do so. = This does not create any
= interoperability problems since the control-plane map-cache = interoperability problems since the = control-plane map-cache
population = procedures are unilateral and are the typical method population procedures are unilateral and are the = typical method
for = map-cache population. for = map-cache population.
=
o The bulk of = the changes to this document which reduces its length o The bulk of the changes to this document which = reduces its length
are due to = moving the LISP control-plane messaging and procedures are due to moving the LISP control-plane messaging = and procedures
=
skipping to = change at = page 34, line 44 =C2=B6 = skipping to change at page 34, line = 44 =C2=B6
20.1. Normative = References 20.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6833bis] = [I-D.ietf-lisp-rfc6833bis]
= Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. = Cabellos-Aparicio,
= "Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) = Control-Plane",
= draft-ietf-lisp-rfc6833bis-18 (work in = progress), October = draft-ietf-lisp-rfc6833bis-19 (work in = progress), October
= 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 40, line 12 =C2=B6 = skipping to change at page 40, line = 12 =C2=B6
Kaduk, Eric = Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, = Kaduk, Eric Rescorla, Alvaro Retana, Alexey = Melnikov, Alissa Cooper,
Suresh = Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed = Suresh Krishnan, Alberto Rodriguez-Natal, = Vina Ermagen, Mohamed
Boucadair, = Brian Trammell, Sabrina Tanamal, and John Drake. The Boucadair, Brian Trammell, Sabrina Tanamal, and John = Drake. The
contributions = they offered greatly added to the security, scale, and contributions they offered greatly added to the = security, scale, and
robustness of = the LISP architecture and protocols. = robustness of the LISP architecture and protocols.
=
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-24 = B.1. Changes to draft-ietf-lisp-rfc6830bis-26
=
= o Posted late = October 2018.
=
= o Changed = description about "reserved" bits to state "reserved and
= = unassigned".
=
= B.2. Changes to = draft-ietf-lisp-rfc6830bis-25
=
o Posted mid = October 2018. o Posted mid October = 2018.
=
o Added more = to the Security Considerations section with discussion o Added more to the Security Considerations section = with discussion
about = echo-nonce attacks. about = echo-nonce attacks.
=
B.2. Changes to = draft-ietf-lisp-rfc6830bis-24 B.3. Changes to = draft-ietf-lisp-rfc6830bis-24
=
o Posted mid = October 2018. o Posted mid October = 2018.
=
o Final = editorial changes for Eric and Ben. = o Final editorial changes for Eric and Ben.
=
B.3. Changes to = draft-ietf-lisp-rfc6830bis-23 B.4. Changes to = draft-ietf-lisp-rfc6830bis-23
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Added an = applicability statement in section 1 to address security = o Added an applicability statement in = section 1 to address security
concerns = from Telechat. concerns from = Telechat.
=
B.4. Changes to = draft-ietf-lisp-rfc6830bis-22 B.5. Changes to = draft-ietf-lisp-rfc6830bis-22
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Changes to = reflect comments post Telechat. o = Changes to reflect comments post Telechat.
=
B.5. Changes to = draft-ietf-lisp-rfc6830bis-21 B.6. Changes to = draft-ietf-lisp-rfc6830bis-21
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o Changes to = reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th = Telechat.
=
B.6. Changes to = draft-ietf-lisp-rfc6830bis-20 B.7. Changes to = draft-ietf-lisp-rfc6830bis-20
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o Fix old = reference to RFC3168, changed to RFC6040. o Fix old reference to RFC3168, changed to = RFC6040.
=
B.7. Changes to = draft-ietf-lisp-rfc6830bis-19 B.8. Changes to = draft-ietf-lisp-rfc6830bis-19
=
o Posted = late-September 2018. o Posted = late-September 2018.
=
o More = editorial changes. o More = editorial changes.
=
B.8. Changes to = draft-ietf-lisp-rfc6830bis-18 B.9. Changes to = draft-ietf-lisp-rfc6830bis-18
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Secdir review (Mirja). o Changes to reflect comments from Secdir review = (Mirja).
=
B.9. Changes to = draft-ietf-lisp-rfc6830bis-17 B.10. Changes to = draft-ietf-lisp-rfc6830bis-17
=
o Posted = September 2018. o Posted September = 2018.
=
o Indicate in = the "Changes since RFC 6830" section why the document o Indicate in the "Changes since RFC 6830" section = why the document
has been = shortened in length. has been = shortened in length.
=
o Make = reference to RFC 8085 about UDP congestion control. o Make reference to RFC 8085 about UDP congestion = control.
=
o More = editorial changes from multiple IESG reviews. o More editorial changes from multiple IESG = reviews.
=
B.10. Changes to = draft-ietf-lisp-rfc6830bis-16 B.11. 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.11. Changes to = draft-ietf-lisp-rfc6830bis-15 B.12. Changes to = draft-ietf-lisp-rfc6830bis-15
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6830" so implementers are o Added section "Changes since RFC 6830" so = implementers are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.12. Changes to = draft-ietf-lisp-rfc6830bis-14 B.13. 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.13. Changes to = draft-ietf-lisp-rfc6830bis-13 B.14. 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.14. Changes to = draft-ietf-lisp-rfc6830bis-12 B.15. 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.15. Changes to = draft-ietf-lisp-rfc6830bis-11 B.16. 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.16. Changes to = draft-ietf-lisp-rfc6830bis-10 B.17. 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.17. Changes to = draft-ietf-lisp-rfc6830bis-09 B.18. 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.18. Changes to = draft-ietf-lisp-rfc6830bis-08 B.19. 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.19. Changes to = draft-ietf-lisp-rfc6830bis-07 B.20. 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.20. Changes to = draft-ietf-lisp-rfc6830bis-06 B.21. 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 44, line 9 =C2=B6 = skipping to change at page 44, line = 15 =C2=B6
o ETRs may, = rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send = Map-Replies.
=
o Recommend, = rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation = headers to 2.
=
o Reference = VPN draft when introducing Instance-ID. = o Reference VPN draft when introducing Instance-ID.
=
o Indicate = that SMRs can be sent when ITR/ETR are in the same node. = o Indicate that SMRs can be sent when = ITR/ETR are in the same node.
=
o Clarify = when private addresses can be used. = o Clarify when private addresses can be used.
=
B.21. Changes to = draft-ietf-lisp-rfc6830bis-05 B.22. Changes to = draft-ietf-lisp-rfc6830bis-05
=
o Posted = August 2017. o Posted August = 2017.
=
o Make it = clear that a Re-encapsulating Tunnel Router is an RTR. o Make it clear that a Re-encapsulating Tunnel = Router is an RTR.
=
B.22. Changes to = draft-ietf-lisp-rfc6830bis-04 B.23. 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.23. Changes to = draft-ietf-lisp-rfc6830bis-03 B.24. 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.24. Changes to = draft-ietf-lisp-rfc6830bis-02 B.25. 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.25. Changes to = draft-ietf-lisp-rfc6830bis-01 B.26. 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.26. Changes to = draft-ietf-lisp-rfc6830bis-00 B.27. 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. 34 change blocks. 
60 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=_96BE765C-1240-4197-8E89-2E9BBC56B3B9 Content-Disposition: attachment; filename=rfcdiff-6833bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6833bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-19.txt - = draft-ietf-lisp-rfc6833bis-20.txt=20 =20 =20 =20 =20 =20 =20 =
< draft-ietf-lisp-rfc6833bis-19.txt  =  draft-ietf-lisp-rfc6833bis-20.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: April = 24, 2019 = UPC/BarcelonaTech Expires: April = 27, 2019 = UPC/BarcelonaTech
= October 21, 2018 = October 24, 2018
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-19 = = draft-ietf-lisp-rfc6833bis-20
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = Control-Plane service interface and communicating with By using this Control-Plane service interface and = communicating with
=
skipping to = change at = page 1, line 47 =C2=B6 = skipping to change at page 1, line 47 =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 April 24, = 2019. This Internet-Draft will = expire on April 27, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 3, line 12 =C2=B6 = skipping to change at page 3, line 12 =C2=B6
12.2. LISP = Packet Type Codes . . . . . . . . . . . . . . . . . 43 = 12.2. LISP Packet Type Codes . . . . . . = . . . . . . . . . . . 43
12.3. LISP = ACT and Flag Fields . . . . . . . . . . . . . . . . 43 = 12.3. LISP ACT and Flag Fields . . . . . = . . . . . . . . . . . 43
12.4. LISP = Address Type Codes . . . . . . . . . . . . . . . . 44 = 12.4. LISP Address Type Codes . . . . . = . . . . . . . . . . . 44
12.5. LISP = Algorithm ID Numbers . . . . . . . . . . . . . . . 44 = 12.5. LISP Algorithm ID Numbers . . . . = . . . . . . . . . . . 44
12.6. LISP = Bit Flags . . . . . . . . . . . . . . . . . . . . . 45 = 12.6. LISP Bit Flags . . . . . . . . . . = . . . . . . . . . . . 45
13. References = . . . . . . . . . . . . . . . . . . . . . . . . . 48 13. References . . . . . . . . . . . . . . . . . . . = . . . . . . 48
13.1. = Normative References . . . . . . . . . . . . . . . . . . 48 = 13.1. Normative References . . . . . . . = . . . . . . . . . . . 48
13.2. = Informative References . . . . . . . . . . . . . . . . . 49 = 13.2. Informative References . . . . . . = . . . . . . . . . . . 49
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 53 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 53
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 53 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 53
B.1. = Changes to draft-ietf-lisp-rfc6833bis-18 = . . . . . . . . 53 B.1. = Changes to draft-ietf-lisp-rfc6833bis-19 = . . . . . . . . 53
B.2. = Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 53 = B.2. Changes to = draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 53
B.3. = Changes to draft-ietf-lisp-rfc6833bis-17 = . . . . . . . . 53 B.3. = Changes to draft-ietf-lisp-rfc6833bis-18 = . . . . . . . . 53
B.4. = Changes to draft-ietf-lisp-rfc6833bis-16 = . . . . . . . . 54 B.4. = Changes to draft-ietf-lisp-rfc6833bis-17 = . . . . . . . . 54
B.5. = Changes to draft-ietf-lisp-rfc6833bis-15 = . . . . . . . . 54 B.5. = Changes to draft-ietf-lisp-rfc6833bis-16 = . . . . . . . . 54
B.6. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 54 B.6. = Changes to draft-ietf-lisp-rfc6833bis-15 = . . . . . . . . 54
B.7. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 54 B.7. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 54
B.8. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 54 B.8. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 54
B.9. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 54 B.9. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . = 55
B.10. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 55 B.10. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 55
B.11. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 55 B.11. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 55
B.12. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 55 B.12. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 55
B.13. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 55 B.13. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 55
B.14. = Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 56 = B.14. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . = 55
B.15. Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 56 B.15. Changes to = draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 56
B.16. Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 56 B.16. Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 56
B.17. Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 57 B.17. Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 56
B.18. Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 57 B.18. Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 57
B.19. Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 57 B.19. Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 57
B.20. Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 57 B.20. Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 57
B.21. Changes to = draft-farinacci-lisp-rfc6833bis-00 . . . . . . 57 B.21. Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 57
= B.22. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 58
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 58
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol = [I-D.ietf-lisp-rfc6830bis] (see
also = [I-D.ietf-lisp-introduction]) specifies an architecture and = also [I-D.ietf-lisp-introduction]) specifies = an architecture and
mechanism for = dynamic tunneling by logically separating the addresses = mechanism for dynamic tunneling by logically = separating the addresses
currently used = by IP in two separate name spaces: Endpoint IDs currently used by IP in two separate name spaces: = Endpoint IDs
(EIDs), used = within sites; and Routing Locators (RLOCs), used on the = (EIDs), used within sites; and Routing = Locators (RLOCs), used on the
transit = networks that make up the Internet infrastructure. To transit networks that make up the Internet = infrastructure. To
=
skipping to = change at = page 13, line 15 =C2=B6 = skipping to change at page 13, line = 15 =C2=B6
S: This is the = Solicit-Map-Request (SMR) bit. See Solicit-Map- S: This is the Solicit-Map-Request (SMR) bit. See = Solicit-Map-
Request = (SMRs) Section 6.1 for details. = Request (SMRs) Section 6.1 for details.
=
p: This is the = PITR bit. This bit is set to 1 when a PITR sends a p: This is the PITR bit. This bit is set to 1 when a = PITR sends a
= Map-Request. = Map-Request.
=
s: This is the = SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 = when an xTR is
sending a = Map-Request in response to a received SMR-based Map- sending a Map-Request in response to a received = SMR-based Map-
= Request. Request.
=
R: This = reserved bit MUST be set to 0 on transmit and MUST be ignored = R: This reserved and = unassigned bit MUST be set to 0 on transmit and
on = receipt. MUST be ignored on = receipt.
=
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 18, line 11 =C2=B6 = skipping to change at page 18, line = 11 =C2=B6
= authentication information will be appended to the end of the = Map- authentication information = will be appended to the end of the Map-
Reply. The = details of signing a Map-Reply message can be found in Reply. The details of signing a Map-Reply message = can be found in
= [I-D.ietf-lisp-sec]. = [I-D.ietf-lisp-sec].
=
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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type = | Authentication Data Content . . . | | AD Type | Authentication Data Content = . . . |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Reserved: = This field MUST be set to 0 on transmit and MUST be Reserved: This unassigned field MUST be set to 0 on transmit = and
ignored = on receipt. MUST be ignored on = receipt.
=
Record Count: = This is the number of records in this reply message. Record Count: This is the number of records in this = reply message.
A record is = comprised of that portion of the packet labeled A record is comprised of that portion of the = packet labeled
'Record' = above and occurs the number of times equal to Record 'Record' above and occurs the number of times = equal to Record
= Count. Count.
=
Nonce: This = 64-bit value from the Map-Request is echoed in this Nonce: This 64-bit value from the Map-Request is = echoed in this
'Nonce' = field of the Map-Reply. 'Nonce' = field of the Map-Reply.
=
Record TTL: = This is the time in minutes the recipient of the Map- Record TTL: This is the time in minutes the = recipient of the Map-
=
skipping to = change at = page 25, line 5 =C2=B6 = skipping to change at page 25, line 5 =C2=B6
Type: 3 = (Map-Register) Type: 3 = (Map-Register)
=
P: This is the = proxy Map-Reply bit. When set to 1, an ETR sends a P: This is the proxy Map-Reply bit. When set to 1, = an ETR sends a
= Map-Register message requesting the Map-Server to proxy a Map- = Map-Register message requesting the = Map-Server to proxy a Map-
Reply. The = Map-Server will send non-authoritative Map-Replies on Reply. The Map-Server will send non-authoritative = Map-Replies on
behalf of = the ETR. behalf of the = ETR.
=
S: This is the = security-capable bit. When set, the procedures from S: This is the security-capable bit. When set, the = procedures from
= [I-D.ietf-lisp-sec] are supported. = [I-D.ietf-lisp-sec] are supported.
=
Reserved: = This field MUST be set to 0 on transmit and MUST be Reserved: This unassigned field MUST be set to 0 on transmit = and
ignored = on receipt. MUST be ignored on = receipt.
=
E: This is the = Map-Register EID-notify bit. This is used by a First- E: This is the Map-Register EID-notify bit. This is = used by a First-
Hop-Router = (FHR) which discovers a dynamic-EID. This EID-notify Hop-Router (FHR) which discovers a dynamic-EID. = This EID-notify
based = Map-Register is sent by the FHR to the same site xTR that = based Map-Register is sent by the FHR to = the same site xTR that
propogates = the Map-Register to the mapping system. The site xTR propogates the Map-Register to the mapping system. = The site xTR
keeps state = to later Map-Notify the FHR after the EID has moves keeps state to later Map-Notify the FHR after the = EID has moves
away. See = [I-D.ietf-lisp-eid-mobility] for a detailed use-case. away. See [I-D.ietf-lisp-eid-mobility] for a = detailed use-case.
=
T: This is the = use-TTL for timeout bit. When set to 1, the xTR wants T: This is the use-TTL for timeout bit. When set to = 1, the xTR wants
the = Map-Server to time out registrations based on the value in the = the Map-Server to time out registrations = based on the value in the
"Record = TTL" field of this message. Otherwise, the default "Record TTL" field of this message. Otherwise, = the default
timeout = described in Section 8.2 is used. = timeout described in Section 8.2 is used.
=
a: This is the = merge-request bit. When set to 1, the xTR requests to a: This is the merge-request bit. When set to 1, the = xTR requests to
merge = RLOC-records from different xTRs registering the same EID- = merge RLOC-records from different xTRs = registering the same EID-
record. = See signal-free multicast [RFC8378] for one use case record. See signal-free multicast [RFC8378] for = one use case
= example. example.
=
R: This = reserved bit MUST be set to 0 on transmit and MUST be ignored = R: This reserved and = unassigned bit MUST be set to 0 on transmit and
on = receipt. MUST be ignored on = receipt.
=
M: This is the = want-map-notify bit. When set to 1, an ETR is M: This is the want-map-notify bit. When set to 1, = an ETR is
requesting = a Map-Notify message to be returned in response to requesting a Map-Notify message to be returned in = response to
sending a = Map-Register message. The Map-Notify message sent by a = sending a Map-Register message. The = Map-Notify message sent by a
Map-Server = is used to acknowledge receipt of a Map-Register Map-Server is used to acknowledge receipt of a = Map-Register
= message. message.
=
Record Count: = This is the number of records in this Map-Register Record Count: This is the number of records in this = Map-Register
message. A = record is comprised of that portion of the packet message. A record is comprised of that portion of = the packet
labeled = 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of = times equal to
=
skipping to = change at = page 48, line 17 =C2=B6 = skipping to change at page 48, line = 17 =C2=B6
13.1. Normative = References 13.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-24 = (work in progress), = (LISP)", draft-ietf-lisp-rfc6830bis-25 = (work in progress),
= October 2018. October = 2018.
=
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
skipping to = change at = page 49, line 30 =C2=B6 = skipping to change at page 49, line = 30 =C2=B6
= 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-ecdsa-auth] = [I-D.ietf-lisp-ecdsa-auth]
= Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA = Farinacci, D. and E. Nordmark, = "LISP Control-Plane ECDSA
= Authentication and Authorization", draft-ietf-lisp-ecdsa- = Authentication and = Authorization", draft-ietf-lisp-ecdsa-
= auth-00 (work in progress), September 2018. auth-00 (work in progress), September = 2018.
=
= [I-D.ietf-lisp-eid-anonymity] = [I-D.ietf-lisp-eid-anonymity]
= Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP = Farinacci, D., Pillay-Esnault, = P., and W. Haddad, "LISP
= EID Anonymity", draft-ietf-lisp-eid-anonymity-03 (work in = EID Anonymity", draft-ietf-lisp-eid-anonymity-04 (work in
= progress), October 2018. = progress), October 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] = [I-D.ietf-lisp-gpe]
= Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. Maino, F., Lemon, J., Agarwal, P., Lewis, = D., and M.
=
skipping to = change at = page 53, line 30 =C2=B6 = skipping to change at page 53, line = 30 =C2=B6
Kaduk, Eric = Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, = Kaduk, Eric Rescorla, Alvaro Retana, Alexey = Melnikov, Alissa Cooper,
Suresh = Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed = Suresh Krishnan, Alberto Rodriguez-Natal, = Vina Ermagen, Mohamed
Boucadair, = Brian Trammell, Sabrina Tanamal, and John Drake. The Boucadair, Brian Trammell, Sabrina Tanamal, and John = Drake. The
contributions = they offered greatly added to the security, scale, and contributions they offered greatly added to the = security, scale, and
robustness of = the LISP architecture and protocols. = robustness of the LISP architecture and protocols.
=
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-18 B.1. = Changes to draft-ietf-lisp-rfc6833bis-19
=
= o Posted late = October 2018.
=
= o Changed = description about "reserved" bits to state "reserved and
= = unassigned".
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-18
=
o Posted mid = October 2018. o Posted mid October = 2018.
=
o Added Fabio = text to the Security Considerations section. o Added Fabio text to the Security Considerations = section.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-18 B.3. Changes to = draft-ietf-lisp-rfc6833bis-18
=
o Posted mid = October 2018. o Posted mid October = 2018.
=
o Fixed = comments from Eric after more email clarity. o Fixed comments from Eric after more email = clarity.
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-17 B.4. Changes to = draft-ietf-lisp-rfc6833bis-17
=
o Posted = early October 2018. o Posted early = October 2018.
=
o Changes to = reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th = Telechat.
=
o Added all = flag bit definitions as request for allocation in IANA o Added all flag bit definitions as request for = allocation in IANA
= Considersations section. = Considersations section.
=
o Added an = applicability statement in section 1 to address security = o Added an applicability statement in = section 1 to address security
concerns = from Telechat. concerns from = Telechat.
=
o Moved m-bit = description and IANA request to draft-ietf-lisp-mn. o Moved m-bit description and IANA request to = draft-ietf-lisp-mn.
=
o Moved I-bit = description and IANA request to draft-ietf-lisp- o Moved I-bit description and IANA request to = draft-ietf-lisp-
= pubsub. pubsub.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-16 B.5. Changes to = draft-ietf-lisp-rfc6833bis-16
=
o Posted = Late-September 2018. o Posted = Late-September 2018.
=
o Re-wrote = Security Considerations section. Thanks Albert. o Re-wrote Security Considerations section. Thanks = Albert.
=
o Added = Alvaro text to be more clear about IANA actions. o Added Alvaro text to be more clear about IANA = actions.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-15 B.6. Changes to = draft-ietf-lisp-rfc6833bis-15
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Colin and Mirja. = o Changes to reflect comments from Colin and Mirja.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-14 B.7. Changes to = draft-ietf-lisp-rfc6833bis-14
=
o Posted = September 2018. o Posted September = 2018.
=
o Changes to = reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, = and Secdir
= reviews. reviews.
=
B.7. Changes to = draft-ietf-lisp-rfc6833bis-13 B.8. Changes to = draft-ietf-lisp-rfc6833bis-13
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.8. Changes to = draft-ietf-lisp-rfc6833bis-12 B.9. 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.9. Changes to = draft-ietf-lisp-rfc6833bis-11 B.10. 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.10. Changes to = draft-ietf-lisp-rfc6833bis-10 B.11. 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.11. Changes to = draft-ietf-lisp-rfc6833bis-09 B.12. 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.12. Changes to = draft-ietf-lisp-rfc6833bis-08 B.13. 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.13. Changes to = draft-ietf-lisp-rfc6833bis-07 B.14. 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 56, line = 13 =C2=B6 = skipping to change at page 56, line = 25 =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.14. Changes to = draft-ietf-lisp-rfc6833bis-06 B.15. 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.15. Changes to = draft-ietf-lisp-rfc6833bis-05 B.16. 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.16. Changes to = draft-ietf-lisp-rfc6833bis-04 B.17. 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.17. Changes to = draft-ietf-lisp-rfc6833bis-03 B.18. 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.18. Changes to = draft-ietf-lisp-rfc6833bis-02 B.19. 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.19. Changes to = draft-ietf-lisp-rfc6833bis-01 B.20. 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.20. Changes to = draft-ietf-lisp-rfc6833bis-00 B.21. 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.21. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.22. 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. 32 change blocks. 
55 lines changed or = deleted 63 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_96BE765C-1240-4197-8E89-2E9BBC56B3B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 24, 2018, at 2:24 AM, = wrote: >=20 > Hi Luigi, >=20 > Fully agree that changing the text and updating the figures would be = appropriate.=20 >=20 > Please note that a similar action is needed for = draft-ietf-lisp-rfc6830bis-24, e.g., >=20 > R: The R-bit is a Reserved bit for future use. It MUST be set to 0 > on transmit and MUST be ignored on receipt. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Luigi Iannone [mailto:ggx@gigix.net] >> Envoy=C3=A9 : mercredi 24 octobre 2018 10:01 >> =C3=80 : Dino Farinacci >> Cc : BOUCADAIR Mohamed TGI/OLN; lisp@ietf.org >> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned >>=20 >> Hi All, >>=20 >> disclaimer: this is my personal point of view. >>=20 >> I didn=E2=80=99t catch before this part of RFC 8126. Thanks Med from = bringing it up. >>=20 >> While I understand Dino=E2=80=99s reply, because I my self as well = always thought >> =E2=80=9Creserved =3D can be used in the future=E2=80=9D, I think = that Med is right. >>=20 >> To be compliant with RFC 8126, and because we may need those = =E2=80=9Creserved=E2=80=9D bits >> in the future, we better mark them as =E2=80=9Cunassigned=E2=80=9D. >> This means changing the text and clearly spell out that this is = conform to >> RFC 8126 definitions. >>=20 >> At the end, it is as simple as adding the following sentence in = section 2 >> =E2=80=9CRequirements Notation=E2=80=9D: >>=20 >> The =E2=80=9CUnassigned=E2=80=9D and =E2=80=9CReserved=E2=80=9D = terminology for bits and fields of >> messages and headers defined in this documents is the Well-Known >> Registration Status Terminology defined in Section 6 of = [RFC8126]. >>=20 >>=20 >> Then we just replace =E2=80=9Creserved=E2=80=9D with =E2=80=9Cunassigne= d=E2=80=9D throughout the document. >>=20 >> Ciao >>=20 >> L. >>=20 >>=20 >>=20 >>> On 23 Oct 2018, at 18:27, Dino Farinacci = wrote: >>>=20 >>> I am not sure if we should make this distinction. What does the WG = think? >> Because fields marked =E2=80=9Creserved=E2=80=9D are obviously = unassigned and don=E2=80=99t know if >> they will be assigned in the future. >>>=20 >>> So I am not sure how helpful in making the distinction. >>>=20 >>> Dino >>>=20 >>>> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com wrote: >>>>=20 >>>> Hi Dino, all, >>>>=20 >>>> Apologies for raising this late easy to fix comment: >>>>=20 >>>> RFC8126 says the following: >>>>=20 >>>> Unassigned: Not currently assigned, and available for = assignment >>>> = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> via documented procedures. While it's generally clear = that >>>> any values that are not registered are unassigned and >>>> available for assignment, it is sometimes useful to >>>> explicitly specify that situation. Note that this is >>>> distinctly different from "Reserved". >>>>=20 >>>> Reserved: Not assigned and not available for assignment. >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> Reserved values are held for special uses, such as to = extend >>>> the namespace when it becomes exhausted. "Reserved" is = also >>>> sometimes used to designate values that had been assigned >>>> but are no longer in use, keeping them set aside as long = as >>>> other unassigned values are available. Note that this is >>>> distinctly different from "Unassigned". >>>>=20 >>>> This is well handled in Section 5.1, but not in other sections = which are >> using Reserved instead of Unassigned as per RFC8126. >>>>=20 >>>> It would be appropriate to update the text accordingly. Thank you. >>>>=20 >>>> Cheers, >>>> Med >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >=20 --Apple-Mail=_96BE765C-1240-4197-8E89-2E9BBC56B3B9-- From nobody Wed Oct 24 22:02: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 098A1128CFD for ; Wed, 24 Oct 2018 22:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m84NicEBSf_N for ; Wed, 24 Oct 2018 22:02:05 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D82512D4E6 for ; Wed, 24 Oct 2018 22:02:05 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 42gZjl4ClFz5wWF; Thu, 25 Oct 2018 07:02:03 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.64]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 42gZjl3MtSzBrLT; Thu, 25 Oct 2018 07:02:03 +0200 (CEST) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM3E.corporate.adroot.infra.ftgroup ([fe80::d9c6:bd7c:e376:5cd%21]) with mapi id 14.03.0415.000; Thu, 25 Oct 2018 07:02:03 +0200 From: To: Dino Farinacci CC: Luigi Iannone , "lisp@ietf.org" Thread-Topic: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned Thread-Index: AdRqpEd10cZL+uOwTGaba/yk/wtayQBazvApAAP+T2A= Date: Thu, 25 Oct 2018 05:02:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E02E717@OPEXCNORMAD.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302E02E717OPEXCNORMADcorp_" MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 05:02:08 -0000 --_000_787AE7BB302AE849A7480A190F8B93302E02E717OPEXCNORMADcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGlubywNCg0KVGhhbmsgeW91Lg0KDQpJ4oCZbSBhZnJhaWQgdGhhdCDCqyByZXNlcnZlZCBh bmQgdW5hc3NpZ25lZCDCuyBpcyBzdGlsbCBub3QgYXBwcm9wcmlhdGUgKHNlZSA4MTI2KS4gUGxl YXNlIGNoYW5nZSBpdCB3aXRoIOKAnHVuYXNzaWduZWQgYW5kIGF2YWlsYWJsZSBmb3IgZnV0dXJl IHVzZeKAnS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogRGlubyBGYXJpbmFjY2kgW21haWx0bzpm YXJpbmFjY2lAZ21haWwuY29tXQ0KRW52b3nDqSA6IGpldWRpIDI1IG9jdG9icmUgMjAxOCAwNTow NQ0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQpDYyA6IEx1aWdpIElhbm5vbmU7IGxp c3BAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFtsaXNwXSBkcmFmdC1pZXRmLWxpc3AtcmZjNjgzM2Jp cy0xOTogUmVzZXJ2ZWQvVW5hc3NpZ25lZA0KDQpIb3cgYWJvdXQgdGhlc2UgY2hhbmdlcz8gU28g d2UgY2FuIG5vdCBvdmVyIGNvbXBsaWNhdGUgdGhpcy4NCg0KRGlubw0KDQoNCg0KPiBPbiBPY3Qg MjQsIDIwMTgsIGF0IDI6MjQgQU0sIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiA8bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+DQo+IEhpIEx1aWdpLA0KPg0KPiBG dWxseSBhZ3JlZSB0aGF0IGNoYW5naW5nIHRoZSB0ZXh0IGFuZCB1cGRhdGluZyB0aGUgZmlndXJl cyB3b3VsZCBiZSBhcHByb3ByaWF0ZS4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBhIHNpbWlsYXIg YWN0aW9uIGlzIG5lZWRlZCBmb3IgZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBiaXMtMjQsIGUuZy4s DQo+DQo+ICAgUjogVGhlIFItYml0IGlzIGEgUmVzZXJ2ZWQgYml0IGZvciBmdXR1cmUgdXNlLiAg SXQgTVVTVCBiZSBzZXQgdG8gMA0KPiAgICAgIG9uIHRyYW5zbWl0IGFuZCBNVVNUIGJlIGlnbm9y ZWQgb24gcmVjZWlwdC4NCj4NCj4gQ2hlZXJzLA0KPiBNZWQNCj4NCj4+IC0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBMdWlnaSBJYW5ub25lIFttYWlsdG86Z2d4QGdpZ2l4Lm5l dF0NCj4+IEVudm95w6kgOiBtZXJjcmVkaSAyNCBvY3RvYnJlIDIwMTggMTA6MDENCj4+IMOAIDog RGlubyBGYXJpbmFjY2kNCj4+IENjIDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTjsgbGlzcEBp ZXRmLm9yZw0KPj4gT2JqZXQgOiBSZTogW2xpc3BdIGRyYWZ0LWlldGYtbGlzcC1yZmM2ODMzYmlz LTE5OiBSZXNlcnZlZC9VbmFzc2lnbmVkDQo+Pg0KPj4gSGkgQWxsLA0KPj4NCj4+IGRpc2NsYWlt ZXI6IHRoaXMgaXMgbXkgcGVyc29uYWwgcG9pbnQgb2Ygdmlldy4NCj4+DQo+PiBJIGRpZG7igJl0 IGNhdGNoIGJlZm9yZSB0aGlzIHBhcnQgb2YgUkZDIDgxMjYuIFRoYW5rcyBNZWQgZnJvbSBicmlu Z2luZyBpdCB1cC4NCj4+DQo+PiBXaGlsZSBJIHVuZGVyc3RhbmQgRGlub+KAmXMgcmVwbHksIGJl Y2F1c2UgSSBteSBzZWxmIGFzIHdlbGwgYWx3YXlzIHRob3VnaHQNCj4+IOKAnHJlc2VydmVkID0g Y2FuIGJlIHVzZWQgaW4gdGhlIGZ1dHVyZeKAnSwgSSB0aGluayB0aGF0IE1lZCBpcyByaWdodC4N Cj4+DQo+PiBUbyBiZSBjb21wbGlhbnQgd2l0aCBSRkMgODEyNiwgYW5kIGJlY2F1c2Ugd2UgbWF5 IG5lZWQgdGhvc2Ug4oCccmVzZXJ2ZWTigJ0gYml0cw0KPj4gaW4gdGhlIGZ1dHVyZSwgd2UgYmV0 dGVyIG1hcmsgdGhlbSBhcyDigJx1bmFzc2lnbmVk4oCdLg0KPj4gVGhpcyBtZWFucyBjaGFuZ2lu ZyB0aGUgdGV4dCBhbmQgY2xlYXJseSBzcGVsbCBvdXQgdGhhdCB0aGlzIGlzIGNvbmZvcm0gdG8N Cj4+IFJGQyA4MTI2IGRlZmluaXRpb25zLg0KPj4NCj4+IEF0IHRoZSBlbmQsIGl0IGlzIGFzIHNp bXBsZSBhcyBhZGRpbmcgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBpbiBzZWN0aW9uIDINCj4+IOKA nFJlcXVpcmVtZW50cyBOb3RhdGlvbuKAnToNCj4+DQo+PiAgICAgICBUaGUgIOKAnFVuYXNzaWdu ZWTigJ0gYW5kIOKAnFJlc2VydmVk4oCdIHRlcm1pbm9sb2d5IGZvciBiaXRzIGFuZCBmaWVsZHMg b2YNCj4+ICAgICAgIG1lc3NhZ2VzIGFuZCBoZWFkZXJzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dHMgaXMgdGhlIFdlbGwtS25vd24NCj4+ICAgICAgIFJlZ2lzdHJhdGlvbiBTdGF0dXMgVGVybWlu b2xvZ3kgZGVmaW5lZCBpbiBTZWN0aW9uIDYgb2YgW1JGQzgxMjZdLg0KPj4NCj4+DQo+PiBUaGVu IHdlIGp1c3QgcmVwbGFjZSDigJxyZXNlcnZlZOKAnSB3aXRoIOKAnHVuYXNzaWduZWTigJ0gdGhy b3VnaG91dCB0aGUgZG9jdW1lbnQuDQo+Pg0KPj4gQ2lhbw0KPj4NCj4+IEwuDQo+Pg0KPj4NCj4+ DQo+Pj4gT24gMjMgT2N0IDIwMTgsIGF0IDE4OjI3LCBEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2Np QGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4NCj4+PiBJIGFtIG5vdCBzdXJlIGlmIHdlIHNob3VsZCBt YWtlIHRoaXMgZGlzdGluY3Rpb24uIFdoYXQgZG9lcyB0aGUgV0cgdGhpbms/DQo+PiBCZWNhdXNl IGZpZWxkcyBtYXJrZWQg4oCccmVzZXJ2ZWTigJ0gYXJlIG9idmlvdXNseSB1bmFzc2lnbmVkIGFu ZCBkb27igJl0IGtub3cgaWYNCj4+IHRoZXkgd2lsbCBiZSBhc3NpZ25lZCBpbiB0aGUgZnV0dXJl Lg0KPj4+DQo+Pj4gU28gSSBhbSBub3Qgc3VyZSBob3cgaGVscGZ1bCBpbiBtYWtpbmcgdGhlIGRp c3RpbmN0aW9uLg0KPj4+DQo+Pj4gRGlubw0KPj4+DQo+Pj4+IE9uIE9jdCAyMywgMjAxOCwgYXQg MTI6NDQgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+Pj4+DQo+Pj4+ IEhpIERpbm8sIGFsbCwNCj4+Pj4NCj4+Pj4gQXBvbG9naWVzIGZvciByYWlzaW5nIHRoaXMgbGF0 ZSBlYXN5IHRvIGZpeCBjb21tZW50Og0KPj4+Pg0KPj4+PiBSRkM4MTI2IHNheXMgdGhlIGZvbGxv d2luZzoNCj4+Pj4NCj4+Pj4gICAgIFVuYXNzaWduZWQ6ICBOb3QgY3VycmVudGx5IGFzc2lnbmVk LCBhbmQgYXZhaWxhYmxlIGZvciBhc3NpZ25tZW50DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KPj4+PiAg ICAgICAgICAgdmlhIGRvY3VtZW50ZWQgcHJvY2VkdXJlcy4gIFdoaWxlIGl0J3MgZ2VuZXJhbGx5 IGNsZWFyIHRoYXQNCj4+Pj4gICAgICAgICAgIGFueSB2YWx1ZXMgdGhhdCBhcmUgbm90IHJlZ2lz dGVyZWQgYXJlIHVuYXNzaWduZWQgYW5kDQo+Pj4+ICAgICAgICAgICBhdmFpbGFibGUgZm9yIGFz c2lnbm1lbnQsIGl0IGlzIHNvbWV0aW1lcyB1c2VmdWwgdG8NCj4+Pj4gICAgICAgICAgIGV4cGxp Y2l0bHkgc3BlY2lmeSB0aGF0IHNpdHVhdGlvbi4gIE5vdGUgdGhhdCB0aGlzIGlzDQo+Pj4+ICAg ICAgICAgICBkaXN0aW5jdGx5IGRpZmZlcmVudCBmcm9tICJSZXNlcnZlZCIuDQo+Pj4+DQo+Pj4+ ICAgICBSZXNlcnZlZDogIE5vdCBhc3NpZ25lZCBhbmQgbm90IGF2YWlsYWJsZSBmb3IgYXNzaWdu bWVudC4NCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl4NCj4+Pj4gICAgICAgICAgIFJlc2VydmVkIHZhbHVlcyBhcmUgaGVs ZCBmb3Igc3BlY2lhbCB1c2VzLCBzdWNoIGFzIHRvIGV4dGVuZA0KPj4+PiAgICAgICAgICAgdGhl IG5hbWVzcGFjZSB3aGVuIGl0IGJlY29tZXMgZXhoYXVzdGVkLiAgIlJlc2VydmVkIiBpcyBhbHNv DQo+Pj4+ICAgICAgICAgICBzb21ldGltZXMgdXNlZCB0byBkZXNpZ25hdGUgdmFsdWVzIHRoYXQg aGFkIGJlZW4gYXNzaWduZWQNCj4+Pj4gICAgICAgICAgIGJ1dCBhcmUgbm8gbG9uZ2VyIGluIHVz ZSwga2VlcGluZyB0aGVtIHNldCBhc2lkZSBhcyBsb25nIGFzDQo+Pj4+ICAgICAgICAgICBvdGhl ciB1bmFzc2lnbmVkIHZhbHVlcyBhcmUgYXZhaWxhYmxlLiAgTm90ZSB0aGF0IHRoaXMgaXMNCj4+ Pj4gICAgICAgICAgIGRpc3RpbmN0bHkgZGlmZmVyZW50IGZyb20gIlVuYXNzaWduZWQiLg0KPj4+ Pg0KPj4+PiBUaGlzIGlzIHdlbGwgaGFuZGxlZCBpbiBTZWN0aW9uIDUuMSwgYnV0IG5vdCBpbiBv dGhlciBzZWN0aW9ucyB3aGljaCBhcmUNCj4+IHVzaW5nIFJlc2VydmVkIGluc3RlYWQgb2YgVW5h c3NpZ25lZCBhcyBwZXIgUkZDODEyNi4NCj4+Pj4NCj4+Pj4gSXQgd291bGQgYmUgYXBwcm9wcmlh dGUgdG8gdXBkYXRlIHRoZSB0ZXh0IGFjY29yZGluZ2x5LiBUaGFuayB5b3UuDQo+Pj4+DQo+Pj4+ IENoZWVycywNCj4+Pj4gTWVkDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+IGxpc3AgbWFpbGluZyBsaXN0DQo+Pj4+IGxpc3BAaWV0Zi5v cmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQo+Pj4N Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ IGxpc3AgbWFpbGluZyBsaXN0DQo+Pj4gbGlzcEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KPg0K --_000_787AE7BB302AE849A7480A190F8B93302E02E717OPEXCNORMADcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhpIERpbm8sPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5J4oCZbSBhZnJhaWQgdGhhdCDC qyZuYnNwO3Jlc2VydmVkIGFuZCB1bmFzc2lnbmVkJm5ic3A7wrsgaXMgc3RpbGwgbm90IGFwcHJv cHJpYXRlIChzZWUgODEyNikuIFBsZWFzZSBjaGFuZ2UgaXQgd2l0aCDigJx1bmFzc2lnbmVkIGFu ZCBhdmFpbGFibGUgZm9yIGZ1dHVyZSB1c2XigJ0uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZu YnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRGlubyBGYXJpbmFj Y2kgW21haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8 L2I+IGpldWRpIDI1IG9jdG9icmUgMjAxOCAwNTowNTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9V Q0FEQUlSIE1vaGFtZWQgVEdJL09MTjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gTHVpZ2kgSWFubm9u ZTsgbGlzcEBpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtsaXNwXSBkcmFm dC1pZXRmLWxpc3AtcmZjNjgzM2Jpcy0xOTogUmVzZXJ2ZWQvVW5hc3NpZ25lZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SG93 IGFib3V0IHRoZXNlIGNoYW5nZXM/IFNvIHdlIGNhbiBub3Qgb3ZlciBjb21wbGljYXRlIHRoaXMu PGJyPg0KPGJyPg0KRGlubzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCjxicj4NCjxicj4NCiZn dDsgT24gT2N0IDI0LCAyMDE4LCBhdCAyOjI0IEFNLCAmbHQ7bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSZndDsgJmx0O21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20mZ3Q7IHdyb3RlOjxi cj4NCiZndDsgPGJyPg0KJmd0OyBIaSBMdWlnaSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgRnVsbHkg YWdyZWUgdGhhdCBjaGFuZ2luZyB0aGUgdGV4dCBhbmQgdXBkYXRpbmcgdGhlIGZpZ3VyZXMgd291 bGQgYmUgYXBwcm9wcmlhdGUuDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNlIG5vdGUgdGhh dCBhIHNpbWlsYXIgYWN0aW9uIGlzIG5lZWRlZCBmb3IgZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzBi aXMtMjQsIGUuZy4sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7IFI6IFRoZSBSLWJp dCBpcyBhIFJlc2VydmVkIGJpdCBmb3IgZnV0dXJlIHVzZS4mbmJzcDsgSXQgTVVTVCBiZSBzZXQg dG8gMDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb24gdHJhbnNtaXQg YW5kIE1VU1QgYmUgaWdub3JlZCBvbiByZWNlaXB0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBDaGVl cnMsPGJyPg0KJmd0OyBNZWQ8YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IC0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLTxicj4NCiZndDsmZ3Q7IERlIDogTHVpZ2kgSWFubm9uZSBbPGEgaHJlZj0i bWFpbHRvOmdneEBnaWdpeC5uZXQiPm1haWx0bzpnZ3hAZ2lnaXgubmV0PC9hPl08YnI+DQomZ3Q7 Jmd0OyBFbnZvecOpIDogbWVyY3JlZGkgMjQgb2N0b2JyZSAyMDE4IDEwOjAxPGJyPg0KJmd0OyZn dDsgw4AgOiBEaW5vIEZhcmluYWNjaTxicj4NCiZndDsmZ3Q7IENjIDogQk9VQ0FEQUlSIE1vaGFt ZWQgVEdJL09MTjsgbGlzcEBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IE9iamV0IDogUmU6IFtsaXNw XSBkcmFmdC1pZXRmLWxpc3AtcmZjNjgzM2Jpcy0xOTogUmVzZXJ2ZWQvVW5hc3NpZ25lZDxicj4N CiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEhpIEFsbCw8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyBkaXNjbGFpbWVyOiB0aGlzIGlzIG15IHBlcnNvbmFsIHBvaW50IG9mIHZpZXcuPGJyPg0K Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSSBkaWRu4oCZdCBjYXRjaCBiZWZvcmUgdGhpcyBwYXJ0 IG9mIFJGQyA4MTI2LiBUaGFua3MgTWVkIGZyb20gYnJpbmdpbmcgaXQgdXAuPGJyPg0KJmd0OyZn dDsgPGJyPg0KJmd0OyZndDsgV2hpbGUgSSB1bmRlcnN0YW5kIERpbm/igJlzIHJlcGx5LCBiZWNh dXNlIEkgbXkgc2VsZiBhcyB3ZWxsIGFsd2F5cyB0aG91Z2h0PGJyPg0KJmd0OyZndDsg4oCccmVz ZXJ2ZWQgPSBjYW4gYmUgdXNlZCBpbiB0aGUgZnV0dXJl4oCdLCBJIHRoaW5rIHRoYXQgTWVkIGlz IHJpZ2h0Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRvIGJlIGNvbXBsaWFudCB3aXRo IFJGQyA4MTI2LCBhbmQgYmVjYXVzZSB3ZSBtYXkgbmVlZCB0aG9zZSDigJxyZXNlcnZlZOKAnSBi aXRzPGJyPg0KJmd0OyZndDsgaW4gdGhlIGZ1dHVyZSwgd2UgYmV0dGVyIG1hcmsgdGhlbSBhcyDi gJx1bmFzc2lnbmVk4oCdLjxicj4NCiZndDsmZ3Q7IFRoaXMgbWVhbnMgY2hhbmdpbmcgdGhlIHRl eHQgYW5kIGNsZWFybHkgc3BlbGwgb3V0IHRoYXQgdGhpcyBpcyBjb25mb3JtIHRvPGJyPg0KJmd0 OyZndDsgUkZDIDgxMjYgZGVmaW5pdGlvbnMuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsg QXQgdGhlIGVuZCwgaXQgaXMgYXMgc2ltcGxlIGFzIGFkZGluZyB0aGUgZm9sbG93aW5nIHNlbnRl bmNlIGluIHNlY3Rpb24gMjxicj4NCiZndDsmZ3Q7IOKAnFJlcXVpcmVtZW50cyBOb3RhdGlvbuKA nTo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGUmbmJzcDsg4oCcVW5hc3NpZ25lZOKAnSBhbmQg4oCcUmVzZXJ2ZWTigJ0g dGVybWlub2xvZ3kgZm9yIGJpdHMgYW5kIGZpZWxkcyBvZjxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1lc3NhZ2VzIGFuZCBoZWFkZXJzIGRlZmluZWQg aW4gdGhpcyBkb2N1bWVudHMgaXMgdGhlIFdlbGwtS25vd248YnI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdpc3RyYXRpb24gU3RhdHVzIFRlcm1pbm9s b2d5IGRlZmluZWQgaW4gU2VjdGlvbiA2IG9mIFtSRkM4MTI2XS48YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBUaGVuIHdlIGp1c3QgcmVwbGFjZSDigJxyZXNlcnZl ZOKAnSB3aXRoIOKAnHVuYXNzaWduZWTigJ0gdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQuPGJyPg0K Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQ2lhbzxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 IEwuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7IE9uIDIzIE9jdCAyMDE4LCBhdCAxODoyNywgRGlubyBGYXJpbmFjY2kgJmx0O2Zh cmluYWNjaUBnbWFpbC5jb20mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyZndDsgSSBhbSBub3Qgc3VyZSBpZiB3ZSBzaG91bGQgbWFrZSB0aGlzIGRpc3RpbmN0aW9u LiBXaGF0IGRvZXMgdGhlIFdHIHRoaW5rPzxicj4NCiZndDsmZ3Q7IEJlY2F1c2UgZmllbGRzIG1h cmtlZCDigJxyZXNlcnZlZOKAnSBhcmUgb2J2aW91c2x5IHVuYXNzaWduZWQgYW5kIGRvbuKAmXQg a25vdyBpZjxicj4NCiZndDsmZ3Q7IHRoZXkgd2lsbCBiZSBhc3NpZ25lZCBpbiB0aGUgZnV0dXJl Ljxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgU28gSSBhbSBub3Qgc3VyZSBo b3cgaGVscGZ1bCBpbiBtYWtpbmcgdGhlIGRpc3RpbmN0aW9uLjxicj4NCiZndDsmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyZndDsgRGlubzxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IE9uIE9jdCAyMywgMjAxOCwgYXQgMTI6NDQgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20gd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IEhpIERpbm8sIGFsbCw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgQXBvbG9naWVzIGZvciByYWlzaW5nIHRoaXMgbGF0ZSBlYXN5IHRvIGZpeCBjb21tZW50 Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBSRkM4MTI2IHNh eXMgdGhlIGZvbGxvd2luZzo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVW5hc3NpZ25lZDombmJzcDsgTm90IGN1cnJl bnRseSBhc3NpZ25lZCwgYW5kIGF2YWlsYWJsZSBmb3IgYXNzaWdubWVudDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmlhIGRvY3VtZW50ZWQgcHJvY2VkdXJlcy4mbmJzcDsg V2hpbGUgaXQncyBnZW5lcmFsbHkgY2xlYXIgdGhhdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YW55IHZhbHVlcyB0aGF0IGFyZSBub3QgcmVnaXN0ZXJlZCBhcmUgdW5hc3NpZ25lZCBhbmQ8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF2YWlsYWJsZSBmb3IgYXNzaWdubWVudCwgaXQgaXMgc29t ZXRpbWVzIHVzZWZ1bCB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXhwbGljaXRseSBzcGVj aWZ5IHRoYXQgc2l0dWF0aW9uLiZuYnNwOyBOb3RlIHRoYXQgdGhpcyBpczxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgZGlzdGluY3RseSBkaWZmZXJlbnQgZnJvbSAmcXVvdDtSZXNlcnZlZCZxdW90 Oy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgUmVzZXJ2ZWQ6Jm5ic3A7IE5vdCBhc3NpZ25lZCBhbmQgbm90IGF2YWls YWJsZSBmb3IgYXNzaWdubWVudC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUmVzZXJ2ZWQgdmFsdWVzIGFyZSBoZWxkIGZvciBzcGVjaWFsIHVzZXMsIHN1Y2ggYXMg dG8gZXh0ZW5kPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgbmFtZXNwYWNlIHdoZW4gaXQg YmVjb21lcyBleGhhdXN0ZWQuJm5ic3A7ICZxdW90O1Jlc2VydmVkJnF1b3Q7IGlzIGFsc288YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNvbWV0aW1lcyB1c2VkIHRvIGRlc2lnbmF0ZSB2YWx1ZXMg dGhhdCBoYWQgYmVlbiBhc3NpZ25lZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnV0IGFyZSBu byBsb25nZXIgaW4gdXNlLCBrZWVwaW5nIHRoZW0gc2V0IGFzaWRlIGFzIGxvbmcgYXM8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IG90aGVyIHVuYXNzaWduZWQgdmFsdWVzIGFyZSBhdmFpbGFibGUu Jm5ic3A7IE5vdGUgdGhhdCB0aGlzIGlzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkaXN0aW5j dGx5IGRpZmZlcmVudCBmcm9tICZxdW90O1VuYXNzaWduZWQmcXVvdDsuPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMgaXMgd2VsbCBoYW5kbGVkIGluIFNl Y3Rpb24gNS4xLCBidXQgbm90IGluIG90aGVyIHNlY3Rpb25zIHdoaWNoIGFyZTxicj4NCiZndDsm Z3Q7IHVzaW5nIFJlc2VydmVkIGluc3RlYWQgb2YgVW5hc3NpZ25lZCBhcyBwZXIgUkZDODEyNi48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSXQgd291bGQgYmUg YXBwcm9wcmlhdGUgdG8gdXBkYXRlIHRoZSB0ZXh0IGFjY29yZGluZ2x5LiBUaGFuayB5b3UuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IENoZWVycyw8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IE1lZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGxp c3AgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBsaXNwQGlldGYub3JnPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xpc3AiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcDwv YT48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IGxpc3AgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7IGxpc3BAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZn dDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3A8L2E+PGJyPg0KJmd0OyA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93302E02E717OPEXCNORMADcorp_-- From nobody Thu Oct 25 05: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 534C8130DEF for ; Thu, 25 Oct 2018 05:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 eV7a8eGswQml for ; Thu, 25 Oct 2018 05:30:38 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8BDD12872C for ; Thu, 25 Oct 2018 05:30:37 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id p2-v6so1319608wmc.2 for ; Thu, 25 Oct 2018 05:30:37 -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=8rLxbnDGCJspRA1oKphGVs0xc5KVwQCExBIN9lDmy6A=; b=zxX6ie6QgvA0ZU+rMqEAhMxKmZ9sotVfV5cXj+LX0+i7oBcfIWqpww9s33j4Xi3UCv 4IhmuK8mjj6XQL2oDu/9y9Ry8hEIIwOM41hFRZEQwrA1bJ7rkV2Z6nZldzRpzQSSOcWi OEW5mjTf5JH68aLxO9NqZQ6pqwIgLtp5fMzpkXLv+/3YJEClBs13D7NOtjQVspJj97lg M6tAimMpVSv1Wvo11GG1r9PvlgYUqhf8fr7UvylweJ5r/n9SRGF1faiPR75TN5DfO/z6 Sxgpvo/fGby6Bil+AXOW7SUphXM/aWJFmwXR4qZznzPQ/R1iqn3hwN5BvZrwxHXPYaPM NKzQ== 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=8rLxbnDGCJspRA1oKphGVs0xc5KVwQCExBIN9lDmy6A=; b=bNBfLNr725OC251kqUKApUqep6LiSTPUxh5LEz9Ls8vJLxsBhN6o1NcSrbP+iHurq+ zbTM9KxrcjgKZOgzFzw8gwT3LyJcJi87ulAaZh9Z4etxwOfas0U/vG8LBWwlpsxIcYaB CHxlOOPuDjMrMhXBLk05hGZdxM/RPp760JhrlhkftiCsrLR6+601UFyQ3ZVts3nHC7vQ PQNNQEQnMdwMExPZ+mOsX84GSXKjCnxamkkm3/xqQ+HYBCbZa0bUfJa/n2UKfwA/uNWN iiCjilFQgXNlMMiumxhCXutJZrxg+g91T82aMQiKe1pYcUfNP9y7bj5zARqJSN1oB2DJ zeEQ== X-Gm-Message-State: AGRZ1gLZbqixOKCe7ydcerKW90h7TvinSoE1C9VyhHE5NEEglrC0VNI7 Jl6ADgTyTm/HxxTKgYDMGBnPCxlZqvo+uA== X-Google-Smtp-Source: AJdET5cQzI6pd0NdT+2IydSbmR4A/NslH61apCVucb5B3+QWq82YFZr9Cchs7g8xB9JNq4FFB/hbCA== X-Received: by 2002:a1c:92d3:: with SMTP id u202-v6mr1814395wmd.39.1540470635758; Thu, 25 Oct 2018 05:30:35 -0700 (PDT) Received: from fatboy-2.home (2a01cb0404807500e51666dd772c2063.ipv6.abo.wanadoo.fr. [2a01:cb04:480:7500:e516:66dd:772c:2063]) by smtp.gmail.com with ESMTPSA id q190-v6sm1612030wmg.40.2018.10.25.05.30.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Oct 2018 05:30:33 -0700 (PDT) From: Luigi Iannone Message-Id: <0105EE7D-396E-4DB5-8430-E44FC039C2FE@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_C647D2AB-0A4C-4CCD-9D4D-DE4CF8B1CB5C" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Thu, 25 Oct 2018 14:30:32 +0200 In-Reply-To: Cc: lisp-chairs@ietf.org, "BRUNGARD, DEBORAH A" To: "lisp@ietf.org list" References: <153736857165.21461.18166105234850504507@ietfa.amsl.com> <1B5FAB89-DA76-4F0D-92BA-FD0E6E5A5A77@gigix.net> <44201301-8E2D-4649-8483-5418A8CFC138@gigix.net> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] WGLC fo draft-ietf-lisp-rfc8113bis-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 12:30:40 -0000 --Apple-Mail=_C647D2AB-0A4C-4CCD-9D4D-DE4CF8B1CB5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, The WGLC for this document is now over. We received a couple of email in support.=20 This is enough since the document is small and there are no real changes = compared to the experimental version. We will ask publication of the document once the writeup is ready. Ciao Luigi > On 8 Oct 2018, at 09:51, Luigi Iannone wrote: >=20 > Folks, >=20 > WG Last Call for 8113bis has been out for more than a week and we did = not receive any feedback. >=20 > Remember that silence is NOT consensus. >=20 > Please ALL , > thake 5 minutes to read this very short document and send feedback on = whether or not you think the document is ready to be published. >=20 > Thanks >=20 > Luigi >=20 >> On 27 Sep 2018, at 11:02, Luigi Iannone > wrote: >>=20 >> Well, >>=20 >> Authors were pretty quick =E2=80=A6 >>=20 >> This email open the one week WG Last Call for the document = draft-ietf-lisp-rfc8113bis-00.txt >>=20 >> Please review this WG document and let the WG know if you agree that = it is ready for handing to the AD. >> If you have objections, please state your reasons why, and explain = what it would take to address your concerns. >>=20 >> Ciao >>=20 >> L. >>=20 >>> On 27 Sep 2018, at 10:22, Luigi Iannone > wrote: >>>=20 >>> All, >>>=20 >>> one week is over and we received several email in support adoption = of this document. >>>=20 >>> Because of such consensus the authors are invited to submit a = document named draft-ietf-lisp-rfc8113bis-00.txt. >>>=20 >>> As soon as the new document is available we will start the WG Last = Call, as already said in my previous mail. >>>=20 >>> Ciao >>>=20 >>> L. >>>=20 >>>=20 >>>> On 19 Sep 2018, at 17:04, Luigi Iannone > wrote: >>>>=20 >>>> Folks, >>>>=20 >>>> here is another piece of the work done in our WG that needs to be = moved to PS. >>>>=20 >>>> It is the updated version of RFC 8113, nothing changed just updated = coherently with the current status of the other documents. >>>>=20 >>>> Because this documents is really really short we will have just one = week adoption call followed be one week WG Last Call. >>>>=20 >>>> This email officially starts the one week call for adoption. >>>>=20 >>>> Please spend 10 minutes having a look at the document and send an = email on whether you agree or not to adopt it. >>>>=20 >>>> Thanks >>>>=20 >>>> Ciao >>>>=20 >>>> Luigi >>>>=20 >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Subject: I-D Action: draft-boucadair-lisp-rfc8113bis-01.txt >>>>> Date: 19 September 2018 at 16:49:31 CEST >>>>> To: > >>>>> Reply-To: internet-drafts@ietf.org = >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>>=20 >>>>>=20 >>>>> Title : Locator/ID Separation Protocol (LISP): = Shared Extension Message & IANA Registry for Packet Type Allocations >>>>> Authors : Mohamed Boucadair >>>>> Christian Jacquenet >>>>> Filename : draft-boucadair-lisp-rfc8113bis-01.txt >>>>> Pages : 5 >>>>> Date : 2018-09-19 >>>>>=20 >>>>> Abstract: >>>>> This document specifies a Locator/ID Separation Protocol (LISP) >>>>> shared message type for defining future extensions and = conducting >>>>> experiments without consuming a LISP packet type codepoint for = each >>>>> extension. >>>>>=20 >>>>> This document obsoletes RFC 8113. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-boucadair-lisp-rfc8113bis/ = >>>>>=20 >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-boucadair-lisp-rfc8113bis-01 = >>>>> = https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-rfc8113bis-01 = = >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-lisp-rfc8113bis-01 = >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of = submission >>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_C647D2AB-0A4C-4CCD-9D4D-DE4CF8B1CB5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = All,

The WGLC for = this document is now over.

We received a couple of email in support. 
This is enough since the document is small and there are no = real changes compared to the experimental version.

We will ask publication = of the document once the writeup is ready.

Ciao


Luigi



On 8 Oct 2018, at 09:51, Luigi Iannone <ggx@gigix.net> = wrote:

Folks,

WG Last Call for 8113bis = has been out for more than a week and we did not receive any = feedback.

Remember that silence is NOT consensus.

Please ALL ,
thake 5 minutes to read this very short document and send = feedback on whether or not you think the document is ready to be = published.

Thanks

Luigi

On 27 Sep 2018, at 11:02, Luigi = Iannone <ggx@gigix.net> wrote:

Well,
Authors were pretty quick = =E2=80=A6

This = email open the one week WG Last Call for the = document draft-ietf-lisp-rfc8113bis-00.txt

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

Ciao

L.

On 27 = Sep 2018, at 10:22, Luigi Iannone <ggx@gigix.net> wrote:

All,

one week is over and we received = several email in support adoption of this document.

Because of such = consensus the authors are invited to submit a document named = draft-ietf-lisp-rfc8113bis-00.txt.

As soon as the new document is = available we will start the WG Last Call, as already said in my previous = mail.

Ciao

L.


On 19 = Sep 2018, at 17:04, Luigi Iannone <ggx@gigix.net> wrote:

Folks,

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

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

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

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

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

Thanks

Ciao

Luigi


Begin forwarded message:

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


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


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

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

  This = document obsoletes RFC 8113.


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

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

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


Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

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





= --Apple-Mail=_C647D2AB-0A4C-4CCD-9D4D-DE4CF8B1CB5C-- From nobody Thu Oct 25 08:04:31 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F946130E6B for ; Thu, 25 Oct 2018 08:04: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, 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 2bGdEksyGERv for ; Thu, 25 Oct 2018 08:04:27 -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 39A49130E6A for ; Thu, 25 Oct 2018 08:04:27 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id 30-v6so3987493plb.10 for ; Thu, 25 Oct 2018 08:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lcs0ca9b0InRqUZ9US5yK7LoRY2EPaxRbvimyb60DI8=; b=ZK5wHdb7XNTFEQGJX+w1tYG/8fxYK1PMjQfVTpeN6wVBojYMKIcfiYP0TaXX+bKSSy 8zzFHENKTTU/BV58vTS2rB4aNjy+v9+D8wQNBnBJlYM4Y3loxV4a+Yv/eQITq2qDc2US DTRDmcd2eU44Km11uzoheqij9QBLjwUUt5ShrMQ6i39RbFwxfXDpqXej3u6Ef+Da5zYB eBGvrC2qAqjg9zUHOg4eAOANkeMriikeu1ibGKqFT1yNXbpK9oGDEDdfFvlTHZ0NFEJL 0Vd/tz7Hz79lsT/OuRqD4Ex37++j+Q96bDFVYkqUCqgqIuyr8BD5tpvlWaj+jrg2SZLA McUw== 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=lcs0ca9b0InRqUZ9US5yK7LoRY2EPaxRbvimyb60DI8=; b=tQXD6tAgl1CYNWCKm/gOKslv5M8vExyEI1PluHQvVXqgGhojK6FkAb+J1DIAsqFXGB 8P7C4HapUC0lcycPsDa0OG/ghORbGoRepSpQkSKANzWjL1SOMiED+TnOR/kb/rv7SyNc xEEpOf3Ukp6PjOjhi+f9XJvMc+gnh2XOgjj/E2bW0M2Z+WAQxuQPyixZ7V8RZmOUJBgl mGS+3YNqeUdx2C1G5OCX5kUhlqdXb+INrAgmsys+RFfbWWqQ8bPtajb5Clxc/obQ0of9 aLZ20igur/17K9w/vM/6zm1bZlp1/mc2l/AZ19gh+H4mYuj9p9KsVPS1bSLacSVU2cL4 A68w== X-Gm-Message-State: AGRZ1gKe2ZVyKxCjhgfRXhE+1oZ4SK5ITCKG1CDsTi0HNJrol5Wwtgci r+Iv5xYMiWq2AdF1+Ygw06I= X-Google-Smtp-Source: AJdET5fYoXsvovZRz1EGmwDaicsYJfeuvK0nKLZnCNDiHjE+h3J0fjbsX0oyabYDAbihvz3fO6oWkQ== X-Received: by 2002:a17:902:5590:: with SMTP id g16-v6mr1919142pli.28.1540479866708; Thu, 25 Oct 2018 08:04:26 -0700 (PDT) Received: from ?IPv6:2603:3024:151c:55f0:48b1:93eb:734d:3b9e? ([2603:3024:151c:55f0:48b1:93eb:734d:3b9e]) by smtp.gmail.com with ESMTPSA id q24-v6sm9073027pff.83.2018.10.25.08.04.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Oct 2018 08:04:25 -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: <787AE7BB302AE849A7480A190F8B93302E02E717@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Date: Thu, 25 Oct 2018 08:04:22 -0700 Cc: Luigi Iannone , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E02E717@OPEXCNORMAD.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 15:04:29 -0000 It doesn=E2=80=99t *have to be* what 8126 is. It needs to be what we = believe the the unassigned bits are labeled. Dino > On Oct 24, 2018, at 10:02 PM, = wrote: >=20 > Hi Dino, > =20 > Thank you. > =20 > I=E2=80=99m afraid that =C2=AB reserved and unassigned =C2=BB is still = not appropriate (see 8126). Please change it with =E2=80=9Cunassigned = and available for future use=E2=80=9D. > =20 > Cheers, > Med > =20 > De : Dino Farinacci [mailto:farinacci@gmail.com]=20 > Envoy=C3=A9 : jeudi 25 octobre 2018 05:05 > =C3=80 : BOUCADAIR Mohamed TGI/OLN > Cc : Luigi Iannone; lisp@ietf.org > Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned > =20 > How about these changes? So we can not over complicate this. >=20 > Dino >=20 >=20 >=20 >=20 > > On Oct 24, 2018, at 2:24 AM, = wrote: > >=20 > > Hi Luigi, > >=20 > > Fully agree that changing the text and updating the figures would be = appropriate.=20 > >=20 > > Please note that a similar action is needed for = draft-ietf-lisp-rfc6830bis-24, e.g., > >=20 > > R: The R-bit is a Reserved bit for future use. It MUST be set to = 0 > > on transmit and MUST be ignored on receipt. > >=20 > > Cheers, > > Med > >=20 > >> -----Message d'origine----- > >> De : Luigi Iannone [mailto:ggx@gigix.net] > >> Envoy=C3=A9 : mercredi 24 octobre 2018 10:01 > >> =C3=80 : Dino Farinacci > >> Cc : BOUCADAIR Mohamed TGI/OLN; lisp@ietf.org > >> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: = Reserved/Unassigned > >>=20 > >> Hi All, > >>=20 > >> disclaimer: this is my personal point of view. > >>=20 > >> I didn=E2=80=99t catch before this part of RFC 8126. Thanks Med = from bringing it up. > >>=20 > >> While I understand Dino=E2=80=99s reply, because I my self as well = always thought > >> =E2=80=9Creserved =3D can be used in the future=E2=80=9D, I think = that Med is right. > >>=20 > >> To be compliant with RFC 8126, and because we may need those = =E2=80=9Creserved=E2=80=9D bits > >> in the future, we better mark them as =E2=80=9Cunassigned=E2=80=9D. > >> This means changing the text and clearly spell out that this is = conform to > >> RFC 8126 definitions. > >>=20 > >> At the end, it is as simple as adding the following sentence in = section 2 > >> =E2=80=9CRequirements Notation=E2=80=9D: > >>=20 > >> The =E2=80=9CUnassigned=E2=80=9D and =E2=80=9CReserved=E2=80=9D= terminology for bits and fields of > >> messages and headers defined in this documents is the = Well-Known > >> Registration Status Terminology defined in Section 6 of = [RFC8126]. > >>=20 > >>=20 > >> Then we just replace =E2=80=9Creserved=E2=80=9D with = =E2=80=9Cunassigned=E2=80=9D throughout the document. > >>=20 > >> Ciao > >>=20 > >> L. > >>=20 > >>=20 > >>=20 > >>> On 23 Oct 2018, at 18:27, Dino Farinacci = wrote: > >>>=20 > >>> I am not sure if we should make this distinction. What does the WG = think? > >> Because fields marked =E2=80=9Creserved=E2=80=9D are obviously = unassigned and don=E2=80=99t know if > >> they will be assigned in the future. > >>>=20 > >>> So I am not sure how helpful in making the distinction. > >>>=20 > >>> Dino > >>>=20 > >>>> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com wrote: > >>>>=20 > >>>> Hi Dino, all, > >>>>=20 > >>>> Apologies for raising this late easy to fix comment: > >>>>=20 > >>>> RFC8126 says the following: > >>>>=20 > >>>> Unassigned: Not currently assigned, and available for = assignment > >>>> = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>>> via documented procedures. While it's generally clear = that > >>>> any values that are not registered are unassigned and > >>>> available for assignment, it is sometimes useful to > >>>> explicitly specify that situation. Note that this is > >>>> distinctly different from "Reserved". > >>>>=20 > >>>> Reserved: Not assigned and not available for assignment. > >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>>> Reserved values are held for special uses, such as to = extend > >>>> the namespace when it becomes exhausted. "Reserved" is = also > >>>> sometimes used to designate values that had been = assigned > >>>> but are no longer in use, keeping them set aside as = long as > >>>> other unassigned values are available. Note that this = is > >>>> distinctly different from "Unassigned". > >>>>=20 > >>>> This is well handled in Section 5.1, but not in other sections = which are > >> using Reserved instead of Unassigned as per RFC8126. > >>>>=20 > >>>> It would be appropriate to update the text accordingly. Thank = you. > >>>>=20 > >>>> Cheers, > >>>> Med > >>>> _______________________________________________ > >>>> lisp mailing list > >>>> lisp@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lisp > >>>=20 > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lisp > >=20 >=20 From nobody Thu Oct 25 08:09: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 E1339130E6A for ; Thu, 25 Oct 2018 08:09:07 -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 MGwMvMHiL4Bc for ; Thu, 25 Oct 2018 08:09:06 -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 E0E2A127133 for ; Thu, 25 Oct 2018 08:09:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 945ED364F7F; Thu, 25 Oct 2018 08:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1540480145; bh=irZBBH0YI7XKoFaDIidboHhfyvoy/wTO7qYTzd/u0HM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YCb80LB/Ws8hU9ZLK85LqyE+0h6d6HGI25L/vdtUC2KJ3UzOy6ioLFJGjB2LVJSrN vO3XMxCGXfRn0hhf//+zr4sLFCpxSAL3QlHlHOKyflSbYekoI25vIrFB98VEygt8jZ s3iPwSZ7EOOmjrln0hkjvoTUycjgcjYGTUWG8LrM= 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 E6C15364F79; Thu, 25 Oct 2018 08:09:04 -0700 (PDT) To: Dino Farinacci , mohamed.boucadair@orange.com Cc: "lisp@ietf.org" References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E02E717@OPEXCNORMAD.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <6d753e78-bc13-7645-ccc3-e5c784318779@joelhalpern.com> Date: Thu, 25 Oct 2018 11:09:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 15:09:08 -0000 Actually, given the existence of RFC 8126, varying from that recommendation for the distinction between Reserved and Unassigned (by which, what we mean is Unassigned) should only be done with very good reason. Yours, Joel On 10/25/18 11:04 AM, Dino Farinacci wrote: > It doesn’t *have to be* what 8126 is. It needs to be what we believe the the unassigned bits are labeled. > > Dino > >> On Oct 24, 2018, at 10:02 PM, wrote: >> >> Hi Dino, >> >> Thank you. >> >> I’m afraid that « reserved and unassigned » is still not appropriate (see 8126). Please change it with “unassigned and available for future useâ€. >> >> Cheers, >> Med >> >> De : Dino Farinacci [mailto:farinacci@gmail.com] >> Envoyé : jeudi 25 octobre 2018 05:05 >> À : BOUCADAIR Mohamed TGI/OLN >> Cc : Luigi Iannone; lisp@ietf.org >> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned >> >> How about these changes? So we can not over complicate this. >> >> Dino >> >> >> >> >>> On Oct 24, 2018, at 2:24 AM, wrote: >>> >>> Hi Luigi, >>> >>> Fully agree that changing the text and updating the figures would be appropriate. >>> >>> Please note that a similar action is needed for draft-ietf-lisp-rfc6830bis-24, e.g., >>> >>> R: The R-bit is a Reserved bit for future use. It MUST be set to 0 >>> on transmit and MUST be ignored on receipt. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Luigi Iannone [mailto:ggx@gigix.net] >>>> Envoyé : mercredi 24 octobre 2018 10:01 >>>> À : Dino Farinacci >>>> Cc : BOUCADAIR Mohamed TGI/OLN; lisp@ietf.org >>>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned >>>> >>>> Hi All, >>>> >>>> disclaimer: this is my personal point of view. >>>> >>>> I didn’t catch before this part of RFC 8126. Thanks Med from bringing it up. >>>> >>>> While I understand Dino’s reply, because I my self as well always thought >>>> “reserved = can be used in the futureâ€, I think that Med is right. >>>> >>>> To be compliant with RFC 8126, and because we may need those “reserved†bits >>>> in the future, we better mark them as “unassignedâ€. >>>> This means changing the text and clearly spell out that this is conform to >>>> RFC 8126 definitions. >>>> >>>> At the end, it is as simple as adding the following sentence in section 2 >>>> “Requirements Notationâ€: >>>> >>>> The “Unassigned†and “Reserved†terminology for bits and fields of >>>> messages and headers defined in this documents is the Well-Known >>>> Registration Status Terminology defined in Section 6 of [RFC8126]. >>>> >>>> >>>> Then we just replace “reserved†with “unassigned†throughout the document. >>>> >>>> Ciao >>>> >>>> L. >>>> >>>> >>>> >>>>> On 23 Oct 2018, at 18:27, Dino Farinacci wrote: >>>>> >>>>> I am not sure if we should make this distinction. What does the WG think? >>>> Because fields marked “reserved†are obviously unassigned and don’t know if >>>> they will be assigned in the future. >>>>> >>>>> So I am not sure how helpful in making the distinction. >>>>> >>>>> Dino >>>>> >>>>>> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com wrote: >>>>>> >>>>>> Hi Dino, all, >>>>>> >>>>>> Apologies for raising this late easy to fix comment: >>>>>> >>>>>> RFC8126 says the following: >>>>>> >>>>>> Unassigned: Not currently assigned, and available for assignment >>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> via documented procedures. While it's generally clear that >>>>>> any values that are not registered are unassigned and >>>>>> available for assignment, it is sometimes useful to >>>>>> explicitly specify that situation. Note that this is >>>>>> distinctly different from "Reserved". >>>>>> >>>>>> Reserved: Not assigned and not available for assignment. >>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> Reserved values are held for special uses, such as to extend >>>>>> the namespace when it becomes exhausted. "Reserved" is also >>>>>> sometimes used to designate values that had been assigned >>>>>> but are no longer in use, keeping them set aside as long as >>>>>> other unassigned values are available. Note that this is >>>>>> distinctly different from "Unassigned". >>>>>> >>>>>> This is well handled in Section 5.1, but not in other sections which are >>>> using Reserved instead of Unassigned as per RFC8126. >>>>>> >>>>>> It would be appropriate to update the text accordingly. Thank you. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>> >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Thu Oct 25 08:48: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 26B53128DFD for ; Thu, 25 Oct 2018 08:48:51 -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 LoInes37310W for ; Thu, 25 Oct 2018 08:48:49 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1176D130E95 for ; Thu, 25 Oct 2018 08:48:46 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id g12-v6so4218748pgs.1 for ; Thu, 25 Oct 2018 08:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nAvDUtPMJypoXGIRmhrQtPMVBJUT4XndtRGgTuTO0c8=; b=HIntHbWsXVbTAwJ2Z/TSqG7cbjuzs43B6IebUESGnYZcKd24deObdmlbisav0iKD4W eSPs7WNIdzZyYcKDMjbYleQM+hN4771JUhqm9oAWCk7us+7Vv6SHVKVksHTGge12dTX8 v7VK1BCLJ8rwG2ScrJrgJfsl9QZbtL+c44OKAtsWOu82sDur1lk4qE8rjA2bCCtu07m+ 35Q7+mYuHJjf6akFqHH5r3mAioyEuXqW8516tbhDViT21qJP/ZBPTQM5hNiGjZmmJK9n 9YYg0JaB+K8FMXJUfvbfnmLr5kJDTwYG6HGgk0+KXj6KfARAXgmHsYshA9GKdZ/huwkl e3OQ== 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=nAvDUtPMJypoXGIRmhrQtPMVBJUT4XndtRGgTuTO0c8=; b=d5B9qh9O0v7HqO43nHMnMPmF+9k9r7U/kZcjTaO9tFEYqsLATvhZ2TFqSXFi7/mTk0 MDs+4J06TNOiW4K5s6XsfUMjeFLO5h3bNpsMQzPJnH+SkLU/RgF9EZrhXloSYfrwBlK6 /sZ/WTQBndj0J+UTLi/0jzEOAlAMdaFIuqg/eIEgOPDxPp1pWMhyyS+6QAO9KHAezbEc TalzqrLonflJSKHrprCi+1STVisnZwTs+Z08b7FqwGTiINGcU0Y79HT/yhptWFT06Jhb is1TinQ5H4Uwe94yIjPmQu1YG2+D3sK23zpksbjH+6OhGif13Kht+AG926gi5tP4YHyy DfPA== X-Gm-Message-State: AGRZ1gL1GnLdXoohUxTY9mfsuOiaAllyyu5SS+gOxRD+/MCGrz7Cc5LB HVBxicF3Hh9ETUgBCloVa78= X-Google-Smtp-Source: AJdET5fzy3IbF62gquVL2IcJB+mX+yGiERPSLI8pOxBS2NfEaNkKTOawE2oXPdEiAPTRe9AjRn5uPQ== X-Received: by 2002:a63:4d09:: with SMTP id a9-v6mr1967314pgb.408.1540482525556; Thu, 25 Oct 2018 08:48:45 -0700 (PDT) Received: from ?IPv6:2603:3024:151c:55f0:48b1:93eb:734d:3b9e? ([2603:3024:151c:55f0:48b1:93eb:734d:3b9e]) by smtp.gmail.com with ESMTPSA id r81-v6sm26422466pfa.110.2018.10.25.08.48.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Oct 2018 08:48:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <6d753e78-bc13-7645-ccc3-e5c784318779@joelhalpern.com> Date: Thu, 25 Oct 2018 08:48:24 -0700 Cc: mohamed.boucadair@orange.com, "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E02E717@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <6d753e78-bc13-7645-ccc3-e5c784318779@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 15:48:51 -0000 I don=E2=80=99t think there should be anything controversial with the = changes I made. Can we move onto more pressing issues? Dino > On Oct 25, 2018, at 8:09 AM, Joel M. Halpern = wrote: >=20 > Actually, given the existence of RFC 8126, varying from that = recommendation for the distinction between Reserved and Unassigned (by = which, what we mean is Unassigned) should only be done with very good = reason. >=20 > Yours, > Joel >=20 > On 10/25/18 11:04 AM, Dino Farinacci wrote: >> It doesn=E2=80=99t *have to be* what 8126 is. It needs to be what we = believe the the unassigned bits are labeled. >> Dino >>> On Oct 24, 2018, at 10:02 PM, = wrote: >>>=20 >>> Hi Dino, >>> Thank you. >>> I=E2=80=99m afraid that =C2=AB reserved and unassigned =C2=BB is = still not appropriate (see 8126). Please change it with =E2=80=9Cunassigne= d and available for future use=E2=80=9D. >>> Cheers, >>> Med >>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>> Envoy=C3=A9 : jeudi 25 octobre 2018 05:05 >>> =C3=80 : BOUCADAIR Mohamed TGI/OLN >>> Cc : Luigi Iannone; lisp@ietf.org >>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: = Reserved/Unassigned >>> How about these changes? So we can not over complicate this. >>>=20 >>> Dino >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Oct 24, 2018, at 2:24 AM, = wrote: >>>>=20 >>>> Hi Luigi, >>>>=20 >>>> Fully agree that changing the text and updating the figures would = be appropriate. >>>>=20 >>>> Please note that a similar action is needed for = draft-ietf-lisp-rfc6830bis-24, e.g., >>>>=20 >>>> R: The R-bit is a Reserved bit for future use. It MUST be set to = 0 >>>> on transmit and MUST be ignored on receipt. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>>> -----Message d'origine----- >>>>> De : Luigi Iannone [mailto:ggx@gigix.net] >>>>> Envoy=C3=A9 : mercredi 24 octobre 2018 10:01 >>>>> =C3=80 : Dino Farinacci >>>>> Cc : BOUCADAIR Mohamed TGI/OLN; lisp@ietf.org >>>>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: = Reserved/Unassigned >>>>>=20 >>>>> Hi All, >>>>>=20 >>>>> disclaimer: this is my personal point of view. >>>>>=20 >>>>> I didn=E2=80=99t catch before this part of RFC 8126. Thanks Med = from bringing it up. >>>>>=20 >>>>> While I understand Dino=E2=80=99s reply, because I my self as well = always thought >>>>> =E2=80=9Creserved =3D can be used in the future=E2=80=9D, I think = that Med is right. >>>>>=20 >>>>> To be compliant with RFC 8126, and because we may need those = =E2=80=9Creserved=E2=80=9D bits >>>>> in the future, we better mark them as =E2=80=9Cunassigned=E2=80=9D. >>>>> This means changing the text and clearly spell out that this is = conform to >>>>> RFC 8126 definitions. >>>>>=20 >>>>> At the end, it is as simple as adding the following sentence in = section 2 >>>>> =E2=80=9CRequirements Notation=E2=80=9D: >>>>>=20 >>>>> The =E2=80=9CUnassigned=E2=80=9D and =E2=80=9CReserved=E2=80=9D= terminology for bits and fields of >>>>> messages and headers defined in this documents is the = Well-Known >>>>> Registration Status Terminology defined in Section 6 of = [RFC8126]. >>>>>=20 >>>>>=20 >>>>> Then we just replace =E2=80=9Creserved=E2=80=9D with = =E2=80=9Cunassigned=E2=80=9D throughout the document. >>>>>=20 >>>>> Ciao >>>>>=20 >>>>> L. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 23 Oct 2018, at 18:27, Dino Farinacci = wrote: >>>>>>=20 >>>>>> I am not sure if we should make this distinction. What does the = WG think? >>>>> Because fields marked =E2=80=9Creserved=E2=80=9D are obviously = unassigned and don=E2=80=99t know if >>>>> they will be assigned in the future. >>>>>>=20 >>>>>> So I am not sure how helpful in making the distinction. >>>>>>=20 >>>>>> Dino >>>>>>=20 >>>>>>> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com = wrote: >>>>>>>=20 >>>>>>> Hi Dino, all, >>>>>>>=20 >>>>>>> Apologies for raising this late easy to fix comment: >>>>>>>=20 >>>>>>> RFC8126 says the following: >>>>>>>=20 >>>>>>> Unassigned: Not currently assigned, and available for = assignment >>>>>>> = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>> via documented procedures. While it's generally clear = that >>>>>>> any values that are not registered are unassigned and >>>>>>> available for assignment, it is sometimes useful to >>>>>>> explicitly specify that situation. Note that this is >>>>>>> distinctly different from "Reserved". >>>>>>>=20 >>>>>>> Reserved: Not assigned and not available for assignment. >>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>> Reserved values are held for special uses, such as to = extend >>>>>>> the namespace when it becomes exhausted. "Reserved" = is also >>>>>>> sometimes used to designate values that had been = assigned >>>>>>> but are no longer in use, keeping them set aside as = long as >>>>>>> other unassigned values are available. Note that this = is >>>>>>> distinctly different from "Unassigned". >>>>>>>=20 >>>>>>> This is well handled in Section 5.1, but not in other sections = which are >>>>> using Reserved instead of Unassigned as per RFC8126. >>>>>>>=20 >>>>>>> It would be appropriate to update the text accordingly. Thank = you. >>>>>>>=20 >>>>>>> Cheers, >>>>>>> Med >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>=20 >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Oct 25 08:57: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 1BF83130E92 for ; Thu, 25 Oct 2018 08:57:14 -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 F97zLAdvODrM for ; Thu, 25 Oct 2018 08:57:11 -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 8F0B6130E94 for ; Thu, 25 Oct 2018 08:57:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 468C5E402F5; Thu, 25 Oct 2018 08:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1540483031; bh=RKHeHSGxpLQH+S8Lye+fnvkKfISUX8fRlL47E2VRF3k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Cj9/zKZsrTcaZcWlPj4bWKV4NqYUwRlah0ocW52ABUcHdRAlSYUhhVE/+8vrgOqYz 3KFjokeSb5U0C2hoNTazuF8HlLgw9wwwBb96etZwEMduYTseIbpkeeNZix6QQ57CK6 JP03kVUA67LjvEMnMM3aBI4zj0bPXgdI2g9b3CEU= 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 92D8CE402EA; Thu, 25 Oct 2018 08:57:10 -0700 (PDT) To: Dino Farinacci Cc: mohamed.boucadair@orange.com, "lisp@ietf.org" References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E02E717@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <6d753e78-bc13-7645-ccc3-e5c784318779@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 25 Oct 2018 11:57:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 15:57:14 -0000 Is it a big deal? No. Is it likely someone will ask for it during IESG review? Moderate. Would I just do it in your shoes? Yes. Do you have to do it? No. Yours, Joel On 10/25/18 11:48 AM, Dino Farinacci wrote: > I don’t think there should be anything controversial with the changes I made. Can we move onto more pressing issues? > > Dino > >> On Oct 25, 2018, at 8:09 AM, Joel M. Halpern wrote: >> >> Actually, given the existence of RFC 8126, varying from that recommendation for the distinction between Reserved and Unassigned (by which, what we mean is Unassigned) should only be done with very good reason. >> >> Yours, >> Joel >> >> On 10/25/18 11:04 AM, Dino Farinacci wrote: >>> It doesn’t *have to be* what 8126 is. It needs to be what we believe the the unassigned bits are labeled. >>> Dino >>>> On Oct 24, 2018, at 10:02 PM, wrote: >>>> >>>> Hi Dino, >>>> Thank you. >>>> I’m afraid that « reserved and unassigned » is still not appropriate (see 8126). Please change it with “unassigned and available for future useâ€. >>>> Cheers, >>>> Med >>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>> Envoyé : jeudi 25 octobre 2018 05:05 >>>> À : BOUCADAIR Mohamed TGI/OLN >>>> Cc : Luigi Iannone; lisp@ietf.org >>>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned >>>> How about these changes? So we can not over complicate this. >>>> >>>> Dino >>>> >>>> >>>> >>>> >>>>> On Oct 24, 2018, at 2:24 AM, wrote: >>>>> >>>>> Hi Luigi, >>>>> >>>>> Fully agree that changing the text and updating the figures would be appropriate. >>>>> >>>>> Please note that a similar action is needed for draft-ietf-lisp-rfc6830bis-24, e.g., >>>>> >>>>> R: The R-bit is a Reserved bit for future use. It MUST be set to 0 >>>>> on transmit and MUST be ignored on receipt. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Luigi Iannone [mailto:ggx@gigix.net] >>>>>> Envoyé : mercredi 24 octobre 2018 10:01 >>>>>> À : Dino Farinacci >>>>>> Cc : BOUCADAIR Mohamed TGI/OLN; lisp@ietf.org >>>>>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned >>>>>> >>>>>> Hi All, >>>>>> >>>>>> disclaimer: this is my personal point of view. >>>>>> >>>>>> I didn’t catch before this part of RFC 8126. Thanks Med from bringing it up. >>>>>> >>>>>> While I understand Dino’s reply, because I my self as well always thought >>>>>> “reserved = can be used in the futureâ€, I think that Med is right. >>>>>> >>>>>> To be compliant with RFC 8126, and because we may need those “reserved†bits >>>>>> in the future, we better mark them as “unassignedâ€. >>>>>> This means changing the text and clearly spell out that this is conform to >>>>>> RFC 8126 definitions. >>>>>> >>>>>> At the end, it is as simple as adding the following sentence in section 2 >>>>>> “Requirements Notationâ€: >>>>>> >>>>>> The “Unassigned†and “Reserved†terminology for bits and fields of >>>>>> messages and headers defined in this documents is the Well-Known >>>>>> Registration Status Terminology defined in Section 6 of [RFC8126]. >>>>>> >>>>>> >>>>>> Then we just replace “reserved†with “unassigned†throughout the document. >>>>>> >>>>>> Ciao >>>>>> >>>>>> L. >>>>>> >>>>>> >>>>>> >>>>>>> On 23 Oct 2018, at 18:27, Dino Farinacci wrote: >>>>>>> >>>>>>> I am not sure if we should make this distinction. What does the WG think? >>>>>> Because fields marked “reserved†are obviously unassigned and don’t know if >>>>>> they will be assigned in the future. >>>>>>> >>>>>>> So I am not sure how helpful in making the distinction. >>>>>>> >>>>>>> Dino >>>>>>> >>>>>>>> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com wrote: >>>>>>>> >>>>>>>> Hi Dino, all, >>>>>>>> >>>>>>>> Apologies for raising this late easy to fix comment: >>>>>>>> >>>>>>>> RFC8126 says the following: >>>>>>>> >>>>>>>> Unassigned: Not currently assigned, and available for assignment >>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>> via documented procedures. While it's generally clear that >>>>>>>> any values that are not registered are unassigned and >>>>>>>> available for assignment, it is sometimes useful to >>>>>>>> explicitly specify that situation. Note that this is >>>>>>>> distinctly different from "Reserved". >>>>>>>> >>>>>>>> Reserved: Not assigned and not available for assignment. >>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>> Reserved values are held for special uses, such as to extend >>>>>>>> the namespace when it becomes exhausted. "Reserved" is also >>>>>>>> sometimes used to designate values that had been assigned >>>>>>>> but are no longer in use, keeping them set aside as long as >>>>>>>> other unassigned values are available. Note that this is >>>>>>>> distinctly different from "Unassigned". >>>>>>>> >>>>>>>> This is well handled in Section 5.1, but not in other sections which are >>>>>> using Reserved instead of Unassigned as per RFC8126. >>>>>>>> >>>>>>>> It would be appropriate to update the text accordingly. Thank you. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>> _______________________________________________ >>>>>>>> lisp mailing list >>>>>>>> lisp@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>> >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp > > From nobody Thu Oct 25 09:01: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 6D297130E92 for ; Thu, 25 Oct 2018 09:01:48 -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 k2W9aJKo03FF for ; Thu, 25 Oct 2018 09:01:45 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FB1130E00 for ; Thu, 25 Oct 2018 09:01:45 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id g21-v6so4402808pfi.7 for ; Thu, 25 Oct 2018 09:01:45 -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=9ybj7wbxX4lxLtn8N6DW95Fq49TUAYJDPhl3FmBjAQI=; b=rXimY+MCIA81OE/0su0+rTN0cjNzu5Uz8uR+9d3nQyU76M3pP9AHs+xjOqlnoqzDxc v+QQKo4muRfJB0pKPDgg/Yj7Wreh7rGypoft6HT9LJvO04emZ41G8roZYaKSXreJK7kD 1D/4GdyCyZGKDPKOoV/QHMJNHwuiwYu3WC5FYnOaWLulTd7EJ6z/CeQqLX0tkEdlX6+J wGpmKcT2fSx7Ob2A38rKHTrElgXXqszqdskQaCaLTdmbW/8yW79PmHf+57YDdh9jhv+o cOlOhCg8s6wNn/dwngIoX4cfhjqA4trRGiGL4qm6Q9Mah28CdMdde8TRV6z/oCXLDDWm zm2w== 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=9ybj7wbxX4lxLtn8N6DW95Fq49TUAYJDPhl3FmBjAQI=; b=PlkoMbWNbkvPsAwsQhuY95iU72ukNTMjQmsjDxQktsBfRQ5IILIkaIqPTFNQWRXFdc BNEfprIgUA5onyOuRu+KS0lMF6Eh8Zwgo01Kt8ccjUZ2gAQ4zKMtFExL1ZiVFHc6sCRV Lbx16Hspi2vGFb6qlGhJXRxVRdQku1RJRQ39AyzZVgVJ55p084xMW1C49mbQxVmoz3Vh ykqkTaexFrmPFTjZK0H1ZidBB4hdbnEHPzcVXcVPkvR0kW1XZwIyAmJWWNK+WmS/GtWe trja7gUFTQ7CDZ8CjFnsYlTQF/1zGDnvBvtw7HNzNHtSDExsyh19g6HCtJ+yEnGityaN 6Yag== X-Gm-Message-State: AGRZ1gKd6UIvLY7GmlhsD9zm6tK3r5RDhbMGyXeVqOfYXsqufTvkd4ot 42jenm6VV/7QhpexsCEZa4BYbVdJ X-Google-Smtp-Source: AJdET5fdodE/DTSDXsKyzH91TSgToQH0RNLD+1eqVaMcyxWsDXZgKWp3pwr7fJUnfeIi5D1czGVWXA== X-Received: by 2002:a62:8f:: with SMTP id 137-v6mr2114435pfa.24.1540483305361; Thu, 25 Oct 2018 09:01:45 -0700 (PDT) Received: from ?IPv6:2603:3024:151c:55f0:48b1:93eb:734d:3b9e? ([2603:3024:151c:55f0:48b1:93eb:734d:3b9e]) by smtp.gmail.com with ESMTPSA id u1-v6sm8586792pgr.61.2018.10.25.09.01.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Oct 2018 09:01:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Thu, 25 Oct 2018 09:01:42 -0700 Cc: mohamed.boucadair@orange.com, "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <967F942A-6E00-481F-A5DC-2A5F0C38F3E2@gmail.com> References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E02E717@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <6d753e78-bc13-7645-ccc3-e5c784318779@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 16:01:48 -0000 Do you think what I added will be objected to? Dino > On Oct 25, 2018, at 8:57 AM, Joel M. Halpern = wrote: >=20 > Is it a big deal? No. > Is it likely someone will ask for it during IESG review? Moderate. > Would I just do it in your shoes? Yes. > Do you have to do it? No. >=20 > Yours, > Joel >=20 > On 10/25/18 11:48 AM, Dino Farinacci wrote: >> I don=E2=80=99t think there should be anything controversial with the = changes I made. Can we move onto more pressing issues? >> Dino >>> On Oct 25, 2018, at 8:09 AM, Joel M. Halpern = wrote: >>>=20 >>> Actually, given the existence of RFC 8126, varying from that = recommendation for the distinction between Reserved and Unassigned (by = which, what we mean is Unassigned) should only be done with very good = reason. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 10/25/18 11:04 AM, Dino Farinacci wrote: >>>> It doesn=E2=80=99t *have to be* what 8126 is. It needs to be what = we believe the the unassigned bits are labeled. >>>> Dino >>>>> On Oct 24, 2018, at 10:02 PM, = wrote: >>>>>=20 >>>>> Hi Dino, >>>>> Thank you. >>>>> I=E2=80=99m afraid that =C2=AB reserved and unassigned =C2=BB is = still not appropriate (see 8126). Please change it with =E2=80=9Cunassigne= d and available for future use=E2=80=9D. >>>>> Cheers, >>>>> Med >>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>> Envoy=C3=A9 : jeudi 25 octobre 2018 05:05 >>>>> =C3=80 : BOUCADAIR Mohamed TGI/OLN >>>>> Cc : Luigi Iannone; lisp@ietf.org >>>>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: = Reserved/Unassigned >>>>> How about these changes? So we can not over complicate this. >>>>>=20 >>>>> Dino >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Oct 24, 2018, at 2:24 AM, = wrote: >>>>>>=20 >>>>>> Hi Luigi, >>>>>>=20 >>>>>> Fully agree that changing the text and updating the figures would = be appropriate. >>>>>>=20 >>>>>> Please note that a similar action is needed for = draft-ietf-lisp-rfc6830bis-24, e.g., >>>>>>=20 >>>>>> R: The R-bit is a Reserved bit for future use. It MUST be set = to 0 >>>>>> on transmit and MUST be ignored on receipt. >>>>>>=20 >>>>>> Cheers, >>>>>> Med >>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : Luigi Iannone [mailto:ggx@gigix.net] >>>>>>> Envoy=C3=A9 : mercredi 24 octobre 2018 10:01 >>>>>>> =C3=80 : Dino Farinacci >>>>>>> Cc : BOUCADAIR Mohamed TGI/OLN; lisp@ietf.org >>>>>>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: = Reserved/Unassigned >>>>>>>=20 >>>>>>> Hi All, >>>>>>>=20 >>>>>>> disclaimer: this is my personal point of view. >>>>>>>=20 >>>>>>> I didn=E2=80=99t catch before this part of RFC 8126. Thanks Med = from bringing it up. >>>>>>>=20 >>>>>>> While I understand Dino=E2=80=99s reply, because I my self as = well always thought >>>>>>> =E2=80=9Creserved =3D can be used in the future=E2=80=9D, I = think that Med is right. >>>>>>>=20 >>>>>>> To be compliant with RFC 8126, and because we may need those = =E2=80=9Creserved=E2=80=9D bits >>>>>>> in the future, we better mark them as =E2=80=9Cunassigned=E2=80=9D= . >>>>>>> This means changing the text and clearly spell out that this is = conform to >>>>>>> RFC 8126 definitions. >>>>>>>=20 >>>>>>> At the end, it is as simple as adding the following sentence in = section 2 >>>>>>> =E2=80=9CRequirements Notation=E2=80=9D: >>>>>>>=20 >>>>>>> The =E2=80=9CUnassigned=E2=80=9D and =E2=80=9CReserved=E2=80= =9D terminology for bits and fields of >>>>>>> messages and headers defined in this documents is the = Well-Known >>>>>>> Registration Status Terminology defined in Section 6 of = [RFC8126]. >>>>>>>=20 >>>>>>>=20 >>>>>>> Then we just replace =E2=80=9Creserved=E2=80=9D with = =E2=80=9Cunassigned=E2=80=9D throughout the document. >>>>>>>=20 >>>>>>> Ciao >>>>>>>=20 >>>>>>> L. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 23 Oct 2018, at 18:27, Dino Farinacci = wrote: >>>>>>>>=20 >>>>>>>> I am not sure if we should make this distinction. What does the = WG think? >>>>>>> Because fields marked =E2=80=9Creserved=E2=80=9D are obviously = unassigned and don=E2=80=99t know if >>>>>>> they will be assigned in the future. >>>>>>>>=20 >>>>>>>> So I am not sure how helpful in making the distinction. >>>>>>>>=20 >>>>>>>> Dino >>>>>>>>=20 >>>>>>>>> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com = wrote: >>>>>>>>>=20 >>>>>>>>> Hi Dino, all, >>>>>>>>>=20 >>>>>>>>> Apologies for raising this late easy to fix comment: >>>>>>>>>=20 >>>>>>>>> RFC8126 says the following: >>>>>>>>>=20 >>>>>>>>> Unassigned: Not currently assigned, and available for = assignment >>>>>>>>> = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>>> via documented procedures. While it's generally = clear that >>>>>>>>> any values that are not registered are unassigned = and >>>>>>>>> available for assignment, it is sometimes useful to >>>>>>>>> explicitly specify that situation. Note that this = is >>>>>>>>> distinctly different from "Reserved". >>>>>>>>>=20 >>>>>>>>> Reserved: Not assigned and not available for assignment. >>>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>>> Reserved values are held for special uses, such as = to extend >>>>>>>>> the namespace when it becomes exhausted. "Reserved" = is also >>>>>>>>> sometimes used to designate values that had been = assigned >>>>>>>>> but are no longer in use, keeping them set aside as = long as >>>>>>>>> other unassigned values are available. Note that = this is >>>>>>>>> distinctly different from "Unassigned". >>>>>>>>>=20 >>>>>>>>> This is well handled in Section 5.1, but not in other sections = which are >>>>>>> using Reserved instead of Unassigned as per RFC8126. >>>>>>>>>=20 >>>>>>>>> It would be appropriate to update the text accordingly. Thank = you. >>>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>> Med >>>>>>>>> _______________________________________________ >>>>>>>>> lisp mailing list >>>>>>>>> lisp@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> lisp mailing list >>>>>>>> lisp@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Oct 29 00:21:12 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719A812D4E9 for ; Mon, 29 Oct 2018 00:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9u5An1d5fkt for ; Mon, 29 Oct 2018 00:21:09 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8745E129C6B for ; Mon, 29 Oct 2018 00:21:09 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 42k5cM46qCz5vgw; Mon, 29 Oct 2018 08:21:07 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 42k5cM33DszDq81; Mon, 29 Oct 2018 08:21:07 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0415.000; Mon, 29 Oct 2018 08:21:07 +0100 From: To: Dino Farinacci CC: Luigi Iannone , "lisp@ietf.org" Thread-Topic: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned Thread-Index: AdRqpEd10cZL+uOwTGaba/yk/wtayQBz8V6zALjrsyA= Date: Mon, 29 Oct 2018 07:21:06 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E038A76@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E02E717@OPEXCNORMAD.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 07:21:12 -0000 SGkgRGlubywNCg0KSWYgSSB3ZXJlIHRoZSBlZGl0b3Igb2YgdGhlIGRvY3VtZW50LCBJIHdvdWxk IGZvbGxvdyA4MTI2Lg0KDQpUaGFuayB5b3UuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogRGlubyBGYXJpbmFjY2kgW21haWx0bzpmYXJp bmFjY2lAZ21haWwuY29tXQ0KPiBFbnZvecOpwqA6IGpldWRpIDI1IG9jdG9icmUgMjAxOCAxNzow NA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+IENjwqA6IEx1aWdpIElhbm5v bmU7IGxpc3BAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtsaXNwXSBkcmFmdC1pZXRmLWxpc3At cmZjNjgzM2Jpcy0xOTogUmVzZXJ2ZWQvVW5hc3NpZ25lZA0KPiANCj4gSXQgZG9lc27igJl0ICpo YXZlIHRvIGJlKiB3aGF0IDgxMjYgaXMuIEl0IG5lZWRzIHRvIGJlIHdoYXQgd2UgYmVsaWV2ZSB0 aGUgdGhlDQo+IHVuYXNzaWduZWQgYml0cyBhcmUgbGFiZWxlZC4NCj4gDQo+IERpbm8NCj4gDQo+ ID4gT24gT2N0IDI0LCAyMDE4LCBhdCAxMDowMiBQTSwgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+DQo+IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4gPg0KPiA+ IEhpIERpbm8sDQo+ID4NCj4gPiBUaGFuayB5b3UuDQo+ID4NCj4gPiBJ4oCZbSBhZnJhaWQgdGhh dCDCqyByZXNlcnZlZCBhbmQgdW5hc3NpZ25lZCDCuyBpcyBzdGlsbCBub3QgYXBwcm9wcmlhdGUg KHNlZQ0KPiA4MTI2KS4gUGxlYXNlIGNoYW5nZSBpdCB3aXRoIOKAnHVuYXNzaWduZWQgYW5kIGF2 YWlsYWJsZSBmb3IgZnV0dXJlIHVzZeKAnS4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4g Pg0KPiA+IERlIDogRGlubyBGYXJpbmFjY2kgW21haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tXQ0K PiA+IEVudm95w6kgOiBqZXVkaSAyNSBvY3RvYnJlIDIwMTggMDU6MDUNCj4gPiDDgCA6IEJPVUNB REFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gPiBDYyA6IEx1aWdpIElhbm5vbmU7IGxpc3BAaWV0Zi5v cmcNCj4gPiBPYmpldCA6IFJlOiBbbGlzcF0gZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzNiaXMtMTk6 IFJlc2VydmVkL1VuYXNzaWduZWQNCj4gPg0KPiA+IEhvdyBhYm91dCB0aGVzZSBjaGFuZ2VzPyBT byB3ZSBjYW4gbm90IG92ZXIgY29tcGxpY2F0ZSB0aGlzLg0KPiA+DQo+ID4gRGlubw0KPiA+DQo+ ID4NCj4gPg0KPiA+DQo+ID4gPiBPbiBPY3QgMjQsIDIwMTgsIGF0IDI6MjQgQU0sIDxtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4g d3JvdGU6DQo+ID4gPg0KPiA+ID4gSGkgTHVpZ2ksDQo+ID4gPg0KPiA+ID4gRnVsbHkgYWdyZWUg dGhhdCBjaGFuZ2luZyB0aGUgdGV4dCBhbmQgdXBkYXRpbmcgdGhlIGZpZ3VyZXMgd291bGQgYmUN Cj4gYXBwcm9wcmlhdGUuDQo+ID4gPg0KPiA+ID4gUGxlYXNlIG5vdGUgdGhhdCBhIHNpbWlsYXIg YWN0aW9uIGlzIG5lZWRlZCBmb3IgZHJhZnQtaWV0Zi1saXNwLQ0KPiByZmM2ODMwYmlzLTI0LCBl LmcuLA0KPiA+ID4NCj4gPiA+ICAgUjogVGhlIFItYml0IGlzIGEgUmVzZXJ2ZWQgYml0IGZvciBm dXR1cmUgdXNlLiAgSXQgTVVTVCBiZSBzZXQgdG8gMA0KPiA+ID4gICAgICBvbiB0cmFuc21pdCBh bmQgTVVTVCBiZSBpZ25vcmVkIG9uIHJlY2VpcHQuDQo+ID4gPg0KPiA+ID4gQ2hlZXJzLA0KPiA+ ID4gTWVkDQo+ID4gPg0KPiA+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4+ IERlIDogTHVpZ2kgSWFubm9uZSBbbWFpbHRvOmdneEBnaWdpeC5uZXRdDQo+ID4gPj4gRW52b3nD qSA6IG1lcmNyZWRpIDI0IG9jdG9icmUgMjAxOCAxMDowMQ0KPiA+ID4+IMOAIDogRGlubyBGYXJp bmFjY2kNCj4gPiA+PiBDYyA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IGxpc3BAaWV0Zi5v cmcNCj4gPiA+PiBPYmpldCA6IFJlOiBbbGlzcF0gZHJhZnQtaWV0Zi1saXNwLXJmYzY4MzNiaXMt MTk6IFJlc2VydmVkL1VuYXNzaWduZWQNCj4gPiA+Pg0KPiA+ID4+IEhpIEFsbCwNCj4gPiA+Pg0K PiA+ID4+IGRpc2NsYWltZXI6IHRoaXMgaXMgbXkgcGVyc29uYWwgcG9pbnQgb2Ygdmlldy4NCj4g PiA+Pg0KPiA+ID4+IEkgZGlkbuKAmXQgY2F0Y2ggYmVmb3JlIHRoaXMgcGFydCBvZiBSRkMgODEy Ni4gVGhhbmtzIE1lZCBmcm9tIGJyaW5naW5nIGl0DQo+IHVwLg0KPiA+ID4+DQo+ID4gPj4gV2hp bGUgSSB1bmRlcnN0YW5kIERpbm/igJlzIHJlcGx5LCBiZWNhdXNlIEkgbXkgc2VsZiBhcyB3ZWxs IGFsd2F5cw0KPiB0aG91Z2h0DQo+ID4gPj4g4oCccmVzZXJ2ZWQgPSBjYW4gYmUgdXNlZCBpbiB0 aGUgZnV0dXJl4oCdLCBJIHRoaW5rIHRoYXQgTWVkIGlzIHJpZ2h0Lg0KPiA+ID4+DQo+ID4gPj4g VG8gYmUgY29tcGxpYW50IHdpdGggUkZDIDgxMjYsIGFuZCBiZWNhdXNlIHdlIG1heSBuZWVkIHRo b3NlIOKAnHJlc2VydmVk4oCdDQo+IGJpdHMNCj4gPiA+PiBpbiB0aGUgZnV0dXJlLCB3ZSBiZXR0 ZXIgbWFyayB0aGVtIGFzIOKAnHVuYXNzaWduZWTigJ0uDQo+ID4gPj4gVGhpcyBtZWFucyBjaGFu Z2luZyB0aGUgdGV4dCBhbmQgY2xlYXJseSBzcGVsbCBvdXQgdGhhdCB0aGlzIGlzIGNvbmZvcm0N Cj4gdG8NCj4gPiA+PiBSRkMgODEyNiBkZWZpbml0aW9ucy4NCj4gPiA+Pg0KPiA+ID4+IEF0IHRo ZSBlbmQsIGl0IGlzIGFzIHNpbXBsZSBhcyBhZGRpbmcgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBp biBzZWN0aW9uDQo+IDINCj4gPiA+PiDigJxSZXF1aXJlbWVudHMgTm90YXRpb27igJ06DQo+ID4g Pj4NCj4gPiA+PiAgICAgICBUaGUgIOKAnFVuYXNzaWduZWTigJ0gYW5kIOKAnFJlc2VydmVk4oCd IHRlcm1pbm9sb2d5IGZvciBiaXRzIGFuZCBmaWVsZHMNCj4gb2YNCj4gPiA+PiAgICAgICBtZXNz YWdlcyBhbmQgaGVhZGVycyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnRzIGlzIHRoZSBXZWxsLUtu b3duDQo+ID4gPj4gICAgICAgUmVnaXN0cmF0aW9uIFN0YXR1cyBUZXJtaW5vbG9neSBkZWZpbmVk IGluIFNlY3Rpb24gNiBvZiBbUkZDODEyNl0uDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IFRoZW4g d2UganVzdCByZXBsYWNlIOKAnHJlc2VydmVk4oCdIHdpdGgg4oCcdW5hc3NpZ25lZOKAnSB0aHJv dWdob3V0IHRoZQ0KPiBkb2N1bWVudC4NCj4gPiA+Pg0KPiA+ID4+IENpYW8NCj4gPiA+Pg0KPiA+ ID4+IEwuDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4+IE9uIDIzIE9jdCAyMDE4LCBh dCAxODoyNywgRGlubyBGYXJpbmFjY2kgPGZhcmluYWNjaUBnbWFpbC5jb20+IHdyb3RlOg0KPiA+ ID4+Pg0KPiA+ID4+PiBJIGFtIG5vdCBzdXJlIGlmIHdlIHNob3VsZCBtYWtlIHRoaXMgZGlzdGlu Y3Rpb24uIFdoYXQgZG9lcyB0aGUgV0cNCj4gdGhpbms/DQo+ID4gPj4gQmVjYXVzZSBmaWVsZHMg bWFya2VkIOKAnHJlc2VydmVk4oCdIGFyZSBvYnZpb3VzbHkgdW5hc3NpZ25lZCBhbmQgZG9u4oCZ dCBrbm93DQo+IGlmDQo+ID4gPj4gdGhleSB3aWxsIGJlIGFzc2lnbmVkIGluIHRoZSBmdXR1cmUu DQo+ID4gPj4+DQo+ID4gPj4+IFNvIEkgYW0gbm90IHN1cmUgaG93IGhlbHBmdWwgaW4gbWFraW5n IHRoZSBkaXN0aW5jdGlvbi4NCj4gPiA+Pj4NCj4gPiA+Pj4gRGlubw0KPiA+ID4+Pg0KPiA+ID4+ Pj4gT24gT2N0IDIzLCAyMDE4LCBhdCAxMjo0NCBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSB3cm90ZToNCj4gPiA+Pj4+DQo+ID4gPj4+PiBIaSBEaW5vLCBhbGwsDQo+ID4gPj4+Pg0K PiA+ID4+Pj4gQXBvbG9naWVzIGZvciByYWlzaW5nIHRoaXMgbGF0ZSBlYXN5IHRvIGZpeCBjb21t ZW50Og0KPiA+ID4+Pj4NCj4gPiA+Pj4+IFJGQzgxMjYgc2F5cyB0aGUgZm9sbG93aW5nOg0KPiA+ ID4+Pj4NCj4gPiA+Pj4+ICAgICBVbmFzc2lnbmVkOiAgTm90IGN1cnJlbnRseSBhc3NpZ25lZCwg YW5kIGF2YWlsYWJsZSBmb3IgYXNzaWdubWVudA0KPiA+ID4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ID4g Pj4+PiAgICAgICAgICAgdmlhIGRvY3VtZW50ZWQgcHJvY2VkdXJlcy4gIFdoaWxlIGl0J3MgZ2Vu ZXJhbGx5IGNsZWFyIHRoYXQNCj4gPiA+Pj4+ICAgICAgICAgICBhbnkgdmFsdWVzIHRoYXQgYXJl IG5vdCByZWdpc3RlcmVkIGFyZSB1bmFzc2lnbmVkIGFuZA0KPiA+ID4+Pj4gICAgICAgICAgIGF2 YWlsYWJsZSBmb3IgYXNzaWdubWVudCwgaXQgaXMgc29tZXRpbWVzIHVzZWZ1bCB0bw0KPiA+ID4+ Pj4gICAgICAgICAgIGV4cGxpY2l0bHkgc3BlY2lmeSB0aGF0IHNpdHVhdGlvbi4gIE5vdGUgdGhh dCB0aGlzIGlzDQo+ID4gPj4+PiAgICAgICAgICAgZGlzdGluY3RseSBkaWZmZXJlbnQgZnJvbSAi UmVzZXJ2ZWQiLg0KPiA+ID4+Pj4NCj4gPiA+Pj4+ICAgICBSZXNlcnZlZDogIE5vdCBhc3NpZ25l ZCBhbmQgbm90IGF2YWlsYWJsZSBmb3IgYXNzaWdubWVudC4NCj4gPiA+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ID4g Pj4+PiAgICAgICAgICAgUmVzZXJ2ZWQgdmFsdWVzIGFyZSBoZWxkIGZvciBzcGVjaWFsIHVzZXMs IHN1Y2ggYXMgdG8gZXh0ZW5kDQo+ID4gPj4+PiAgICAgICAgICAgdGhlIG5hbWVzcGFjZSB3aGVu IGl0IGJlY29tZXMgZXhoYXVzdGVkLiAgIlJlc2VydmVkIiBpcyBhbHNvDQo+ID4gPj4+PiAgICAg ICAgICAgc29tZXRpbWVzIHVzZWQgdG8gZGVzaWduYXRlIHZhbHVlcyB0aGF0IGhhZCBiZWVuIGFz c2lnbmVkDQo+ID4gPj4+PiAgICAgICAgICAgYnV0IGFyZSBubyBsb25nZXIgaW4gdXNlLCBrZWVw aW5nIHRoZW0gc2V0IGFzaWRlIGFzIGxvbmcgYXMNCj4gPiA+Pj4+ICAgICAgICAgICBvdGhlciB1 bmFzc2lnbmVkIHZhbHVlcyBhcmUgYXZhaWxhYmxlLiAgTm90ZSB0aGF0IHRoaXMgaXMNCj4gPiA+ Pj4+ICAgICAgICAgICBkaXN0aW5jdGx5IGRpZmZlcmVudCBmcm9tICJVbmFzc2lnbmVkIi4NCj4g PiA+Pj4+DQo+ID4gPj4+PiBUaGlzIGlzIHdlbGwgaGFuZGxlZCBpbiBTZWN0aW9uIDUuMSwgYnV0 IG5vdCBpbiBvdGhlciBzZWN0aW9ucyB3aGljaA0KPiBhcmUNCj4gPiA+PiB1c2luZyBSZXNlcnZl ZCBpbnN0ZWFkIG9mIFVuYXNzaWduZWQgYXMgcGVyIFJGQzgxMjYuDQo+ID4gPj4+Pg0KPiA+ID4+ Pj4gSXQgd291bGQgYmUgYXBwcm9wcmlhdGUgdG8gdXBkYXRlIHRoZSB0ZXh0IGFjY29yZGluZ2x5 LiBUaGFuayB5b3UuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gQ2hlZXJzLA0KPiA+ID4+Pj4gTWVkDQo+ ID4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4+Pj4gbGlzcCBtYWlsaW5nIGxpc3QNCj4gPiA+Pj4+IGxpc3BAaWV0Zi5vcmcNCj4gPiA+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KPiA+ID4+Pg0K PiA+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4+PiBsaXNwIG1haWxpbmcgbGlzdA0KPiA+ID4+PiBsaXNwQGlldGYub3JnDQo+ID4gPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KPiA+ID4NCj4gPg0K DQo= From nobody Mon Oct 29 02:02:11 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620A8130DF9 for ; Mon, 29 Oct 2018 02:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unf2x070TRtm for ; Mon, 29 Oct 2018 02:02:05 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853E712D4EC for ; Mon, 29 Oct 2018 02:02:05 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id q12-v6so4374210wmq.0 for ; Mon, 29 Oct 2018 02:02:05 -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=t3N4CsREQV+Keezt52sp7YvzXwdsvDNuNjOqQo0w5R4=; b=MjhjRm7pIge1LIB9yYNSCmoV/NVwyVgZQAaVBnsQ9dNxd+qfQYyBA6/amkRPEPDnI+ /028rVRXu6J1kCJ7X0t4sAb46yo/ijEHmub6kPwgQTy2qUV1Hct8EzmgNk8721cTD8xt KlD/xPM/kGX3Dzj2kOra07NM0xdctU9WVpZFHfH/WT7T1qPzsvmoboqCYz+IS16D6Kqj DXT8fP9fqYMhqFOLUZIy+tpeU5bsd96tqsM3kyAOMdwLmpcs2aUCJ5BlSplxCZ0pGB/c 5LNO9kavCKehUVV5klXkP4U1BXCOJWYpTfGzNvhNAeCAWIte1HRK5XKDu8Q027a+5lgS s2IQ== 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=t3N4CsREQV+Keezt52sp7YvzXwdsvDNuNjOqQo0w5R4=; b=Z7Pub9Eb3Dg6s9QXukG/uwIIQAy3/W3P/A4Aw05KtGyxaWvGsq2/BH3OnPrDfIaVEZ s2Z0RG9iK3ek/O37ynsBrHlKnEn0F0C4lGQZqXWPWiTtNt6hT4nM3ohg0j5Xn0hEvako Yl8H51iuGPsPNel7U4yltZq1yrDQHE7JXu8InIa73Y7ZHa5AlxkN1NHZgQk+03vYT1w+ OxpQ1oRPWzABCW3olfBvRcQIAyHveAg06nDYZImlKE4/iwqmttN3cbbRvHe5bZ1jmMuY V3cwdZ5n1ObiVM8nJG8DzdWoMm9l9nFoZwGa6T4aRc1kdX88TGb3oamyvVgJAFEkZnyK ZRLQ== X-Gm-Message-State: AGRZ1gLdLmXoY20Su/Aq4jMKqEfoY4k8q6coWpLA7oMjL95iiVk3+x3a +FfuvkMs24uVj2Qp59pfq/zpZQ== X-Google-Smtp-Source: AJdET5fXXRMTV2rxtx6LqovOuxmBEtcaBgfp2hb/WInfQo9ZO27goApTCJStjs+7uW0aOxkb+d5pCw== X-Received: by 2002:a1c:950a:: with SMTP id x10-v6mr6437871wmd.43.1540803723802; Mon, 29 Oct 2018 02:02:03 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:7440:4ef3:2d17:e7d9? ([2001:660:330f:a4:7440:4ef3:2d17:e7d9]) by smtp.gmail.com with ESMTPSA id c8-v6sm31032901wrb.6.2018.10.29.02.02.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 02:02:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Luigi Iannone In-Reply-To: <967F942A-6E00-481F-A5DC-2A5F0C38F3E2@gmail.com> Date: Mon, 29 Oct 2018 10:02:07 +0100 Cc: "Joel M. Halpern" , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7DB00E16-230A-493D-B09D-CF7C563742AC@gigix.net> References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E02E717@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <6d753e78-bc13-7645-ccc3-e5c784318779@joelhalpern.com> <967F942A-6E00-481F-A5DC-2A5F0C38F3E2@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 09:02:08 -0000 > On 25 Oct 2018, at 18:01, Dino Farinacci wrote: >=20 > Do you think what I added will be objected to? May be. IMO The point is: If you do not doing it now and someone complains you will slow down = publication by weeks. If you do it now you will spend 5 minutes and everybody will be happy. Your call. Ciao L. >=20 > Dino >=20 >> On Oct 25, 2018, at 8:57 AM, Joel M. Halpern = wrote: >>=20 >> Is it a big deal? No. >> Is it likely someone will ask for it during IESG review? Moderate. >> Would I just do it in your shoes? Yes. >> Do you have to do it? No. >>=20 >> Yours, >> Joel >>=20 >> On 10/25/18 11:48 AM, Dino Farinacci wrote: >>> I don=E2=80=99t think there should be anything controversial with = the changes I made. Can we move onto more pressing issues? >>> Dino >>>> On Oct 25, 2018, at 8:09 AM, Joel M. Halpern = wrote: >>>>=20 >>>> Actually, given the existence of RFC 8126, varying from that = recommendation for the distinction between Reserved and Unassigned (by = which, what we mean is Unassigned) should only be done with very good = reason. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 10/25/18 11:04 AM, Dino Farinacci wrote: >>>>> It doesn=E2=80=99t *have to be* what 8126 is. It needs to be what = we believe the the unassigned bits are labeled. >>>>> Dino >>>>>> On Oct 24, 2018, at 10:02 PM, = wrote: >>>>>>=20 >>>>>> Hi Dino, >>>>>> Thank you. >>>>>> I=E2=80=99m afraid that =C2=AB reserved and unassigned =C2=BB is = still not appropriate (see 8126). Please change it with =E2=80=9Cunassigne= d and available for future use=E2=80=9D. >>>>>> Cheers, >>>>>> Med >>>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>>> Envoy=C3=A9 : jeudi 25 octobre 2018 05:05 >>>>>> =C3=80 : BOUCADAIR Mohamed TGI/OLN >>>>>> Cc : Luigi Iannone; lisp@ietf.org >>>>>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: = Reserved/Unassigned >>>>>> How about these changes? So we can not over complicate this. >>>>>>=20 >>>>>> Dino >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On Oct 24, 2018, at 2:24 AM, = wrote: >>>>>>>=20 >>>>>>> Hi Luigi, >>>>>>>=20 >>>>>>> Fully agree that changing the text and updating the figures = would be appropriate. >>>>>>>=20 >>>>>>> Please note that a similar action is needed for = draft-ietf-lisp-rfc6830bis-24, e.g., >>>>>>>=20 >>>>>>> R: The R-bit is a Reserved bit for future use. It MUST be set = to 0 >>>>>>> on transmit and MUST be ignored on receipt. >>>>>>>=20 >>>>>>> Cheers, >>>>>>> Med >>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : Luigi Iannone [mailto:ggx@gigix.net] >>>>>>>> Envoy=C3=A9 : mercredi 24 octobre 2018 10:01 >>>>>>>> =C3=80 : Dino Farinacci >>>>>>>> Cc : BOUCADAIR Mohamed TGI/OLN; lisp@ietf.org >>>>>>>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: = Reserved/Unassigned >>>>>>>>=20 >>>>>>>> Hi All, >>>>>>>>=20 >>>>>>>> disclaimer: this is my personal point of view. >>>>>>>>=20 >>>>>>>> I didn=E2=80=99t catch before this part of RFC 8126. Thanks Med = from bringing it up. >>>>>>>>=20 >>>>>>>> While I understand Dino=E2=80=99s reply, because I my self as = well always thought >>>>>>>> =E2=80=9Creserved =3D can be used in the future=E2=80=9D, I = think that Med is right. >>>>>>>>=20 >>>>>>>> To be compliant with RFC 8126, and because we may need those = =E2=80=9Creserved=E2=80=9D bits >>>>>>>> in the future, we better mark them as =E2=80=9Cunassigned=E2=80=9D= . >>>>>>>> This means changing the text and clearly spell out that this is = conform to >>>>>>>> RFC 8126 definitions. >>>>>>>>=20 >>>>>>>> At the end, it is as simple as adding the following sentence in = section 2 >>>>>>>> =E2=80=9CRequirements Notation=E2=80=9D: >>>>>>>>=20 >>>>>>>> The =E2=80=9CUnassigned=E2=80=9D and =E2=80=9CReserved=E2=80= =9D terminology for bits and fields of >>>>>>>> messages and headers defined in this documents is the = Well-Known >>>>>>>> Registration Status Terminology defined in Section 6 of = [RFC8126]. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Then we just replace =E2=80=9Creserved=E2=80=9D with = =E2=80=9Cunassigned=E2=80=9D throughout the document. >>>>>>>>=20 >>>>>>>> Ciao >>>>>>>>=20 >>>>>>>> L. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On 23 Oct 2018, at 18:27, Dino Farinacci = wrote: >>>>>>>>>=20 >>>>>>>>> I am not sure if we should make this distinction. What does = the WG think? >>>>>>>> Because fields marked =E2=80=9Creserved=E2=80=9D are obviously = unassigned and don=E2=80=99t know if >>>>>>>> they will be assigned in the future. >>>>>>>>>=20 >>>>>>>>> So I am not sure how helpful in making the distinction. >>>>>>>>>=20 >>>>>>>>> Dino >>>>>>>>>=20 >>>>>>>>>> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com = wrote: >>>>>>>>>>=20 >>>>>>>>>> Hi Dino, all, >>>>>>>>>>=20 >>>>>>>>>> Apologies for raising this late easy to fix comment: >>>>>>>>>>=20 >>>>>>>>>> RFC8126 says the following: >>>>>>>>>>=20 >>>>>>>>>> Unassigned: Not currently assigned, and available for = assignment >>>>>>>>>> = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>>>> via documented procedures. While it's generally = clear that >>>>>>>>>> any values that are not registered are unassigned = and >>>>>>>>>> available for assignment, it is sometimes useful to >>>>>>>>>> explicitly specify that situation. Note that this = is >>>>>>>>>> distinctly different from "Reserved". >>>>>>>>>>=20 >>>>>>>>>> Reserved: Not assigned and not available for assignment. >>>>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>>>> Reserved values are held for special uses, such as = to extend >>>>>>>>>> the namespace when it becomes exhausted. "Reserved" = is also >>>>>>>>>> sometimes used to designate values that had been = assigned >>>>>>>>>> but are no longer in use, keeping them set aside as = long as >>>>>>>>>> other unassigned values are available. Note that = this is >>>>>>>>>> distinctly different from "Unassigned". >>>>>>>>>>=20 >>>>>>>>>> This is well handled in Section 5.1, but not in other = sections which are >>>>>>>> using Reserved instead of Unassigned as per RFC8126. >>>>>>>>>>=20 >>>>>>>>>> It would be appropriate to update the text accordingly. Thank = you. >>>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>> Med >>>>>>>>>> _______________________________________________ >>>>>>>>>> lisp mailing list >>>>>>>>>> lisp@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> lisp mailing list >>>>>>>>> lisp@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Oct 29 08:33:03 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEAA130FB1 for ; Mon, 29 Oct 2018 08:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 OJ_LXVNr5tmY for ; Mon, 29 Oct 2018 08:32:59 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 4D3B3130DF9 for ; Mon, 29 Oct 2018 08:32:59 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id a15-v6so4219571pfn.0 for ; Mon, 29 Oct 2018 08:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KNZk5PmtTFjJTZiAbmZe7U8hZo4Vh2g1hKU1eaMKBtw=; b=Olr7U2OT5UJkVMGn3LZYJqQL9aDwskJhHMAzdMyzak61GNYEGTaiLM0npoNBSLWL/F dZqGVencCzi7xOZAVQX0ez05TBAx/eeYZSMRkqekgnTGjaDGJPoNYfcDBX9HyjJ0KklC Cg3S5yVJGassWJIZ4yoUhMR0vZMzN0k05nKNCw6Ops0mrg7CZPwsbR2Ll0rTQd9dCrLL mbJd37ofufddb7oHXouY8y9T1j197hWh+MtHc3+QEnwL2G5LTBQV4cujIVxE2bX9qBHl kAllmetixU8WftkmFTolZkPBkaQ4ghpoG8VZmZCa/T/7ufJvff/+qpHMPG+zaBdgCaOq LIvg== 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=KNZk5PmtTFjJTZiAbmZe7U8hZo4Vh2g1hKU1eaMKBtw=; b=MMiSpRXgCqYMCPGYcoeyxdB8xosKUN+RL+ZaWv2OnpmPknp0sJzEwH+NB8DAwMmiUN E0P57GRWIIj7+ErwqSS1KycCdyGJkcrw3EZbS7EbwxKpHtSzoFhNOhxuZ3j/bdwO/Vmq FcZs+yDJoWdGq5HSF0Rl/+NZpNprGC3EZIzxyorOCsZG+t8rFa8GnJc2LW5e1f/+XziF 3x12rgx3VEDXHb9nmlscz0jADk1C+fyErssgWrAfORMka6d1pmzljNoo3VQo6bwaQWGB FJSgDDKBpXGcpOz5jRH1Bn7RxE991Vc0ZmdG6gtxjLgKhzlXkRJR94DEac3kmceBN6hB hITw== X-Gm-Message-State: AGRZ1gLrormwf6oGYYhEAtTtoQebE/IZkKGOjc75gNiyMgSal9ArIau+ OmE8CNaZrwqzrRFdzaKIz2omfLGo X-Google-Smtp-Source: AJdET5fsUNH+5CGxkkrNB5LD2pURnCzqEe4LSKiNsBCQePIH2vDLtiG4mcAzy22uxjoaVgam1lRa7g== X-Received: by 2002:a63:4b60:: with SMTP id k32mr14278036pgl.186.1540827178606; Mon, 29 Oct 2018 08:32:58 -0700 (PDT) Received: from [192.168.8.224] ([12.188.91.2]) by smtp.gmail.com with ESMTPSA id r81-v6sm50256427pfa.110.2018.10.29.08.32.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 08:32:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <7DB00E16-230A-493D-B09D-CF7C563742AC@gigix.net> Date: Mon, 29 Oct 2018 08:32:55 -0700 Cc: "Joel M. Halpern" , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <27CFAE62-4D4D-4F8F-93BF-460EDF844BE4@gmail.com> References: <787AE7BB302AE849A7480A190F8B93302E019A18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <248E66A4-71C5-4A94-989E-76650EB75061@gigix.net> <787AE7BB302AE849A7480A190F8B93302E029E07@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E02E717@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <6d753e78-bc13-7645-ccc3-e5c784318779@joelhalpern.com> <967F942A-6E00-481F-A5DC-2A5F0C38F3E2@gmail.com> <7DB00E16-230A-493D-B09D-CF7C563742AC@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 15:33:02 -0000 Changing it to what? Be specific commenters. Dino > On Oct 29, 2018, at 2:02 AM, Luigi Iannone wrote: >=20 >=20 >=20 >> On 25 Oct 2018, at 18:01, Dino Farinacci wrote: >>=20 >> Do you think what I added will be objected to? >=20 > May be. >=20 > IMO The point is: >=20 > If you do not doing it now and someone complains you will slow down = publication by weeks. >=20 > If you do it now you will spend 5 minutes and everybody will be happy. >=20 > Your call. >=20 > Ciao >=20 > L. >=20 >=20 >>=20 >> Dino >>=20 >>> On Oct 25, 2018, at 8:57 AM, Joel M. Halpern = wrote: >>>=20 >>> Is it a big deal? No. >>> Is it likely someone will ask for it during IESG review? Moderate. >>> Would I just do it in your shoes? Yes. >>> Do you have to do it? No. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 10/25/18 11:48 AM, Dino Farinacci wrote: >>>> I don=E2=80=99t think there should be anything controversial with = the changes I made. Can we move onto more pressing issues? >>>> Dino >>>>> On Oct 25, 2018, at 8:09 AM, Joel M. Halpern = wrote: >>>>>=20 >>>>> Actually, given the existence of RFC 8126, varying from that = recommendation for the distinction between Reserved and Unassigned (by = which, what we mean is Unassigned) should only be done with very good = reason. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 10/25/18 11:04 AM, Dino Farinacci wrote: >>>>>> It doesn=E2=80=99t *have to be* what 8126 is. It needs to be what = we believe the the unassigned bits are labeled. >>>>>> Dino >>>>>>> On Oct 24, 2018, at 10:02 PM, = wrote: >>>>>>>=20 >>>>>>> Hi Dino, >>>>>>> Thank you. >>>>>>> I=E2=80=99m afraid that =C2=AB reserved and unassigned =C2=BB is = still not appropriate (see 8126). Please change it with =E2=80=9Cunassigne= d and available for future use=E2=80=9D. >>>>>>> Cheers, >>>>>>> Med >>>>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>> Envoy=C3=A9 : jeudi 25 octobre 2018 05:05 >>>>>>> =C3=80 : BOUCADAIR Mohamed TGI/OLN >>>>>>> Cc : Luigi Iannone; lisp@ietf.org >>>>>>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: = Reserved/Unassigned >>>>>>> How about these changes? So we can not over complicate this. >>>>>>>=20 >>>>>>> Dino >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Oct 24, 2018, at 2:24 AM, = wrote: >>>>>>>>=20 >>>>>>>> Hi Luigi, >>>>>>>>=20 >>>>>>>> Fully agree that changing the text and updating the figures = would be appropriate. >>>>>>>>=20 >>>>>>>> Please note that a similar action is needed for = draft-ietf-lisp-rfc6830bis-24, e.g., >>>>>>>>=20 >>>>>>>> R: The R-bit is a Reserved bit for future use. It MUST be set = to 0 >>>>>>>> on transmit and MUST be ignored on receipt. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>>=20 >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : Luigi Iannone [mailto:ggx@gigix.net] >>>>>>>>> Envoy=C3=A9 : mercredi 24 octobre 2018 10:01 >>>>>>>>> =C3=80 : Dino Farinacci >>>>>>>>> Cc : BOUCADAIR Mohamed TGI/OLN; lisp@ietf.org >>>>>>>>> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: = Reserved/Unassigned >>>>>>>>>=20 >>>>>>>>> Hi All, >>>>>>>>>=20 >>>>>>>>> disclaimer: this is my personal point of view. >>>>>>>>>=20 >>>>>>>>> I didn=E2=80=99t catch before this part of RFC 8126. Thanks = Med from bringing it up. >>>>>>>>>=20 >>>>>>>>> While I understand Dino=E2=80=99s reply, because I my self as = well always thought >>>>>>>>> =E2=80=9Creserved =3D can be used in the future=E2=80=9D, I = think that Med is right. >>>>>>>>>=20 >>>>>>>>> To be compliant with RFC 8126, and because we may need those = =E2=80=9Creserved=E2=80=9D bits >>>>>>>>> in the future, we better mark them as =E2=80=9Cunassigned=E2=80=9D= . >>>>>>>>> This means changing the text and clearly spell out that this = is conform to >>>>>>>>> RFC 8126 definitions. >>>>>>>>>=20 >>>>>>>>> At the end, it is as simple as adding the following sentence = in section 2 >>>>>>>>> =E2=80=9CRequirements Notation=E2=80=9D: >>>>>>>>>=20 >>>>>>>>> The =E2=80=9CUnassigned=E2=80=9D and =E2=80=9CReserved=E2=80= =9D terminology for bits and fields of >>>>>>>>> messages and headers defined in this documents is the = Well-Known >>>>>>>>> Registration Status Terminology defined in Section 6 of = [RFC8126]. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Then we just replace =E2=80=9Creserved=E2=80=9D with = =E2=80=9Cunassigned=E2=80=9D throughout the document. >>>>>>>>>=20 >>>>>>>>> Ciao >>>>>>>>>=20 >>>>>>>>> L. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 23 Oct 2018, at 18:27, Dino Farinacci = wrote: >>>>>>>>>>=20 >>>>>>>>>> I am not sure if we should make this distinction. What does = the WG think? >>>>>>>>> Because fields marked =E2=80=9Creserved=E2=80=9D are obviously = unassigned and don=E2=80=99t know if >>>>>>>>> they will be assigned in the future. >>>>>>>>>>=20 >>>>>>>>>> So I am not sure how helpful in making the distinction. >>>>>>>>>>=20 >>>>>>>>>> Dino >>>>>>>>>>=20 >>>>>>>>>>> On Oct 23, 2018, at 12:44 AM, mohamed.boucadair@orange.com = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi Dino, all, >>>>>>>>>>>=20 >>>>>>>>>>> Apologies for raising this late easy to fix comment: >>>>>>>>>>>=20 >>>>>>>>>>> RFC8126 says the following: >>>>>>>>>>>=20 >>>>>>>>>>> Unassigned: Not currently assigned, and available for = assignment >>>>>>>>>>> = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>>>>> via documented procedures. While it's generally = clear that >>>>>>>>>>> any values that are not registered are unassigned = and >>>>>>>>>>> available for assignment, it is sometimes useful to >>>>>>>>>>> explicitly specify that situation. Note that this = is >>>>>>>>>>> distinctly different from "Reserved". >>>>>>>>>>>=20 >>>>>>>>>>> Reserved: Not assigned and not available for assignment. >>>>>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>>>>> Reserved values are held for special uses, such as = to extend >>>>>>>>>>> the namespace when it becomes exhausted. "Reserved" = is also >>>>>>>>>>> sometimes used to designate values that had been = assigned >>>>>>>>>>> but are no longer in use, keeping them set aside as = long as >>>>>>>>>>> other unassigned values are available. Note that = this is >>>>>>>>>>> distinctly different from "Unassigned". >>>>>>>>>>>=20 >>>>>>>>>>> This is well handled in Section 5.1, but not in other = sections which are >>>>>>>>> using Reserved instead of Unassigned as per RFC8126. >>>>>>>>>>>=20 >>>>>>>>>>> It would be appropriate to update the text accordingly. = Thank you. >>>>>>>>>>>=20 >>>>>>>>>>> Cheers, >>>>>>>>>>> Med >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> lisp mailing list >>>>>>>>>>> lisp@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> lisp mailing list >>>>>>>>>> lisp@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>>=20 >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From nobody Tue Oct 30 01:22: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 402E2130DDC for ; Tue, 30 Oct 2018 01:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 uhreF7KNSF9U for ; Tue, 30 Oct 2018 01:22:13 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D8E130DCF for ; Tue, 30 Oct 2018 01:22:13 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id d17-v6so11203627wre.11 for ; Tue, 30 Oct 2018 01:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=XWy4e5lGtxFj+Nm5Ve4Zj6FGL4Apg+l6WbTEOtjjthQ=; b=LmKhhHfdzqSVQAswNLXJbjnWMyEi092D8uaV34H5jetgpTjd6a9p/5z/74Fz1Oqzhu bZxmeZnUbX3VPP2/+KbegBE4ExPNX9Z4W8Gv8TYqdv1h5fiZruPG6xEMBvmhSXnRs57I TZE32/iZ0f6uvVvl5dWH4lzMV87HmIXFzWmFKwIl91JkmrxCvNQCoMpVyQQUdfKAXqf+ 4gLge9Fq3IHMPesnKk7/NGjwHUgRYxUG+QTKcMDsxcPhxywjh77Mf3yozAAlurSlmMpj g7DFnZ1/BwEKxJtG3F7G3EDhmhQGmLwJ0yvEBcmBzERbEQ9e6wV9WobtSADM+f6CWXCE 4h3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=XWy4e5lGtxFj+Nm5Ve4Zj6FGL4Apg+l6WbTEOtjjthQ=; b=VureVuA0ie3Wy0MIbbyJAHvp8yq8YLaJEB8CYRoXXM9pQ+2F0AyGRd+J0N2K+Wrh57 g5PYAL7fxiQ7vkE+yxD5B3GoGHkkSei9Gia1M8pdiITO9QJ9SzbscWBlGhyidoBPiova foL6041+cgAawcNViY4odiG4yqWHhpZ9j4LyrTryHTw2822eutWJEN/7DHq14ROw3KlN M3rJmWt1jUg7AREUTqiTeUCbbAKXs+fpmXiMwNBHaNfpimTqi7zpt0m2BjWYbwFvP1Av nYm3e1TGxPzQjEKAck+I1Ri4rAfn8+KjOQBkjvhqJ7F3ZVEWRrE/es22AKwj3z8IhpU7 oYtA== X-Gm-Message-State: AGRZ1gL1j6rT216WxY1pq1Ru1rDyb0TlCidrhNSYCOM6mvKNpNk/fzxx aHmrQWtzTiO7vOa0JA15s9nhU174bIbYTg== X-Google-Smtp-Source: AJdET5fr50rvPMsC1jM7fSCPf3qA4RguK0ygWmv3aAtt1PjlYC8gYI3nIy4bUNTkLYqkZUCpOb0b6A== X-Received: by 2002:adf:f1cd:: with SMTP id z13-v6mr10802626wro.79.1540887731203; Tue, 30 Oct 2018 01:22:11 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:838:eb26:ac10:bd36? ([2001:660:330f:a4:838:eb26:ac10:bd36]) by smtp.gmail.com with ESMTPSA id i7-v6sm43631716wrb.30.2018.10.30.01.22.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Oct 2018 01:22:09 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_9E2001DB-B8E7-4425-BAE2-D3A2CF6E8C14" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 30 Oct 2018 09:22:08 +0100 References: <153877793727.1026.1146854495726676148.idtracker@ietfa.amsl.com> <1B08CE0F-6AA0-49C1-8A36-F562844F83DD@gigix.net> <63BE166E-8166-478D-828E-087511AD4D4C@gigix.net> To: "lisp@ietf.org list" In-Reply-To: <63BE166E-8166-478D-828E-087511AD4D4C@gigix.net> Message-Id: X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] [Call for Agenda Items] IETF 103 Preliminary Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 08:22:25 -0000 --Apple-Mail=_9E2001DB-B8E7-4425-BAE2-D3A2CF6E8C14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, hereafter your can find the final agenda (please let me know if you spot = any error). For the presenters: PLEASE SEND SLIDES SATURDAY NIGHT AT LATEST. Our meeting is Monday morning and we need time to upload the slides to = the material page. Ciao L. Session 1/1 (120 Minutes) =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Monday, November 5, 2018 9:00 - 11:00, Morning Session I, 120 Minutes Room: Boromphimarn 3 - Administration Halpern/Iannone - Blue Sheets - Agenda Bashing - Status reports for WG drafts 5 Minutes (Cumulative Time: 5 Minutes) o WG Items - LISP YANG Model - draft-ietf-lisp-yang-09 10 Minutes (Cumulative Time: 15 Minutes) Reshad Rahman - Update on 6830bis/6833bis documents 20 Minutes (Cumulative Time: 35 Minutes) Albert Cabellos - LISP EID Anonimity - draft-ietf-lisp-eid-anonymity-04 10 Minutes (Cumulative Time: 45 Minutes) Dino Farinacci - LISP Control Plane ECDSA Authentication and Authorization - = draft-ietf-lisp-ecdsa-auth-00 10 Minutes (Cumulative Time: 55 Minutes) Dino Farinacci - Publish/Subscribe Functionality for LISP - draft-ietf-lisp-pubsub-01 10 Minutes (Cumulative Time: 65 Minutes) Alberto Rodriguez Natal o Non WG Items - Automotive Network 15 Minutes (Cumulative Time: 80 Minutes) Sharon Barkai - Overflow Time/ Discussion 30 Minutes (Cumulative Time: 120 Minutes) > On 24 Oct 2018, at 13:16, Luigi Iannone wrote: >=20 > Hi All, >=20 > hereafter the current LISP WG Preliminary Agenda. >=20 > As you can see we still have more than a hour that is unallocated. >=20 > Please, if you have anything you want to share with the WG drop an = email to there chairs. >=20 > Ciao >=20 > L. >=20 > CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com = ) > Luigi Iannone ( ggx AT gigix.net ) >=20 > SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com = ) > Padma Pillay-Esnault ( padma.ietf AT gmail.com = ) >=20 >=20 > AGENDA >=20 > Session 1/1 (120 Minutes) > =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=20 > Monday, November 5, 2018 > 9:00 - 11:00, Morning Session I, 120 Minutes > Room: Boromphimarn 3 >=20 > - Administration > Halpern/Iannone > - Blue Sheets > - Agenda Bashing > - Status reports for WG drafts > 5 Minutes (Cumulative Time: 5 Minutes) >=20 >=20 >=20 > o WG Items >=20 > - LISP YANG Model - draft-ietf-lisp-yang-08.txt > 10 Minutes (Cumulative Time: 15 Minutes) > Reshad Rahman >=20 > - Update on 6830bis/6833bis documents > 20 Minutes (Cumulative Time: 35 Minutes) >=20 > - LISP EID Anonimity - draft-ietf-lisp-eid-anonymity-04 > 10 Minutes (Cumulative Time: 45 Minutes) >=20 >=20 >=20 >=20 > o Non WG Items >=20 > - Overflow Time/ Discussion > 75 Minutes (Cumulative Time: 120 Minutes) >=20 >=20 >=20 >=20 >=20 >> On 7 Oct 2018, at 23:58, Luigi Iannone > wrote: >>=20 >> Folks, >>=20 >> The preliminary agenda has been published. >> We will meet Monday Morning 5 November. >>=20 >> While the agenda is still subject to changes it is time to think = about presentation slots. >>=20 >> Please send your requests for agenda items (Presenter=E2=80=99s name, = title, slot duration)=20 >> to lisp-chairs@tools.ietf.org >>=20 >> Ciao >>=20 >> L. >>=20 >>> Begin forwarded message: >>>=20 >>> From: IETF Agenda > >>> Subject: [Recentattendees] IETF 103 Preliminary Agenda >>> Date: 6 October 2018 at 00:18:57 CEST >>> To: "IETF Announcement List" > >>> Cc: recentattendees@ietf.org , = ietf@ietf.org , 103all@ietf.org = >>> Reply-To: agenda@ietf.org >>>=20 >>> IETF 103 >>> Bangkok, Thailand >>> November 3-9, 2018 >>> Hosts: Huawei and Cisco >>>=20 >>> The IETF 103 Preliminary Agenda has been posted. The final agenda = will be published on Friday, October 12, 2018.=20 >>>=20 >>> https://datatracker.ietf.org/meeting/103/agenda.html = >>> https://datatracker.ietf.org/meeting/103/agenda.txt = >>>=20 >>>=20 >>> IETF 103 Information: https://www.ietf.org/how/meetings/103/ >>> Register online at: https://www.ietf.org/how/meetings/register/ >>>=20 >>> Don=E2=80=99t forget to register for these exciting IETF 103 events! >>>=20 >>> Hackathon=20 >>> Signup: = https://www.ietf.org/registration/ietf103/hackathonregistration.py >>> More information: = https://www.ietf.org/how/runningcode/hackathons/103-hackathon/ >>> Keep up to date by subscribing to:=20 >>> https://www.ietf.org/mailman/listinfo/hackathon >>>=20 >>> Code Sprint >>> Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103SprintSignUp >>> More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103Sprint >>>=20 >>> _______________________________________________ >>> Recentattendees mailing list >>> Recentattendees@ietf.org >>> https://www.ietf.org/mailman/listinfo/recentattendees >>=20 >=20 --Apple-Mail=_9E2001DB-B8E7-4425-BAE2-D3A2CF6E8C14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = All,

hereafter your = can find the final agenda (please let me know if you spot any = error).

For = the presenters: PLEASE SEND SLIDES SATURDAY NIGHT AT LATEST.

Our meeting is Monday = morning and we need time to upload the slides to the material = page.

Ciao

L.



Session 1/1 (120 Minutes)
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

Monday, November 5, 2018
9:00 - 11:00, Morning Session I, 120 Minutes
Room: Boromphimarn 3

- Administration
    Halpern/Iannone
  =   - Blue Sheets
    - Agenda = Bashing
    - Status reports for WG = drafts
5 Minutes = (Cumulative Time: 5 Minutes)



o WG Items

- LISP YANG Model - = draft-ietf-lisp-yang-09
  10 Minutes = (Cumulative Time: 15 Minutes)
  Reshad = Rahman

- = Update on 6830bis/6833bis documents
  20 = Minutes (Cumulative Time: 35 Minutes)
  Albert = Cabellos

- = LISP EID Anonimity - draft-ietf-lisp-eid-anonymity-04
  10 Minutes (Cumulative Time: 45 Minutes)
  Dino Farinacci

- LISP Control Plane ECDSA = Authentication and Authorization - = draft-ietf-lisp-ecdsa-auth-00
  10 Minutes = (Cumulative Time: 55 Minutes)
  Dino = Farinacci

- = Publish/Subscribe Functionality for LISP - = draft-ietf-lisp-pubsub-01
  10 Minutes = (Cumulative Time: 65 Minutes)
  Alberto = Rodriguez Natal

o Non WG Items

- Automotive Network
  15 Minutes = (Cumulative Time: 80 Minutes)
  Sharon = Barkai


- Overflow Time/ Discussion
  30 Minutes (Cumulative Time: 120 Minutes)


On 24 Oct 2018, at 13:16, Luigi = Iannone <ggx@gigix.net> wrote:

Hi All,

hereafter the current = LISP WG Preliminary Agenda.

As you can see we still have more than a hour that is = unallocated.

Please, if you have anything you want to share with the WG = drop an email to there chairs.

Ciao

L.

CHAIR(s):  Joel Halpern ( jmh AT joelhalpern.com )
                Luigi Iannone ( ggx AT gigix.net )

SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com )
           	   Padma Pillay-Esnault ( padma.ietf AT gmail.com )


AGENDA

Session 1/1 (120 Minutes)
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

Monday, November 5, 2018
9:00 - 11:00, Morning Session I, 120 Minutes
Room: Boromphimarn 3

- Administration
    Halpern/Iannone
    - Blue Sheets
    - Agenda Bashing
    - Status reports for WG drafts
	5 Minutes 	(Cumulative Time: 5 Minutes)



o WG Items

- LISP YANG Model - draft-ietf-lisp-yang-08.txt
  10 Minutes (Cumulative Time: 15 Minutes)
  Reshad Rahman

- Update on 6830bis/6833bis documents
  20 Minutes (Cumulative Time: 35 Minutes)

- LISP EID Anonimity - draft-ietf-lisp-eid-anonymity-04
  10 Minutes (Cumulative Time: 45 Minutes)




o Non WG Items

- Overflow Time/ Discussion
  75 Minutes (Cumulative Time: 120 Minutes)





On 7 Oct 2018, at 23:58, Luigi Iannone <ggx@gigix.net> = wrote:

Folks,

The preliminary agenda = has been published.
We will meet Monday Morning 5 = November.

While = the agenda is still subject to changes it is time to think about = presentation slots.

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

Ciao

L.

Begin = forwarded message:

From: IETF Agenda <agenda@ietf.org>
Subject: [Recentattendees] IETF 103 Preliminary Agenda
Date: 6 October 2018 at 00:18:57 CEST
To: "IETF Announcement List" <ietf-announce@ietf.org>
Cc: recentattendees@ietf.org, ietf@ietf.org, 103all@ietf.org
Reply-To: agenda@ietf.org

IETF 103
Bangkok, Thailand
November= 3-9, 2018
Hosts: Huawei and Cisco

The IETF 103 Preliminary Agenda has been posted. The final = agenda will be published on Friday, October 12, 2018.

https://datatracker.ietf.org/meeting/103/agenda.html
https://datatracker.ietf.org/meeting/103/agenda.txt


IETF 103 Information: https://www.ietf.org/how/meetings/103/
Register online at: https://www.ietf.org/how/meetings/register/

Don=E2=80=99t forget to register for these = exciting IETF 103 events!

Hackathon
= Signup: https://www.ietf.org/registration/ietf103/hackathonregistration= .py
More information: https://www.ietf.org/how/runningcode/hackathons/103-hackathon/<= /a>
Keep up to date by subscribing = to:
https://www.ietf.org/mailman/listinfo/hackathon

Code Sprint
Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103SprintSignUp
= More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103Sprint

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



= --Apple-Mail=_9E2001DB-B8E7-4425-BAE2-D3A2CF6E8C14-- From nobody Tue Oct 30 07:26: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 1C61112D4EA for ; Tue, 30 Oct 2018 07:26:53 -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 QzlRkc8q3ctO for ; Tue, 30 Oct 2018 07:26:51 -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 CF44A12D4EC for ; Tue, 30 Oct 2018 07:26:51 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id t6-v6so5618931plo.9 for ; Tue, 30 Oct 2018 07:26:51 -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=azQLixxSh+kWWJGh101H86XDIh3bmFcnsajzCUYQd/8=; b=qdW0aPxKq+jAu7h7ZbajMQfMulunWZf5+R25zkpIXx3PGRH2GyE+Wd6FyZPoYBOiU3 LTgujV+8lTUQRQkmd7v10CINtKrY3Imeh8eefCaGuGAgf4w0WXv3ZP9NtrD4ox2c7RGx BMVJhxbKkbMzhWAVTQX0J6wHSv8EeMhMTtDlZaJV1KQalyWJIfQaYgPJUKWch6Urp/24 JlhiJR9cs75b1D63RbbusBUQ5kblGWshoART31ZqrO7CG07sPtl8ip6rLiqXKsYAkitr ISwh/Gn8aOEuQJdOUrAfvn2YfjheoNmZ2QV7BrtmUM0O/aMwi1t+M6btns2TziFlUuGX G3HQ== 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=azQLixxSh+kWWJGh101H86XDIh3bmFcnsajzCUYQd/8=; b=QgE+Rcyjbf5vzz8zn7xeAycNDUTJq3g1TCjEF6fkZrqTBV4vN/BbQl5hwiZuYYbXrI kE2Z0lnHi00U72gv1rvjpdUmhJFlm7VYO7DCFbboh6VgrK69/+B2oT4gMd/RlRJ0nJI8 BDeyvEvzr0vLyzPCEgU8xl0Cx6+wEgFuTmpcsNj5BaCw6qaxmIULNY2chniWtensf+yZ 4Q738RZyjLnNAU9BRJbpPNSEhsHAiYKwzSI9Be7XpMutYxDujFhzlXQwIF9Gqp7oMolc M8CzHW3j4+0IW8ilRNVOyiy4xV7EfxeQSHgqdM1Px8ssdLz+leNyBnHMGDUjMKGYLut4 YEYg== X-Gm-Message-State: AGRZ1gL62gC7OqmB2SW5gsvy7AUwkSDvo7JpYIaY+XGG16ea44gI87r0 LHSwQQ45L3VD8HGGfc5e1QFWrkL0 X-Google-Smtp-Source: AJdET5eKxtFoRDdxCfpB1weR2epxWyMMLDO68FpKwiCaVmcek5hVF014WuzCoeSlZj664lRYtvzR+w== X-Received: by 2002:a17:902:860a:: with SMTP id f10-v6mr1153873plo.96.1540909611391; Tue, 30 Oct 2018 07:26:51 -0700 (PDT) Received: from [10.31.79.60] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id 23-v6sm7633262pgp.77.2018.10.30.07.26.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Oct 2018 07:26:50 -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, 30 Oct 2018 07:26:49 -0700 Cc: "lisp@ietf.org list" Content-Transfer-Encoding: 7bit Message-Id: <18DC3EB5-0BB7-4B20-9B73-01702C21E69E@gmail.com> References: <153877793727.1026.1146854495726676148.idtracker@ietfa.amsl.com> <1B08CE0F-6AA0-49C1-8A36-F562844F83DD@gigix.net> <63BE166E-8166-478D-828E-087511AD4D4C@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] [Call for Agenda Items] IETF 103 Preliminary Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 14:26:53 -0000 > - LISP EID Anonimity - draft-ietf-lisp-eid-anonymity-04 > 10 Minutes (Cumulative Time: 45 Minutes) > Dino Farinacci Padma is doing this presentation. Dino From nobody Tue Oct 30 07:31:00 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7A5129C6A for ; Tue, 30 Oct 2018 07:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 lFOBgcRrZVIh for ; Tue, 30 Oct 2018 07:30:56 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 1CB711293FB for ; Tue, 30 Oct 2018 07:30:56 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id r63-v6so12011668wma.4 for ; Tue, 30 Oct 2018 07:30:55 -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=orXz3WQeYFTUIPGRU7wNLevv9lny1l8NuGeZ76XBEpQ=; b=HIv2hWYEHTyJBdcZFnqkGzA7dZEEXQlW6X4ykFeA4Woj5lc3t7ten/sxUROPnAITqV nL91uoisSy9FI2xy7ddrZU7CPapxYvP/5Mgi1aBKg4YWpMX1XZfFYCOsclZXw6lp+yM8 SUv2yU5MfogJ2F4sA+Cw85d7kUg+/is9gdNiBl2hefYkdvQT6iN/h/eRTl1QDriYwBMo 501T0N7vAzGTkOcg8AaGQ1Yvbetps32HlckcGltnxYKPK454K72X7uiZezQ4ORPhQ8w7 I9jrSMvn85IJ8c2Fx9Fe+J3o+zp0u0NLFZfUjYPUbt9NUBN7b4i+06X8gxfnXcwRHPP+ Gcxg== 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=orXz3WQeYFTUIPGRU7wNLevv9lny1l8NuGeZ76XBEpQ=; b=PU8huM7+kszT+8+v7fU2hxu+VZy6LE5Kxqg0SIwuJT54EI2IxVle2yT6bL1vvvcOft hvEETfpxqy7NCcQ4GGMAHq/l+5b3sQESfMgWotDUOrOcSRuyanuNpV2uAPI08B9EjeGr 6QH1xA16xd/HHHrzE2iSFBJrANeBS3HJPeOOxdZv4EoS8VOKomyai42oDt5cBEqyjn3v 1NvhwqeqAvSGr1e+ajmQet41f22S8ArO78Jjz+Owc66hhZ1onsErsvc7mn9UeSAwXRDM EmalRFZStFUogBR0CkUMg9Sa+ztXeEJSutonJ+1qTgDjEIRs3tyW6/hGNier2rs2ZZnt xQrw== X-Gm-Message-State: AGRZ1gJ4DNqoLMCK19YYiXfQDGc6y98qIEo6NLcKBVLwk8R6mSzlnolq GlEShegJnwfo593X+ZanKio6WQ== X-Google-Smtp-Source: AJdET5dT74S3wSwm9uYAcNyYN3Q0NMfG7pu15+v0ipzQN70zPB+n91B85sr+89fJB1+EDfVrFksl2w== X-Received: by 2002:a1c:410a:: with SMTP id o10-v6mr2032777wma.19.1540909854359; Tue, 30 Oct 2018 07:30:54 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:5008:b804:8de9:cc9b? ([2001:660:330f:a4:5008:b804:8de9:cc9b]) by smtp.gmail.com with ESMTPSA id n1-v6sm6597537wra.59.2018.10.30.07.30.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Oct 2018 07:30:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Luigi Iannone In-Reply-To: <18DC3EB5-0BB7-4B20-9B73-01702C21E69E@gmail.com> Date: Tue, 30 Oct 2018 15:30:49 +0100 Cc: "lisp@ietf.org list" Content-Transfer-Encoding: 7bit Message-Id: References: <153877793727.1026.1146854495726676148.idtracker@ietfa.amsl.com> <1B08CE0F-6AA0-49C1-8A36-F562844F83DD@gigix.net> <63BE166E-8166-478D-828E-087511AD4D4C@gigix.net> <18DC3EB5-0BB7-4B20-9B73-01702C21E69E@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [lisp] [Call for Agenda Items] IETF 103 Preliminary Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 14:30:59 -0000 Thanks. Updated. Ciao L. > On 30 Oct 2018, at 15:26, Dino Farinacci wrote: > >> - LISP EID Anonimity - draft-ietf-lisp-eid-anonymity-04 >> 10 Minutes (Cumulative Time: 45 Minutes) >> Dino Farinacci > > Padma is doing this presentation. > > Dino >