From nobody Thu Aug 1 10:01:00 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB0A1201D0 for ; Thu, 1 Aug 2019 10:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 rRcROFxghpa2 for ; Thu, 1 Aug 2019 10:00:56 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 02DED1201D2 for ; Thu, 1 Aug 2019 10:00:54 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id m9so32355784pls.8 for ; Thu, 01 Aug 2019 10:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=IxObJ8NaLUdp/sxofH3AONNeSSUT3XAlj3eMS1tmOXs=; b=TJYMAInbhoJ7tTZQaOVbn3jQizwdQHKDcD3ooMLDjkLfg4DpJNNkELF6jSHhhMRcJl r7ILMIDkBVkuH2sY0Or13SVL1dA0USjCWfZXYGqpkB/VmVGduAlaueeZDnx+n1ZuOXDD Ig3NID9D+9GPl9+XX0xulCf6faO5LLvvqYubaug5f44/TjnCZw5xHw23XMimOU9JnXR+ 9ucEL0xwUDw6+wcT0O6jl2xJDVoc6VaiITIx0ijSBMjp6cZL1HaJYY5QG1yz/PrHYlLv tvre6bWmfXliaW3bSeMMZ0g3dXrmJbaJSzy21MJ63AJtapbUlZ9T/7GI3ZInYJPWDsE8 ulPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=IxObJ8NaLUdp/sxofH3AONNeSSUT3XAlj3eMS1tmOXs=; b=p3Q1wmAu+Ow6o3E2MOmbufkxhe0l2nu573EPoD5O2UA40tfnrgkAbunMndzYsqvQGN K+HGUPKytl8s3rcddq8HVvDglp3yt4OebHoMjzkbufnI97SgIQusBXgqoBKogNueHV6K j9Nm6M1S8ON4SMDR9x8RgVMyhN6nVUTz6blkT7RykyXMbP2kcrH9IhuoBEsNxZKSaLOX AOu1Un9knK81+rOXtZ7Fg2ARlCFcsX6rzqxW7AzeygpFYiNzPNJt45s9LuL3+gyIUFTS hhdSKw24rWFfikh3PWhTrAICrTaKc5ZctyXdWDcBiiHvmrVwq8k00YsGw4iEVc5eXCVj sCCA== X-Gm-Message-State: APjAAAXh1WpqYdra4zyKRoBdM61bbih9qlsXgq1UGh9ZkQid6VSNnCUx inCdefFoKbyYET172cCOjKbSa78Z X-Google-Smtp-Source: APXvYqxshbVePPTyoI6GFLGJr0inLp0eSKx+qESLmsCQ1wqar9Ty8vKK5IAOWGThGDERiDKots4eQw== X-Received: by 2002:a17:902:4283:: with SMTP id h3mr123240085pld.15.1564678854256; Thu, 01 Aug 2019 10:00:54 -0700 (PDT) Received: from [10.97.50.122] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id p20sm87634242pgi.81.2019.08.01.10.00.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Aug 2019 10:00:53 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/alternative; boundary="Apple-Mail=_604C2AC3-BE6B-4C8C-8912-063B5A2017AC" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 1 Aug 2019 10:00:52 -0700 References: Cc: RIPE NCC Support To: "lisp@ietf.org list" Message-Id: <547CDFBA-E4CB-4422-890C-A8CC895C0F62@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [lisp] Fwd: #202719 - Re: LISP EID prefix 2001:5:3::/48 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, 01 Aug 2019 17:00:59 -0000 --Apple-Mail=_604C2AC3-BE6B-4C8C-8912-063B5A2017AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am still using this block but RIPE wants to remove it per IETF = recommendations. Should we update RFC 7955 to indicate the = =E2=80=9Cexperiment=E2=80=9D is still continuing? Dino > Begin forwarded message: >=20 > From: RIPE NCC Support > Subject: #202719 - Re: LISP EID prefix 2001:5:3::/48 > Date: August 1, 2019 at 5:09:09 AM PDT > To: farinacci > Reply-To: RIPE NCC Support >=20 > ##- Please type your reply above this line -## > Ticket (202719) has been updated. To add additional comments, reply to = this email. >=20 > Mike Petrusha (RIPE NCC Support)=20 > Aug 1, 14:09 CEST >=20 > Dear Colleagues, >=20 > The RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 to = lispers.net on 2016-11-16. >=20 > The assigned prefix will be removed on 31 August 2019. >=20 > According to RFC 7955, https://tools.ietf.org/html/rfc7955 = > "According to the 3+3 year experimentation plan, defined in > [RFC 7954 ], all registrations = MUST end by August 2019, unless > the IETF community decides to grant a permanent LISP EID > address block." >=20 >=20 > -- > Sincerely, >=20 > Mike Petrusha > RIPE NCC >=20 >=20 > This email is a service from RIPE NCC Support. > [PMZV6Q-QO6Q] --Apple-Mail=_604C2AC3-BE6B-4C8C-8912-063B5A2017AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = am still using this block but RIPE wants to remove it per IETF = recommendations. Should we update RFC 7955 to indicate the = =E2=80=9Cexperiment=E2=80=9D is still continuing?

Dino

Begin = forwarded message:

From: = RIPE NCC Support <support@ripe.net>
Subject: = #202719 - Re: = LISP EID prefix 2001:5:3::/48
Date: = August 1, 2019 at 5:09:09 AM = PDT
To: = farinacci <farinacci@gmail.com>
Reply-To: = RIPE NCC Support <support@ripe.net>

##- = Please type your reply above this line -##

Ticket = (202719) has been updated. To add additional comments, reply to this = email.

Mike Petrusha (RIPE NCC Support) 

Aug 1, 14:09 = CEST

Dear Colleagues,

The= RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 to lispers.net on 2016-11-16.

The assigned prefix will be removed on 31 = August 2019.

According to RFC 7955, https://tools.ietf.org/html/rfc7955
"According to the 3+3 year experimentation plan, =
defined in
[RFC 7954], all registrations MUST end =
by August 2019, unless
the IETF community decides to grant =
a permanent LISP EID
address block."

--
Sincerely,

Mike Petrusha
RIPE = NCC


This email is a service from RIPE NCC Support.
[PMZV6Q-QO6Q]

= --Apple-Mail=_604C2AC3-BE6B-4C8C-8912-063B5A2017AC-- From nobody Thu Aug 1 10:47:02 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4AE1201B8 for ; Thu, 1 Aug 2019 10:47:01 -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 R5xLToQ88saW for ; Thu, 1 Aug 2019 10:46:59 -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 552F41201B4 for ; Thu, 1 Aug 2019 10:46:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45zyR71Zz6z1V4VC; Thu, 1 Aug 2019 10:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1564681619; bh=2tefbCtZ0urnct3ObWUxuXfnj5huVQmHust/4OT80Iw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=biOO4f+C+GYdCHqcuOAjExCICF2IzrNPHrEUCd7Mg1E6xHgsIhEFPWrjZG4qHUI1v RSjS6OzvY4Cwl5IqZllDKhO4nERhOBRvv5LFlur2OMbMbVfvE6RDsfH7BxjsYzJ4CT hzHNXzpiUqM7ssiut6WK91faenPTlGFLmtz4Rg9g= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [172.20.7.244] (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 45zyR64ky6z1V4Ts; Thu, 1 Aug 2019 10:46:58 -0700 (PDT) To: Dino Farinacci , "lisp@ietf.org list" References: <547CDFBA-E4CB-4422-890C-A8CC895C0F62@gmail.com> From: "Joel M. Halpern" Message-ID: <7193daf7-8c2f-31f9-14b5-e8548e9330ec@joelhalpern.com> Date: Thu, 1 Aug 2019 13:46:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <547CDFBA-E4CB-4422-890C-A8CC895C0F62@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Fwd: #202719 - Re: LISP EID prefix 2001:5:3::/48 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, 01 Aug 2019 17:47:01 -0000 I am presuming your phrasing is slightly misleading. If you individually are the only user of the block, I do not see how we can justify asking RIPE to continue the assignment. Yours, Joel On 8/1/2019 1:00 PM, Dino Farinacci wrote: > I am still using this block but RIPE wants to remove it per IETF > recommendations. Should we update RFC 7955 to indicate the “experiment” > is still continuing? > > Dino > >> Begin forwarded message: >> >> *From: *RIPE NCC Support > >> *Subject: **#202719 - Re: LISP EID prefix 2001:5:3::/48* >> *Date: *August 1, 2019 at 5:09:09 AM PDT >> *To: *farinacci > >> *Reply-To: *RIPE NCC Support > >> >> ##- Please type your reply above this line -## >> >> Ticket (202719) has been updated. To add additional comments, reply to >> this email. >> >> *Mike Petrusha*(RIPE NCC Support) >> >> Aug 1, 14:09 CEST >> >> Dear Colleagues, >> >> The RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 tolispers.net >> on 2016-11-16. >> >> The assigned prefix will be removed on 31 August 2019. >> >> According to RFC 7955,https://tools.ietf.org/html/rfc7955 >> "According to the 3+3 year experimentation plan, defined in >> [RFC 7954 ], all registrations MUST end by August 2019, unless >> the IETF community decides to grant a permanent LISP EID >> address block." >> >> >> -- >> Sincerely, >> >> Mike Petrusha >> RIPE NCC >> >> >> This email is a service from RIPE NCC Support. >> [PMZV6Q-QO6Q] > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Thu Aug 1 11:33:20 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659001201D0 for ; Thu, 1 Aug 2019 11:33:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 mWwXvGlsuORI for ; Thu, 1 Aug 2019 11:33:17 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF10120168 for ; Thu, 1 Aug 2019 11:33:17 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id m30so34570229pff.8 for ; Thu, 01 Aug 2019 11:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wNDoNtInAYYyGQS56+n4dl0kLa/nv8+4lyV+BjZzkAc=; b=ZvBPtb5AyZgz3bYDLeofBaLBe+RMX72j5sdKQV9zfqykGmAFWmbuiRCYa2sQ1Wikyf arI54TLQi5GZS0FO8owBqJ7yo1l4avPEkByhEqUDUUmBxEcTqki6Wngd9vfRfxaBM99L +t7UtzFZYlZVBm4k66IrCxBWLd4NmiEMRg+lVKKaQpI/l5zVwkp15jBpNPNxrtHlAx4U OSn9ru2cZaHNcbpyaf2lXwoUC0TFPqUyrPR2ZPytMdFmVKDT5K/blXrMTysY9DZLIFM2 tVBNDSAiAg7jOgztWA1eJ5god56yg3XoTCAcV6988cJs8JplsmhYle1keLzrjKGEoS9+ qbxQ== 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=wNDoNtInAYYyGQS56+n4dl0kLa/nv8+4lyV+BjZzkAc=; b=VjPe4kTVKe6e7tIWyK52AUHM8N0b56BSgQxuSKXLLKIR4/kZMe7NMTuVJ8vSjBwkiq 61sc1qCOHi1aWlGZqxJnql0zi/dS8yyLD/mEZlrG3j0o9MI6vxAuRjx/D/AiDV4iq6WC oCF5wEwr63m9BzZ7NWVE8Ob65TH4XnpKMOhISjQKe+gLWI67qLGHQtljLxG74JvAAjRv BYjR0uT83EVuomqmUucPkSA/miHGaHCFbO5Ss88xiUlhF2tvuB07ZzbA355Fnhp6pWGV aoYF/eH4frKWFEDyMINRSxTSBp7jJrm+etqzNNrEo1eFspTisWs8OmCZ1MExyoCu1c4T WFNQ== X-Gm-Message-State: APjAAAVulT7N1ODbxa5T9MOy/b7aYeWJklmYv5FVuNeOsqgOKEwAxdT9 hYUlesB9jpTRwrkWcJHNCDo= X-Google-Smtp-Source: APXvYqxYyURv5WcPOI0YB8SI/X0rf8olIRJx1jEegdrXpY6DQC/qMD5rUBEqmz9FxNKJX6OEAuK8mg== X-Received: by 2002:aa7:97bb:: with SMTP id d27mr54638252pfq.93.1564684396525; Thu, 01 Aug 2019 11:33:16 -0700 (PDT) Received: from [10.97.50.122] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id n26sm75061026pfa.83.2019.08.01.11.33.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Aug 2019 11:33:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <7193daf7-8c2f-31f9-14b5-e8548e9330ec@joelhalpern.com> Date: Thu, 1 Aug 2019 11:33:15 -0700 Cc: "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: References: <547CDFBA-E4CB-4422-890C-A8CC895C0F62@gmail.com> <7193daf7-8c2f-31f9-14b5-e8548e9330ec@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Fwd: #202719 - Re: LISP EID prefix 2001:5:3::/48 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, 01 Aug 2019 18:33:19 -0000 No, its not about me. RIPE wants to stop allocating experimental EID = blocks. Do we, the LISP WG, want that to happen? Dino > On Aug 1, 2019, at 10:46 AM, Joel M. Halpern = wrote: >=20 > I am presuming your phrasing is slightly misleading. If you = individually are the only user of the block, I do not see how we can = justify asking RIPE to continue the assignment. >=20 > Yours, > Joel >=20 > On 8/1/2019 1:00 PM, Dino Farinacci wrote: >> I am still using this block but RIPE wants to remove it per IETF = recommendations. Should we update RFC 7955 to indicate the = =E2=80=9Cexperiment=E2=80=9D is still continuing? >> Dino >>> Begin forwarded message: >>>=20 >>> *From: *RIPE NCC Support > >>> *Subject: **#202719 - Re: LISP EID prefix 2001:5:3::/48* >>> *Date: *August 1, 2019 at 5:09:09 AM PDT >>> *To: *farinacci > >>> *Reply-To: *RIPE NCC Support > >>>=20 >>> ##- Please type your reply above this line -## >>>=20 >>> Ticket (202719) has been updated. To add additional comments, reply = to this email. >>>=20 >>> *Mike Petrusha*(RIPE NCC Support) >>>=20 >>> Aug 1, 14:09 CEST >>>=20 >>> Dear Colleagues, >>>=20 >>> The RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 = tolispers.net on 2016-11-16. >>>=20 >>> The assigned prefix will be removed on 31 August 2019. >>>=20 >>> According to RFC 7955,https://tools.ietf.org/html/rfc7955 >>> "According to the 3+3 year experimentation plan, defined in >>> [RFC 7954 ], all registrations = MUST end by August 2019, unless >>> the IETF community decides to grant a permanent LISP EID >>> address block." >>>=20 >>>=20 >>> -- >>> Sincerely, >>>=20 >>> Mike Petrusha >>> RIPE NCC >>>=20 >>>=20 >>> This email is a service from RIPE NCC Support. >>> [PMZV6Q-QO6Q] >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Aug 1 11:36:17 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0201200E5 for ; Thu, 1 Aug 2019 11:36:15 -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 Q-VsEWw7AXpc for ; Thu, 1 Aug 2019 11:36:13 -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 800AF120059 for ; Thu, 1 Aug 2019 11:36:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45zzWx37Q5z1V4VW; Thu, 1 Aug 2019 11:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1564684573; bh=LtxiZUi3UrXk8yTJfw/s+cdvTiLguKdA2RIMW/s1ISA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CAP5M/KWJlkKge97diQIGOWqz4Q0BIDcgkdpqcpj5KGKVeKDxa9ZP1lz775bdJ0QW Y6JE6IjbORXBE/VMvbEgQusSn13nZUea0MczNvOZ7CKfG5sfWJR0VzXAuxY8E5AYif jUXACfgz+9BwchRhdx1BD/Emr7sD8lx0G21upD4s= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [172.20.7.244] (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 45zzWw6Pnqz1V4VQ; Thu, 1 Aug 2019 11:36:12 -0700 (PDT) To: Dino Farinacci Cc: "lisp@ietf.org list" References: <547CDFBA-E4CB-4422-890C-A8CC895C0F62@gmail.com> <7193daf7-8c2f-31f9-14b5-e8548e9330ec@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <97c6dce6-ae82-9706-743d-519fcd00c837@joelhalpern.com> Date: Thu, 1 Aug 2019 14:36:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Fwd: #202719 - Re: LISP EID prefix 2001:5:3::/48 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, 01 Aug 2019 18:36:15 -0000 If only one person is using the block after all this time, then yes, we as a working group want RIPE to stop allocating experimental EIDs. If there is significant usage, then we should understand what it is and why. Yours, Joel On 8/1/2019 2:33 PM, Dino Farinacci wrote: > No, its not about me. RIPE wants to stop allocating experimental EID blocks. Do we, the LISP WG, want that to happen? > > Dino > >> On Aug 1, 2019, at 10:46 AM, Joel M. Halpern wrote: >> >> I am presuming your phrasing is slightly misleading. If you individually are the only user of the block, I do not see how we can justify asking RIPE to continue the assignment. >> >> Yours, >> Joel >> >> On 8/1/2019 1:00 PM, Dino Farinacci wrote: >>> I am still using this block but RIPE wants to remove it per IETF recommendations. Should we update RFC 7955 to indicate the “experiment” is still continuing? >>> Dino >>>> Begin forwarded message: >>>> >>>> *From: *RIPE NCC Support > >>>> *Subject: **#202719 - Re: LISP EID prefix 2001:5:3::/48* >>>> *Date: *August 1, 2019 at 5:09:09 AM PDT >>>> *To: *farinacci > >>>> *Reply-To: *RIPE NCC Support > >>>> >>>> ##- Please type your reply above this line -## >>>> >>>> Ticket (202719) has been updated. To add additional comments, reply to this email. >>>> >>>> *Mike Petrusha*(RIPE NCC Support) >>>> >>>> Aug 1, 14:09 CEST >>>> >>>> Dear Colleagues, >>>> >>>> The RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 tolispers.net on 2016-11-16. >>>> >>>> The assigned prefix will be removed on 31 August 2019. >>>> >>>> According to RFC 7955,https://tools.ietf.org/html/rfc7955 >>>> "According to the 3+3 year experimentation plan, defined in >>>> [RFC 7954 ], all registrations MUST end by August 2019, unless >>>> the IETF community decides to grant a permanent LISP EID >>>> address block." >>>> >>>> >>>> -- >>>> Sincerely, >>>> >>>> Mike Petrusha >>>> RIPE NCC >>>> >>>> >>>> This email is a service from RIPE NCC Support. >>>> [PMZV6Q-QO6Q] >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp > > From nobody Thu Aug 1 11:38:56 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842371201E3 for ; Thu, 1 Aug 2019 11:38:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 HbdYEHh9va8S for ; Thu, 1 Aug 2019 11:38:49 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06C01201CC for ; Thu, 1 Aug 2019 11:38:41 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id u17so34684026pgi.6 for ; Thu, 01 Aug 2019 11:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xU5FG5BIdj9nvYdX4yCr+QDa95z6PjjQC3dmRumT5dI=; b=X6T3giXVLa7u4Ix5AUdSRQKKQaWS5e457y2NYzonpxOwFYID55LaWpAu92gqOVdfNv 0QLBgaZddeaiX/7dZVX+3HwRnwIL/qWM3Jt5cESNY7LGkjmoQEElllG8Mu0cfwSmupD/ d8tUs8eBWZBLUKQAszEAXTif6Yl9/HJRHV8UhkGZeu6oQUrSUremeNOGx0cgUk/8pwc9 AsNU5sJYtqJzD+GjLb/aDI6LuHlDgOTurqhkrjfcZhjTJLECwxEhEgSKY4D5zwjBg99T Gn8uo/W6h+bDsfJnMT1t9fqxzXLjHt31Uhvibrt7Q3JhvcxzViVW/tMQbVLcODFb71ae E15w== 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=xU5FG5BIdj9nvYdX4yCr+QDa95z6PjjQC3dmRumT5dI=; b=gv2oKGujvlorPXmlsMhTjp7Dbv+vwH2Jp4/RyeLvt7FIfaQok5QhUpU9kgjgCO/Avp +iwoPCRTsaee5L7v0f8py441L6NgolmKpLl13nCaZDKVLuKBoNIjAc/n/Hkw4BpCrfjZ UKQ0IpWcjcRewhuNjalivT5NNm+36F3HrZsqQSE897eeaVyciTbfGZ+ePD8C8rJ6d1x4 +lizMahMZo9EiSRUgzB9M6HszPbgdDo4qmikJyziq2cTffMZ4FwZBi4aJp7npbpXpBbs w9elwwXL0d/SVFnROgf9RSytcL+gp9kW4i08ddhmkGkO2DzlJDyIVbiz4v+WyuttlKFo bIDQ== X-Gm-Message-State: APjAAAVROxGvZqIydtcx3n2Ut+1hD5EjEzRdeTeNSkSpnM61R0yoCU5U K3KpkywzfYiwpi8Ss+0s0s8= X-Google-Smtp-Source: APXvYqym4q/dnzArd08cXolrulMBceejwPcqZ8M7NpOS3OheL9Phif2yophr3/XaR0szd2avKO74cg== X-Received: by 2002:a62:1c5:: with SMTP id 188mr52944695pfb.26.1564684721243; Thu, 01 Aug 2019 11:38:41 -0700 (PDT) Received: from [10.97.50.122] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id n98sm5441679pjc.26.2019.08.01.11.38.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Aug 2019 11:38:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <97c6dce6-ae82-9706-743d-519fcd00c837@joelhalpern.com> Date: Thu, 1 Aug 2019 11:38:38 -0700 Cc: "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <62350D10-4641-4DB9-8FEE-065ACF0A160D@gmail.com> References: <547CDFBA-E4CB-4422-890C-A8CC895C0F62@gmail.com> <7193daf7-8c2f-31f9-14b5-e8548e9330ec@joelhalpern.com> <97c6dce6-ae82-9706-743d-519fcd00c837@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Fwd: #202719 - Re: LISP EID prefix 2001:5:3::/48 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, 01 Aug 2019 18:38:53 -0000 > If only one person is using the block after all this time, then yes, = we as a working group want RIPE to stop allocating experimental EIDs. You are missing the point Joel. There are many sub-blocks allocated from = the experimental block from RFC 7955. I am not the only sub-block. > If there is significant usage, then we should understand what it is = and why. What if there is *any* usage for any subblock? Dino >=20 > Yours, > Joel >=20 > On 8/1/2019 2:33 PM, Dino Farinacci wrote: >> No, its not about me. RIPE wants to stop allocating experimental EID = blocks. Do we, the LISP WG, want that to happen? >> Dino >>> On Aug 1, 2019, at 10:46 AM, Joel M. Halpern = wrote: >>>=20 >>> I am presuming your phrasing is slightly misleading. If you = individually are the only user of the block, I do not see how we can = justify asking RIPE to continue the assignment. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 8/1/2019 1:00 PM, Dino Farinacci wrote: >>>> I am still using this block but RIPE wants to remove it per IETF = recommendations. Should we update RFC 7955 to indicate the = =E2=80=9Cexperiment=E2=80=9D is still continuing? >>>> Dino >>>>> Begin forwarded message: >>>>>=20 >>>>> *From: *RIPE NCC Support > >>>>> *Subject: **#202719 - Re: LISP EID prefix 2001:5:3::/48* >>>>> *Date: *August 1, 2019 at 5:09:09 AM PDT >>>>> *To: *farinacci > >>>>> *Reply-To: *RIPE NCC Support > >>>>>=20 >>>>> ##- Please type your reply above this line -## >>>>>=20 >>>>> Ticket (202719) has been updated. To add additional comments, = reply to this email. >>>>>=20 >>>>> *Mike Petrusha*(RIPE NCC Support) >>>>>=20 >>>>> Aug 1, 14:09 CEST >>>>>=20 >>>>> Dear Colleagues, >>>>>=20 >>>>> The RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 = tolispers.net on 2016-11-16. >>>>>=20 >>>>> The assigned prefix will be removed on 31 August 2019. >>>>>=20 >>>>> According to RFC 7955,https://tools.ietf.org/html/rfc7955 >>>>> "According to the 3+3 year experimentation plan, defined in >>>>> [RFC 7954 ], all = registrations MUST end by August 2019, unless >>>>> the IETF community decides to grant a permanent LISP EID >>>>> address block." >>>>>=20 >>>>>=20 >>>>> -- >>>>> Sincerely, >>>>>=20 >>>>> Mike Petrusha >>>>> RIPE NCC >>>>>=20 >>>>>=20 >>>>> This email is a service from RIPE NCC Support. >>>>> [PMZV6Q-QO6Q] >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Aug 1 11:41:05 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407291200E5 for ; Thu, 1 Aug 2019 11:41:03 -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 jBfy4jzUgb37 for ; Thu, 1 Aug 2019 11:41:01 -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 F0BB812013D for ; Thu, 1 Aug 2019 11:41:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45zzdS6G2tz1V4Vh; Thu, 1 Aug 2019 11:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1564684860; bh=mnVb2A6UXJrPnv7wtoaWCKgH5raKBjyj3T4kXBltbgI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aTQZW3wbpjsEgE2EZSmGNKX//S6kpybfn+Ujqjdi+2/xEW95WUmdwpBfIdrihuFOx OdNOEpWrcDVHI20q9Y51bPKbyImRy9AaFkMra31SqlUveWyNy+/yChg1jDOjo7EvRj ivy1DnSznh+mABPakf7TUUshsTYGbDmofiydoLYY= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [172.20.7.244] (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 45zzdS2MPmz1V4VQ; Thu, 1 Aug 2019 11:41:00 -0700 (PDT) To: Dino Farinacci Cc: "lisp@ietf.org list" References: <547CDFBA-E4CB-4422-890C-A8CC895C0F62@gmail.com> <7193daf7-8c2f-31f9-14b5-e8548e9330ec@joelhalpern.com> <97c6dce6-ae82-9706-743d-519fcd00c837@joelhalpern.com> <62350D10-4641-4DB9-8FEE-065ACF0A160D@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 1 Aug 2019 14:40:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <62350D10-4641-4DB9-8FEE-065ACF0A160D@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Fwd: #202719 - Re: LISP EID prefix 2001:5:3::/48 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, 01 Aug 2019 18:41:03 -0000 We asked for an experiment. As such, we need to re-evaluate the experiment. You said "I am using it". As I said, I presume that is a mis-statement. Who is using EIDs from that block? What are they being used for? Is having a block actually helpful? In particular, given that our focus as a working group has moved away from Internet-Wide deployments of LISP to more specialized use cases, it is not at all clear that the PS-to-be documents warrant the allocation. Yours, Joel On 8/1/2019 2:38 PM, Dino Farinacci wrote: >> If only one person is using the block after all this time, then yes, we as a working group want RIPE to stop allocating experimental EIDs. > > You are missing the point Joel. There are many sub-blocks allocated from the experimental block from RFC 7955. I am not the only sub-block. > >> If there is significant usage, then we should understand what it is and why. > > What if there is *any* usage for any subblock? > > Dino > >> >> Yours, >> Joel >> >> On 8/1/2019 2:33 PM, Dino Farinacci wrote: >>> No, its not about me. RIPE wants to stop allocating experimental EID blocks. Do we, the LISP WG, want that to happen? >>> Dino >>>> On Aug 1, 2019, at 10:46 AM, Joel M. Halpern wrote: >>>> >>>> I am presuming your phrasing is slightly misleading. If you individually are the only user of the block, I do not see how we can justify asking RIPE to continue the assignment. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 8/1/2019 1:00 PM, Dino Farinacci wrote: >>>>> I am still using this block but RIPE wants to remove it per IETF recommendations. Should we update RFC 7955 to indicate the “experiment” is still continuing? >>>>> Dino >>>>>> Begin forwarded message: >>>>>> >>>>>> *From: *RIPE NCC Support > >>>>>> *Subject: **#202719 - Re: LISP EID prefix 2001:5:3::/48* >>>>>> *Date: *August 1, 2019 at 5:09:09 AM PDT >>>>>> *To: *farinacci > >>>>>> *Reply-To: *RIPE NCC Support > >>>>>> >>>>>> ##- Please type your reply above this line -## >>>>>> >>>>>> Ticket (202719) has been updated. To add additional comments, reply to this email. >>>>>> >>>>>> *Mike Petrusha*(RIPE NCC Support) >>>>>> >>>>>> Aug 1, 14:09 CEST >>>>>> >>>>>> Dear Colleagues, >>>>>> >>>>>> The RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 tolispers.net on 2016-11-16. >>>>>> >>>>>> The assigned prefix will be removed on 31 August 2019. >>>>>> >>>>>> According to RFC 7955,https://tools.ietf.org/html/rfc7955 >>>>>> "According to the 3+3 year experimentation plan, defined in >>>>>> [RFC 7954 ], all registrations MUST end by August 2019, unless >>>>>> the IETF community decides to grant a permanent LISP EID >>>>>> address block." >>>>>> >>>>>> >>>>>> -- >>>>>> Sincerely, >>>>>> >>>>>> Mike Petrusha >>>>>> RIPE NCC >>>>>> >>>>>> >>>>>> This email is a service from RIPE NCC Support. >>>>>> [PMZV6Q-QO6Q] >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp > From nobody Thu Aug 1 11:51:17 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF92E1200E5 for ; Thu, 1 Aug 2019 11:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 zZ1cizy_px9H for ; Thu, 1 Aug 2019 11:51:14 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557D6120059 for ; Thu, 1 Aug 2019 11:51:14 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id t14so32579947plr.11 for ; Thu, 01 Aug 2019 11:51: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=YhXyFG5i2oj2BjDuQvrx59WOX35OxSStMmH1A2AjJjI=; b=U9qJtmj+GE8Nxk3dtuqqL7jJTJYhWBaIZDt7txYC5XyvkEdZZ2OaLWYBfBTvF/xYpB Lt8vBwOIdON4HHcFkLnWsRe+os+CvloJOCMSc62M4zagVJLfRTkeSYv02Ku6vJ0ztufA mYn/G9ywEd8jnHDhFCKfxVU3V9DwhfHGeXvc8r0OlnPRdpR3PzB34Axhkb/CgIompNm/ sChrWepHaMDbDeED/eujaqlgTf2NORWxTk1k4PEZefgC1Wm+LrFtdEV5lfGldTL658gL WCC+LqFnTp00KcVOM743X+EiW6A32N79QX/UyOYgK46+8/RL3xitRdllsnhxq9byz9vZ 3QTg== 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=YhXyFG5i2oj2BjDuQvrx59WOX35OxSStMmH1A2AjJjI=; b=NUS6YY4/f5693S4KKl4635aaKae4N0ZZWHkG/KJj89QniS4NTCcd0MqU6Nln2awLhH EYGmDSlDofzuZh98loEJ+8asrUtDpMA+zttBglwg2py/eZNyfue9Pe2zPffTN9ak+/uR iYIghSzqOUrpVPYG5nPKVD/2h6utjlRHHzrPPOsbXP6CsGCW7uv8gvMUIfTt2mw7bC2k uxDsHE/XdnLhBCyy38/ETj+wUfa/UpzzDEIcgntTgWIYZQrsMuOegQmgcqtvx3f0vAlv NadIK0iKXma1HQi4F/3oYugBQRArUkqTUE3qsVmX1X9vOip0iOL8tWkkKorroOlJDrND SZtQ== X-Gm-Message-State: APjAAAU1YTvVy9lC6hoUoYaH3ABCYk+Oj+O328K3qn5WW4MngoxAOfIU bk4R1cuDoQUBu6Hs4Hs8Okk= X-Google-Smtp-Source: APXvYqxnbHg2dJmo4cF3Abh33qpC51XNhRRMakgyDbpjtLeTNeqD7xXZTGifZXfPvVxV7KYaSPc8iw== X-Received: by 2002:a17:902:7781:: with SMTP id o1mr127367543pll.205.1564685473830; Thu, 01 Aug 2019 11:51:13 -0700 (PDT) Received: from [10.97.50.122] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id f7sm71178415pfd.43.2019.08.01.11.51.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Aug 2019 11:51: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: Thu, 1 Aug 2019 11:51:12 -0700 Cc: "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <1A6037C9-6F43-40AC-9160-7E5B937800B4@gmail.com> References: <547CDFBA-E4CB-4422-890C-A8CC895C0F62@gmail.com> <7193daf7-8c2f-31f9-14b5-e8548e9330ec@joelhalpern.com> <97c6dce6-ae82-9706-743d-519fcd00c837@joelhalpern.com> <62350D10-4641-4DB9-8FEE-065ACF0A160D@gmail.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Fwd: #202719 - Re: LISP EID prefix 2001:5:3::/48 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, 01 Aug 2019 18:51:16 -0000 > We asked for an experiment. As such, we need to re-evaluate the = experiment. That is my point. > You said "I am using it". As I said, I presume that is a = mis-statement. Who is using EIDs from that block? What are they being = used for? Is having a block actually helpful? I am using EIDs out of the subblock that RIPE allocated to me. I have = renewed the block each year. I can=E2=80=99t tell you who are using them = without their permission. They are being used to be on an IPv6 overlay. = They are being used with some structure in the address as well as = crypto-EIDs. Yes, having the block is useful. Especially was we will have a = requirement to have these EIDs interwork with IPv6 Internet nodes. > In particular, given that our focus as a working group has moved away = from Internet-Wide deployments of LISP to more specialized use cases, it = is not at all clear that the PS-to-be documents warrant the allocation. I can=E2=80=99t see why it would be harmful to ask for another 3 years. Dino From nobody Fri Aug 2 09:23:10 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30AB120203 for ; Fri, 2 Aug 2019 09:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 6A-eUUsTWLHd for ; Fri, 2 Aug 2019 09:23:07 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FAE512020A for ; Fri, 2 Aug 2019 09:23:07 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id q10so36272272pff.9 for ; Fri, 02 Aug 2019 09:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZGqCc8sdP6QCqtTWC9A3OA9K4RJef5Dogbq4XOaPo2w=; b=UCiEMWIb+SP865weahhK2qPyh2cyYNcU+jr+V+8r3hiKGOtPZCm9ecEgvFDe0GEzKf 1nPXyfRIgHr2YVbZot/6j3nKFnnmCDBOt6U1EI2c0cpoF+Btzz1RvfITma4nRA1fM8+s OewIpW9VHTxDtekvHS2++A4uqzqoXfilqibWlDHinN4/2XuNpOpcdAgFMLobmY7gXnk4 fil58L9/XwZeQU2ZmulVII3AxN6bBitjqhFioMbRl/nJxlGzvYWbjoWEyctIzP8l5rD3 lQ9KfZkedZvAFTZAVPhr+08qGJtSuTQzqTMD0gjLoNfrvyd40JmgKj2fmlPQ416HjrsG jv2A== 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=ZGqCc8sdP6QCqtTWC9A3OA9K4RJef5Dogbq4XOaPo2w=; b=hfltJoiBHPQX/gnejLhWWfXzcNgLycKw5EE/eDfmMsnfxiXf7noiYi5oNw7/nFqqn/ CqCc3//Q6EpRmq2TH2mbn1szGSiqJvk77a+CKBym6KqkVAyfD4hfk8AFLyUuGwyGZTjp 9v8Kuuz3fz7Wsprcyf6Dj3W4BspHKLlXF+h6tRjzqAluwLI8oss/1UPkXScZc/mVAnr9 JViWRahtGugg/HdrC+wdEPpMHpT059wAuhll/P25BzJVYhePhIJjz3gXg0yF+BII0a0k LcibIY4jdaG6+cQsXs5r/T5lZo4k6iIcN5GhGXy+lrvunREnkCgexTHgJH11ztADSMZj TTmQ== X-Gm-Message-State: APjAAAXrtwP1wL3KRbh6H1iLkV0PZAG2aThqjzjvZibR07Br9OuluWHc XQ2hYNLds6O7FL4FbhwSRXw= X-Google-Smtp-Source: APXvYqyJ4dptGfLD9dTJ4rDjxVEQCGut3dzc7lUhM8+mvzG5wSux89wpEscF35eZDNyKFnh8FBQwDg== X-Received: by 2002:a63:2cd5:: with SMTP id s204mr106738026pgs.95.1564762986508; Fri, 02 Aug 2019 09:23:06 -0700 (PDT) Received: from [10.97.50.122] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id z4sm63864677pgp.80.2019.08.02.09.23.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Aug 2019 09:23:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Fri, 2 Aug 2019 09:23:04 -0700 Cc: "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <5F2EBDEC-81B4-4B9A-A93F-093200529B42@gmail.com> References: <547CDFBA-E4CB-4422-890C-A8CC895C0F62@gmail.com> To: RIPE NCC Support X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] #202719 - Re: LISP EID prefix 2001:5:3::/48 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, 02 Aug 2019 16:23:09 -0000 Mike, I have cc=E2=80=99ed the LISP WG in this response. Thanks for = providing the active assignments. As a member of the LISP WG, I would like to vote for an update to RFC = 7955 to have the 2001:5::/32 block stay allocated until 2022. Thanks Mike. Dino > On Aug 2, 2019, at 2:33 AM, RIPE NCC Support wrote: >=20 > ##- Please type your reply above this line -## > Ticket (202719) has been updated. To add additional comments, reply to = this email. >=20 > Mike Petrusha (RIPE NCC Support)=20 > Aug 2, 11:33 CEST >=20 > Dear Dino, >=20 > We sent a number of e-mails to LISP WG and received no reply still. >=20 > We are not sure if this reply will appear on the mailing list, if not, = could you please forward it there. >=20 > With regards to the questions about number of assignments: > as you can see at = https://apps.db.ripe.net/db-web-ui/#/query?searchtext=3D-rMT%20inet6num%20= 2001:5::%2F32 there are currently fouractive registrations within = 2001:5::/32 >=20 > Also, from https://www.ripe.net/ripe/mail/archives/lisp-announce/ you = can see that another five assignments existed in the past and have = either expired or were returned. >=20 > ----- Forwarded message ----- >=20 > Date: Tue, 30 Jul 2019 09:34:31 +0200 > From: "RIPE NCC" > To: Deborah Brungard , > Luigi Iannone , > Joel Halpern , > Padma Pillay-Esnault , > LISP WG > Subject: LISP EID assignments from 2001:5::/32 >=20 >=20 > Dear LISP WG, >=20 > This e-mail is from the RIPE NCC, the Internet Registry in Europe. >=20 > The RIPE NCC provides temporary LISP EID assignments from LISP EID = prefix 2001:5::/32 in accordance with RFC 7955: LISP EID Block = Management, https://tools.ietf.org/html/rfc7955 >=20 > We are contacting you as we are approaching August 2019, at which = point we need to start removing existing LISP EID assignments within = 2001:5::/32 (unless IETF made a decision to extend this period). >=20 > Following RFC 7955, https://tools.ietf.org/html/rfc7955 > "According to the 3+3 year experimentation plan, defined in > [RFC 7954], all registrations MUST end by August 2019, unless > the IETF community decides to grant a permanent LISP EID > address block." >=20 > In accordance with RFC 7954: LISP EID Block > https://tools.ietf.org/html/rfc7954#section-6 > " IANA allocated the requested address space in September 2016 for a > duration of 3 (three) years (through September 2019), with an = option > to extend this period by 3 (three) more years (until September = 2022). > By the end of the first period, the IETF will provide a decision on > whether to transform the prefix into a permanent assignment or to = put > it back in the free pool..." >=20 > Could you please let us know whether such decision was made by the = IETF? >=20 >=20 > According to https://tools.ietf.org/html/rfc7954#section-7 > " In order to trigger the process for a permanent allocation, a > document is required. Such a document has to articulate the > rationale for why a permanent allocation would be beneficial. More > specifically, the document has to detail the experience gained = during > experimentation and all of the technical benefits provided by the = use > of a LISP-specific prefix. " >=20 > Could you please let us know if such document was created? >=20 >=20 > According to https://tools.ietf.org/html/rfc7954#section-7 > " If no explicit action is carried out by the end of the experiment = (by > September 2019), it is automatically considered that there was not > sufficient interest in having a permanent allocation; therefore, = the > address block will be returned to the free pool." >=20 > Based on this, the RIPE NCC is ready to proceed with removing existing = LISP EID assignments within 2001:5::/32 in August 2019 (as defined by = RFC 7955) and returning 2001:5::/32 to the IANA in September 2019 (as = defined by RFC 7954). >=20 > We await your reply. >=20 >=20 > -- > Sincerely, >=20 > Mike Petrusha > RIPE NCC >=20 >=20 >=20 > farinacci > Aug 1, 19:00 CEST >=20 > I am still using this block but RIPE wants to remove it per IETF = recommendations. Should we update RFC 7955 to indicate the = =E2=80=9Cexperiment=E2=80=9D is still continuing? >=20 > Dino >=20 > > Begin forwarded message: > >=20 > > From: RIPE NCC Support > > Subject: #202719 - Re: LISP EID prefix 2001:5:3::/48 > > Date: August 1, 2019 at 5:09:09 AM PDT > > To: farinacci > > Reply-To: RIPE NCC Support >=20 >=20 > Mike Petrusha (RIPE NCC Support)=20 > Aug 1, 14:09 CEST >=20 > Dear Colleagues, >=20 > The RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 to = lispers.net on 2016-11-16. >=20 > The assigned prefix will be removed on 31 August 2019. >=20 > According to RFC 7955, https://tools.ietf.org/html/rfc7955 > "According to the 3+3 year experimentation plan, defined in > [RFC 7954], all registrations MUST end by August 2019, unless > the IETF community decides to grant a permanent LISP EID > address block." >=20 >=20 > -- > Sincerely, >=20 > Mike Petrusha > RIPE NCC >=20 >=20 > This email is a service from RIPE NCC Support. > [PMZV6Q-QO6Q] From nobody Fri Aug 2 10:58:59 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29892120782 for ; Fri, 2 Aug 2019 10:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 4_9zPl82ASRe for ; Fri, 2 Aug 2019 10:58:54 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A4512077C for ; Fri, 2 Aug 2019 10:58:51 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id n9so52969854wrr.4 for ; Fri, 02 Aug 2019 10:58: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=uHCz/elNJ22La2mojj2OFWIT9AZwgaHyuFfVHe+AiGY=; b=pRpIsq8kEwRiJmxNTvzCDKtnnjVkbXj1W0gxqiV1jd+4WiGs8kijzzxPNvfsXtMAFC +PwtHj/6gR4qGMlBVndjoxUhBnZ4Qjd+x/4zfiJlkYCtz9A3//upyLtJO/eUff958YsY Ld/AUUJt27MmA90T9VSbKxLHHdGLtxuwt3jUAM9WnN+yJts+AxvbMgqqfh2nPBpy3Gbh C578vciaCTNZbgdOKQj8yReFEqg4pMPiU7EKdazo97F5pa+lnl7LJSbm8iQo5h8m+nE/ Ta7/lqFcJQB+trHgvhLJD36SgrRjx3TSAe7j4SDl7Wjj3LVND889AHmEPVV2wW0NULMs 9MdA== 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=uHCz/elNJ22La2mojj2OFWIT9AZwgaHyuFfVHe+AiGY=; b=H1DapOw0Y1kbkE56TzwWrLbErx8mreOPnYvqOCr7OErG6pgeFQSHXT53U/JTUhbFcq OYHZpk0KrODYL1BnYMxy1ILg1Xtiqf1m7luA7qZQfnVoW/vokeWgt0bOyJk1h8A5eddF Dq5oyAg/WT6kTkZuf3RZwAvKSHVwRr54gC4+t4h29gCfSjBBE9kSIQgiUpAtRiWSkek2 pHgzNjyck3rqGeSf4Uhwp3VbDSEwgV9gNwE13uJbHCuNYShitSovtH9GHwqdraKAalhn EW1cfxFvNburQjlxpfURqv+i4XC4UAbXmpentIGUR1Io5M79iCAvY6wdCYezw5pKvJGK YOWQ== X-Gm-Message-State: APjAAAWA30hecNZ7J+LwpARQgf08Ikw9hYBQ0sNfRfaqFjx3Rfg414df nOs2gFOGFUehlZZUniGnHw== X-Google-Smtp-Source: APXvYqyDD1ThdDyinlL7tL8oA26WLTbEzOtJW1AckAjJGUjJoJJnyxkO0PPCejQl6PAp2lXw+C0JkQ== X-Received: by 2002:a5d:56c7:: with SMTP id m7mr5610911wrw.64.1564768729361; Fri, 02 Aug 2019 10:58:49 -0700 (PDT) Received: from [192.168.1.12] ([213.57.218.196]) by smtp.gmail.com with ESMTPSA id n9sm122152719wrp.54.2019.08.02.10.58.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Aug 2019 10:58:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPhone Mail (16F203) In-Reply-To: <5F2EBDEC-81B4-4B9A-A93F-093200529B42@gmail.com> Date: Fri, 2 Aug 2019 20:58:46 +0300 Cc: RIPE NCC Support , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <69619B4A-3A73-4F83-98D3-22CBACFCEEF3@gmail.com> References: <547CDFBA-E4CB-4422-890C-A8CC895C0F62@gmail.com> <5F2EBDEC-81B4-4B9A-A93F-093200529B42@gmail.com> To: Dino Farinacci Archived-At: Subject: Re: [lisp] #202719 - Re: LISP EID prefix 2001:5:3::/48 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, 02 Aug 2019 17:58:57 -0000 Dino, Mike, if ok would like to add to this important thread - One practical use of LISP EIDs which is being deployed in US cities and majo= r metropolitans is that of IP addressable shared geo-states. In these use-cases each geo-cell in a formal grid of the earth, for example H= 3 resolution 9 in draft-lisp-nexagon, is allocated unique EID. This allows for interoperable connectionless session layer - publish (ucast)= and subscribe (mcast) sharing - of geo-state via EID addressable broker. Fo= rmal EID brokers enable real-time enumeration of road safety-defects-furnitu= re, verified and shared multi-vendor while protecting sources privacy. There are ~5B H3 resolution 9 hexagons on earth out of which ~1% need to be a= ddressable, 50M EID networked hexagons. We allocated a sub-block of 2001:5::/32 EID experimental for this purpose, 6= 4bit H3 IDs mapped algorithmically to 128bit EIDs. Extending the draft will help leveraging the network for real-time public-sa= fety using addressable brokering for better verification, privacy, and secur= e linear (vs polynomial) interoperability effort.=20 --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Aug 2, 2019, at 7:23 PM, Dino Farinacci wrote: >=20 > Mike, I have cc=E2=80=99ed the LISP WG in this response. Thanks for provid= ing the active assignments. >=20 > As a member of the LISP WG, I would like to vote for an update to RFC 7955= to have the 2001:5::/32 block stay allocated until 2022. >=20 > Thanks Mike. >=20 > Dino >=20 >> On Aug 2, 2019, at 2:33 AM, RIPE NCC Support wrote: >>=20 >> ##- Please type your reply above this line -## >> Ticket (202719) has been updated. To add additional comments, reply to th= is email. >>=20 >> Mike Petrusha (RIPE NCC Support)=20 >> Aug 2, 11:33 CEST >>=20 >> Dear Dino, >>=20 >> We sent a number of e-mails to LISP WG and received no reply still. >>=20 >> We are not sure if this reply will appear on the mailing list, if not, co= uld you please forward it there. >>=20 >> With regards to the questions about number of assignments: >> as you can see at https://apps.db.ripe.net/db-web-ui/#/query?searchtext=3D= -rMT%20inet6num%202001:5::%2F32 there are currently fouractive registrations= within 2001:5::/32 >>=20 >> Also, from https://www.ripe.net/ripe/mail/archives/lisp-announce/ you can= see that another five assignments existed in the past and have either expir= ed or were returned. >>=20 >> ----- Forwarded message ----- >>=20 >> Date: Tue, 30 Jul 2019 09:34:31 +0200 >> From: "RIPE NCC" >> To: Deborah Brungard , >> Luigi Iannone , >> Joel Halpern , >> Padma Pillay-Esnault , >> LISP WG >> Subject: LISP EID assignments from 2001:5::/32 >>=20 >>=20 >> Dear LISP WG, >>=20 >> This e-mail is from the RIPE NCC, the Internet Registry in Europe. >>=20 >> The RIPE NCC provides temporary LISP EID assignments from LISP EID prefix= 2001:5::/32 in accordance with RFC 7955: LISP EID Block Management, https:/= /tools.ietf.org/html/rfc7955 >>=20 >> We are contacting you as we are approaching August 2019, at which point w= e need to start removing existing LISP EID assignments within 2001:5::/32 (u= nless IETF made a decision to extend this period). >>=20 >> Following RFC 7955, https://tools.ietf.org/html/rfc7955 >> "According to the 3+3 year experimentation plan, defined in >> [RFC 7954], all registrations MUST end by August 2019, unless >> the IETF community decides to grant a permanent LISP EID >> address block." >>=20 >> In accordance with RFC 7954: LISP EID Block >> https://tools.ietf.org/html/rfc7954#section-6 >> " IANA allocated the requested address space in September 2016 for a >> duration of 3 (three) years (through September 2019), with an option >> to extend this period by 3 (three) more years (until September 2022). >> By the end of the first period, the IETF will provide a decision on >> whether to transform the prefix into a permanent assignment or to put >> it back in the free pool..." >>=20 >> Could you please let us know whether such decision was made by the IETF? >>=20 >>=20 >> According to https://tools.ietf.org/html/rfc7954#section-7 >> " In order to trigger the process for a permanent allocation, a >> document is required. Such a document has to articulate the >> rationale for why a permanent allocation would be beneficial. More >> specifically, the document has to detail the experience gained during >> experimentation and all of the technical benefits provided by the use >> of a LISP-specific prefix. " >>=20 >> Could you please let us know if such document was created? >>=20 >>=20 >> According to https://tools.ietf.org/html/rfc7954#section-7 >> " If no explicit action is carried out by the end of the experiment (by >> September 2019), it is automatically considered that there was not >> sufficient interest in having a permanent allocation; therefore, the >> address block will be returned to the free pool." >>=20 >> Based on this, the RIPE NCC is ready to proceed with removing existing LI= SP EID assignments within 2001:5::/32 in August 2019 (as defined by RFC 7955= ) and returning 2001:5::/32 to the IANA in September 2019 (as defined by RFC= 7954). >>=20 >> We await your reply. >>=20 >>=20 >> -- >> Sincerely, >>=20 >> Mike Petrusha >> RIPE NCC >>=20 >>=20 >>=20 >> farinacci >> Aug 1, 19:00 CEST >>=20 >> I am still using this block but RIPE wants to remove it per IETF recommen= dations. Should we update RFC 7955 to indicate the =E2=80=9Cexperiment=E2=80= =9D is still continuing? >>=20 >> Dino >>=20 >>> Begin forwarded message: >>>=20 >>> From: RIPE NCC Support >>> Subject: #202719 - Re: LISP EID prefix 2001:5:3::/48 >>> Date: August 1, 2019 at 5:09:09 AM PDT >>> To: farinacci >>> Reply-To: RIPE NCC Support >>=20 >>=20 >> Mike Petrusha (RIPE NCC Support)=20 >> Aug 1, 14:09 CEST >>=20 >> Dear Colleagues, >>=20 >> The RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 to lispers.net o= n 2016-11-16. >>=20 >> The assigned prefix will be removed on 31 August 2019. >>=20 >> According to RFC 7955, https://tools.ietf.org/html/rfc7955 >> "According to the 3+3 year experimentation plan, defined in >> [RFC 7954], all registrations MUST end by August 2019, unless >> the IETF community decides to grant a permanent LISP EID >> address block." >>=20 >>=20 >> -- >> Sincerely, >>=20 >> Mike Petrusha >> RIPE NCC >>=20 >>=20 >> This email is a service from RIPE NCC Support. >> [PMZV6Q-QO6Q] >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Aug 2 14:40:09 2019 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 69D28120059; Fri, 2 Aug 2019 14:40:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker 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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156478200742.20926.12898163237864009248.idtracker@ietfa.amsl.com> Date: Fri, 02 Aug 2019 14:40:07 -0700 Archived-At: Subject: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-27: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 21:40:07 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lisp-rfc6830bis-27: 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: ---------------------------------------------------------------------- Updating for the -27 by removing points that are fully addressed but leaving points that I still want to have further discussion on. It may be most expedient to continue discussion on my -26 ballot thread. Please also note that the COMMENT section was entirely refreshed for the -26 and had a few additions as I read the -27. The various places where we mention "gleaming" or similar unauthenticated (un-path-verified?) schemes for learning mapping information should all mention at their description that they are susceptible to spoofing and link to the security considerations. [ed. I have noted offlist to the authors some specific locations] 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 I do not remember there being an ordering (or even consistency) requirement on the ITR-RLOC entries in the Map-Request, so it's unclear that just replacing one entry with an AFI-0 entry would convey this information. I suppose that using only a single ITR-RLOC entry, with AFI 0, would provide a usable signal to the ETR, but that does not seem to be what is being described here. (Also, on a rhetorical point, please clarify that the "as well as" is for setting the LSB to 0 in data packets; Map-Requests do not include any LSBs.) If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the Locator-Set and new records appended to the Locator-Set. At some point, it would be useful to compact the Locator-Set so the Locator-Status-Bit settings can be efficiently packed. This text, implying that compactification must wait for some unspecified later event, seems to be assuming some requirement to preserve order of Locator-Set entries that I cannot find a description of in either 6830bis or 6833bis. [ed. these previous two items are rather poorly described; another thread is ongoing to try to clarify both my concerns and how they might be addressed] I think Warren is correct that there is also an attack that lies in convincing an ITR that an ETR is not reachable even when it is reachable. The following items were present in my original DISCUSS position and still have not been resolved. Note that I copy below the previous ballot text even for some issues that are described above already in different words. There are some fairly subtle ordering requirements between the order of entries in Map-Reply messages and the Locator-Status-Bits in data-plane traffic (so that the semantic meaning of the status bits are meaningful), which is only given a minimal treatment in the control-plane document. The need for synchronization in interpreting these bits should be mentioned more prominently in the data-plane document as well. The usage of the Instance ID does not seem to be adequately covered; from what I've been able to pick up so far it seems that both source and destination participants must agree on the meaning of an Instance ID, and the source and destination EIDs must be in the same Instance. This does not seem like it is compatible with Internet scale, especially if there are only 24 usable bits of Instance ID. There seems to be a lot of intra-site synchronization requirements, notably with respect to Map-Version consistency, the contents and ordering of locator sets for EIDs in the site, etc.; the actual hard requirements for synchronization within a site should be clearly called out, ideally in a single location. The security considerations attempt to defer substantially to the threat-analysis in RFC 7835, which does not really seem like a complete threat analysis and does not provide analysis as to what requirements are placed on the boundaries between the different components of LISP (data plane, control plane, mapping system, various extensions, etc.). The secdir reviewer had some good thoughts in this space. [We're getting closer to something that's possible to properly analyze, but I haven't done that analysis yet] ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I note as a preface that in many places in this (and other) review, I ask questions. The ones that indicate I actually don't understand are generally accompanied by text like "just to confirm" or provide some option for possible interpretation. Others are intended as rhetorical devices, indicating that the text locally at this point in the document is unclear and the question posed should be addressed in the document, in-line. Section 1 LISP encapsulation uses a dynamic form of tunneling where no static provisioning is required or necessary. Do I interpret this correctly as meaning that no static provisioning is necessary on end-hosts? It seems that ETRs and the mapping system entities definitely need static configuration. But do end sites need to know what lisp site/administrative domain they are part of? LISP is an overlay protocol that separates control from Data-Plane, this document specifies the Data-Plane, how LISP-capable routers (Tunnel Routers) exchange packets by encapsulating them to the appropriate location. [...] nit: this is a comma splice Section 3 Anycast Address: Anycast Address is a term used in this document to How does this definition differ from the one in RFC 8499? Data-Probe: A Data-Probe is a LISP-encapsulated data packet where the inner-header destination address equals the outer-header destination address used to trigger a Map-Reply by a decapsulating ETR. [...] nit: is this better as two sentences? ("...is a LISP-encapsulated data packet where the inner-header destination address equals the outer-header destination address. It is used to trigger...") I would also say something in this paragraph about how this behavior blurs the distinction between EID and RLOC. When using Data-Probes, by sending Map-Requests on the underlying routing system, EID-Prefixes must be advertised. I don't understand why the one follows from the other (in fact, there seem to be three not-particularly-related concepts in this sentence). (I also note that "Data-Probe" is not mentioned anywhere in this document other than its own definition, which would suggest that it could be moved to 6833bis, which does mention them.) EID-to-RLOC Database: The EID-to-RLOC Database is a global distributed database that contains all known EID-Prefix-to-RLOC I thought we had agreed to remove this "global distributed database" language. addresses that are routable on the underlay. 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. nit: we haven't indicated a definite site for "the site" to be meaningful. EID-to-RLOC Map-Cache: The EID-to-RLOC Map-Cache is generally short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID- to-RLOC mappings; it is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more global in scope to LISP nodes. "global" caught my eye again here; perhaps "global in scope to a LISP deployment"? EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are allocated to a site by an address allocation authority. EID- Prefixes are associated with a set of RLOC addresses. EID-Prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the larger EID-Prefix block. nit: I think the causality here is backwards -- the breaking up does not occur at the moment that you associate an RLOC set to a larger EID-Prefix block. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. [...] 6833bis says (section 5.8) that the inner header can use either RLOC or EID addresses in the header address fields, which contradicts this statement. 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 Er, that the ISP ITR uses as source or as destination? 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, one with an encoded Locator 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 database. There are a set of well-defined actions that are encoded in a Negative Map-Reply. This bit about Negative Map-Replys comes out of the blue; is it really needed in this paragraph? TE-ETR: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. nit: is it really the act of stripping the header that is done for TE purposes? Also in Section 3 (moved from Discuss, since probably editorial): Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. [...] 6833bis says (section 5.8) that the inner header can use either RLOC or EID addresses in the header address fields, which contradicts this statement. Section 4.1 2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [I-D.ietf-lisp-rfc6833bis] for further information. 3. The ITR sends a LISP Map-Request as specified in [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited. At risk of repeating myself, isn't (3) just doing what (2) says the ITR must be able to do? I don't see why both items are needed. 5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- RLOC mapping database. This is the list of EID-Prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is Isn't this (1) something that 6833bis should be authoritative on, and (2) a recipe for random hangs if the mapping system ever misdirects a map-request? 7. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the The use of "subsequent" implies that he original IP packet does not receive this treatment. But we don't say anywhere that it gets dropped, leaving us guessing as to what is supposed to happen to it. 9. In order to defer the need for a mapping lookup in the reverse direction, an ETR can OPTIONALLY create a cache entry that maps the source EID (inner-header source IP address) to the source RLOC (outer-header source IP address) in a received LISP packet. Such a cache entry is termed a "glean mapping" and only contains This gleaming seems susceptible to spoofing. Section 5.3 L: The L-bit is the 'Locator-Status-Bits' field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32 bits of the LISP header are in use. What happens to those bits when the L-bit is set to zero? E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored and has no meaning when the N-bit is set to 0. When the N-bit is set to 1 and this bit is set to 1, an ITR is requesting that the Do we need to say what to do when N is 1 and E is 0? LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the [...] 'Locator-Status-Bits' field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator-Status-Bits are numbered from 0 to n-1 from the least significant bit of the field. The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a I guess maybe clarifying that LSB 0 is the last bit in the field is worthwhile? Ah, we have an example down in Section 10. the ETRs at the same site. When a site has multiple EID-Prefixes that result in multiple mappings (where each could have a different Locator-Set), the Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches. If the LSB for I don't think there is guaranteed to be a single unique EID-Prefix that matches the inner source EID; we need to say longest-match here. When doing ETR/PETR decapsulation: o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) MUST be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is 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. I'm not sure how to do this check when doing initial encapsulation; there's no outer header then. o The outer-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. IPv6 is a first-class IP protocol; it should not be relegated to a parenthetical. (This shows up in several places.) Note that if an ETR/PETR is also an ITR/PITR and chooses to re- encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1. Where is the decrementing of the TTL documented? I just see "copy" in the above text. Is the last paragraph adding anything that was not already said previously? It seems pretty redundant on first read. Section 6 The Map-Cache is a local cache of mappings, entries are expired based on the associated Time to live. In addition, entries can be updated nit: comma splice. Finally, the Map-Cache also contains reachability information about EIDs and RLOCs, and uses LISP reachability information mechanisms to determine the reachability of RLOCs, see Section 10 for the specific mechanisms. nit: The Map-Cache performs reachability discovery? That seems incongruous with a cache nature; perhaps it is better to say that it is updated with the results of such procedures. Section 7.1 Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR. Why would an ETR want to take on this additional state-keeping burden instead of relegating it to the end host? When the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L and send an ICMPv4 ICMP Which size? Section 8 There are several cases where segregation is needed at the EID level. For instance, this is the case for deployments containing overlapping addresses, traffic isolation policies or multi-tenant virtualization. (Note that earlier we state that EIDs must be unique...) Section 9 o Either side (more likely the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the [in the next paragraph we talk about sending Map-Requests to verify gleamed mappings, which doesn't mesh very well with "does not send Map-Requests" here] client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner-header source EID and the outer-header source RLOC of received packets. [...] Isn't this susceptible to spoofing? Instead of using the Map-Cache or mapping system, RLOC information MAY be gleaned from received tunneled packets or Map-Request messages. A "gleaned" Map-Cache entry, one learned from the source To double-check, this is describing the same behavior described in the iast bullet point? 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. A reply to this As I commented on 6833bis, I'd appreciate mention that this "verification" is akin to reverse-routability verification and does not involve any cryptographic assurances. This "gleaning" mechanism is OPTIONAL, refer to Section 16 for security issues regarding this mechanism. nit: comma splice Section 10 1. An ETR MAY examine the Locator-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is 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. Maybe note that this only conveys "up" information, which is necessary but not sufficient for reachability. 2. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely to be reachable. Liktely to, but not guaranteed, since that's a spoofable field and we rely on the ITR to fill it with something useful. When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. [...] This ("up-to-date") wording concerns me, relating to the interaction between map-versioning, addition/removal of locators from a mapping, and propagation to values in the LSBs. I do not think there is currently a strong consistency guarantee in place that would justify the "up-to-date" wording, and 6834bis has not received IETF (or IESG) review yet. My current understanding is that the status information provided via this mechanism could be characterized as "best-effort" or "accurate in the steady-state". The security considerations of Section 16 related with data-plane reachability applies to the data-plane RLOC reachability mechanisms nit: I think this is "related to", not "related with". Section 10.1 When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR is an xTR (co-located as an ITR), it next sends a data packet to the ITR (when it is an xTR co-located nit: I don't think this is grammatical; maybe "when it next sends"? Some side discussion: in some sense, the echo nonce functionality is the most reliable method for determining reachability, and yet we say that it MAY be overridden by other methods. There's also some potential conflict between the "will set the E-bit and N-bit for every packet it sends while in the echo-nonce-request state" and the later text about echoing the peer's nonce when both ETR and ITR go into the echo-nonce-request state at the same time. 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. Is this only in RLOC-probe Map-Reply messages (and not generic, including mapping-driven, Map-Reply messages)? If so, I think that 6833bis needs some clarification in Section 5.4. (If not, I think that "RLOC-probe" should be removed from here.) Section 13 ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing Locator-Set. (It might be apropos to explicitly remind the reader that the entries in the locator-set are sorted by IP address.) 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 Why will the xTRs set the Locator-Status-Bit to 0? Won't they just use the updated mapping and have a smaller number of LSBs in their data packets? If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the Locator-Set and new records appended to the Locator-Set. At some point, it would be How can this happen when the Locator-Set is required to be sorted? Or does the sorting requirement not apply to the "Map-Reply Record" field of the Map-Request? Section 13.1 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. This seems vastly underspecified not just to the detailed semantics (for which the 6834bis reference is probably a suitable replacement) but also the goals of the synchronization that is to be obtained. It's unclear to me that it's appropriate to mention Map-Register and versions at all in this document; instead we might just note that 6834bs provides for version synchronization for the ETRs within a site. (If that's what it does; I haven't yet read it in detail.) Section 14 Just like it would if the destination EID was a unicast address. nit: this is a sentence fragment; I suggest joining to the previous sentence with a comma. 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 Isn't the outer destination address an RLOC? How do EIDs come into play? Section 20.2 Maybe throw us a bone and include the string "draft-iannone-openlisp-implementation" in the [OPENLISP] entry? From nobody Thu Aug 15 09:35:20 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A3C1200CC for ; Thu, 15 Aug 2019 09:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 XvVJ-yQqqsRz for ; Thu, 15 Aug 2019 09:35:15 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 2C59F1200BA for ; Thu, 15 Aug 2019 09:35:15 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id n4so1529995pgv.2 for ; Thu, 15 Aug 2019 09:35:15 -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=C7E2q8AW4oYcA9VtfUxVoY2JQ8yOi4saB+V+b56kcwk=; b=C/oqoKgr003bmyS6Fn1y9WyiZdOgDbim/NiWol82WHVR/MzDBKGjKZ//Hd2FcaAvzr uLFDbBYXqHp6ECVI3ElmaM4z1RST9G6UGbh0sDZh0TSrgTqfscOj3ljk72vlwJSD8R32 UmbRb22o3rkdrP9L0EdH35URTGuPxTJT+zWUi71JEayYx7SLw+VFrMX2Yk59n8AyjkQw eH2iFNxwR8SWznyN2W9A+Ik4wUHqKrl7SWjLMBeSd8fgrB7ttSE7Et2KyM1GWuvMjN0C 9pweYK6wA+AXRPIksVcivVkvKFnrWK9L+P/lV1mAnsONR6LzIl6xHV0EqmYvqaTQbvVO 5skA== 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=C7E2q8AW4oYcA9VtfUxVoY2JQ8yOi4saB+V+b56kcwk=; b=b1XdrpnvUMY4wewa2mUWi50GsSNeuF9I3g5uAzGttZKWYHKHXjJBt7lkUGj5sQmqlm 5NKPUqcYlgtS5EKHAt/QDl1155b6G5yxJcMvDZA5XbnjHUIqqsec/y5X9e7BHA5pkUJq TEfCrcsu/XM9Q/wo0Bi/TLNsgHHXU9k77BrbyO1uBwusFRDDrcow/b842oHqVApGCUns HL5fT607HZ2l8Rf/GQBUTr86UiBPYk5Yr0MjvoXfukAXZaSJl6VjYtWe1Ub8CoKGx3Es LboZdZxRumbVgtHM6/3HpTEHBs0vGSPtGseVGH3iVis5vHNaij7bD6YYENlDL9Z2557P pumQ== X-Gm-Message-State: APjAAAUdUzHtYejsCieG5eIUwYaHIy44kXk93TyvPx6Z0rL+cyTkl5BN rJdfeS+lVSYA3KRY9nip6x0= X-Google-Smtp-Source: APXvYqyLll4HLsCtH4UnKzCphvqgRRJ31TtGP8bq/pGxnVt8dJryhlRLqvaQhvFl+mleAAUbDNWBEg== X-Received: by 2002:a63:6686:: with SMTP id a128mr4095896pgc.361.1565886914574; Thu, 15 Aug 2019 09:35:14 -0700 (PDT) Received: from [10.97.50.148] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id k6sm3234025pfi.12.2019.08.15.09.35.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Aug 2019 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: Thu, 15 Aug 2019 09:35:12 -0700 Cc: Jmh , Ggx , Db3546 , Padma Pillay-Esnault , Sharon Barkai , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <369E4986-97E4-496C-8D7E-85E43AB20E7B@gmail.com> References: To: RIPE NCC Support X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] #202067 - LISP EID assignments from 2001:5::/32 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, 15 Aug 2019 16:35:19 -0000 I am cc=E2=80=99ing the LISP WG which you did not have on your To: list = orignally. Dino > On Aug 15, 2019, at 4:42 AM, RIPE NCC Support = wrote: >=20 > ##- Please type your reply above this line -## > You are registered as a CC on this ticket (202067). Reply to this = email to add a comment to the request. >=20 >=20 > Mike Petrusha (RIPE NCC Support)=20 > Aug 15, 13:42 CEST >=20 > Dear LISP WG, >=20 > The RIPE NCC received no formal reply from the IETF. > Considering this and also based on the recent emails exchanged in the = LISP WG on this topic, we understand that no formal decision was made as = mentioned in RFC 7954: LISP EID Block >=20 > " By the end of the first period, the IETF will provide a decision on > whether to transform the prefix into a permanent assignment or to = put > it back in the free pool" > Therefore, it is our current understanding that we need to act in = accordance with https://tools.ietf.org/html/rfc7954#section-7 > " If no explicit action is carried out by the end of the experiment = (by > September 2019), it is automatically considered that there was not > sufficient interest in having a permanent allocation; therefore, = the > address block will be returned to the free pool." > and also based on RFC 7955, https://tools.ietf.org/html/rfc7955 > "According to the 3+3 year experimentation plan, defined in > [RFC 7954], all registrations MUST end by August 2019, unless > the IETF community decides to grant a permanent LISP EID > address block." > the RIPE NCC will complete de-registration of four existing LISP EID = assignments within 2001:5::/32 in August 2019 and will then return = 2001:5::/32 to the IANA in September 2019. >=20 > -- > Mike Petrusha > RIPE NCC >=20 >=20 >=20 > Mike Petrusha (RIPE NCC Support)=20 > Aug 1, 14:16 CEST >=20 > Dear Colleagues, >=20 > We await your reply with regards to 2001:5::/32 LISP EID prefix > -- > Sincerely, >=20 > Mike Petrusha > RIPE NCC >=20 >=20 >=20 > Mike Petrusha (RIPE NCC Support)=20 > Jul 30, 09:34 CEST >=20 > Dear LISP WG, >=20 > This e-mail is from the RIPE NCC, the Internet Registry in Europe. >=20 > The RIPE NCC provides temporary LISP EID assignments from LISP EID = prefix 2001:5::/32 in accordance with RFC 7955: LISP EID Block = Management, https://tools.ietf.org/html/rfc7955 >=20 > We are contacting you as we are approaching August 2019, at which = point we need to start removing existing LISP EID assignments within = 2001:5::/32 (unless IETF made a decision to extend this period). >=20 > Following RFC 7955, https://tools.ietf.org/html/rfc7955 > "According to the 3+3 year experimentation plan, defined in > [RFC 7954], all registrations MUST end by August 2019, unless > the IETF community decides to grant a permanent LISP EID > address block." >=20 > In accordance with RFC 7954: LISP EID Block > https://tools.ietf.org/html/rfc7954#section-6 > " IANA allocated the requested address space in September 2016 for a > duration of 3 (three) years (through September 2019), with an = option > to extend this period by 3 (three) more years (until September = 2022). > By the end of the first period, the IETF will provide a decision on > whether to transform the prefix into a permanent assignment or to = put > it back in the free pool..." >=20 > Could you please let us know whether such decision was made by the = IETF? >=20 >=20 > According to https://tools.ietf.org/html/rfc7954#section-7 > " In order to trigger the process for a permanent allocation, a > document is required. Such a document has to articulate the > rationale for why a permanent allocation would be beneficial. More > specifically, the document has to detail the experience gained = during > experimentation and all of the technical benefits provided by the = use > of a LISP-specific prefix. " >=20 > Could you please let us know if such document was created? >=20 >=20 > According to https://tools.ietf.org/html/rfc7954#section-7 > " If no explicit action is carried out by the end of the experiment = (by > September 2019), it is automatically considered that there was not > sufficient interest in having a permanent allocation; therefore, = the > address block will be returned to the free pool." >=20 > Based on this, the RIPE NCC is ready to proceed with removing existing = LISP EID assignments within 2001:5::/32 in August 2019 (as defined by = RFC 7955) and returning 2001:5::/32 to the IANA in September 2019 (as = defined by RFC 7954). >=20 > We await your reply. >=20 > -- > Sincerely, >=20 > Mike Petrusha > RIPE NCC >=20 >=20 > This email is a service from RIPE NCC Support. > [R5DPD5-K8OP] From nobody Fri Aug 16 18:24:22 2019 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 9EA4812008B; Fri, 16 Aug 2019 18:24:13 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <156600505355.5349.5116002398079899114@ietfa.amsl.com> Date: Fri, 16 Aug 2019 18:24:13 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-6834bis-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: Sat, 17 Aug 2019 01:24:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : Locator/ID Separation Protocol (LISP) Map-Versioning Authors : Luigi Iannone Damien Saucez Olivier Bonaventure Filename : draft-ietf-lisp-6834bis-04.txt Pages : 19 Date : 2019-08-16 Abstract: This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism. This document obsoletes RFC 6834 "Locator/ID Separation Protocol (LISP) Map-Versioning", which is the initial experimental specifications of the mechanisms updated by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-6834bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-6834bis-04 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-6834bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-6834bis-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 Aug 20 11:30:16 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338FA12018D; Tue, 20 Aug 2019 11:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 header.b=BZESNRc5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lKi/XsWo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFd4ApLam99h; Tue, 20 Aug 2019 11:30:11 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1990A12011C; Tue, 20 Aug 2019 11:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8048; q=dns/txt; s=iport; t=1566325811; x=1567535411; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1P/aJy0HcERVvNaZEmdLzH0CKnkSCHUi5AuZXQDaovk=; b=BZESNRc5Fp5txFD0SlF6WT6Csa8Z/yXuECp9Kh1qdwYLPog7+8GrkCHL 7aBLqaHEWp/mYEhxRBcaanBq6Ks1dC5Lo0gCote5neXzmT3c9pbTzCypt a3Vr1Gd4gNZO9yl0dJBd0KLOnDbxr8xNge+zLtD6wIKwm7yLtPo5gROaY c=; IronPort-PHdr: =?us-ascii?q?9a23=3ALJ8ZBh+JMbmaU/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVciMFUT/BPXrdCc9Ws9FUQwt8g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAACnO1xd/5NdJa1dCRoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVUDAQEBAQsBgURQA21VIAQLKoQfg0cDinyCN4EjlmeBLoE?= =?us-ascii?q?kA1QJAQEBDAEBHw4CAQGEPwIXgj4jNgcOAgUBAQQBAQECAQYEbYUnDIVLAgE?= =?us-ascii?q?DEhERDAEBJRIBDwIBCA4MAiYCAgIwFRACBAENBSKDAAGBagMdAQKhGgKBOIh?= =?us-ascii?q?hc4EygnsBAQWFCRiCFAmBDCgBiiWBQxiBf4ERJwwTghc1PoQQCgMRFoMLMoI?= =?us-ascii?q?EIo8XhTKWI20JAoIdhmiJXIN1G4IxhzCOZY1bgTaGLZArAgQCBAUCDgEBBYF?= =?us-ascii?q?WATGBWHAVOyoBgkEJgjkMF4NPilNygSmLQgIkB4IlAQE?= X-IronPort-AV: E=Sophos;i="5.64,408,1559520000"; d="scan'208";a="310687535" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Aug 2019 18:30:08 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x7KIU5wW015050 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Aug 2019 18:30:07 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 20 Aug 2019 13:30:03 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 20 Aug 2019 13:30:03 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 20 Aug 2019 14:30:03 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NZKBvm6qnsXJD99qEGvmTtHFrk9dj0BTcPnigqWQ8LQnjhwyqkKdNz+wDR0caVyfShXese47MBJvBZbc5jvubn9FBCh2clsRomKrHThaodgvzjmmiNnQo8qXaPR/K3aksVmjIwiZTaxvIUgD4Bu+BupwLQdSgcuLMhNOar09EM96xZ4fF1/vUp6+OkSq/EX8dYIL5zwfZQK+pds6WC0ZVQDvMLIKG3aV8VtozROKU8mV03pSFsV69YhaXxzQGsXgJQQhalCW50OSqi0WYuhLrctHXC6k1NUtG5ncy6BnkuNmN7RERq9zi2kEhHiaJIL4pLncnC+aL1d9Ic/8gbHLiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1P/aJy0HcERVvNaZEmdLzH0CKnkSCHUi5AuZXQDaovk=; b=X7qjJUyeocKeip6pqrahqwija96wT4+DVbIaCSUgw22jHHGF7qQI1ckInYH+7Dk9DUX/gJCLWDFKOWNYAK044VYfI1trB9SD8I4WePuxQbi7LD4XRc2MnSxrlym5B3AFlRuUDUYQSsofa04lGJ3iUHXb4gUw5bnOTHPg0ilS7TOcAKsTreos3fzdwxVIonQ5K+l/4sB9ZTG7WHLbTZ/pUhJORHetvcJ1ibvEihyGRgH5CwqYNjjE1q6iD/Vvey//Hm6cX1QqZeDc5QS14h8V7ltNlTBLC0h21O3amTJ0CodEhNmVxgDNM1P5RJ2OdermN5Vwjl27C7VV7l+deaVIFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1P/aJy0HcERVvNaZEmdLzH0CKnkSCHUi5AuZXQDaovk=; b=lKi/XsWo1lPnLbSW4w4UumT8rXe8VYiAQWRASRZyY/sorzKCWECi+vWecX1JaCQgqm7HEN479cBNgFxFC/fnHRixkBMCkkOi5zeIhKAF+ubrn+h1oiGpM/pFKHWFUEy1s9cVr5XHXiSB9Y4NQmz96tITPegSDkT6yMfd134vUPs= Received: from BYAPR11MB3014.namprd11.prod.outlook.com (20.177.225.13) by BYAPR11MB3207.namprd11.prod.outlook.com (20.177.127.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Tue, 20 Aug 2019 18:30:00 +0000 Received: from BYAPR11MB3014.namprd11.prod.outlook.com ([fe80::59ae:773d:d7b0:9ca]) by BYAPR11MB3014.namprd11.prod.outlook.com ([fe80::59ae:773d:d7b0:9ca%7]) with mapi id 15.20.2178.018; Tue, 20 Aug 2019 18:30:00 +0000 From: "Alberto Rodriguez Natal (natal)" To: Christian Hopps , "yang-doctors@ietf.org" CC: "lisp@ietf.org" , "draft-ietf-lisp-yang.all@ietf.org" Thread-Topic: Yangdoctors early review of draft-ietf-lisp-yang-11 Thread-Index: AQHVQ1Nu85KNK2Kykkek9GiFQm7DE6cEDo0A Date: Tue, 20 Aug 2019 18:30:00 +0000 Message-ID: <69983428-3A0C-4DAB-857E-75586DCE27D0@cisco.com> References: <156410535896.17429.16464147399003551309@ietfa.amsl.com> In-Reply-To: <156410535896.17429.16464147399003551309@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 authentication-results: spf=none (sender IP is ) smtp.mailfrom=natal@cisco.com; x-originating-ip: [2001:420:301:1310:a410:cab3:320c:8b02] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 82367bd7-68cb-4313-0cd3-08d7259c6956 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3207; x-ms-traffictypediagnostic: BYAPR11MB3207: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 013568035E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(366004)(39860400002)(136003)(51914003)(199004)(189003)(6306002)(6506007)(8676002)(229853002)(81166006)(71190400001)(6436002)(6486002)(6512007)(486006)(8936002)(256004)(186003)(14444005)(71200400001)(86362001)(11346002)(476003)(2616005)(64756008)(66446008)(36756003)(305945005)(66946007)(46003)(446003)(76116006)(66476007)(66556008)(7736002)(2906002)(99286004)(6116002)(76176011)(81156014)(53936002)(33656002)(102836004)(54906003)(14454004)(25786009)(478600001)(58126008)(4326008)(2501003)(110136005)(6246003)(316002)(5660300002)(53376002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3207; H:BYAPR11MB3014.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: fRneVnT9Zb5yJKs81cz1PsMSVpeTXnCiMuX9jfydSLHwOMoj6DBqKds4Gztb0mh/x1dU/GSTvYq2WfluJ2ojBADNlF7WLoU8xTaTXBOg4eMUwie3jOv4qdqTivORkk2fNXCAE0gH/mF+ZKwtP/RcW1gEXrtDs5nEEjHvWk3P4ShS/VeG4pvI8LI57/AHkAxzp4jqh/g7JShwY/y8EvF4qsGb8nixFKvIMd1qQGUGBE/e/nPRXOi2bbGwT+/kRO+jppiakWloyua82cTHOhpZuLu2+T53OU0muCZsezJS3XaJ/vDk2ovME+Fwv9xSaR9WwEJwm32gzVz71VDOBRpp8/MH+jOZ2zmlhf1hITj8P4rPHJ4A8qRryrw9J8/tt7ukcRRgpHIxQw6kUEj+2kQyTb9l5q1PmJYJ//x06Xp1XwE= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 82367bd7-68cb-4313-0cd3-08d7259c6956 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2019 18:30:00.7429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Q/YmDPTAqWQfRJFV2s+8z38XYV8hrPebMViUId3BvBWI5mcW7wWneT8YtQLFmFqu X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3207 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [lisp] Yangdoctors early review of draft-ietf-lisp-yang-11 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, 20 Aug 2019 18:30:14 -0000 Q2hyaXMsIA0KDQpUaGFua3MgYSBsb3QgZm9yIHRoZSByZXZpZXcgYW5kIGFwb2xvZ2llcyBmb3Ig dGhlIGRlbGF5ZWQgcmVzcG9uc2UuIFdlIHdlbnQgdGhyb3VnaCB5b3VyIGNvbW1lbnRzIGFuZCB0 aGV5IG1ha2UgZ29vZCBzZW5zZSB0byB1cy4gUGxlYXNlIHNlZSBpbmxpbmUgZm9yIHNvbWUgcmVw bGllcyBmcm9tIG91ciBlbmQuDQoNClRoYW5rcywNCkFsYmVydG8NCg0K77u/T24gNy8yNS8xOSwg Njo0MiBQTSwgIkNocmlzdGlhbiBIb3BwcyB2aWEgRGF0YXRyYWNrZXIiIDxub3JlcGx5QGlldGYu b3JnPiB3cm90ZToNCg0KICAgIFJldmlld2VyOiBDaHJpc3RpYW4gSG9wcHMNCiAgICBSZXZpZXcg cmVzdWx0OiBPbiB0aGUgUmlnaHQgVHJhY2sNCiAgICANCiAgICANCiAgICAqIGRyYWZ0LWlldGYt bGlzcC15YW5nLTExIGVhcmx5IHlhbmctZG9jdG9yIHJldmlldy4NCiAgICANCiAgICAqKiBNaW5v cg0KICAgIA0KICAgICAgIC0gRW51bWVyYXRpb25zIGFyZSBub3QgZXh0ZW5zaWJsZSBhbmQgc28g c2hvdWxkIG9ubHkgYmUgdXNlZCB3aGVuIGFsbCB0aGUNCiAgICAgICAgIHZhbHVlcyBhcmUga25v d24gYW5kIHdpbGwgbm90IG5lZWQgdG8gYmUgYWRkZWQgdG8uIFNvLCBhdXRoLWFsZ29yaXRobS10 eXBlDQogICAgICAgICBzaG91bGQgdXNlIGlkZW50aXRpZXMgYW5kIG5vdCBhbiBlbnVtZXJhdGlv biwgYXMgaXQgYWxtb3N0IGZvciBzdXJlIHdpbGwNCiAgICAgICAgIG5lZWQgdG8gYmUgYWRkZWQg dG8gaW4gdGhlIGZ1dHVyZS4gQW4gZXhhbXBsZSBvZiB0aGlzIGlzIHByZXNlbnQgaW4gUkZDODE3 Nw0KICAgICAgICAgKGtleWNoYWlucykgd2hpY2ggaGFzIGlkZW50aXRpZXMgZGVyaXZlZCBmcm9t IGEgYmFzZSBpZGVudGl0eQ0KICAgICAgICAgImNyeXB0by1hbGdvcml0aG0iLg0KDQpbQVJdIEFn cmVlZCwgd2Ugd2lsbCB1cGRhdGUuDQoNCiAgICAgICAtICJ0eXBlIHN0cmluZyIgaXMgYSB2ZXJ5 IGluY2x1c2l2ZSBVVEYtOCBzdHJpbmcsIGFsb25nIHdpdGggYWxsIGxlZ2FsIFVURi04DQogICAg ICAgICBjaGFyYWN0ZXJzIGl0IGluY2x1ZGVzIHRhYnMsIHNwYWNlcywgbmV3bGluZXMgYW5kIGNh cnJpYWdlIHJldHVybnMuIFRoaXMNCiAgICAgICAgIG1heSBub3QgYmUgd2hhdCB5b3UgYWN0dWFs bHkgd2FudCBmb3IgdGhpbmdzIGxpa2UgImVpZC1pZCJzIG9yDQogICAgICAgICAiYXV0aC1rZXkt aWQiLiBZb3UgcHJvYmFibHkgd2FudCB0byB1c2UgYSBtb3JlIHJlc3RyaWN0ZWQgdHlwZWRlZiB2 YXJpYXRpb24NCiAgICAgICAgIG9mIHN0cmluZyAodXNpbmcgYSBwYXR0ZXJuIHRvIHJlc3RyaWN0 IGl0cyB2YWx1ZXMpLg0KICAgIA0KW0FSXSBHb29kIHBvaW50LCB3ZeKAmWxsIG1ha2UgdGhpcyBt b3JlIHJlc3RyaWN0aXZlLg0KDQogICAgICAgLSBOb2RlIG5hbWUgY29uc2lzdGVuY3ksIHlvdSBw cm9iYWJseSBzaG91bGQgYmUgY29uc2lzdGVudCB3aXRoIHRoZSBuYW1lIGZvcg0KICAgICAgICAg bm9kZXMgb2YgdGhlIHNhbWUgdHlwZS4gRm9yIGV4YW1wbGUgdHlwZSAiZWlkLWlkIiwgc29tZXRp bWVzIHRoZSBuYW1lIGlzDQogICAgICAgICAiaWQiIG90aGVyIHRpbWVzICJlaWQtaWQiIGlzIHVz ZWQuDQogICAgDQpbQVJdIEdvb2QgY2F0Y2gsIHdl4oCZbGwgdXBkYXRlLg0KDQogICAgICAgLSBU VEwgaXMgbGltaXRlZCB0byBtaW51dGUgdW5pdHMuIFRoaXMgbWF5IGJlIG92ZXJseSByZXN0cmlj dGl2ZS4gQ291bGRuJ3QNCiAgICAgICAgIHRoZXJlIGJlIHNvbWUgdXNlIChwZXJoYXBzIG5vdCBj b21tb24pIGUuZy4sIHBlcmhhcHMgd2hlbiBkZWJ1Z2dpbmcsIG9yIGluDQogICAgICAgICBmdXR1 cmUgdmVyc2lvbnMgb2YgdGhlIHByb3RvY29sIHdoZXJlIHNlY29uZHMgZ3JhbnVsYXJpdHkgbWln aHQgYmUgdXNlZnVsPw0KICAgICAgICAgQ2hhbmdpbmcgdGhlc2Ugbm9kZXMgbGF0ZXIgaXMgbm9u LWJhY2t3YXJkcyBjb21wYXRpYmxlIGFuZCB0aHVzIHZlcnkNCiAgICAgICAgIHBhaW5mdWwgdG8g ZG8uDQogICAgDQpbQVJdIFRoYXQncyBhIGZhaXIgY29tbWVudC4gV2UgdXNlZCBtaW51dGVzIGlu IHRoZSBtb2RlbCwgaG93ZXZlciwgc2luY2UgUkZDNjgzM2JpcyBkZWZpbmVzIHRoZSBUVExzIGlu IG1pbnV0ZXMuIERvIHlvdSB0aGluayBpdCB3b3VsZCBiZSByZWFzb25hYmxlIHRvIGxlYXZlIHRo ZSBUVEwgaW4gbWludXRlcyBhbmQgYWxpZ25lZCB3aXRoIDY4MzNiaXM/IA0KDQogICAgKiogZ2Vv IGNvb3JkaW5hdGVzDQogICAgDQogICAgICAgLSBJdCBtaWdodCBiZSB3b3J0aCBjb25zaWRlcmlu ZyB1c2luZyB0aGUgZ3JvdXBpbmcgaW4gdGhlIGdlby1sb2NhdGlvbiBtb2R1bGUNCiAgICAgICAg IGZvciBzcGVjaWZ5aW5nIGNvb3JkaW5hdGVzLiBUaGUgb25seSBkcmF3YmFjayBoZXJlIHdvdWxk IGJlIGlmIGdlby1sb2NhdGlvbg0KICAgICAgICAgY2F1c2VzIHRoZSBwdWJsaWNhdGlvbiB0byBi ZSBkZWxheWVkIGIvYyBsaXNwLXlhbmcgZmluaXNoZXMgZmlyc3QuIEluIGFueQ0KICAgICAgICAg Y2FzZSB0aGUgZGVzY3JpcHRpb24gZm9yIHRoZSBjb29yZGluYXRlIG5vZGVzIHNob3VsZCBlY2hv IG1vcmUgb2YgdGhlIGluZm8gZnJvbQ0KICAgICAgICAgdGhlIExDQUYgUkZDLCBpbiBwYXJ0aWN1 bGFyIHRoYXQgdGhlIGNvb3JkaW5hdGUgc3lzdGVtIHVzZWQgaXMgV0dTLTg0KS4NCiAgICANCltB Ul0gVGhhbmtzIGZvciBwb2ludGluZyB1cyB0byB0aGUgZ2VvLWxvY2F0aW9uIG1vZHVsZS4gQWZ0 ZXIgc29tZSBkaXNjdXNzaW9uIG9uIHRoaXMsIHdlIGJlbGlldmUgd2UgcHJlZmVyIHRvIGZvbGxv dyAoaWYgeW91IHRoaW5rIGl0J3Mgb2spIHRoZSBmb3JtYXQgb24gUkZDODA2MCBzaW5jZSBhbnkg b3RoZXIgZm9ybWF0IHdvdWxkIG5lZWQgdG8gbWFwIHRvIDgwNjAuIFdlIHdvdWxkIGRlZmluaXRl bHkgdXBkYXRlIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgbm9kZXMgdG8gcmVmbGVjdCBtb3JlIGlu Zm8gZnJvbSA4MDYwIGFzIHlvdSBzdWdnZXN0ZWQuDQoNCiAgICAgICAtIEkgZm91bmQgYSBsaXNw IGdlbyBkcmFmdCBhbmQgaXQgc2VlbXMgdG8gc3BlY2lmeSBhIGJpdCBtb3JlIGRldGFpbCB0aGFu IGlzDQogICAgICAgICBjb3ZlcmVkIGluIHRoaXMgbW9kdWxlIChlLmcuLCB0aGUga2lsb21ldGVy IGJpdCwgcmFkaXVzLCB1bmNlcnRhaW50eSkuIE5vdA0KICAgICAgICAgc3VyZSBpZiB0aGF0IHdv dWxkIGJlIGFwcHJvcHJpYXRlIHRvIGFkZCBvciBub3QuDQogICAgDQpbQVJdIFdlIHByb2JhYmx5 IHdhbnQgdG8gZm9sbG93IFJGQyA4MDYwIGhlcmUgYXMgd2VsbC4NCg0KICAgICoqIE5pdHMNCiAg ICANCiAgICAgIC0gSW52YWxpZCBleGFtcGxlIFhNTCBmb3IgTElTUCBNYXAtU2VydmVyLi4gVGhl IGNvbmZpZyBuYW1lc3BhY2Ugc2hvdWxkIG5vdCBiZQ0KICAgICAgICAiaHR0cDovL3RhaWwtZi5j b20vbnMvY29uZmlnLzEuMCIuDQogICAgDQpbQVJdIFllcywgYWdyZWVkLg0KDQogICAgICAtIENv cnJlY3QgbW9kdWxlIHZzIG1vZGVsIGxhbmd1YWdlLg0KICAgICAgICAtIE9MRDogPHQ+VGhpcyBt b2R1bGUgaXMgdGhlIGJhc2UgTElTUCBtb2R1bGUgdGhhdCBpcyBhdWdtZW50ZWQgaW4gbXVsdGlw bGUNCiAgICAgICAgbW9kZWxzIHRvIHJlcHJlc2VudCB2YXJpb3VzIExJU1AgZGV2aWNlIHJvbGVz LjwvdD4NCiAgICAgICAgLSBORVc6IDx0PlRoaXMgaXMgdGhlIGJhc2UgTElTUCBtb2R1bGUuICBJ dCBpcyBmdXJ0aGVyIGF1Z21lbnRlZCBieSB0aGUNCiAgICAgICAgTElTUCBkZXZpY2Ugcm9sZSBz cGVjaWZpYyBtb2R1bGVzIGRlZmluZWQgZWxzZXdoZXJlIGluIHRoaXMgZG9jdW1lbnQuPC90Pg0K ICAgIA0KW0FSXSBZZXMsIGFncmVlZC4NCg0KICAgICAgLSBZYW5nIGNvbW1lbnRzIG5lZWQgc29t ZSBncmFtbWFyIGZpeGVzLg0KICAgICAgICAtIGUuZy4sICdUaGlzIGF1Z21lbnRzICp0aGUqIExJ U1AgZGVjaWNlcyBsaXN0IC4uLicNCiAgICANCltBUl0gQWdyZWVkLCB3aWxsIGZpeC4NCg0KICAg ICAgLSBJIGdvdCBzb21lIHdhcm5pbmcgZnJvbSB2YWxpZGF0aW9uIHRvb2xzLCBidXQgSSdtIG5v dCBzdXJlIGlmIHRoZXkgYXJlDQogICAgICAgdmFsaWQsIHBsZWFzZSBkb3VibGUgY2hlY2sgdGhv dWdoLg0KICAgIA0KW0FSXSBUaGFua3MgZm9yIHRoZSBoZWFkcyB1cCwgd2Ugd2lsbCBjaGVjayBh bmQgZml4IHRob3NlLg0KDQogICAgICAgIC0gUHlhbmcgbml0czoNCiAgICAgICAgICAjK2JlZ2lu X3NyYyBiYXNoDQogICAgICAgICAgICBmb3IgZiBpbiAqLnlhbmc7IGRvIGVjaG8gJGY7IFwNCiAg ICAgICAgICAgIHB5YW5nIC0taWV0ZiAtLW1heC1saW5lLWxlbmd0aCA2OSAkZiA7IFwNCiAgICAg ICAgICAgIGRvbmUNCiAgICAgICAgICAgIGlldGYtbGlzcC1hZGRyZXNzLXR5cGVzQDIwMTktMDIt MjMueWFuZw0KICAgICAgICAgICAgaWV0Zi1saXNwLWV0ckAyMDE5LTAyLTIzLnlhbmcNCiAgICAg ICAgICAgIGlldGYtbGlzcC1ldHJAMjAxOS0wMi0yMy55YW5nOjg2OiB3YXJuaW5nOiBsaW5lIGxl bmd0aCA3MCBleGNlZWRzIDY5IGNoYXJhY3RlcnMNCiAgICAgICAgICAgIGlldGYtbGlzcC1ldHJA MjAxOS0wMi0yMy55YW5nOjEwNjogd2FybmluZzogbGluZSBsZW5ndGggNzAgZXhjZWVkcyA2OSBj aGFyYWN0ZXJzDQogICAgICAgICAgICBpZXRmLWxpc3AtZXRyQDIwMTktMDItMjMueWFuZzoxNTc6 IHdhcm5pbmc6IGxpbmUgbGVuZ3RoIDcxIGV4Y2VlZHMgNjkgY2hhcmFjdGVycw0KICAgICAgICAg ICAgaWV0Zi1saXNwLWV0ckAyMDE5LTAyLTIzLnlhbmc6MTY0OiB3YXJuaW5nOiBsaW5lIGxlbmd0 aCA3MCBleGNlZWRzIDY5IGNoYXJhY3RlcnMNCiAgICAgICAgICAgIGlldGYtbGlzcC1ldHJAMjAx OS0wMi0yMy55YW5nOjE3MTogd2FybmluZzogbGluZSBsZW5ndGggNzIgZXhjZWVkcyA2OSBjaGFy YWN0ZXJzDQogICAgICAgICAgICBpZXRmLWxpc3AtZXRyQDIwMTktMDItMjMueWFuZzoxNzk6IHdh cm5pbmc6IGxpbmUgbGVuZ3RoIDcyIGV4Y2VlZHMgNjkgY2hhcmFjdGVycw0KICAgICAgICAgICAg aWV0Zi1saXNwLWl0ckAyMDE5LTAyLTIzLnlhbmcNCiAgICAgICAgICAgIGlldGYtbGlzcC1pdHJA MjAxOS0wMi0yMy55YW5nOjEyNTogd2FybmluZzogbGluZSBsZW5ndGggNzAgZXhjZWVkcyA2OSBj aGFyYWN0ZXJzDQogICAgICAgICAgICBpZXRmLWxpc3AtbWFwcmVzb2x2ZXJAMjAxOS0wMi0yMy55 YW5nDQogICAgICAgICAgICBpZXRmLWxpc3AtbWFwcmVzb2x2ZXJAMjAxOS0wMi0yMy55YW5nOjkx OiB3YXJuaW5nOiBsaW5lIGxlbmd0aCA3MiBleGNlZWRzIDY5IGNoYXJhY3RlcnMNCiAgICAgICAg ICAgIGlldGYtbGlzcC1tYXBzZXJ2ZXJAMjAxOS0wMy0wNS55YW5nDQogICAgICAgICAgICBpZXRm LWxpc3AtbWFwc2VydmVyQDIwMTktMDMtMDUueWFuZzoyMDQ6IHdhcm5pbmc6IGxpbmUgbGVuZ3Ro IDcwIGV4Y2VlZHMgNjkgY2hhcmFjdGVycw0KICAgICAgICAgICAgaWV0Zi1saXNwQDIwMTktMDMt MDUueWFuZw0KICAgICAgICAgICAgaWV0Zi1saXNwQDIwMTktMDMtMDUueWFuZzo0MzE6IHdhcm5p bmc6IGxpbmUgbGVuZ3RoIDcwIGV4Y2VlZHMgNjkgY2hhcmFjdGVycw0KICAgICAgICAgICAgaWV0 Zi1saXNwQDIwMTktMDMtMDUueWFuZzo0ODU6IHdhcm5pbmc6IGxpbmUgbGVuZ3RoIDcxIGV4Y2Vl ZHMgNjkgY2hhcmFjdGVycw0KICAgICAgICAgICAgaWV0Zi1saXNwQDIwMTktMDMtMDUueWFuZzo0 OTA6IHdhcm5pbmc6IGxpbmUgbGVuZ3RoIDcxIGV4Y2VlZHMgNjkgY2hhcmFjdGVycw0KICAgICAg ICAgICMrZW5kX3NyYw0KICAgIA0KW0FSXSBUaGFua3MgYSBsb3QgZm9yIGluY2x1ZGluZyB0aGUg cHlhbmcgYXJndW1lbnRzIHlvdSB1c2VkLCB3aWxsIGhlbHAgdXMgdG8gZml4IHRoZSBuaXRzLg0K ICAgIA0KDQo= From nobody Tue Aug 20 14:14:45 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DCD1200B8; Tue, 20 Aug 2019 14:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 AiQ-uMW1D6cG; Tue, 20 Aug 2019 14:14:41 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id B882E1200A3; Tue, 20 Aug 2019 14:14:38 -0700 (PDT) Received: from stubbs.int.chopps.org (172-222-100-236.dhcp.chtrptr.net [172.222.100.236]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 0DDA460195; Tue, 20 Aug 2019 17:14:37 -0400 (EDT) From: Christian Hopps Message-Id: <624A552C-CF02-4716-A7C1-2A12DD6826C6@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_BFBDA6AD-3B48-4409-A73A-054D52672DAA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 20 Aug 2019 17:14:37 -0400 In-Reply-To: <69983428-3A0C-4DAB-857E-75586DCE27D0@cisco.com> Cc: Christian Hopps , "yang-doctors@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-yang.all@ietf.org" To: "Alberto Rodriguez Natal (natal)" References: <156410535896.17429.16464147399003551309@ietfa.amsl.com> <69983428-3A0C-4DAB-857E-75586DCE27D0@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lisp] Yangdoctors early review of draft-ietf-lisp-yang-11 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, 20 Aug 2019 21:14:43 -0000 --Apple-Mail=_BFBDA6AD-3B48-4409-A73A-054D52672DAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 20, 2019, at 2:30 PM, Alberto Rodriguez Natal (natal) = wrote: >=20 > - TTL is limited to minute units. This may be overly = restrictive. Couldn't > there be some use (perhaps not common) e.g., perhaps when = debugging, or in > future versions of the protocol where seconds granularity = might be useful? > Changing these nodes later is non-backwards compatible and = thus very > painful to do. >=20 > [AR] That's a fair comment. We used minutes in the model, however, = since RFC6833bis defines the TTLs in minutes. Do you think it would be = reasonable to leave the TTL in minutes and aligned with 6833bis? If it were me I'd probably use seconds and mention in the description = that the RFC granularity is minutes; however, since you don't define a = range (a good thing) one backward compatible way to be able to specify = sub-minute values in the future would be to augment in a seconds (or = sub-seconds) node and have the minutes value be 0, so I think you're OK = if you want to leave it as minutes. Thanks, Chris. --Apple-Mail=_BFBDA6AD-3B48-4409-A73A-054D52672DAA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl1cYr0ACgkQLh2DDte4 MCUr9g/9ENGSpj609SoXZOUxHQHsI8BSRQ5ehl8cdLg2q9msNrOQHzkSLUAAF6pd nfvy3kWbNkMX/qxArKJan/lbZ8vKXn7mEEBehKqr7eFODbnsygZaQ2+4rnNy5nVA oeCTnc24uY+chQI7GMmd7BJOE7JHj8N5+xTEJ5MUx/41PxNdSXxthK3shQxbi2LK 0Bq7fAqgHv/xF293Gd2ivcEe3KaQMghSzOHxj3DiYBEMZ7xbq0C1Zcd6lQJAB6uh GcUytcf4F9E/mMfS3EmgLokDEj7wwu+U88HV+eLk7YGZxwKvGkBEXRu2RRPjki4Y +US7OBBcpg1OXhMGOZBalLUCRYGbgANEtsOonkdVX/+UFF+DmhMXZCuYTcR807nK taT4u4CRTkejGUpuTqJ/CSn7wBaMfFAMUBbYZ3gfPk1KdBc3kKvyz4waPJMDTP/5 9LK6gsaZcr6aIaGkyzwVwYthMTuJupm4DQe75WKSXJMpcWi8bQkc7xmH4v4B8FZ+ h6tHYVH/pm3ILAu/VJiMRjgKCKIL9v0jp2IIxAzNFJXckLNyInJ9LxaJ3P6L+3Io HU6CfBQZ4qhqnV1p7NcK9SkLh1b0yRy5K0dqugU22E4tzCQA6GpTORfN03PNJUGD AoqdE+6PcBJEaSIzdUCZlUcfmFPNS80qzuVhRivZvid6cKQJbTQ= =gQt6 -----END PGP SIGNATURE----- --Apple-Mail=_BFBDA6AD-3B48-4409-A73A-054D52672DAA-- From nobody Tue Aug 20 20:44:04 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942CA120106; Tue, 20 Aug 2019 20:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 header.b=L3MSQJ3x; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LxzLfUIG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyU-LeWAO4-a; Tue, 20 Aug 2019 20:44:01 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A584B12007A; Tue, 20 Aug 2019 20:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1794; q=dns/txt; s=iport; t=1566359041; x=1567568641; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1FSDGxkcPhtfc4bulqEJCJT9VfDpioZWh/zmW7xz7Ro=; b=L3MSQJ3xFFzzR9aJg16riMdgeZ3xH/AFnq1ITn1Px7tdveYPUe6xjgro hzgZ3k6cWVRmyR4D5Nh7hQr9fBTSJ1D6xjDH8OKQvKoTXrmqrc3TliuZW OGYeyewA7no9sOyIlOqCuCv2gn/LKJ7wY/5CAggUhBCH7q/psjP2kNsg6 s=; IronPort-PHdr: =?us-ascii?q?9a23=3ADFXZ5RYDvPoE/0KTSRGl3Gf/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20Q+bRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavsZjAzGOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAADZvFxd/4oNJK1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwYBAQELAYFEUAOBQiAECyqEH4NHA4RShiuCNyWXZYEugSQDVAk?= =?us-ascii?q?BAQEMAQEtAgEBhD8CF4I+IzQJDgIFAQEEAQEBAgEGBG2FJwyFSgEBAQMBEhE?= =?us-ascii?q?RDAEBNwEPAgEIDgoCAhkNAgICMBUQAgQOBSKDAIFrAw4PAQKgIgKBOIhhc4E?= =?us-ascii?q?ygnsBAQWFFxiCFAmBDCgBi2gYgX+BOAwTgkw+hB0ngwsyggQijxecQgkCgh2?= =?us-ascii?q?UORuYRqVpAgQCBAUCDgEBBYFQOIFYcBVlAYJBgkKDcopTcoEpi06CUgEB?= X-IronPort-AV: E=Sophos;i="5.64,410,1559520000"; d="scan'208";a="310920425" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Aug 2019 03:43:59 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x7L3hx1o013218 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Aug 2019 03:43:59 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 20 Aug 2019 22:43:59 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 20 Aug 2019 22:43:58 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 20 Aug 2019 23:43:58 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kY1f7Iyvca8gwivWtA1jsu1co20apjcDrD+tJrjtuFMCGbanPY+OBGwITzV8H9hC/yLNziKwzYyXosgxRFmk31XhkD1bmdwzXvQwbXqce5+6hzAlfLYoIhVy4KcRALeJvzItFIvUx4HPET83raNoV0z5niWEZEHBV1XXK7yeJ1iEEYmJ+HzvLYlvsLFZUcYqNWBnmlEoXjKKhR/NMyj237O7W1u2ENAziEUYRQntcWQMKG2dQ1CRXnVrLFl7ec2xQM0kYScKS/H1GskaqvQ4drT+MN2UNHr0A70zpUlKWCwtLyWkJfBiqndx0QRw82636mBNN9WkBvItjcseaWGhJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1FSDGxkcPhtfc4bulqEJCJT9VfDpioZWh/zmW7xz7Ro=; b=Kap93UwX0nzFLZryINJzSdrr35at8FKGjDcd64eCB5UBY/R/hzRhCvEGJoSfhYORO3CPqd0KgkDPZ2NEQubUjSqY6jtRdCB9OEA24UyLw5xXb3IBA3VLljXn2c2ZYRrKX5/z6sr7xeMoPcjhMrk/uXoNGWynvXEBSQYsNP8przaKE3Z/VybZ0eCYBj8K5vIKsVIXIeFSvaEpV+fLmduADgEeKpUu3P6YmqgptPIMczHIXaBbPI7Km6Upspr1xyfcC0OV5u/gNeovPc++rd/D2EG8Ke3Kau0NwnZc6jtDdUkJccLyHBSlYmWFjJHJXD4MItYnnkwUsZXKVxE1lZIQMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1FSDGxkcPhtfc4bulqEJCJT9VfDpioZWh/zmW7xz7Ro=; b=LxzLfUIGMghsqzGeYCaXNde8WaFlLlxkNuidsJ4nAtIObcgcaiILyXtaxq93cYm1LtsYr6oSUCr+W5FtTP/7QFBq4TkhxfBSmsAHRH8JIVPyh+x1o+29ge1gi2hrLIWlpbRvASbgrfSnUgux35aPOJAYxOvoxQyH9jD2kFLG1yc= Received: from BYAPR11MB3014.namprd11.prod.outlook.com (20.177.225.13) by BYAPR11MB3191.namprd11.prod.outlook.com (20.177.127.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Wed, 21 Aug 2019 03:43:57 +0000 Received: from BYAPR11MB3014.namprd11.prod.outlook.com ([fe80::59ae:773d:d7b0:9ca]) by BYAPR11MB3014.namprd11.prod.outlook.com ([fe80::59ae:773d:d7b0:9ca%7]) with mapi id 15.20.2178.018; Wed, 21 Aug 2019 03:43:56 +0000 From: "Alberto Rodriguez Natal (natal)" To: Christian Hopps CC: "yang-doctors@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-yang.all@ietf.org" Thread-Topic: Yangdoctors early review of draft-ietf-lisp-yang-11 Thread-Index: AQHVQ1Nu85KNK2Kykkek9GiFQm7DE6cEDo0AgACjV4D///dtAA== Date: Wed, 21 Aug 2019 03:43:56 +0000 Message-ID: <58A3BD0A-F0AE-43E8-8846-2E890D60F1F3@cisco.com> References: <156410535896.17429.16464147399003551309@ietfa.amsl.com> <69983428-3A0C-4DAB-857E-75586DCE27D0@cisco.com> <624A552C-CF02-4716-A7C1-2A12DD6826C6@chopps.org> In-Reply-To: <624A552C-CF02-4716-A7C1-2A12DD6826C6@chopps.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 authentication-results: spf=none (sender IP is ) smtp.mailfrom=natal@cisco.com; x-originating-ip: [2001:420:c0c8:1005::564] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f2baac4-93e0-457b-9153-08d725e9cb9e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR11MB3191; x-ms-traffictypediagnostic: BYAPR11MB3191: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(376002)(366004)(396003)(346002)(199004)(189003)(25786009)(8936002)(8676002)(6436002)(33656002)(446003)(66556008)(36756003)(76116006)(86362001)(66446008)(81156014)(256004)(81166006)(2616005)(66476007)(71190400001)(71200400001)(66946007)(6116002)(64756008)(478600001)(2906002)(14454004)(11346002)(486006)(5660300002)(6506007)(53546011)(476003)(186003)(305945005)(46003)(102836004)(7736002)(229853002)(54906003)(53936002)(76176011)(6486002)(4326008)(316002)(6512007)(6246003)(99286004)(6916009)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3191; H:BYAPR11MB3014.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: a142v4UlnuFI7BcKOOV0crV3AOdC9bBJt6XQuu0o9nUOQfg6wCvZJeS10rLRGaEhH6HoqE9jgKgTEZzHyyvpXyF0tmyvhynxGnFPY6AgNQzugX6uMmaSxwKjXxdPG+Do08fFpu7oevIRt96SkxQy9PJeOqHb/cnLQKG8tmONjjc65NI0xTMZb2s4KmJkzDXvnHYbCMd+BucNNjAbuW0x8WOGfJwiDCOGsmBztFtJJBkDAriCAZ4kzd4xrGoHtwCuylLcgiHdtMZJeI9GOKGSu9ga/fNvT04+w+nU/cZZRELN7ivHkoR/0/M7zPlwrDNz/5RssrWEACoAulLa+63SuTlrI6W/PXHrh3YnSFBscH8m49fxYN0dOCi7CwQ73flG+sw+pTmB8UKCoCyccnkFedJh0hpI7qvWud6Q2U/U1xQ= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3f2baac4-93e0-457b-9153-08d725e9cb9e X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 03:43:56.7538 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AmVHjjCMh1YZuOQrkBYNqc9R3Q2EDaSsxJQ9W6dT40CyiM7zxZn50e70d71ZsZQ0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3191 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [lisp] Yangdoctors early review of draft-ietf-lisp-yang-11 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, 21 Aug 2019 03:44:04 -0000 VGhhbmtzIENocmlzLCB0aGF0IG1ha2VzIHNlbnNlLiBXZSdsbCBsZWF2ZSBpdCBhcyBtaW51dGVz IHRoZW4uIA0KDQpCZXN0LA0KQWxiZXJ0bw0KDQrvu79PbiA4LzIwLzE5LCAyOjE0IFBNLCAiQ2hy aXN0aWFuIEhvcHBzIiA8Y2hvcHBzQGNob3Bwcy5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgDQog ICAgPiBPbiBBdWcgMjAsIDIwMTksIGF0IDI6MzAgUE0sIEFsYmVydG8gUm9kcmlndWV6IE5hdGFs IChuYXRhbCkgPG5hdGFsQGNpc2NvLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+ICAgICAgIC0g VFRMIGlzIGxpbWl0ZWQgdG8gbWludXRlIHVuaXRzLiBUaGlzIG1heSBiZSBvdmVybHkgcmVzdHJp Y3RpdmUuIENvdWxkbid0DQogICAgPiAgICAgICAgIHRoZXJlIGJlIHNvbWUgdXNlIChwZXJoYXBz IG5vdCBjb21tb24pIGUuZy4sIHBlcmhhcHMgd2hlbiBkZWJ1Z2dpbmcsIG9yIGluDQogICAgPiAg ICAgICAgIGZ1dHVyZSB2ZXJzaW9ucyBvZiB0aGUgcHJvdG9jb2wgd2hlcmUgc2Vjb25kcyBncmFu dWxhcml0eSBtaWdodCBiZSB1c2VmdWw/DQogICAgPiAgICAgICAgIENoYW5naW5nIHRoZXNlIG5v ZGVzIGxhdGVyIGlzIG5vbi1iYWNrd2FyZHMgY29tcGF0aWJsZSBhbmQgdGh1cyB2ZXJ5DQogICAg PiAgICAgICAgIHBhaW5mdWwgdG8gZG8uDQogICAgPiANCiAgICA+IFtBUl0gVGhhdCdzIGEgZmFp ciBjb21tZW50LiBXZSB1c2VkIG1pbnV0ZXMgaW4gdGhlIG1vZGVsLCBob3dldmVyLCBzaW5jZSBS RkM2ODMzYmlzIGRlZmluZXMgdGhlIFRUTHMgaW4gbWludXRlcy4gRG8geW91IHRoaW5rIGl0IHdv dWxkIGJlIHJlYXNvbmFibGUgdG8gbGVhdmUgdGhlIFRUTCBpbiBtaW51dGVzIGFuZCBhbGlnbmVk IHdpdGggNjgzM2Jpcz8NCiAgICANCiAgICBJZiBpdCB3ZXJlIG1lIEknZCBwcm9iYWJseSB1c2Ug c2Vjb25kcyBhbmQgbWVudGlvbiBpbiB0aGUgZGVzY3JpcHRpb24gdGhhdCB0aGUgUkZDIGdyYW51 bGFyaXR5IGlzIG1pbnV0ZXM7IGhvd2V2ZXIsIHNpbmNlIHlvdSBkb24ndCBkZWZpbmUgYSByYW5n ZSAoYSBnb29kIHRoaW5nKSBvbmUgYmFja3dhcmQgY29tcGF0aWJsZSB3YXkgdG8gYmUgYWJsZSB0 byBzcGVjaWZ5IHN1Yi1taW51dGUgdmFsdWVzIGluIHRoZSBmdXR1cmUgd291bGQgYmUgdG8gYXVn bWVudCBpbiBhIHNlY29uZHMgKG9yIHN1Yi1zZWNvbmRzKSBub2RlIGFuZCBoYXZlIHRoZSBtaW51 dGVzIHZhbHVlIGJlIDAsIHNvIEkgdGhpbmsgeW91J3JlIE9LIGlmIHlvdSB3YW50IHRvIGxlYXZl IGl0IGFzIG1pbnV0ZXMuDQogICAgDQogICAgVGhhbmtzLA0KICAgIENocmlzLg0KICAgIA0KDQo= From nobody Fri Aug 30 11:54:46 2019 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 8518B1200E7; Fri, 30 Aug 2019 11:54:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone , lisp-chairs@ietf.org, ggx@gigix.net, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156719127553.25739.936459114738864865.idtracker@ietfa.amsl.com> Date: Fri, 30 Aug 2019 11:54:35 -0700 Archived-At: Subject: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-25: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 18:54:36 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lisp-rfc6833bis-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updating for the -25 by removing points that are fully addressed but leaving points that I still want to have further discussion on. It may be most expedient to continue discussion on my -24 ballot thread. There are a couple of new items to the -25, that I attempt to call out as such (they appear right before the "the following items were present in my original DISCUSS position" section). Please also note that the COMMENT section was entirely refreshed for the -24, and I make some additions for the -25. This document has normative dependencies on other WG drafts that are not yet mature (one could perhaps define this as having completed IETF LC). In particular, I believe there is a nontrivial chance that either or both of lisp-sec and 6834bis could require changes to this document in order to be fit for purpose, and thus that this document cannot safely be approved for publication until these normative dependencies are closer to publication. In particular, I have done a fairly full review of lisp-sec and have DISCUSS-worthy points with it (I have not done much review of 6834bis yet). Also in Section 5.6: Implementations of this specification MUST include support for either HMAC-SHA-1-96 [RFC2404] and HMAC-SHA-256-128 [RFC4868] where the latter is RECOMMENDED. I don't think this sort of "mandatory to choose" is BCP 201-compliant, since we need to have at least one MTI, strong, algorithm, and this text did not pick one to be MTI. Now (-25) we're at "SHOULD include support for HMAC-SHA256-128-HKDF-SHA256", which is also not quite MTI (but is definitely strong). Of course, I personally won't complain if we just go with the new HKDF stuff, but I recognize that it would be a big change for implementations and deployments, and don't think we need to make the spec completely disjoint from reality just to check a box. So we could make HMAC-SHA-256-128 MTI and leave the new one as SHOULD, for example. I think there needs to be more description of Site-ID usage and scoping in order to be fully interoperable (more in the COMMENT section). [ed. Even focusing on the scoping while leaving the detailed usage as deployment-specific would be okay] There are multiple places where we talk about message contents being copied from a corresponding request (e.g., from Map-Request to Map-Notify); we need to explicitly state that the authentication data is recomputed to match, e.g., the new message type. I've tried to note these occurrences in the COMMENT section. [ed. I think just from Map-Notify to Map-Notify-Ack is all that's left] The condition for Map-Notify-Ack terminating Map-Notify retransmission seems incomplete. Specifically, we should only accept the Map-Notify-Ack to stop retransmission if the authentication data validates (and maybe that it uses the same Key-ID as the Map-Notify, though that might be overkill). So just "a Map-Notify-Ack is received by the Map-Server with the same nonce" is not quite enough. The LISP-SEC protocol defines a mechanism for providing origin authentication, integrity, anti-replay, protection, and prevention of 'man-in-the- middle' and 'prefix overclaiming' attacks on the Map-Request/Map- Reply exchange. [...] Does LISP-SEC actually provide any additional anti-replay protection not present in the base protocol? I do not remember any such additional protection. [ed. specifically, the nonce mechanism already in this document provides a decent level of replay protection, so I am trying to nail down how LISP-SEC does incrementally better than what's already here, for the specific case of an attacker literally recording a Map-Reply and replaying it, bit-for-bit, at a later time. Section 11 ("Changes since RFC 6833") is inaccurate (see COMMENT). I did not check whether it is complete, but someone needs to do so before final publication. [ed. Waiting to do this until all other changes are in is fine.] New in the -25, there's an internal inconsistency between Section 5.6's description of the Authentication Data procedure, that says implementations "SHOULD include support for HMAC-SHA256-128+HKDF-SHA256", and Section 9's "[a]n implementation MUST support HMAC-SHA256-128+HKDF-SHA256". Not new in the -25, but IIRC not previously discussed, how does a Map-Server pick a Nonce value for unsolicited Map-Notify messages? The following items were present in my original DISCUSS position and still have not been resolved. Note that I copy below the previous ballot text even for some issues that are described above already in different words. I think we need greater clarity on the 'E' and 'M' bits in the ECM format; more in the Comment section [of the ballot on -16], quoted here for clarity: > E: This is the to-ETR bit. When set to 1, the Map-Server's > intention is to forward the ECM to an authoritative ETR. > > I think this needs to say more about which message flows this bit is > defined for. Presumably the ITR will never use it for sending an > encapsulated Map-Request to a Map-Resolver, but there seem to be plenty of > places where ECM wrapping is used. > > M: This is the to-MS bit. When set to 1, a Map-Request is being > sent to a co-located Map-Resolver and Map-Server where the > message can be processed directly by the Map-Server versus the > Map-Resolver using the LISP-DDT procedures in [RFC8111]. > > How does the sender know that its configured Map-Resolver is also a > Map-Server? It's unclear to me why this needs a bit in the message as > opposed to just happening based on the attributes of the receiving > Map-Server. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [moving from DISCUSS to COMMENT based on explanation of this usage being a common historical usage in the LISP community. It still seems needlessly ambiguous and confusing to me, though.] There are many instances (some noted in my Comment) where a bidirectional interaction between two xTRs is described, yet the peers are identified as "ITR" and "ETR". This is very confusing when the entity named as "ITR" is described as performing ETR functionality, or vice versa; pedagogically, it would be much better to use non-role-based names for the entities while describing these exchanges. 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 This is a -bis document; is "new" really appropriate? (It also appears in the Introduction, of course.) Section 1 LISP is not intended to address problems of connectivity and scaling on behalf of arbitrary communicating parties. Relevant situations are described in the scoping section of the introduction to [I-D.ietf-lisp-rfc6830bis]. It looks like we inline that text into this document as Section 1.1, below; perhaps this paragraph is no longer needed, then? Section 4 A Map-Server is a device that publishes EID-Prefixes in a LISP mapping database on behalf of a set of ETRs. When it receives a Map Request (typically from an ITR), it consults the mapping database to nit: isn't it typically from a Map-Resolver (or other mapping-system-internal entity)? It's originally from an ITR, of course, but the flow assumed by this document is described as ITR->Map-Resolver->mapping-system-internals->Map-Server->ETR. Note that while it is conceivable that a Map-Resolver could cache responses to improve performance, issues surrounding cache management will need to be resolved so that doing so will be reliable and nit: s/will/would/? practical. As initially deployed, Map-Resolvers will operate only in a non-caching mode, decapsulating and forwarding Encapsulated Map Requests received from ITRs. Any specification of caching functionality is out of scope for this document. I think it's better to say something like "In this specification," rather than "As initially deployed". Also, I've confused myself a couple times from this -- it's only the Map-Resolver that doesn't cache; the ITR is free to cache. It might be helpful to call out that distinction here. Interestingly, in Section 1 we made an analogy from DNS *caching* resolvers to Map-Resolvers; would an analogy from DNS *recursive* resolvers have been more apt? Section 5 I still think it's needlessly confusing to duplicate the IP/UDP header layout figure here, at least without a prefacing comment noting that this is the standard IP+UDP header with the IP addresses replaced by RLOCs. But this is a non-blocking comment and the authors have already replied, so feel free to ignore. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values. It's not entirely clear to me what this requirement is saying. Section 5.2 A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. It is set to 1 when an ITR wants the destination site to return the Map-Reply rather than the mapping database system returning a Map-Reply. Given that we've already disclaimed caching in the mapping system, aren't all responses supposed to come from the destination site rather than the mapping system? Searching the rest of the document for the string "authoritative" suggests that this is perhaps intended to avoid proxying behavior from terminating Map-Servers (but when an ETR requests proxying is it still guaranteed to be able to generate its own Map-Replys?), in which case this could probably be phrased better. 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. [...] Why are these only SHOULD? I still think it is needlessly confusing to have bit labels that differ only by letter case. While this may not be confusing for the authors, there are plenty of other people who could potentially be confused by it. (Also, why are there two bits 'R' next to a 'Rsvd' field that all have the same "reserved" semantics?) 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. At this point in the document, we haven't seen anything to suggest that an xTR is going to be sending Map-Requests to other xTRs in the same site; a forward reference is probably in order. D: This is the dont-map-reply bit. It is used in the SMR procedure described in Section 6.1. When an xTR sends an SMR Map-Request message, it doesn't need a Map-Reply returned. When this bit is set, the receiver of the Map-Request does not return a Map-Reply. nit: I'd suggest consolidating the behavior description and leaving the explanations all at the end, so "This is the dont-map-reply bit. When this bit is set, the receiver of the Map-Request does not return a Map-Reply. It is used in the SMR procedure described in Section 6.1; when an xTR sends an SMR Map-Request message, it doesn't need a Map-Reply returned." Nonce: This is an 8-octet random value created by the sender of the Map-Request. This nonce will be returned in the Map-Reply. The nonce is used as an index to identify the corresponding Map- Request when a Map-Reply message is received. The nonce MUST be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security-sensitive random data. Since this value is just serving as a "number used once" (i.e., to match replies to requests), this is a stronger requirement than we need -- it merely needs to be unique per ITR. EID mask-len: This is the mask length for the EID-Prefix. In bits, right? ... EID-Prefix: This prefix address length is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family when the ... then maybe we shouldn't switch to bytes for just one sentence (and go back to bits later in the paragraph)? entry, the EID-Prefix is set to the destination IP address of the data packet, and the 'EID mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR wants to query a site about Is this really an xTR-specific action, or does it apply to any ITR functionality? This allows the ETR that will receive this Map-Request to cache the data if it chooses to do so. OTOH, this one does seem to require an xTR. Section 5.3 For the initial case, the destination IP address used for the Map-Request is the data packet's destination address (i.e., the destination EID) that had a mapping cache lookup failure. [...] This seems like a type mismatch between RLOC/EID -- per the headers, the destination address should be an RLOC, but we are forced to use an EID in this case. The disparity should probably be called out and explained, e.g., clarify that it's okay to use an EID as destination inside ECM encapsulation (and, apparently, if we believe Section 5.8, that it's required to do so). A successful Map-Reply, which is one that has a nonce that matches an outstanding Map-Request nonce, will update the cached set of RLOCs associated with the EID-Prefix range. nit: A negative Map-Reply will match the nonce. Will it also update the cached set? Is it still considered to be "successful"? If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- Request. I see we talked about this last time around; did you want to add some text about how, despite the protocol message not definitionally allowing for this detection, in practice it is still possible? Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does So, "(i.e., it is also an ITR)"? If the ETR (when it is an xTR co-located as an ITR) has a Map-Cache entry that matches the "piggybacked" EID and the RLOC is in the Locator-Set for the entry, then it MAY send the nit: "cached entry" would help clarify the prerequisites here. source. If the RLOC is not in the Locator-Set, then the ETR MUST send the "verifying Map-Request" to the "piggybacked" EID. [...] "send ... to the [...] EID" seems like a type mismatch again, since we only can send Map-Requests to RLOCs. Section 5.4 Map-Request. See RLOC-probing Section 7.1 for more details. When the probe-bit is set to 1 in a Map-Reply message, the A-bit in each EID-record included in the message MUST be set to 1. Do we want to specify any special handling if that NUST is disobeyed? S: This is the Security bit. When set to 1, the following authentication information will be appended to the end of the Map- Reply. The details of signing a Map-Reply message can be found in [I-D.ietf-lisp-sec]. Please do not use the word "signing" here; it is a term of art that is not appropriate to the actual operation performed. Record TTL: This is the time in minutes the recipient of the Map- Reply will store the mapping. If the TTL is 0, the entry MUST be I think "can" is more appropriate than "will"; generally a local cache can safely be invalidated at will. Locator Count: This is the number of Locator entries. A Locator Please scope this to "in the given Record". EID mask-len: This is the mask length for the EID-Prefix. (in bits, right?) ACT: This 3-bit field describes Negative Map-Reply actions. In any other message type, these bits are set to 0 and ignored on receipt. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. [...] This is the section on Map-Reply messages; why are we talking about other message types? Also, do we want to mention that the possible values are managed by IANA? A: The Authoritative bit, when set to 1, is always set to 1 by an ETR. When a Map-Server is proxy Map-Replying for a LISP site, the Authoritative bit is set to 0. This indicates to requesting ITRs that the Map-Reply was not originated by a LISP node managed at the site that owns the EID-Prefix. nit: This text is needlessly confusing. How about "The authoritative bit can only be set to 1 by an ETR (and not a Map-Server generating Map-Reply messages as a proxy). If this bit is set to 0, that indicates ..."? Section 5.5 Please provide a link/reference for Data-Probe on first usage. For each Map-Reply record, the list of Locators in a Locator-Set MUST appear in the same order for each ETR that originates a Map-Reply message. The Locator-Set MUST be sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address. IIUC, there is no need for "MUST appear in the same order" if you also mandate a specific sorting function. Section 5.6 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- Reply. [...] nit: "just one?" Do you want to give a mnemonic for the 'I' bit? The "Nonce" field is acting as a sequence number, not just as a number used once. I strongly suggest changing the name accordingly. Authentication Data Length: This is the length in octets of the 'Authentication Data' field that follows this field. The length of the 'Authentication Data' field is dependent on the MAC algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Why does a device that won't be able to validate the authentication data need to be able to parse the packet? I thought all Map-Registers needed to be authenticated. xTR-ID: xTR-ID is a 128 bit field at the end of the Map-Register message, starting after the final Record in the message. The xTR- ID is used to uniquely identify a xTR. The same xTR-ID value MUST NOT be used in two different xTRs. Globally, over all time? Within a single LISP domain, over all time? Please be specific. Site-ID: Site-ID is a 64 bit field at the end of the Map- Register message, following the xTR-ID. Site-ID is used to uniquely identify to which site the xTR that sent the message belongs. Where is a (LISP) "site" formally defined? Are there weird topologies or edge cases that we need to consider when assigning numbers, risk of having two IDs that might validly apply to a single xTR, etc.? Section 5.7 (If Nonce is renamed above, it should be renamed here as well.) The fields of the Map-Notify-Ack are copied from the corresponding Map-Notify message to acknowledge its correct processing. Please note that the authorization data is recomputed, here. The Map-Notify-Ack message has the same contents as a Map-Notify message. It is used to acknowledge the receipt of a Map-Notify (solicited or unsolicited) and for the sender to stop retransmitting So a normal exchange would include Map-Register, Map-Notify, and Map-Notify-Ack? A Map-Server sends an unsolicited Map-Notify message (one that is not used as an acknowledgment to a Map-Register message) that follows the Congestion Control And Relability Guideline sections of [RFC8085]. A This second clause ("that follows") is rather a non sequitur here. And we still don't know what purpose the unsolicited Map-Notify serves! Map-Notify is retransmitted until a Map-Notify-Ack is received by the Map-Server with the same nonce used in the Map-Notify message. If a Presumably we care about (e.g.) the key ID matching and the authentication data validating, as well? Map-Notify-Ack is never received by the Map-Server, it issues a log message. An implementation SHOULD retransmit up to 3 times at 3 second retransmission intervals, after which time the retransmission interval is exponentially backed-off for another 3 retransmission "exponentially" is not well defined unless the base of the exponent is specified. attempts. After this time, an xTR can only get the RLOC-set change by later querying the mapping system or by RLOC-probing one of the RLOCs of the existing cached RLOC-set to get the new RLOC-set. What RLOC-set change? This text doesn't seem to indicate what functionality is going on here. Section 5.8 An Encapsulated Control Message (ECM) is used to encapsulate control packets sent between xTRs and the mapping database system. Some of the flag bit descriptions appear to describe usages that are or can be entirely within the mapping system. D: This is the DDT-bit. When set to 1, the sender is requesting a Map-Referral message to be returned. The details of this procedure are described in [RFC8111]. E.g., here, the sender can be (IIUC) within the mapping system. E: This is the to-ETR bit. When set to 1, the Map-Server's intention is to forward the ECM to an authoritative ETR. I'm not sure that "intention" is quite right, here -- as far as this document is concerned, a Map-Server will always know whether it is sending an ECM to an authoritative ETR. Also, this bit does not seem to be used for anything within this document, and no external reference is given. Are the 'M' and 'E' bits mutally exclusive? (Would we even care?) I suggest adding more text about which sender/receiver pairs are permitted (or allowed or expected) to set the D, E, and M bits. invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero. This is the only place in this document that we disallow port 4341. Should we also be disallowing it from being used as the non-4342 port for other exchanges? LCM: The format is one of the control message formats described in this section. [...] nit: "this section" means 5.8; presumably we mean Section 5. Section 6.1 I agree with Warren that the direct usage of mapping information included in an SMR presents a substantial attack surface, both for DoS and potentially for redirecting traffic wholesale (whether for snooping purposes or use as volumetric DoS to a third-party target). There is some discussion of the risks of spoofing with this sort of "gleaming" behavior, but I strongly suggest mentioning something like "this technique presents a risk of off-path spoofing; see Section 9 for details" at each such non-validated scheme for learning mapping information. Since ETRs are not required to keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) to those sites to which it has been sending LISP encapsulated data packets for the last minute. In particular, an ETR will send an SMR to an ITR to which it has recently sent encapsulated data. This can only occur when both ITR and ETR functionality reside in the same router. I still think that this text is needlessly confusing about which action is taken by which router, and could be improved as, e.g., "this can only occur when the ETR also provides ITR functionality (that is, it is an xTR)". The following procedure shows how an SMR exchange occurs when a site is doing Locator-Set compaction for an EID-to-RLOC mapping: Where is locator-set compaction defined? Throughout this whole example, "the site with the changed mapping" and "the site that sent the Map-Request" are kind of clunky phrases; it might be cleaner writing to give them names (like "site A" and "site B"). messages. It is RECOMMENDED that the SMR sender rate-limits Map- Request for the same destination RLOC to no more than one packet per 3 seconds. It is RECOMMENDED that the SMR responder rate-limits Map- Request for the same EID-Prefix to no more than once per 3 seconds. Please double-check that "SMR sender"/"SMR responder" and "Map-Request" usage are consistent/as-intended. 2. A remote ITR that receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. [...] How does the ITR decide which destination to send the Map-Request to? copied from the SMR message. If the source Locator is the only Locator in the cached Locator-Set, the remote ITR SHOULD send a just to double-check: this is the source Locator from the SMR? Map-Request to the database mapping system just in case the single Locator has changed and may no longer be reachable to accept the Map-Request. Is this the only case that the Map-Request would go to the mapping system? 3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When nit: I suggest a comma after "Map-Reply" to avoid the misparse that the Map-Reply must be received while the cached mapping is in use (and that the rate limiting would continue indefinitely if the cached mapping expired in the meantime). 5. The ETRs at the site with the changed mapping record the fact that the site that sent the Map-Request has received the new mapping data in the Map-Cache entry for the remote site so the Locator-Status-Bits are reflective of the new mapping for packets going to the remote site. [...] The Locator-Status-Bits in which direction? (Probably should also give a section ref to 6830bis for the definition.) It might also be appropriate to discuss the interaction with the relevant map version. For security reasons, an ITR MUST NOT process unsolicited Map- Replies. To avoid Map-Cache entry corruption by a third party, a sender of an SMR-based Map-Request MUST be verified. If an ITR To be clear, the verification here is essentially return-routability verification, aka proof that the sender actually owns the claimed address, right? I think it is appropriate to have some text noting the specific behavior, and that this is not any sort of cryptographic or strongly authenticated verification. 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. [...] What is an "SMR-based Map-Request" (also appears in the next paragraph and one other place)? Is it just an SMR? If it's some actual Map-Request, I'm confused at why an *I*TR would be receiving it. Section 7 3. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [RFC6832] and LISP-encapsulated data is sent to a non-LISP-capable site. Is the ITR supposed to conclude that the RLOC is likely down in this situation? When ITRs receive ICMP Network Unreachable or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators that are described in Locator lists of Map- Replies. [...] Is this really as precise as it can be? It kind of sounds like it says that all Map-Replies will be ignored when any ICMP Network/Host Unreachable message is received. If it does not find one and BGP is running in the Default- Free Zone (DFZ), it can decide to not use the Locator even though the Is running in the DFZ consistent with the reduced scope of running in a single administrative domain? Optionally, an ITR can send a Map-Request to a Locator, and if a Map- Reply is returned, reachability of the Locator has been determined. Is this describing the same flow as item (5) above and Section 7.1 below? If so, it seems totally redundant and could be omitted. Obviously, sending such probes increases the number of control messages originated by Tunnel Routers for active flows, so Locators are assumed to be reachable when they are advertised. I'm not sure what "advertised" is intended to mean, here. Is it "advertised into the mapping system"? But that is not directly visible to the ITR, only indirectly through the results of an actual mapping request (and even then, the Map-Reply from an ETR could be invalid, e.g., overclaiming, unless LISP-SEC is used. Both Requests and Replies MUST be rate- limited. [...] I believe this requirement duplicates requirements already made elsewhere; the other locations also include more guidance on actual rates. Section 7.1 A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to the mapping database system as one would when soliciting mapping data. [..] I strongly suggest using a word other than "soliciting" to avoid confusion with SMR. data. The EID record encoded in the Map-Request is the EID-Prefix of the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a Is it worth reminding the reader that the source EID here is zero-length and source-EID-AFI set to zero? mapping data record for its own database mapping information that contains the local EID-Prefixes and RLOCs for its site. [...] To double-check: this mapping data record is included in the "Map-Reply Record" field of the Map-Request message? It would probably help the reader to be consistent about this terminology. Section 8.1 In particular, the ITR need not connect to the LISP-ALT infrastructure or implement the BGP and GRE protocols that it uses. Why does LISP-ALT get a callout but not (e.g.) LISP-DDT? Section 8.3 If the EID-prefix is registered or not registered and there is a authentication failure, then a Drop/ What is the authentication flow that would be failing here? The Map-Register for the corresponding prefix? If either of these actions result as a temporary state in policy or authentication then a Send-Map-Request action with 1-minute TTL MAY be returned to allow the requestor to retry the Map-Request. How can an SMR have an associated TTL? The message format is that of a regular Map-Request, is it not? Section 8.4 Upon receipt of an Encapsulated Map-Request, a Map-Resolver decapsulates the enclosed message and then searches for the requested EID in its local database of mapping entries (statically configured or learned from associated ETRs if the Map-Resolver is also a Map- Server offering proxy reply service). This seems to be the first time the document admits the possibility for a local database of mapping entries on a Map-Resolver; this makes me wonder if there was an incomplete removal of such functionality from the document, especially given that local caching of responses on the Map-Resolver is explicitly disclaimed in Section 4. Section 8.4.1 ETRs MAY have anycast RLOC addresses which are registered as part of their RLOC-set to the mapping system. However, registrations MUST use their unique RLOC addresses or distinct authentication keys to identify security associations with the Map-Servers. xTR-IDs cannot be used for this purpose? Section 9 I think we should have some discussion here about how mapping information gleamed from SMR messages does not necessarily benefit from the on-path guarantee that the nonce provides for regular mapping-system exchanges. The Map-Register message is vulnerable to replay attacks by a man-in-the-middle. A compromised ETR can overclaim the 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 SHOULD verify that all EID-Prefixes registered by an ETR match the configuration stored on the Map-Server. The conversion of the Map-Register 'Nonce' field into a sequence number provides some moderate remediation against the replay attack; that should be included in this discussion. Encrypting control messages via DTLS [RFC6347] or LISP-crypto [RFC8061] SHOULD be used to support privacy to prevent eavesdroping and packet tampering for messages exchanged between xTRs, xTRs and the mapping system, and nodes that make up the mapping system. nit: "to support privacy to prevent eavesdropping and packet tampering" doesn't read as grammatical; is the "to support privacy" still needed or maybe just a missing "and"? less-nit: this current wording makes it seem like LISP-crypto should be a normative reference, but I think the intended semantics are more of "some mechanism SHOULD be used to provide [privacy/confidentiality protection], and here is an incomplete list of mechanisms that do so" Section 10 Thank you for adding the Privacy Considerations section; it is imporant to document this property of the system and let the operator make informed decisions. 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 Also Section 1.1 of this document. Section 11 o The "m", "I", "L", and "D" bits are added to the Map-Request message. See Section 5.3 for details. Isn't this more a Section 5.2 thing than 5.3? Also, I don't see "m" or "I" bits described (though I do see "M"). o The "S", "I", "E", "T", "a", and "m" bits are added to the Map- Register message. See Section 5.6 for details. I see an "M" bit but not an "m" one. Section 12.3 It feels a little weird to lump the ACT fields (which have a registry) together in a section with the flag fields scattered throughout the protocol (which do not). Is it bad to have separate subsections for them (especially when Section 12.6 already exists and does provide a registry for other flag bits)? Section 12.6 A sub-registry needs to be created per each message and record. [...] What is a "record" in this context? (It does not seem like a mapping record.) I mostly expect IANA to ask for a listing of which bits/ranges are/aren't allocatabale. From nobody Fri Aug 30 12:21:51 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664A11201DE; Fri, 30 Aug 2019 12:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWb9juqXvyd4; Fri, 30 Aug 2019 12:21:42 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3BAE11200E7; Fri, 30 Aug 2019 12:21:41 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7UJLaPY004648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Aug 2019 15:21:38 -0400 Date: Fri, 30 Aug 2019 14:21:35 -0500 From: Benjamin Kaduk To: draft-ietf-lisp-rfc6833bis@ietf.org Cc: The IESG , ggx@gigix.net, lisp-chairs@ietf.org, lisp@ietf.org Message-ID: <20190830192135.GN84368@kduck.mit.edu> References: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <153805056019.26512.877252229948689152.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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, 30 Aug 2019 19:21:45 -0000 Since Ekr has cycled off the IESG, I'll try to take over any remaining points here. It seems like there may just be the one left, hooray! The authors very helpfully put together a spreadsheet with all the comments, discussion about them, and pointers to what changed (if anything) in the document as a result; thank you for that! On Thu, Sep 27, 2018 at 05:16:00AM -0700, Eric Rescorla wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- [trimming heavily] > > S 6.1. > > receives an SMR-based Map-Request and the source is not in the > > Locator-Set for the stored Map-Cache entry, then the responding Map- > > Request MUST be sent with an EID destination to the mapping database > > system. Since the mapping database system is a more secure way to > > reach an authoritative ETR, it will deliver the Map-Request to the > > authoritative source of the mapping data. > > If I'm understanding this correctly, this allows an ETR to prevent an > ITR from learning that it is no longer the appropriate ETR for a > prefix. The way this attack works is that before the topology shift, I > send SMRs, thus causing Map-Requests, which, because my entry is > cached, refresh the cache on the ITR past the topology shift. I can > keep doing this indefinitely. Am I missing something If I can perhaps try to refine the questionable scenario, suppose there's an ITR "A" that's trying to direct traffic to EID "B", and "B" is currently behind an evil ETR "C" but will shortly move behind a different ETR "D". For simplicity, suppose further that C is the only ETR at that site, so there is only one RLOC in the legitimate mapping data. The claim here is that, if C knows what timeout/configuration A has stored for the mapping information for B, then C can periodically send SMR to A, and the procedures in this section cause A to send the solicited Map-Reply not through the mapping system, but directly to C, since C's RLOC is already in the Map-Cache entry that A has stored for mapping B's EID. Since C is evil and wants to keep looking at B's traffic, C will then reply with a (now-false, after B has moved away) Map-Reply that "confirms" that C is the right RLOC for reaching B, and A continues to route traffic for B through C. Thus, C is able to "hold on to" traffic to B even after B has moved away. If A bothered to send a Map-Request to the mapping system, it would discover the truth, but I didn't find anything that required that to happen. In this simple example, there's only the one ETR, and since D has never seen traffic from A it may not know to send an SMR to A that would trigger a request to the mapping system. I do see in numbered point (2) that "If the source Locator is the only Locator in the cached Locator-Set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single Locator has changed and may no longer be reachable to accept the Map-Request", but (a) that's only a SHOULD, and (b) while this is true in my simplified example above, it would not be hard to construct more complicated scenarios where it failed to apply. I also consider the case that if B is sending return traffic towards [something behind] A, and that traffic goes through D where D acts as an ITR, then D will know to send its own SMR to A. But, (c) nothing requires D to be an xTR as opposed to just an ETR, and (d) unidirectional flows would still be affected. -Ben