From nobody Mon Jan 5 08:34:10 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBD81A1B21 for ; Mon, 5 Jan 2015 08:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWb4WgxUfU87; Mon, 5 Jan 2015 08:34:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ABA1A1B03; Mon, 5 Jan 2015 08:34:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ggx@gigix.net, draft-ietf-lisp-introduction.all@tools.ietf.org, lisp@ietf.org, lisp-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105163400.22179.62350.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 08:34:00 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/6CQhshSB8Dfk6de6oVsdHyQK0fw Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 16:34:08 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Thu Jan 8 04:44:08 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726DE1ACD2F; Thu, 8 Jan 2015 04:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPGoiuu__312; Thu, 8 Jan 2015 04:44:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBCC1ACD19; Thu, 8 Jan 2015 04:44:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108124405.9793.32714.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 04:44:05 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-10.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 12:44:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP EID Block Authors : Luigi Iannone Darrel Lewis David Meyer Vince Fuller Filename : draft-ietf-lisp-eid-block-10.txt Pages : 16 Date : 2015-01-08 Abstract: This is a direction to IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-eid-block-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 8 04:50:51 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6A91A00F4 for ; Thu, 8 Jan 2015 04:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNAO8aJbuJTK for ; Thu, 8 Jan 2015 04:50:46 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4771A00D4 for ; Thu, 8 Jan 2015 04:50:46 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so3025451wiw.2 for ; Thu, 08 Jan 2015 04:50:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hg/ZixGU1LeNzx0TvMCE6i/W6SvgEXcpiAuak3c4MPI=; b=g+wdJH7+mUtR2wqaJvX4XosLJFpmantSqMJj8I9cAoP1apUYB+PZUIzEKgxuW95W8I llLpNvX4TcTF29ZhSfCoyVq45wGhE9QevD4PbO08d8u0ClLRVg1cS34PUNT4YAt+Z+qA 4+p+hzKLOnGgw+QoxbAzUjEo3s203H7ON7cDZ1dIfLc5zwFWkMgUBiEmd3JMs2Mnn/7/ 1JZlhEmURLso/j2fz875RUFnvP4acgHvVipussTfarww0I453qRFNuNxKv9W6pxCtlco egpDFI56sDXxUQKG1R3b4hiXgSwTP9g/HAcB2U5RKuWCB9JiI3YmGwNiAXvrCt4RO/m6 7J7g== X-Gm-Message-State: ALoCoQkulFhtFl6IOMmxAUXmmpc1mrbn/dGCnIpRoXlaac8Yw7+6H4ZxpwbskKuBASF4p3LPjI5p X-Received: by 10.180.82.98 with SMTP id h2mr19476332wiy.7.1420721444987; Thu, 08 Jan 2015 04:50:44 -0800 (PST) Received: from ?IPv6:2001:660:330f:38:8882:5281:61d2:829d? ([2001:660:330f:38:8882:5281:61d2:829d]) by mx.google.com with ESMTPSA id vs8sm6054023wjc.6.2015.01.08.04.50.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Jan 2015 04:50:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_22E3B507-5C47-4601-9F67-566801A06886" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Luigi Iannone In-Reply-To: <40D65A23-0FB0-4D1B-BC87-367AE8367541@gigix.net> Date: Thu, 8 Jan 2015 13:50:37 +0100 Message-Id: <6726A5C0-80CE-461A-9304-8E35BA8B9210@gigix.net> References: <2529C978-FA62-47B0-A223-0B85276DC2D3@gigix.net> <40D65A23-0FB0-4D1B-BC87-367AE8367541@gigix.net> To: LISP mailing list list X-Mailer: Apple Mail (2.1993) Archived-At: Subject: Re: [lisp] [EXTENDED] draft-saucez-lisp-impact-07 - Call for WG Adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 12:50:49 -0000 --Apple-Mail=_22E3B507-5C47-4601-9F67-566801A06886 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, the extended WG Adoption Call is now over for = draft-saucez-lisp-impact-07. Despite the holidays season people reacted and clearly indicated that = there is consensus in adopting this document as WG item. Now is time to send feedback to the authors about the content of the = brand new WG document :-) Thank you all and Happy 2015! Luigi > On 22 Dec 2014, at 16:08, Luigi Iannone wrote: >=20 > Hi All, >=20 > the two weeks have elapsed since the beginning of the WG Adoption Call = for draft-saucez-lisp-impact-07. >=20 > There was actually very little reaction on this call. >=20 > Silence does not help to make a decision, one way or another. >=20 > Recall that our charter explicitly state that we will work on "A = description of the impacts of LISP=E2=80=9D. >=20 > The WG Adoption Call is extended for another two weeks (until 5th = January 2015). >=20 > Please take this opportunity to express your opinion on this document. >=20 > Thanks >=20 > Luigi & Joel=20 >=20 >> On 04 Dec 2014, at 12:27, Luigi Iannone > wrote: >>=20 >> Hi All, >>=20 >> During the 91st IETF authors of the draft-saucez-lisp-impact-07 >> [https://tools.ietf.org/html/draft-saucez-lisp-impact-07 = ]=20 >> asked for WG adoption. Meeting participants expressed consensus on = adoption. >>=20 >> This message begins the two weeks call for WG adoption to confirm the = meeting outcome.=20 >> The call ends on December 19th 2014. >>=20 >> Please respond to the LISP mailing list with any statements of = approval or disapproval. >>=20 >> Recall that: >>=20 >> - This is not WG Last Call. The document is not final, and the WG is = expected to=20 >> modify the document=E2=80=99s content until there is WG consensus = that the content is solid. =20 >> Therefore, please don=E2=80=99t oppose adoption just because you = want to see changes to its content. >>=20 >> - If you have objections to adoption of the document, please state = your reasons why,=20 >> and explain what it would take to address your concerns. >>=20 >> - If you have issues with the content, by all means raise those = issues and we can=20 >> begin a dialog about how best to address them. >> =20 >> = =20 >> Luigi and Joel >>=20 >>=20 >=20 --Apple-Mail=_22E3B507-5C47-4601-9F67-566801A06886 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi All,

the= extended  WG Adoption Call is now over for = draft-saucez-lisp-impact-07.

Despite the holidays season people = reacted and clearly indicated that there is consensus in adopting this = document as WG item.

Now is time to send feedback to the authors about the content = of the brand new WG document :-)

Thank you all and Happy 2015!

Luigi



On 22 Dec 2014, at 16:08, Luigi Iannone <ggx@gigix.net> = wrote:

Hi All,

the two weeks have = elapsed since the beginning of the WG Adoption Call  for = draft-saucez-lisp-impact-07.

There was actually very little reaction = on this call.

Silence does not help to make a decision, one way or = another.

Recall = that our charter explicitly state that we will work on "A description of the impacts of = LISP=E2=80=9D.

The WG Adoption Call is extended for = another two weeks (until 5th January 2015).

Please take this opportunity to express = your opinion on this document.

Thanks

Luigi & Joel 

On 04 Dec 2014, at 12:27, Luigi Iannone = <ggx@gigix.net> = wrote:

Hi All,

During the 91st IETF = authors of the draft-saucez-lisp-impact-07
[https://tools.ietf.org/html/draft-saucez-lisp-impact-07]&nb= sp;
asked for WG adoption. Meeting participants expressed = consensus on adoption.

This message begins = the two weeks call for WG adoption to confirm the meeting = outcome. 
The call ends on  December 19th = 2014.

Please respond to the LISP mailing = list with any statements of approval or disapproval.

Recall that:

- This is not WG Last Call. The document is not final, and = the WG is expected to 
  modify the = document=E2=80=99s content until there is WG consensus that the = content is solid.  
  Therefore, = please don=E2=80=99t oppose adoption just because you want to see = changes to its content.

- If you have objections to adoption of the document, please = state your reasons why, 
  and explain = what it would take to address your concerns.

- If you have issues with the content, = by all means raise those issues and we can 
  begin a dialog about how best to address them.
                =       
      =                     =                     =                     =                     =                 =   
Luigi and Joel




= --Apple-Mail=_22E3B507-5C47-4601-9F67-566801A06886-- From nobody Thu Jan 8 13:10:15 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5641ACE05; Thu, 8 Jan 2015 13:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWX_T6DzKBvh; Thu, 8 Jan 2015 13:10:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8661ACDFB; Thu, 8 Jan 2015 13:10:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108211003.16644.44341.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 13:10:03 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-impact-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 21:10:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Impact Authors : Damien Saucez Luigi Iannone Albert Cabellos Florin Coras Filename : draft-ietf-lisp-impact-00.txt Pages : 15 Date : 2015-01-08 Abstract: The Locator/Identifier Separation Protocol (LISP) aims at improving the Internet scalability properties leveraging on three simple principles: address role separation, encapsulation, and mapping. In this document, based on implementation, deployment, and theoretical studies, we discuss the impact that deployment of LISP can have on both the Internet in general and for the end-users in particular. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-impact-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 12 06:47:49 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76331ABD3C for ; Mon, 12 Jan 2015 06:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQIsskMXo7fI for ; Mon, 12 Jan 2015 06:47:46 -0800 (PST) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072C71ABD37 for ; Mon, 12 Jan 2015 06:47:46 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id q58so19489868wes.12 for ; Mon, 12 Jan 2015 06:47:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version; bh=8D9aUOSLALvaFMhuB2+zPYC094VPp+mfL5u5qNPOYFg=; b=RrPrIGbh8ReFLP7QCdXASSR5uF3mmhIX+XT+xxDF4IihKstQ9EhjbKZv9O/YQsCSTy AqQ4aBuoR0K/ccISc08bCJuezb3F6achs0sgsjk3VEWz0MRFN4kLs6f2PlEvmYS3/Igc yBDBJ1b9tp/9JwOxM+UTpi1V4M56VcfuEJd3AhEYgZsgav16ZxgYMI0W4rk5qjRKtWiI b9U9KEK8yOHJ0IeuTuohcFY8hl/lZRMfYHXJZIp79D5HNhbIrdpKOrNjKLRQlDxt8TZQ 7AX73uP4sbsfk+sxjAq5fzf2KOrjx58fdrWyK4fKsHJOxDfwgha63DeXkbh/+kVT2T4g Z2yw== X-Gm-Message-State: ALoCoQnmL8Cd/zxWXcdW8mP28KruPr/34c3wJQqyYYPI+N4pcenvzNL5aWGg/IwLJMWHaDgxhDnc X-Received: by 10.194.157.4 with SMTP id wi4mr4572162wjb.54.1421074063345; Mon, 12 Jan 2015 06:47:43 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:a536:20cf:2823:4017? ([2001:660:330f:a4:a536:20cf:2823:4017]) by mx.google.com with ESMTPSA id gl5sm10533504wib.0.2015.01.12.06.47.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Jan 2015 06:47:42 -0800 (PST) From: Luigi Iannone Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Jan 2015 15:47:56 +0100 Message-Id: To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Damien Saucez , Olivier Bonaventure Subject: [lisp] Progress on threats document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 14:47:47 -0000 Hi All, back in Toronto the WG agreed to organise the threats document in two = main parts:=20 1- threat analysis=20 2- threats mitigation there was also agreement to try to finalise the first part before = tackling the second one. To this end, this would be the right time to review the current document = and send any comment/feedback to the authors. Having such review by the end of February at latest would give = sufficient time to have a new document with the first part done and a = newly proposed second part before the meeting in Dallas. Please speak up before the end of February if you have any comment, = otherwise authors will consider the first part as done. ciao Luigi= From nobody Mon Jan 12 11:27:41 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6644E1ACD8D for ; Mon, 12 Jan 2015 11:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ply0vFt5W59G for ; Mon, 12 Jan 2015 11:27:39 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222241ACD89 for ; Mon, 12 Jan 2015 11:27:39 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id y19so5082131wgg.3 for ; Mon, 12 Jan 2015 11:27:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:resent-cc:resent-from:date :content-transfer-encoding:resent-date:message-id:resent-to:to; bh=C3rLr4Ib89mI0/z/L0b5pevVQjWiE4QmfXsS0wHlQdQ=; b=vEw15vrGOwbyLIJqMsNuluTa+HpEz4vHS0hvDcmhIJ+elyLL2Zt42+Hh5tmh/aOAWc pMCFo3Jqd6HhD5w2CY1RmEh8bvnjpBQoqPCkQUAAXEXFCkRLQLtSJ/1MfC8YM7phxP5g mTpiev2JNjlWm7mWFeWUdJ/gXtOuBEaczPM00b5Gnv189nV86VJUsb/oLZg5lQZSkFBs dysB+vhl3n3n3qLTP/QzjKUKG9rfg6zsTvGt5ebZmDwbZ4YMIMhTtWm91/9gFppLLrkO ldaeh3qACJco7aL0V38K1gaSBQAoSsPWFWeirkUyCWq4CGjzFtefHkhKyOHb2QV8TmTr RGQg== X-Received: by 10.180.75.199 with SMTP id e7mr33653177wiw.21.1421090857374; Mon, 12 Jan 2015 11:27:37 -0800 (PST) Received: from saehrimnir.inria.fr (saehrimnir.inria.fr. [138.96.206.202]) by mx.google.com with ESMTPSA id fa13sm11381831wid.17.2015.01.12.11.27.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Jan 2015 11:27:37 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Damien Saucez Resent-Cc: draft-ietf-lisp-eid-block-mgmnt@tools.ietf.org Resent-From: Damien Saucez Date: Mon, 12 Jan 2015 18:35:01 +0100 Content-Transfer-Encoding: quoted-printable Resent-Date: Mon, 12 Jan 2015 20:27:36 +0100 Message-Id: <14EC5801-1FB4-4F66-A02C-BC2D0CDFF75A@gmail.com> Resent-To: LISP mailing list list To: draft-ietf-lisp-eid-block-mgmnt@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [lisp] LISP EID Block Management Guidelines - IPR disclosures X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 19:27:40 -0000 Dear all, I am the document shepherd for draft-ietf-lisp-eid-block-mgmnt-04. In = order for me to complete the shepherd writeup, I would like first to ask the = authors and the WG if any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been = filed. Best regards, Damien Saucez= From nobody Mon Jan 12 13:49:24 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65E41ACDE7; Mon, 12 Jan 2015 13:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lNg2_C3Hj7G; Mon, 12 Jan 2015 13:49:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1381A6F0A; Mon, 12 Jan 2015 13:49:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112214918.14918.60258.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 13:49:18 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-crypto-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 21:49:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Data-Plane Confidentiality Author : Dino Farinacci Filename : draft-ietf-lisp-crypto-00.txt Pages : 11 Date : 2015-01-12 Abstract: This document describes a mechanism for encrypting LISP encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data-plane from third-party surveillance attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-crypto/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-crypto-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 14 08:26:34 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12BE1A9024 for ; Wed, 14 Jan 2015 08:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCMCD24mutF8 for ; Wed, 14 Jan 2015 08:26:23 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45231A901F for ; Wed, 14 Jan 2015 08:26:22 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id AEF9288119; Wed, 14 Jan 2015 08:26:22 -0800 (PST) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 3AEE671C0002; Wed, 14 Jan 2015 08:26:22 -0800 (PST) Message-ID: <54B698A7.1080309@innovationslab.net> Date: Wed, 14 Jan 2015 11:26:15 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "lisp@ietf.org" , draft-ietf-lisp-introduction@tools.ietf.org, "lisp-chairs@tools.ietf.org" Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IKbSwj5KKpejpDOlGNNtbMGJHqqx8K79P" Archived-At: Subject: [lisp] AD Evaluation: draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 16:26:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IKbSwj5KKpejpDOlGNNtbMGJHqqx8K79P Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable All, I have completed by AD Evaluation of draft-ietf-lisp-introduction as a part of the IETF publication process. I have some comments/questions that should be resolved prior to starting an IETF Last Call. Please let me know if you have any questions on these... 1. Section 1 * I am going to try and short-circuit the inevitable question that will arise about the reference [Chiappa]. Since it is a web page, the RFC Editor will be concerned by its long-term stability. Is that the best reference for that text? Anything similar that has been published in a conference/journal/RFC/etc.? * The text uses the terms underlay and overlay without any context (in the summary bullets). This is easily fixed by augmenting the text in the 2nd paragraph to identify which networks form the underlay and the overlay. 2. Section 3 (and a few times in 3.5) : s/inetrworking/internetworking/ 3. Section 3.2 * Is it correct to say that EIDs are only routable at the edge? This seems to contradict the text in section 3.5 that says EIDs may be injected in the global routing system. * I find the PI and PA analogies misleading. EIDs are global, but they may change their point of attachment. If that occurs, you are not guaranteed that your EID space does not change. * In the example, bullet four mistakenly says that the destination address of the outer header is set to RLOC_B2 (it should be RLOC_b1). 4. Section 3.3.1 introduces the term RTR (Reencapsulating Tunnel Routers) with no real description of how it functions or relates to ITRs and ETRs. 5. Section 3.4.3 makes reference to the LISP WG. Given that this document will probably outlive the WG, I would suggest re-wording to remove a direct reference to the WG. 6. Section 3.4 has no discussion of EIDs and NATs. Given the global nature of the mapping system, it would seem that NATs don't play well with LISP. There should be some discussion of that. 7. Section 4.1 * s/requires of a /requires a/ * The discussion of SMR should contain a reference to 6830 or a brief discussion of how the SMR is used. 8. Section 5 * I would suggest having a reference to both the MIP and the NEMO specs when discussing mobility. LISP has the potential to operate in a manner conducive with NEMO if the xTR acts as the NEMO Mobile Router. * Should there be some discussion of the mapping system's TTL mechanism impact on mobility support? 9. Section 9 talks about propagating multicast state as (S-EID, G). Does that mean that multicast in LISP is really only allowed to be SSM? 10. I am surprised that there are 2 Security Consideration sections (7 & 9). I am even more surprised that one says "Nothing new here" and the other actually discusses potential issues with the LISP approach. Regards, Brian --IKbSwj5KKpejpDOlGNNtbMGJHqqx8K79P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUtpitAAoJEBOZRqCi7goqmtAH/1ic5+vC1spjn+xbDtEnW/dv 3EpXW8tFhxiyE5ImVOSjE9wgGIxjWr9vPhnuHfp8M/2OYTV1ntHN9vXxieoiLxX9 UjO2KU1JHQ5jGmm0fn+ZwD75qqbJ39rMDd4M97pefWWhpZLk1si8Lwm0RojNAsRo 3DXS72gJ8DHKjWa2kHjWJ23H8/iPyTguOsPg2pAR7ntldPSxYTKJYikqTOsfqG2V MsZ776rAOaB3JTYJcjS+9TKywZTz04GhiECbCdsjzUpw8F9X3wYkxcoLhl94yE7t KPdlE7wtwupomlFs2+YZHfygrPsrq+VSEkvAxrXdPvOXvFYy4oRCOuy14iCDq+I= =LYbi -----END PGP SIGNATURE----- --IKbSwj5KKpejpDOlGNNtbMGJHqqx8K79P-- From nobody Wed Jan 14 08:26:42 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8121A9029 for ; Wed, 14 Jan 2015 08:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSmCwu4inpU1; Wed, 14 Jan 2015 08:26:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7671C1A8BB5; Wed, 14 Jan 2015 08:26:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ggx@gigix.net, draft-ietf-lisp-introduction.all@tools.ietf.org, lisp@ietf.org, lisp-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114162638.14923.73179.idtracker@ietfa.amsl.com> Date: Wed, 14 Jan 2015 08:26:38 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 16:26:40 -0000 IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Wed Jan 14 10:10:57 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCB91AC3BA for ; Wed, 14 Jan 2015 10:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad8674JIFWUs for ; Wed, 14 Jan 2015 10:10:53 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C2F1AC3BC for ; Wed, 14 Jan 2015 10:10:53 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id eu11so11926516pac.11 for ; Wed, 14 Jan 2015 10:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1ZNWHE9tkDqpBmaMlLuN2ihD7wcHpDBbIz27pV+ST5Q=; b=LA5ehA25A/lGCFADg7fKNrLTPhnFli340+76yZDh72YZ82Suk5HI0/nDepFd1tGI06 vM+E6+aGqSV4e6gAybEkJsyQS6OyWqpkHQZSL4FYXih8mw1ysQbsWyfE6pn9U+bMgxjm Z5L/DpqoOf+bV/iqXib/ZK+dA1tTOgADyGVZ8Ic4WEJEiR2EeTsQV63YlWYgZbIpt3md LcH1PUm+SWpBRSBWD7r/L72VxC7oFHThADdwvHOiE7L42/TLldXMe8221bz9T564UrC0 xuN/yyqVeG0a5OULvhQvkGeI98n2XO4YjICD5DrMVbB+mBOwNDlys+r+1B/UVg8dzlVh j3OQ== X-Received: by 10.66.117.199 with SMTP id kg7mr7723199pab.92.1421259052733; Wed, 14 Jan 2015 10:10:52 -0800 (PST) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id v8sm20307313pdp.94.2015.01.14.10.10.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 10:10:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Dino Farinacci In-Reply-To: <54B698A7.1080309@innovationslab.net> Date: Wed, 14 Jan 2015 10:10:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> References: <54B698A7.1080309@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1993) Archived-At: Cc: draft-ietf-lisp-introduction@tools.ietf.org, "lisp@ietf.org" , "lisp-chairs@tools.ietf.org" Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 18:10:56 -0000 Here are some brief responses to your comments Brian. Thanks for doing = the throuogh review. > On Jan 14, 2015, at 8:26 AM, Brian Haberman = wrote: >=20 > All, > I have completed by AD Evaluation of draft-ietf-lisp-introduction > as a part of the IETF publication process. I have some > comments/questions that should be resolved prior to starting an IETF > Last Call. Please let me know if you have any questions on these... >=20 > 1. Section 1 >=20 > * I am going to try and short-circuit the inevitable question that = will > arise about the reference [Chiappa]. Since it is a web page, the RFC > Editor will be concerned by its long-term stability. Is that the best > reference for that text? Anything similar that has been published in = a > conference/journal/RFC/etc.? I will yield to the authors. > * The text uses the terms underlay and overlay without any context (in > the summary bullets). This is easily fixed by augmenting the text in > the 2nd paragraph to identify which networks form the underlay and the > overlay. Those terms aren't used very much in RFC 6830 because those terms seem = to become fashionable with the advent of nv03. If the authors want to = continue to use those terms, I have no problem with that, but would = suggest that the Definition of Terms section say that the underlay is = what is referred to in RFC 6830 as "the underlying core routing system". = And that an "overlay" is the encapsulation relationship between ITRs, = ETRs, PxTRs, and RTRs. > 2. Section 3 (and a few times in 3.5) : = s/inetrworking/internetworking/ >=20 > 3. Section 3.2 >=20 > * Is it correct to say that EIDs are only routable at the edge? This > seems to contradict the text in section 3.5 that says EIDs may be > injected in the global routing system. Well it depends on your reference point. If the overlay is the center of = perspective, then the global routing system is a non-LISP site relative = to the overlay. The whole point is that EIDs are routable where LISP is = not available. And that is true inside of a LISP site where packets are = at a point in the data-path pre-encapsulation or post-decapsulation. > * I find the PI and PA analogies misleading. EIDs are global, but = they > may change their point of attachment. If that occurs, you are not > guaranteed that your EID space does not change. It is desirable that your EIDs do not change. But the scope of EID = mobility may be limited and if a legacy site wants to continue to use = DHCP and address addresses out of, say an enterprise address pool, it = should be able to do that while losing session survivability features. = That is a decision for the organization that is supporting mobility into = its own domain. > * In the example, bullet four mistakenly says that the destination > address of the outer header is set to RLOC_B2 (it should be RLOC_b1). >=20 > 4. Section 3.3.1 introduces the term RTR (Reencapsulating Tunnel > Routers) with no real description of how it functions or relates to = ITRs > and ETRs. Well there are references to it in RFC 6830 and there are many use-cases = for them which we are not allowed to reference since the drafts are not = working group documents. > 5. Section 3.4.3 makes reference to the LISP WG. Given that this > document will probably outlive the WG, I would suggest re-wording to > remove a direct reference to the WG. >=20 > 6. Section 3.4 has no discussion of EIDs and NATs. Given the global > nature of the mapping system, it would seem that NATs don't play well > with LISP. There should be some discussion of that. LISP plays very well with NATs and we have many use-cases which are = alive and being used. But again the draft on NAT-traversal is not a = working group document so it is hard to reference it. EIDs are = translatable by NATs and so are RLOCs. It all depends where the xTR = resides (on the public versus private side of the NAT). > 7. Section 4.1 >=20 > * s/requires of a /requires a/ >=20 > * The discussion of SMR should contain a reference to 6830 or a brief > discussion of how the SMR is used. >=20 > 8. Section 5 >=20 > * I would suggest having a reference to both the MIP and the NEMO = specs > when discussing mobility. LISP has the potential to operate in a = manner > conducive with NEMO if the xTR acts as the NEMO Mobile Router. Well if we do that then there are a ton of other cases where a xTR can = be co-located with other functions (i.e. a simple reference is say a = wifi AP). So singlingly out MIP/NEMO seems to be favoring these = technologies versus others. Why would we want to do that? Plus, it raises questions more than simplifies the understanding of = LISP. This is an intro document. > * Should there be some discussion of the mapping system's TTL = mechanism > impact on mobility support? The TTL is not used for mobility to work. It is the SMR and Map-Notify = mechanisms between xTRs and the mapping system and xTRs, respectively. > 9. Section 9 talks about propagating multicast state as (S-EID, G). > Does that mean that multicast in LISP is really only allowed to be = SSM? We are encouraging SSM but an (RP-EID, G) can be used as well. RFC 6831 = describes all PIM modes. > 10. I am surprised that there are 2 Security Consideration sections (7 = & > 9). I am even more surprised that one says "Nothing new here" and the > other actually discusses potential issues with the LISP approach. >=20 > Regards, > Brian Thanks again, Dino >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Jan 16 08:14:17 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3B61ACE81 for ; Fri, 16 Jan 2015 08:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyXJYU6I1YL6 for ; Fri, 16 Jan 2015 08:14:13 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70811ACE76 for ; Fri, 16 Jan 2015 08:14:12 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so4860958wiw.4 for ; Fri, 16 Jan 2015 08:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YqN8hobrRmK0pMsuU+rd2+IyCsg4eeMWx7Ob6JrI9sY=; b=xcLVo/v0bhJEkIZhuNWq39OEmwmCSP5WAZVbZ/r1mIF6O4H7DAuejZ54qLSbOFBvLg Gc4kxVgW5xT38TvBVTmspMb/ShF2lwMpuyfyQj80fb5t7zqjgcS/uoIidSATKrhpsnTm cq3SVuQ+IB9Qz+siJp0I7/0a1PRevGHan2G/lN/hD1nKrNkClZltCQfr/IGKD3Tnbh8g 0icTabYs86BCcrTnERpgqJtrApGK3KdfPwAfs5tpELxKNTlYhtfZIQZ5en3elkHQiQET Dlj7hmFHeKmifFoWpxAgaEdBTiKGK+hv7Cg1+L4uNN+hSmLseWOhgrVeWZlp21kPjReZ Ffxw== X-Received: by 10.194.184.171 with SMTP id ev11mr29768193wjc.119.1421424851116; Fri, 16 Jan 2015 08:14:11 -0800 (PST) Received: from [192.168.1.135] (167.135.23.95.dynamic.jazztel.es. [95.23.135.167]) by mx.google.com with ESMTPSA id dn2sm3552647wib.14.2015.01.16.08.14.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Jan 2015 08:14:10 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Albert Cabellos In-Reply-To: <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> Date: Fri, 16 Jan 2015 17:14:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1C31C60B-19D7-4421-92C6-878976064E83@gmail.com> References: <54B698A7.1080309@innovationslab.net> <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> To: Dino Farinacci , Brian Haberman X-Mailer: Apple Mail (2.1993) Archived-At: Cc: draft-ietf-lisp-introduction@tools.ietf.org, "lisp@ietf.org" , "lisp-chairs@tools.ietf.org" Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 16:14:15 -0000 Hi Thank you very much for the review, please see inline my replies: > On Jan 14, 2015, at 7:10 PM, Dino Farinacci = wrote: >=20 > Here are some brief responses to your comments Brian. Thanks for doing = the throuogh review. >=20 >> On Jan 14, 2015, at 8:26 AM, Brian Haberman = wrote: >>=20 >> All, >> I have completed by AD Evaluation of draft-ietf-lisp-introduction >> as a part of the IETF publication process. I have some >> comments/questions that should be resolved prior to starting an IETF >> Last Call. Please let me know if you have any questions on these... >>=20 >> 1. Section 1 >>=20 >> * I am going to try and short-circuit the inevitable question that = will >> arise about the reference [Chiappa]. Since it is a web page, the RFC >> Editor will be concerned by its long-term stability. Is that the = best >> reference for that text? Anything similar that has been published in = a >> conference/journal/RFC/etc.? >=20 > I will yield to the authors. Unfortunately I=C2=B4ve been unable to find a more =E2=80=9Cstable=E2=80=9D= publication. However the exact same document is cited in RFC4423 with = the following =E2=80=9Cdisclaimer=E2=80=9D: "(=E2=80=A6) the unpublished Internet Draft "Endpoints and Endpoint = Names" [10] by Noel Chiappa (=E2=80=A6)=E2=80=9D Please let me know if adding a similar sentence is enough. >=20 >> * The text uses the terms underlay and overlay without any context = (in >> the summary bullets). This is easily fixed by augmenting the text in >> the 2nd paragraph to identify which networks form the underlay and = the >> overlay. >=20 > Those terms aren't used very much in RFC 6830 because those terms seem = to become fashionable with the advent of nv03. If the authors want to = continue to use those terms, I have no problem with that, but would = suggest that the Definition of Terms section say that the underlay is = what is referred to in RFC 6830 as "the underlying core routing system". = And that an "overlay" is the encapsulation relationship between ITRs, = ETRs, PxTRs, and RTRs. I think that the second paragraph already introduces many new and = important concepts, what about updating the first two bullet points? o RLOCs have meaning only in the underlay network, **that is the = underlying core routing system.** o EIDs have meaning only in the overlay network unless they are = leaked into the underlay network. **The overlay is the encapsulation = relationship between LISP-capable routers.** >=20 >> 2. Section 3 (and a few times in 3.5) : = s/inetrworking/internetworking/ >>=20 Thanks for catching this typo. >> 3. Section 3.2 >>=20 >> * Is it correct to say that EIDs are only routable at the edge? This >> seems to contradict the text in section 3.5 that says EIDs may be >> injected in the global routing system. >=20 > Well it depends on your reference point. If the overlay is the center = of perspective, then the global routing system is a non-LISP site = relative to the overlay. The whole point is that EIDs are routable where = LISP is not available. And that is true inside of a LISP site where = packets are at a point in the data-path pre-encapsulation or = post-decapsulation. >=20 What about changing the last sentence to: Because of this, EIDs are usually routable at the edge (within LISP = sites) or in the non-LISP Internet. >> * I find the PI and PA analogies misleading. EIDs are global, but = they >> may change their point of attachment. If that occurs, you are not >> guaranteed that your EID space does not change. >=20 > It is desirable that your EIDs do not change. But the scope of EID = mobility may be limited and if a legacy site wants to continue to use = DHCP and address addresses out of, say an enterprise address pool, it = should be able to do that while losing session survivability features. = That is a decision for the organization that is supporting mobility into = its own domain. I suggest removing both analogies (PI and PA), two sentences overall. >=20 >> * In the example, bullet four mistakenly says that the destination >> address of the outer header is set to RLOC_B2 (it should be RLOC_b1). >>=20 Thanks >> 4. Section 3.3.1 introduces the term RTR (Reencapsulating Tunnel >> Routers) with no real description of how it functions or relates to = ITRs >> and ETRs. >=20 > Well there are references to it in RFC 6830 and there are many = use-cases for them which we are not allowed to reference since the = drafts are not working group documents. >=20 What about extending the last sentence of the paragraph? Typically such functions are implemented by Reencapsulating Tunnel = Routers (RTRs), **An RTR can be thought as a router that first acts as = an ETR by decapsulating packets and then as an ITR by encapsulating them = towards another locator.** >> 5. Section 3.4.3 makes reference to the LISP WG. Given that this >> document will probably outlive the WG, I would suggest re-wording to >> remove a direct reference to the WG. Updated sentence: Many of the existing mechanisms to create distributed systems have been = explored and considered for the Mapping System architecture: >>=20 >> 6. Section 3.4 has no discussion of EIDs and NATs. Given the global >> nature of the mapping system, it would seem that NATs don't play well >> with LISP. There should be some discussion of that. >=20 > LISP plays very well with NATs and we have many use-cases which are = alive and being used. But again the draft on NAT-traversal is not a = working group document so it is hard to reference it. EIDs are = translatable by NATs and so are RLOCs. It all depends where the xTR = resides (on the public versus private side of the NAT). I will add a paragraph summarizing section 7 of RFC6832 at the end of = section 3.5. >=20 >> 7. Section 4.1 >>=20 >> * s/requires of a /requires a/ >>=20 Thanks >> * The discussion of SMR should contain a reference to 6830 or a brief >> discussion of how the SMR is used. >>=20 Could you please elaborate further this comment? "Solicit-Map-Request (SMR): SMR is an explicit mechanism to = update mapping information. In particular a special type of Map-Request can be sent on demand by ETRs to request refreshing a mapping. Upon reception of a SMR message, the ITR must refresh the bindings by sending a Map-Request to the Mapping System." >> 8. Section 5 >>=20 >> * I would suggest having a reference to both the MIP and the NEMO = specs >> when discussing mobility. LISP has the potential to operate in a = manner >> conducive with NEMO if the xTR acts as the NEMO Mobile Router. >=20 > Well if we do that then there are a ton of other cases where a xTR can = be co-located with other functions (i.e. a simple reference is say a = wifi AP). So singlingly out MIP/NEMO seems to be favoring these = technologies versus others. Why would we want to do that? >=20 > Plus, it raises questions more than simplifies the understanding of = LISP. This is an intro document. What about adding the following sentence at the end of section 5? The decoupled identity and location provided by LISP allows it to = operate with other layer 2 and layer 3 mobility solutions. >=20 >> * Should there be some discussion of the mapping system's TTL = mechanism >> impact on mobility support? >=20 > The TTL is not used for mobility to work. It is the SMR and Map-Notify = mechanisms between xTRs and the mapping system and xTRs, respectively. True, but mappings from LISP mobile nodes are expected to have a low TTL = (1 min), what about updating the last paragraph to: Whenever the device changes of RLOC, the xTR updates the RLOC of its local mapping and registers it to its Map-Server, **typically with a = low TTL value (1min)**. To avoid the need of a home gateway, the ITR also indicates the RLOC change to all remote devices that have ongoing communications with the device that moved. The combination of both methods ensures the scalability of the system as signaling is strictly limited the Map-Server and to hosts with which communications are ongoing. >=20 >> 9. Section 9 talks about propagating multicast state as (S-EID, G). >> Does that mean that multicast in LISP is really only allowed to be = SSM? >=20 > We are encouraging SSM but an (RP-EID, G) can be used as well. RFC = 6831 describes all PIM modes. >=20 What about rephrasing the last sentence of the Multicast section: LISP [RFC6831] supports all PIM modes, additionally LISP can also = support non-PIM mechanisms to maintain multicast state. >> 10. I am surprised that there are 2 Security Consideration sections = (7 & >> 9). I am even more surprised that one says "Nothing new here" and = the >> other actually discusses potential issues with the LISP approach. >>=20 My fault, Section 7 should be =E2=80=9CLISP Security Considerations=E2=80=9D= Section 9 describes the security considerations for the document itself. Regards Albert From nobody Fri Jan 16 09:48:08 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E081B29E6 for ; Fri, 16 Jan 2015 09:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfhkUHjBX31v for ; Fri, 16 Jan 2015 09:48:04 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2091B29DA for ; Fri, 16 Jan 2015 09:48:04 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id r10so23965768pdi.7 for ; Fri, 16 Jan 2015 09:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IGb7Qkndm87HYbcwm2CifpkDLk5IFlaHg+eiXuXUXnI=; b=vRO9sacsXpYLCQYiOEcpP6at5nlKP7UfeN7UKmTgXgsFesZTqbGcIQWPrVqbEGO8b7 omG9mBdm+Zir5LPHyswDc+aY2OiUrnLHWi5y0BZebqO0qAFo/UB116y2nXqD7VqjNBRo qWcIModLLbG/i6VTtXyhLZqADHnxi8ITuBL8elj2z6iH+vnDQ2vEW9nwsEFxFmfvjmfi k/PubyZuzNpY5MrRvYMpKxIjrLOf5bnLfz0I4/Gm5ri6WbFspsKXBP/+132dwlRXCixV mJHGlxF9vuhBJXzXnEish1oxSOA22QEr7ryXvB93Mf+AashCo80OqCuCXFLj9KcC6b7w IlzQ== X-Received: by 10.66.63.34 with SMTP id d2mr24391348pas.143.1421430483303; Fri, 16 Jan 2015 09:48:03 -0800 (PST) Received: from dino-macbook-4.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id bu4sm4620498pdb.80.2015.01.16.09.48.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Jan 2015 09:48:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Dino Farinacci In-Reply-To: <1C31C60B-19D7-4421-92C6-878976064E83@gmail.com> Date: Fri, 16 Jan 2015 09:48:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <045DEFC6-6A54-4B59-B055-0371AE451CC7@gmail.com> References: <54B698A7.1080309@innovationslab.net> <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> <1C31C60B-19D7-4421-92C6-878976064E83@gmail.com> To: Albert Cabellos X-Mailer: Apple Mail (2.1993) Archived-At: Cc: draft-ietf-lisp-introduction@tools.ietf.org, "lisp-chairs@tools.ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 17:48:06 -0000 Albert, I agree with all your changes and suggestions. Thanks. Dino > On Jan 16, 2015, at 8:14 AM, Albert Cabellos = wrote: >=20 >=20 > Hi >=20 > Thank you very much for the review, please see inline my replies: >=20 >> On Jan 14, 2015, at 7:10 PM, Dino Farinacci = wrote: >>=20 >> Here are some brief responses to your comments Brian. Thanks for = doing the throuogh review. >>=20 >>> On Jan 14, 2015, at 8:26 AM, Brian Haberman = wrote: >>>=20 >>> All, >>> I have completed by AD Evaluation of draft-ietf-lisp-introduction >>> as a part of the IETF publication process. I have some >>> comments/questions that should be resolved prior to starting an IETF >>> Last Call. Please let me know if you have any questions on these... >>>=20 >>> 1. Section 1 >>>=20 >>> * I am going to try and short-circuit the inevitable question that = will >>> arise about the reference [Chiappa]. Since it is a web page, the = RFC >>> Editor will be concerned by its long-term stability. Is that the = best >>> reference for that text? Anything similar that has been published = in a >>> conference/journal/RFC/etc.? >>=20 >> I will yield to the authors. >=20 > Unfortunately I=C2=B4ve been unable to find a more =E2=80=9Cstable=E2=80= =9D publication. However the exact same document is cited in RFC4423 = with the following =E2=80=9Cdisclaimer=E2=80=9D: >=20 > "(=E2=80=A6) the unpublished Internet Draft "Endpoints and Endpoint = Names" [10] by Noel Chiappa (=E2=80=A6)=E2=80=9D >=20 > Please let me know if adding a similar sentence is enough. >=20 >>=20 >>> * The text uses the terms underlay and overlay without any context = (in >>> the summary bullets). This is easily fixed by augmenting the text = in >>> the 2nd paragraph to identify which networks form the underlay and = the >>> overlay. >>=20 >> Those terms aren't used very much in RFC 6830 because those terms = seem to become fashionable with the advent of nv03. If the authors want = to continue to use those terms, I have no problem with that, but would = suggest that the Definition of Terms section say that the underlay is = what is referred to in RFC 6830 as "the underlying core routing system". = And that an "overlay" is the encapsulation relationship between ITRs, = ETRs, PxTRs, and RTRs. >=20 > I think that the second paragraph already introduces many new and = important concepts, what about updating the first two bullet points? >=20 > o RLOCs have meaning only in the underlay network, **that is the = underlying core routing system.** >=20 > o EIDs have meaning only in the overlay network unless they are = leaked into the underlay network. **The overlay is the encapsulation = relationship between LISP-capable routers.** >=20 >>=20 >>> 2. Section 3 (and a few times in 3.5) : = s/inetrworking/internetworking/ >>>=20 >=20 > Thanks for catching this typo. >=20 >>> 3. Section 3.2 >>>=20 >>> * Is it correct to say that EIDs are only routable at the edge? = This >>> seems to contradict the text in section 3.5 that says EIDs may be >>> injected in the global routing system. >>=20 >> Well it depends on your reference point. If the overlay is the center = of perspective, then the global routing system is a non-LISP site = relative to the overlay. The whole point is that EIDs are routable where = LISP is not available. And that is true inside of a LISP site where = packets are at a point in the data-path pre-encapsulation or = post-decapsulation. >>=20 >=20 > What about changing the last sentence to: >=20 > Because of this, EIDs are usually routable at the edge (within LISP = sites) or in the non-LISP Internet. >=20 >>> * I find the PI and PA analogies misleading. EIDs are global, but = they >>> may change their point of attachment. If that occurs, you are not >>> guaranteed that your EID space does not change. >>=20 >> It is desirable that your EIDs do not change. But the scope of EID = mobility may be limited and if a legacy site wants to continue to use = DHCP and address addresses out of, say an enterprise address pool, it = should be able to do that while losing session survivability features. = That is a decision for the organization that is supporting mobility into = its own domain. >=20 > I suggest removing both analogies (PI and PA), two sentences overall. >=20 >>=20 >>> * In the example, bullet four mistakenly says that the destination >>> address of the outer header is set to RLOC_B2 (it should be = RLOC_b1). >>>=20 >=20 > Thanks >=20 >>> 4. Section 3.3.1 introduces the term RTR (Reencapsulating Tunnel >>> Routers) with no real description of how it functions or relates to = ITRs >>> and ETRs. >>=20 >> Well there are references to it in RFC 6830 and there are many = use-cases for them which we are not allowed to reference since the = drafts are not working group documents. >>=20 >=20 > What about extending the last sentence of the paragraph? >=20 > Typically such functions are implemented by Reencapsulating Tunnel = Routers (RTRs), **An RTR can be thought as a router that first acts as = an ETR by decapsulating packets and then as an ITR by encapsulating them = towards another locator.** >=20 >=20 >>> 5. Section 3.4.3 makes reference to the LISP WG. Given that this >>> document will probably outlive the WG, I would suggest re-wording to >>> remove a direct reference to the WG. >=20 > Updated sentence: >=20 > Many of the existing mechanisms to create distributed systems have = been explored and considered for the Mapping System architecture: >=20 >>>=20 >>> 6. Section 3.4 has no discussion of EIDs and NATs. Given the global >>> nature of the mapping system, it would seem that NATs don't play = well >>> with LISP. There should be some discussion of that. >>=20 >> LISP plays very well with NATs and we have many use-cases which are = alive and being used. But again the draft on NAT-traversal is not a = working group document so it is hard to reference it. EIDs are = translatable by NATs and so are RLOCs. It all depends where the xTR = resides (on the public versus private side of the NAT). >=20 > I will add a paragraph summarizing section 7 of RFC6832 at the end of = section 3.5. >=20 >>=20 >>> 7. Section 4.1 >>>=20 >>> * s/requires of a /requires a/ >>>=20 >=20 > Thanks >=20 >>> * The discussion of SMR should contain a reference to 6830 or a = brief >>> discussion of how the SMR is used. >>>=20 >=20 > Could you please elaborate further this comment? >=20 > "Solicit-Map-Request (SMR): SMR is an explicit mechanism to = update > mapping information. In particular a special type of Map-Request > can be sent on demand by ETRs to request refreshing a mapping. > Upon reception of a SMR message, the ITR must refresh the = bindings > by sending a Map-Request to the Mapping System." >=20 >>> 8. Section 5 >>>=20 >>> * I would suggest having a reference to both the MIP and the NEMO = specs >>> when discussing mobility. LISP has the potential to operate in a = manner >>> conducive with NEMO if the xTR acts as the NEMO Mobile Router. >>=20 >> Well if we do that then there are a ton of other cases where a xTR = can be co-located with other functions (i.e. a simple reference is say a = wifi AP). So singlingly out MIP/NEMO seems to be favoring these = technologies versus others. Why would we want to do that? >>=20 >> Plus, it raises questions more than simplifies the understanding of = LISP. This is an intro document. >=20 > What about adding the following sentence at the end of section 5? >=20 > The decoupled identity and location provided by LISP allows it to = operate with other layer 2 and layer 3 mobility solutions. >=20 >>=20 >>> * Should there be some discussion of the mapping system's TTL = mechanism >>> impact on mobility support? >>=20 >> The TTL is not used for mobility to work. It is the SMR and = Map-Notify mechanisms between xTRs and the mapping system and xTRs, = respectively. >=20 > True, but mappings from LISP mobile nodes are expected to have a low = TTL (1 min), what about updating the last paragraph to: >=20 > Whenever the device changes of RLOC, the xTR updates the RLOC of its > local mapping and registers it to its Map-Server, **typically with a = low TTL value (1min)**. To avoid the need > of a home gateway, the ITR also indicates the RLOC change to all > remote devices that have ongoing communications with the device that > moved. The combination of both methods ensures the scalability of > the system as signaling is strictly limited the Map-Server and to > hosts with which communications are ongoing. >>=20 >>> 9. Section 9 talks about propagating multicast state as (S-EID, G). >>> Does that mean that multicast in LISP is really only allowed to be = SSM? >>=20 >> We are encouraging SSM but an (RP-EID, G) can be used as well. RFC = 6831 describes all PIM modes. >>=20 >=20 > What about rephrasing the last sentence of the Multicast section: >=20 > LISP [RFC6831] supports all PIM modes, additionally LISP can also = support non-PIM mechanisms to maintain multicast state. >=20 >=20 >>> 10. I am surprised that there are 2 Security Consideration sections = (7 & >>> 9). I am even more surprised that one says "Nothing new here" and = the >>> other actually discusses potential issues with the LISP approach. >>>=20 >=20 > My fault, Section 7 should be =E2=80=9CLISP Security Considerations=E2=80= =9D >=20 > Section 9 describes the security considerations for the document = itself. >=20 > Regards >=20 > Albert >=20 >=20 >=20 From nobody Sat Jan 17 02:50:52 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6DC1ACCE7 for ; Sat, 17 Jan 2015 02:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRduHmEUQuhs for ; Sat, 17 Jan 2015 02:50:48 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id DC6EE1ACCE4 for ; Sat, 17 Jan 2015 02:50:48 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C4DDF180489; Sat, 17 Jan 2015 02:50:41 -0800 (PST) To: gschudel@cisco.com, atjain@juniper.net, vimoreno@cisco.com, brian@innovationslab.net, ted.lemon@nominum.com, jmh@joelhalpern.com, ggx@gigix.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150117105041.C4DDF180489@rfc-editor.org> Date: Sat, 17 Jan 2015 02:50:41 -0800 (PST) Archived-At: Cc: lisp@ietf.org, rfc-editor@rfc-editor.org Subject: [lisp] [Technical Errata Reported] RFC7052 (4235) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 10:50:51 -0000 The following errata report has been submitted for RFC7052, "Locator/ID Separation Protocol (LISP) MIB". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7052&eid=4235 -------------------------------------- Type: Technical Reported by: Isidor Kouvelas Section: 7 Original Text ------------- Example 3: As an example where LCAF is used, suppose that the IPv4 EID-Prefix stored is 192.0.2.0/24 and it is part of LISP Instance ID 101. In this case, the values within lispMapCacheEntry would be: lispMapCacheEidLength = 11 lispMapCacheEid = 16387, 7, 2, 101, 1, 192.0.2.0, 24 ... [skip] ... where 11 is the total length in octets of the next object (lispMapCacheEID of type LispAddressType). Then, the value 16387 indicates the LCAF AF (see the IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 7 indicates that the LCAF AF is 7 octets in length in this case, 2 indicates that LCAF Type 2 encoding is used (see the LCAF document), 101 gives the Instance ID, 1 gives the AFI (per the IANA-ADDRESS-FAMILY-NUMBERS-MIB) for an IPv4 address, 192.0.2.0 is the IPv4 address, and 24 is the mask-length in bits. Note that the lispMapCacheEidLength value of 11 octets is used to compute the length of the last field in lispMapCacheEid to be 1 octet -- as computed by 11 - (2 + 1 + 1 + 1 + 1 + 4) = 1. Corrected Text -------------- Example 3: As an example where LCAF is used, suppose that the IPv4 EID-Prefix stored is 192.0.2.0/24 and it is part of LISP Instance ID 101. In this case, the values within lispMapCacheEntry would be: lispMapCacheEidLength = 14 lispMapCacheEid = 16387, 10, 2, 101, 1, 192.0.2.0, 24 ... [skip] ... where 14 is the total length in octets of the next object (lispMapCacheEID of type LispAddressType). Then, the value 16387 indicates the LCAF AF (see the IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 10 indicates that the LCAF AF is 10 octets in length in this case, 2 indicates that LCAF Type 2 encoding is used (see the LCAF document), 101 gives the Instance ID, 1 gives the AFI (per the IANA-ADDRESS-FAMILY-NUMBERS-MIB) for an IPv4 address, 192.0.2.0 is the IPv4 address, and 24 is the mask-length in bits. Note that the lispMapCacheEidLength value of 14 octets is used to compute the length of the last field in lispMapCacheEid to be 1 octet -- as computed by 14 - (2 + 1 + 1 + 3 + 2 + 4) = 1. Notes ----- The Instance ID within the type 2 LCAF is 24 bits and requires 3 octets (incorrectly calculated as 1) The AFI within the LCAF type 2 requires 2 octets (incorrectly calculated as 1) Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7052 (draft-ietf-lisp-mib-13) -------------------------------------- Title : Locator/ID Separation Protocol (LISP) MIB Publication Date : October 2013 Author(s) : G. Schudel, A. Jain, V. Moreno Category : EXPERIMENTAL Source : Locator/ID Separation Protocol Area : Internet Stream : IETF Verifying Party : IESG From nobody Mon Jan 19 06:36:19 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DF21B2A9D for ; Mon, 19 Jan 2015 06:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8HNiQzilcDL; Mon, 19 Jan 2015 06:36:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42ED71B2A9A; Mon, 19 Jan 2015 06:36:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-lisp-eid-block-mgmnt.all@tools.ietf.org, damien.saucez@gmail.com, lisp@ietf.org, lisp-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119143615.12420.19825.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 06:36:15 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 14:36:18 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ From nobody Mon Jan 19 06:45:12 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818A21B2A97 for ; Mon, 19 Jan 2015 06:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u91Nkn0zTlzO for ; Mon, 19 Jan 2015 06:45:08 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A491ACE94 for ; Mon, 19 Jan 2015 06:45:08 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 34E8E880E1; Mon, 19 Jan 2015 06:45:08 -0800 (PST) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A274C71C0002; Mon, 19 Jan 2015 06:45:07 -0800 (PST) Message-ID: <54BD186C.9020401@innovationslab.net> Date: Mon, 19 Jan 2015 09:45:00 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Dino Farinacci References: <54B698A7.1080309@innovationslab.net> <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> In-Reply-To: <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kMouf4AeAQCs2t2sPFrlpoIBG807wrJJJ" Archived-At: Cc: draft-ietf-lisp-introduction@tools.ietf.org, "lisp@ietf.org" , "lisp-chairs@tools.ietf.org" Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 14:45:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kMouf4AeAQCs2t2sPFrlpoIBG807wrJJJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dino, On 1/14/15 1:10 PM, Dino Farinacci wrote: > Here are some brief responses to your comments Brian. Thanks for > doing the throuogh review. >=20 >> On Jan 14, 2015, at 8:26 AM, Brian Haberman >> wrote: >>=20 >> All, I have completed by AD Evaluation of >> draft-ietf-lisp-introduction as a part of the IETF publication >> process. I have some comments/questions that should be resolved >> prior to starting an IETF Last Call. Please let me know if you >> have any questions on these... >>=20 >> 1. Section 1 >>=20 >> * I am going to try and short-circuit the inevitable question that >> will arise about the reference [Chiappa]. Since it is a web page, >> the RFC Editor will be concerned by its long-term stability. Is >> that the best reference for that text? Anything similar that has >> been published in a conference/journal/RFC/etc.? >=20 > I will yield to the authors. >=20 >> * The text uses the terms underlay and overlay without any context >> (in the summary bullets). This is easily fixed by augmenting the >> text in the 2nd paragraph to identify which networks form the >> underlay and the overlay. >=20 > Those terms aren't used very much in RFC 6830 because those terms > seem to become fashionable with the advent of nv03. If the authors > want to continue to use those terms, I have no problem with that, but > would suggest that the Definition of Terms section say that the > underlay is what is referred to in RFC 6830 as "the underlying core > routing system". And that an "overlay" is the encapsulation > relationship between ITRs, ETRs, PxTRs, and RTRs. That is fine with me. >=20 >> 2. Section 3 (and a few times in 3.5) : >> s/inetrworking/internetworking/ >>=20 >> 3. Section 3.2 >>=20 >> * Is it correct to say that EIDs are only routable at the edge? >> This seems to contradict the text in section 3.5 that says EIDs may >> be injected in the global routing system. >=20 > Well it depends on your reference point. If the overlay is the center > of perspective, then the global routing system is a non-LISP site > relative to the overlay. The whole point is that EIDs are routable > where LISP is not available. And that is true inside of a LISP site > where packets are at a point in the data-path pre-encapsulation or > post-decapsulation. I agree with what you say above, but the document explicitly says EIDs are only routable at the edge and that is not the case in non-LISP parts of the Internet. The document just needs to be more explicit on that poi= nt. >=20 >> * I find the PI and PA analogies misleading. EIDs are global, but >> they may change their point of attachment. If that occurs, you are >> not guaranteed that your EID space does not change. >=20 > It is desirable that your EIDs do not change. But the scope of EID > mobility may be limited and if a legacy site wants to continue to use > DHCP and address addresses out of, say an enterprise address pool, it > should be able to do that while losing session survivability > features. That is a decision for the organization that is supporting > mobility into its own domain. Given my concern and your comment above, how does the EID/PI analogy hold= ? >=20 >> * In the example, bullet four mistakenly says that the destination=20 >> address of the outer header is set to RLOC_B2 (it should be >> RLOC_b1). >>=20 >> 4. Section 3.3.1 introduces the term RTR (Reencapsulating Tunnel=20 >> Routers) with no real description of how it functions or relates to >> ITRs and ETRs. >=20 > Well there are references to it in RFC 6830 and there are many > use-cases for them which we are not allowed to reference since the > drafts are not working group documents. So, Section 3.3.1 should point the reader to 6830 when it mentions the RT= R. >=20 >> 5. Section 3.4.3 makes reference to the LISP WG. Given that this=20 >> document will probably outlive the WG, I would suggest re-wording >> to remove a direct reference to the WG. >>=20 >> 6. Section 3.4 has no discussion of EIDs and NATs. Given the >> global nature of the mapping system, it would seem that NATs don't >> play well with LISP. There should be some discussion of that. >=20 > LISP plays very well with NATs and we have many use-cases which are > alive and being used. But again the draft on NAT-traversal is not a > working group document so it is hard to reference it. EIDs are > translatable by NATs and so are RLOCs. It all depends where the xTR > resides (on the public versus private side of the NAT). Even though the NAT-traversal draft is not a WG draft, this document can spend a few cycles talking about the general ability of LISP to operate in the face of NATs. >=20 >> 7. Section 4.1 >>=20 >> * s/requires of a /requires a/ >>=20 >> * The discussion of SMR should contain a reference to 6830 or a >> brief discussion of how the SMR is used. >>=20 >> 8. Section 5 >>=20 >> * I would suggest having a reference to both the MIP and the NEMO >> specs when discussing mobility. LISP has the potential to operate >> in a manner conducive with NEMO if the xTR acts as the NEMO Mobile >> Router. >=20 > Well if we do that then there are a ton of other cases where a xTR > can be co-located with other functions (i.e. a simple reference is > say a wifi AP). So singlingly out MIP/NEMO seems to be favoring these > technologies versus others. Why would we want to do that? MIP and NEMO are the general modes of mobility that most closely approximate what is being discussed in Section 5. My thought was to give the reader a basis for how mobility in LISP operates, including the drawbacks. >=20 > Plus, it raises questions more than simplifies the understanding of > LISP. This is an intro document. >=20 >> * Should there be some discussion of the mapping system's TTL >> mechanism impact on mobility support? >=20 > The TTL is not used for mobility to work. It is the SMR and > Map-Notify mechanisms between xTRs and the mapping system and xTRs, > respectively. Shouldn't that be mentioned somewhere in this draft? >=20 >> 9. Section 9 talks about propagating multicast state as (S-EID, >> G). Does that mean that multicast in LISP is really only allowed to >> be SSM? >=20 > We are encouraging SSM but an (RP-EID, G) can be used as well. RFC > 6831 describes all PIM modes. So, to avoid erroneous assumptions, perhaps the intro should mention that= =2E Regards, Brian --kMouf4AeAQCs2t2sPFrlpoIBG807wrJJJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUvRh3AAoJEBOZRqCi7goqujsIANgeYNZ3gmZXYf52/XsxzO7V POGiP121eDYuGMUrMBirh8Ku1I35t2seD1FKTY6GA5QsQhwhvcRfuLLR8iU/lZAN p7V7gSJiaehDzhXyuelgeQGmToBc+MvwS1S1k3qUEFFgMQeSKE+MrXYhPurVsxbG CBFC0ReAZyW2x75yC9q5ftk87hlxtPMhhU7ioTZjy9v3b4S8Mtmx441ePkKQWbaq WBLxSwJ2mpzWkcrKDLw/ieeI1guLw7kpF6bDCT/As7frndbXJTZo7QyueS3+lQKY e2zvKoP2wQPWE1YDsHU7RQnQw7qC6jFnyFVw9l682Ryedd+IFKuv/qL8YrB5vl0= =cpb5 -----END PGP SIGNATURE----- --kMouf4AeAQCs2t2sPFrlpoIBG807wrJJJ-- From nobody Mon Jan 19 06:58:23 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2641B2A94 for ; Mon, 19 Jan 2015 06:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnr_v1oPxahD for ; Mon, 19 Jan 2015 06:58:18 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6AC01B29ED for ; Mon, 19 Jan 2015 06:58:18 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8B9B6880E1; Mon, 19 Jan 2015 06:58:18 -0800 (PST) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C1B0671C0002; Mon, 19 Jan 2015 06:58:17 -0800 (PST) Message-ID: <54BD1B88.30900@innovationslab.net> Date: Mon, 19 Jan 2015 09:58:16 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Albert Cabellos , Dino Farinacci References: <54B698A7.1080309@innovationslab.net> <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> <1C31C60B-19D7-4421-92C6-878976064E83@gmail.com> In-Reply-To: <1C31C60B-19D7-4421-92C6-878976064E83@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="omaKviGMNG2g6nAKNSFrrpH70aUqBigwT" Archived-At: Cc: draft-ietf-lisp-introduction@tools.ietf.org, "lisp@ietf.org" , "lisp-chairs@tools.ietf.org" Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 14:58:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --omaKviGMNG2g6nAKNSFrrpH70aUqBigwT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Albert, On 1/16/15 11:14 AM, Albert Cabellos wrote: >=20 > Hi >=20 > Thank you very much for the review, please see inline my replies: >=20 >> On Jan 14, 2015, at 7:10 PM, Dino Farinacci >> wrote: >>=20 >> Here are some brief responses to your comments Brian. Thanks for >> doing the throuogh review. >>=20 >>> On Jan 14, 2015, at 8:26 AM, Brian Haberman >>> wrote: >>>=20 >>> All, I have completed by AD Evaluation of >>> draft-ietf-lisp-introduction as a part of the IETF publication >>> process. I have some comments/questions that should be resolved >>> prior to starting an IETF Last Call. Please let me know if you >>> have any questions on these... >>>=20 >>> 1. Section 1 >>>=20 >>> * I am going to try and short-circuit the inevitable question >>> that will arise about the reference [Chiappa]. Since it is a web >>> page, the RFC Editor will be concerned by its long-term >>> stability. Is that the best reference for that text? Anything >>> similar that has been published in a=20 >>> conference/journal/RFC/etc.? >>=20 >> I will yield to the authors. >=20 > Unfortunately I=C2=B4ve been unable to find a more =E2=80=9Cstable=E2=80= =9D publication. > However the exact same document is cited in RFC4423 with the > following =E2=80=9Cdisclaimer=E2=80=9D: >=20 > "(=E2=80=A6) the unpublished Internet Draft "Endpoints and Endpoint Nam= es" > [10] by Noel Chiappa (=E2=80=A6)=E2=80=9D >=20 > Please let me know if adding a similar sentence is enough. I think that is fine. Just be prepared to work with the RFC Editor on th= is. >=20 >>=20 >>> * The text uses the terms underlay and overlay without any >>> context (in the summary bullets). This is easily fixed by >>> augmenting the text in the 2nd paragraph to identify which >>> networks form the underlay and the overlay. >>=20 >> Those terms aren't used very much in RFC 6830 because those terms >> seem to become fashionable with the advent of nv03. If the authors >> want to continue to use those terms, I have no problem with that, >> but would suggest that the Definition of Terms section say that the >> underlay is what is referred to in RFC 6830 as "the underlying core >> routing system". And that an "overlay" is the encapsulation >> relationship between ITRs, ETRs, PxTRs, and RTRs. >=20 > I think that the second paragraph already introduces many new and > important concepts, what about updating the first two bullet points? >=20 > o RLOCs have meaning only in the underlay network, **that is the > underlying core routing system.** >=20 > o EIDs have meaning only in the overlay network unless they are > leaked into the underlay network. **The overlay is the encapsulation > relationship between LISP-capable routers.** That works. >=20 >>=20 >>> 2. Section 3 (and a few times in 3.5) : >>> s/inetrworking/internetworking/ >>>=20 >=20 > Thanks for catching this typo. >=20 >>> 3. Section 3.2 >>>=20 >>> * Is it correct to say that EIDs are only routable at the edge? >>> This seems to contradict the text in section 3.5 that says EIDs >>> may be injected in the global routing system. >>=20 >> Well it depends on your reference point. If the overlay is the >> center of perspective, then the global routing system is a non-LISP >> site relative to the overlay. The whole point is that EIDs are >> routable where LISP is not available. And that is true inside of a >> LISP site where packets are at a point in the data-path >> pre-encapsulation or post-decapsulation. >>=20 >=20 > What about changing the last sentence to: >=20 > Because of this, EIDs are usually routable at the edge (within LISP > sites) or in the non-LISP Internet. Yes. >=20 >>> * I find the PI and PA analogies misleading. EIDs are global, >>> but they may change their point of attachment. If that occurs, >>> you are not guaranteed that your EID space does not change. >>=20 >> It is desirable that your EIDs do not change. But the scope of EID >> mobility may be limited and if a legacy site wants to continue to >> use DHCP and address addresses out of, say an enterprise address >> pool, it should be able to do that while losing session >> survivability features. That is a decision for the organization >> that is supporting mobility into its own domain. >=20 > I suggest removing both analogies (PI and PA), two sentences > overall. >=20 Ok. >>=20 >>> * In the example, bullet four mistakenly says that the >>> destination address of the outer header is set to RLOC_B2 (it >>> should be RLOC_b1). >>>=20 >=20 > Thanks >=20 >>> 4. Section 3.3.1 introduces the term RTR (Reencapsulating Tunnel=20 >>> Routers) with no real description of how it functions or relates >>> to ITRs and ETRs. >>=20 >> Well there are references to it in RFC 6830 and there are many >> use-cases for them which we are not allowed to reference since the >> drafts are not working group documents. >>=20 >=20 > What about extending the last sentence of the paragraph? >=20 > Typically such functions are implemented by Reencapsulating Tunnel > Routers (RTRs), **An RTR can be thought as a router that first acts > as an ETR by decapsulating packets and then as an ITR by > encapsulating them towards another locator.** >=20 The above plus a reference to 6830 would be good. >=20 >>> 5. Section 3.4.3 makes reference to the LISP WG. Given that >>> this document will probably outlive the WG, I would suggest >>> re-wording to remove a direct reference to the WG. >=20 > Updated sentence: >=20 > Many of the existing mechanisms to create distributed systems have > been explored and considered for the Mapping System architecture: Yes. >=20 >>>=20 >>> 6. Section 3.4 has no discussion of EIDs and NATs. Given the >>> global nature of the mapping system, it would seem that NATs >>> don't play well with LISP. There should be some discussion of >>> that. >>=20 >> LISP plays very well with NATs and we have many use-cases which are >> alive and being used. But again the draft on NAT-traversal is not >> a working group document so it is hard to reference it. EIDs are >> translatable by NATs and so are RLOCs. It all depends where the xTR >> resides (on the public versus private side of the NAT). >=20 > I will add a paragraph summarizing section 7 of RFC6832 at the end of > section 3.5. >=20 Sounds good. >>=20 >>> 7. Section 4.1 >>>=20 >>> * s/requires of a /requires a/ >>>=20 >=20 > Thanks >=20 >>> * The discussion of SMR should contain a reference to 6830 or a >>> brief discussion of how the SMR is used. >>>=20 >=20 > Could you please elaborate further this comment? >=20 > "Solicit-Map-Request (SMR): SMR is an explicit mechanism to update=20 > mapping information. In particular a special type of Map-Request can > be sent on demand by ETRs to request refreshing a mapping. Upon > reception of a SMR message, the ITR must refresh the bindings by > sending a Map-Request to the Mapping System." There are more interesting conditions/rules for the use of SMR that are only found in RFC 6830. I am suggesting adding a reference to 6830 at this point so readers know where to go to find more info on the SMR. >=20 >>> 8. Section 5 >>>=20 >>> * I would suggest having a reference to both the MIP and the NEMO >>> specs when discussing mobility. LISP has the potential to >>> operate in a manner conducive with NEMO if the xTR acts as the >>> NEMO Mobile Router. >>=20 >> Well if we do that then there are a ton of other cases where a xTR >> can be co-located with other functions (i.e. a simple reference is >> say a wifi AP). So singlingly out MIP/NEMO seems to be favoring >> these technologies versus others. Why would we want to do that? >>=20 >> Plus, it raises questions more than simplifies the understanding of >> LISP. This is an intro document. >=20 > What about adding the following sentence at the end of section 5? >=20 > The decoupled identity and location provided by LISP allows it to > operate with other layer 2 and layer 3 mobility solutions. The text talks about both network (NEMO) and host (MIP) mobility. I am not concerned with LISP interacting with those protocols, I am thinking of how LISP replaces those protocols. The descriptions in Section 5 align with very well (i.e., the first paragraph describes LISP replacing NEMO and the second paragraph describes LISP replacing MIP). My proposal was to simply add references in those paragraphs to the mobility protocol that LISP is approximately. I do like your proposed addition in order to highlight that LISP will not interfere with other mobility solutions. >=20 >>=20 >>> * Should there be some discussion of the mapping system's TTL >>> mechanism impact on mobility support? >>=20 >> The TTL is not used for mobility to work. It is the SMR and >> Map-Notify mechanisms between xTRs and the mapping system and xTRs, >> respectively. >=20 > True, but mappings from LISP mobile nodes are expected to have a low > TTL (1 min), what about updating the last paragraph to: >=20 > Whenever the device changes of RLOC, the xTR updates the RLOC of its=20 > local mapping and registers it to its Map-Server, **typically with a > low TTL value (1min)**. To avoid the need of a home gateway, the ITR > also indicates the RLOC change to all remote devices that have > ongoing communications with the device that moved. The combination of > both methods ensures the scalability of the system as signaling is > strictly limited the Map-Server and to hosts with which > communications are ongoing. The above would be good. >>=20 >>> 9. Section 9 talks about propagating multicast state as (S-EID, >>> G). Does that mean that multicast in LISP is really only allowed >>> to be SSM? >>=20 >> We are encouraging SSM but an (RP-EID, G) can be used as well. RFC >> 6831 describes all PIM modes. >>=20 >=20 > What about rephrasing the last sentence of the Multicast section: >=20 > LISP [RFC6831] supports all PIM modes, additionally LISP can also > support non-PIM mechanisms to maintain multicast state. >=20 Yes. >=20 >>> 10. I am surprised that there are 2 Security Consideration >>> sections (7 & 9). I am even more surprised that one says >>> "Nothing new here" and the other actually discusses potential >>> issues with the LISP approach. >>>=20 >=20 > My fault, Section 7 should be =E2=80=9CLISP Security Considerations=E2=80= =9D >=20 > Section 9 describes the security considerations for the document > itself. I think maintaining two security consideration sections will be confusing. Either document that *this* document introduces no new security issues or have the security considerations section summarize the security impacts of LISP. Regards, Brian --omaKviGMNG2g6nAKNSFrrpH70aUqBigwT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUvRuNAAoJEBOZRqCi7goqAYwH/2HxY3qXmUzTlJhzTLJeJ+fY jw01OB97BEDjhOqRI8QvXBKpKQ1c4bXSYGRvkfFgPFw+XfEX1lw/3z15kqdIjPN7 TuvS8KXZT6anrbxqWrDQCglyoot8VCq4qY2RfddifY6HrEUR/smgEC99X7w0L5eK C/MMVK/MuR7VfI7BmRDxUFl3EjN9se1gulEWEtw6xIULJzXs+lPwiZLzY4V2naic mcretP+99kjgUoX+plqLUGHqPCspyiaGAFTp8OhHrI8qYOZAEqE0sQJqoeFQfzfu 7ws31aLpWXwUljvblLl2G1V1+JUIwqFhrQ/i0DX6wZj3j8rT5ZIbptaDRz4QBMY= =MES6 -----END PGP SIGNATURE----- --omaKviGMNG2g6nAKNSFrrpH70aUqBigwT-- From nobody Mon Jan 19 09:56:57 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734CC1B2BDF for ; Mon, 19 Jan 2015 09:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP4E-jF15b_E for ; Mon, 19 Jan 2015 09:56:52 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654ED1B2BD7 for ; Mon, 19 Jan 2015 09:56:52 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id bj1so40107936pad.9 for ; Mon, 19 Jan 2015 09:56:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U35Bi2lkz+U2q2yxIZiLKvngfQ8NXgC4SRjZ9D0XEuE=; b=DBlmkhpppJ6dCpue8zWUYJdvK8MuBnkguJvlB2rOBelvvg4vL1riDxagU8c1yXAKGl YB+GmhaK5uhkwSeK5mUdHkIeg5Igey/qKoDTPcZirk5vKdxOSld9q06F9JEdEaCmYP7Q RyUVBmSRASCUGuM4J7wEBhI0qDX/l6WyAWvCZ8kirYRNW9oRqiB7RC1RXlscPwzVpvfk iur5TMvIL6Ry3kN2atTzYN7B9n1STz3UUtbq40JSESJTTdd/pH2CQU5eWdBJ05rj2m2X S1CVCvrX6ooqZ1+U7b46SkmllnaN5fz3bNPmKYTCH3929mL0jkX1tVhkITQFjCGT2yPx ImKA== X-Received: by 10.66.97.6 with SMTP id dw6mr20106410pab.114.1421690211654; Mon, 19 Jan 2015 09:56:51 -0800 (PST) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id uk5sm732764pbc.17.2015.01.19.09.56.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Jan 2015 09:56:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Dino Farinacci In-Reply-To: <54BD186C.9020401@innovationslab.net> Date: Mon, 19 Jan 2015 09:56:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <35BBD0D7-FBC9-4B39-9BEF-BBBC7AD61583@gmail.com> References: <54B698A7.1080309@innovationslab.net> <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> <54BD186C.9020401@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1993) Archived-At: Cc: draft-ietf-lisp-introduction@tools.ietf.org, "lisp@ietf.org" , "lisp-chairs@tools.ietf.org" Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 17:56:54 -0000 Since you responded Brian to Albert's email and have commented and = agreed to most of the changes, I don't need to respond to each point = below. I think we are golden. Agree? Dino > On Jan 19, 2015, at 6:45 AM, Brian Haberman = wrote: >=20 > Hi Dino, >=20 > On 1/14/15 1:10 PM, Dino Farinacci wrote: >> Here are some brief responses to your comments Brian. Thanks for >> doing the throuogh review. >>=20 >>> On Jan 14, 2015, at 8:26 AM, Brian Haberman >>> wrote: >>>=20 >>> All, I have completed by AD Evaluation of >>> draft-ietf-lisp-introduction as a part of the IETF publication >>> process. I have some comments/questions that should be resolved >>> prior to starting an IETF Last Call. Please let me know if you >>> have any questions on these... >>>=20 >>> 1. Section 1 >>>=20 >>> * I am going to try and short-circuit the inevitable question that >>> will arise about the reference [Chiappa]. Since it is a web page, >>> the RFC Editor will be concerned by its long-term stability. Is >>> that the best reference for that text? Anything similar that has >>> been published in a conference/journal/RFC/etc.? >>=20 >> I will yield to the authors. >>=20 >>> * The text uses the terms underlay and overlay without any context >>> (in the summary bullets). This is easily fixed by augmenting the >>> text in the 2nd paragraph to identify which networks form the >>> underlay and the overlay. >>=20 >> Those terms aren't used very much in RFC 6830 because those terms >> seem to become fashionable with the advent of nv03. If the authors >> want to continue to use those terms, I have no problem with that, but >> would suggest that the Definition of Terms section say that the >> underlay is what is referred to in RFC 6830 as "the underlying core >> routing system". And that an "overlay" is the encapsulation >> relationship between ITRs, ETRs, PxTRs, and RTRs. >=20 > That is fine with me. >=20 >>=20 >>> 2. Section 3 (and a few times in 3.5) : >>> s/inetrworking/internetworking/ >>>=20 >>> 3. Section 3.2 >>>=20 >>> * Is it correct to say that EIDs are only routable at the edge? >>> This seems to contradict the text in section 3.5 that says EIDs may >>> be injected in the global routing system. >>=20 >> Well it depends on your reference point. If the overlay is the center >> of perspective, then the global routing system is a non-LISP site >> relative to the overlay. The whole point is that EIDs are routable >> where LISP is not available. And that is true inside of a LISP site >> where packets are at a point in the data-path pre-encapsulation or >> post-decapsulation. >=20 > I agree with what you say above, but the document explicitly says EIDs > are only routable at the edge and that is not the case in non-LISP = parts > of the Internet. The document just needs to be more explicit on that = point. >=20 >>=20 >>> * I find the PI and PA analogies misleading. EIDs are global, but >>> they may change their point of attachment. If that occurs, you are >>> not guaranteed that your EID space does not change. >>=20 >> It is desirable that your EIDs do not change. But the scope of EID >> mobility may be limited and if a legacy site wants to continue to use >> DHCP and address addresses out of, say an enterprise address pool, it >> should be able to do that while losing session survivability >> features. That is a decision for the organization that is supporting >> mobility into its own domain. >=20 > Given my concern and your comment above, how does the EID/PI analogy = hold? >=20 >>=20 >>> * In the example, bullet four mistakenly says that the destination=20= >>> address of the outer header is set to RLOC_B2 (it should be >>> RLOC_b1). >>>=20 >>> 4. Section 3.3.1 introduces the term RTR (Reencapsulating Tunnel=20 >>> Routers) with no real description of how it functions or relates to >>> ITRs and ETRs. >>=20 >> Well there are references to it in RFC 6830 and there are many >> use-cases for them which we are not allowed to reference since the >> drafts are not working group documents. >=20 > So, Section 3.3.1 should point the reader to 6830 when it mentions the = RTR. >=20 >>=20 >>> 5. Section 3.4.3 makes reference to the LISP WG. Given that this=20 >>> document will probably outlive the WG, I would suggest re-wording >>> to remove a direct reference to the WG. >>>=20 >>> 6. Section 3.4 has no discussion of EIDs and NATs. Given the >>> global nature of the mapping system, it would seem that NATs don't >>> play well with LISP. There should be some discussion of that. >>=20 >> LISP plays very well with NATs and we have many use-cases which are >> alive and being used. But again the draft on NAT-traversal is not a >> working group document so it is hard to reference it. EIDs are >> translatable by NATs and so are RLOCs. It all depends where the xTR >> resides (on the public versus private side of the NAT). >=20 > Even though the NAT-traversal draft is not a WG draft, this document = can > spend a few cycles talking about the general ability of LISP to = operate > in the face of NATs. >=20 >>=20 >>> 7. Section 4.1 >>>=20 >>> * s/requires of a /requires a/ >>>=20 >>> * The discussion of SMR should contain a reference to 6830 or a >>> brief discussion of how the SMR is used. >>>=20 >>> 8. Section 5 >>>=20 >>> * I would suggest having a reference to both the MIP and the NEMO >>> specs when discussing mobility. LISP has the potential to operate >>> in a manner conducive with NEMO if the xTR acts as the NEMO Mobile >>> Router. >>=20 >> Well if we do that then there are a ton of other cases where a xTR >> can be co-located with other functions (i.e. a simple reference is >> say a wifi AP). So singlingly out MIP/NEMO seems to be favoring these >> technologies versus others. Why would we want to do that? >=20 > MIP and NEMO are the general modes of mobility that most closely > approximate what is being discussed in Section 5. My thought was to > give the reader a basis for how mobility in LISP operates, including = the > drawbacks. >=20 >>=20 >> Plus, it raises questions more than simplifies the understanding of >> LISP. This is an intro document. >>=20 >>> * Should there be some discussion of the mapping system's TTL >>> mechanism impact on mobility support? >>=20 >> The TTL is not used for mobility to work. It is the SMR and >> Map-Notify mechanisms between xTRs and the mapping system and xTRs, >> respectively. >=20 > Shouldn't that be mentioned somewhere in this draft? >=20 >>=20 >>> 9. Section 9 talks about propagating multicast state as (S-EID, >>> G). Does that mean that multicast in LISP is really only allowed to >>> be SSM? >>=20 >> We are encouraging SSM but an (RP-EID, G) can be used as well. RFC >> 6831 describes all PIM modes. >=20 > So, to avoid erroneous assumptions, perhaps the intro should mention = that. >=20 > Regards, > Brian >=20 From nobody Tue Jan 20 05:00:40 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A48E1B2A29 for ; Tue, 20 Jan 2015 05:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJajn5b26Sc4 for ; Tue, 20 Jan 2015 05:00:31 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C138B1AD375 for ; Tue, 20 Jan 2015 05:00:30 -0800 (PST) Received: by mail-qg0-f54.google.com with SMTP id q108so2604477qgd.13 for ; Tue, 20 Jan 2015 05:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RBcsmBwuJGkIXEMIl/MNzEE8Vf5RulOjW/9aNS6+X1k=; b=xzpgU8Y7D6avaR2cBEEgAsjrdPwHl97SFdPFedadZECa8la+xU1G6OBmBrjN1LK0kO nx9BYxwmtm5yuNsLZx1fcSvZOGu/utSO61+7SvJeqyH6C2SocIYcFq50VaGivX1H9JSF wnDeL8fPPu4qFDXfREVzyeWrMA0MsQL+V7Ub6RKr4DKEDDlwDFAkaj5tTfvVW4A4axK+ xozvL+EQC6L19/GM09dBUS+FsXHE/vqXQbOe9ctP4nD8Ih86VwafjWGURxZzCM1ZK3Ru 7ksduNK2KfO5SEmPQwjlWY05wrZ4jhFLuhJ3DJbry6mxdK9zeqQ/MQpOL+Hjm/B7rekA Sttw== MIME-Version: 1.0 X-Received: by 10.224.61.1 with SMTP id r1mr37270939qah.0.1421758829974; Tue, 20 Jan 2015 05:00:29 -0800 (PST) Received: by 10.96.67.101 with HTTP; Tue, 20 Jan 2015 05:00:29 -0800 (PST) In-Reply-To: <54BD1B88.30900@innovationslab.net> References: <54B698A7.1080309@innovationslab.net> <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> <1C31C60B-19D7-4421-92C6-878976064E83@gmail.com> <54BD1B88.30900@innovationslab.net> Date: Tue, 20 Jan 2015 14:00:29 +0100 Message-ID: From: Albert Cabellos To: Brian Haberman Content-Type: multipart/alternative; boundary=001a11c3f4d4047001050d15068f Archived-At: Cc: "lisp-chairs@tools.ietf.org" , draft-ietf-lisp-introduction@tools.ietf.org, "lisp@ietf.org" Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 13:00:38 -0000 --001a11c3f4d4047001050d15068f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Thanks, please see inline my replies (removed text for which we all agree): > [snip] > > > > >>> * The discussion of SMR should contain a reference to 6830 or a > >>> brief discussion of how the SMR is used. > >>> > > > > Could you please elaborate further this comment? > > > > "Solicit-Map-Request (SMR): SMR is an explicit mechanism to update > > mapping information. In particular a special type of Map-Request can > > be sent on demand by ETRs to request refreshing a mapping. Upon > > reception of a SMR message, the ITR must refresh the bindings by > > sending a Map-Request to the Mapping System." > > There are more interesting conditions/rules for the use of SMR that are > only found in RFC 6830. I am suggesting adding a reference to 6830 at > this point so readers know where to go to find more info on the SMR. > > Agreed, I=C2=B4ll add a sentence. Further uses of SMRs are documented in [RFC6830]. > > > >>> 8. Section 5 > >>> > >>> * I would suggest having a reference to both the MIP and the NEMO > >>> specs when discussing mobility. LISP has the potential to > >>> operate in a manner conducive with NEMO if the xTR acts as the > >>> NEMO Mobile Router. > >> > >> Well if we do that then there are a ton of other cases where a xTR > >> can be co-located with other functions (i.e. a simple reference is > >> say a wifi AP). So singlingly out MIP/NEMO seems to be favoring > >> these technologies versus others. Why would we want to do that? > >> > >> Plus, it raises questions more than simplifies the understanding of > >> LISP. This is an intro document. > > > > What about adding the following sentence at the end of section 5? > > > > The decoupled identity and location provided by LISP allows it to > > operate with other layer 2 and layer 3 mobility solutions. > > The text talks about both network (NEMO) and host (MIP) mobility. I am > not concerned with LISP interacting with those protocols, I am thinking > of how LISP replaces those protocols. The descriptions in Section 5 > align with very well (i.e., the first paragraph describes LISP replacing > NEMO and the second paragraph describes LISP replacing MIP). My > proposal was to simply add references in those paragraphs to the > mobility protocol that LISP is approximately. > > I do like your proposed addition in order to highlight that LISP will > not interfere with other mobility solutions. > > What about adding two sentences at the end of each paragraph: This functionality is similar to [RFC NEMO]. This functionality is similar to [RFC MIP] [RFC MIPv6]. [snip] >>> 10. I am surprised that there are 2 Security Consideration > >>> sections (7 & 9). I am even more surprised that one says > >>> "Nothing new here" and the other actually discusses potential > >>> issues with the LISP approach. > >>> > > > > My fault, Section 7 should be =E2=80=9CLISP Security Considerations=E2= =80=9D > > > > Section 9 describes the security considerations for the document > > itself. > > I think maintaining two security consideration sections will be > confusing. Either document that *this* document introduces no new > security issues or have the security considerations section summarize > the security impacts of LISP. > > Agreed, will do the latter (so Section 9 is now Section 7). > Regards, > Brian > > > > --001a11c3f4d4047001050d15068f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Thanks, please see inline my replies= (removed text for which we all agree):
=C2=A0
= [snip]
=C2=A0
>
>>> * The discussion of SMR should contain a reference to 6830 or = a
>>> brief discussion of how the SMR is used.
>>>
>
> Could you please elaborate further this comment?
>
> "Solicit-Map-Request (SMR):=C2=A0 SMR is an explicit mechanism to= update
> mapping information.=C2=A0 In particular a special type of Map-Request= can
> be sent on demand by ETRs to request refreshing a mapping. Upon
> reception of a SMR message, the ITR must refresh the bindings by
> sending a Map-Request to the Mapping System."

There are more interesting conditions/rules for the use of SMR that = are
only found in RFC 6830.=C2=A0 I am suggesting adding a reference to 6830 at=
this point so readers know where to go to find more info on the SMR.


Agreed, I=C2= =B4ll add a sentence.

Further uses of SMRs are doc= umented in [RFC6830].
=C2=A0
>
>>> 8. Section 5
>>>
>>> * I would suggest having a reference to both the MIP and the N= EMO
>>> specs when discussing mobility.=C2=A0 LISP has the potential t= o
>>> operate in a manner conducive with NEMO if the xTR acts as the=
>>> NEMO Mobile Router.
>>
>> Well if we do that then there are a ton of other cases where a xTR=
>> can be co-located with other functions (i.e. a simple reference is=
>> say a wifi AP). So singlingly out MIP/NEMO seems to be favoring >> these technologies versus others. Why would we want to do that? >>
>> Plus, it raises questions more than simplifies the understanding o= f
>> LISP. This is an intro document.
>
> What about adding the following sentence at the end of section 5?
>
> The decoupled identity and location provided by LISP allows it to
> operate with other layer 2 and layer 3 mobility solutions.

The text talks about both network (NEMO) and host (MIP) mobility.=C2= =A0 I am
not concerned with LISP interacting with those protocols, I am thinking
of how LISP replaces those protocols.=C2=A0 The descriptions in Section 5 align with very well (i.e., the first paragraph describes LISP replacing NEMO and the second paragraph describes LISP replacing MIP).=C2=A0 My
proposal was to simply add references in those paragraphs to the
mobility protocol that LISP is approximately.

I do like your proposed addition in order to highlight that LISP will
not interfere with other mobility solutions.


What about add= ing two sentences at the end of each paragraph:

Th= is functionality is similar to [RFC NEMO].
This functionality= is similar to [RFC MIP] [RFC MIPv6].

=C2=A0[snip]=

>>> 10. I am surprised that there are 2 Security Consideration
>>> sections (7 & 9).=C2=A0 I am even more surprised that one = says
>>> "Nothing new here" and the other actually discusses = potential
>>> issues with the LISP approach.
>>>
>
> My fault, Section 7 should be =E2=80=9CLISP Security Considerations=E2= =80=9D
>
> Section 9 describes the security considerations for the document
> itself.

I think maintaining two security consideration sections will be
confusing.=C2=A0 Either document that *this* document introduces no new
security issues or have the security considerations section summarize
the security impacts of LISP.


Agreed, will do the latter (so Section= 9 is now Section 7).

=C2=A0
Regards,
Brian




--001a11c3f4d4047001050d15068f-- From nobody Tue Jan 20 05:09:57 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE681B2A33 for ; Tue, 20 Jan 2015 05:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uehm-tF87wT0 for ; Tue, 20 Jan 2015 05:09:49 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D751B2A2D for ; Tue, 20 Jan 2015 05:09:49 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A967888126; Tue, 20 Jan 2015 05:09:49 -0800 (PST) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 4D57A71C0002; Tue, 20 Jan 2015 05:09:48 -0800 (PST) Message-ID: <54BE539A.5060602@innovationslab.net> Date: Tue, 20 Jan 2015 08:09:46 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Albert Cabellos References: <54B698A7.1080309@innovationslab.net> <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> <1C31C60B-19D7-4421-92C6-878976064E83@gmail.com> <54BD1B88.30900@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2L2cEVkt3W2N8NC9I4N9bAOLbRpmcOv61" Archived-At: Cc: "lisp-chairs@tools.ietf.org" , draft-ietf-lisp-introduction@tools.ietf.org, "lisp@ietf.org" Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 13:09:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2L2cEVkt3W2N8NC9I4N9bAOLbRpmcOv61 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Albert, That all works for me. Regards, Brian On 1/20/15 8:00 AM, Albert Cabellos wrote: > Hi >=20 > Thanks, please see inline my replies (removed text for which we all agr= ee): >=20 >=20 >> [snip] >> >=20 >=20 >>> >>>>> * The discussion of SMR should contain a reference to 6830 or a >>>>> brief discussion of how the SMR is used. >>>>> >>> >>> Could you please elaborate further this comment? >>> >>> "Solicit-Map-Request (SMR): SMR is an explicit mechanism to update >>> mapping information. In particular a special type of Map-Request can= >>> be sent on demand by ETRs to request refreshing a mapping. Upon >>> reception of a SMR message, the ITR must refresh the bindings by >>> sending a Map-Request to the Mapping System." >> >> There are more interesting conditions/rules for the use of SMR that ar= e >> only found in RFC 6830. I am suggesting adding a reference to 6830 at= >> this point so readers know where to go to find more info on the SMR. >> >> > Agreed, I=C2=B4ll add a sentence. >=20 > Further uses of SMRs are documented in [RFC6830]. >=20 >=20 >>> >>>>> 8. Section 5 >>>>> >>>>> * I would suggest having a reference to both the MIP and the NEMO >>>>> specs when discussing mobility. LISP has the potential to >>>>> operate in a manner conducive with NEMO if the xTR acts as the >>>>> NEMO Mobile Router. >>>> >>>> Well if we do that then there are a ton of other cases where a xTR >>>> can be co-located with other functions (i.e. a simple reference is >>>> say a wifi AP). So singlingly out MIP/NEMO seems to be favoring >>>> these technologies versus others. Why would we want to do that? >>>> >>>> Plus, it raises questions more than simplifies the understanding of >>>> LISP. This is an intro document. >>> >>> What about adding the following sentence at the end of section 5? >>> >>> The decoupled identity and location provided by LISP allows it to >>> operate with other layer 2 and layer 3 mobility solutions. >> >> The text talks about both network (NEMO) and host (MIP) mobility. I a= m >> not concerned with LISP interacting with those protocols, I am thinkin= g >> of how LISP replaces those protocols. The descriptions in Section 5 >> align with very well (i.e., the first paragraph describes LISP replaci= ng >> NEMO and the second paragraph describes LISP replacing MIP). My >> proposal was to simply add references in those paragraphs to the >> mobility protocol that LISP is approximately. >> >> I do like your proposed addition in order to highlight that LISP will >> not interfere with other mobility solutions. >> >> > What about adding two sentences at the end of each paragraph: >=20 > This functionality is similar to [RFC NEMO]. > This functionality is similar to [RFC MIP] [RFC MIPv6]. >=20 > [snip] >=20 >>>> 10. I am surprised that there are 2 Security Consideration >>>>> sections (7 & 9). I am even more surprised that one says >>>>> "Nothing new here" and the other actually discusses potential >>>>> issues with the LISP approach. >>>>> >>> >>> My fault, Section 7 should be =E2=80=9CLISP Security Considerations=E2= =80=9D >>> >>> Section 9 describes the security considerations for the document >>> itself. >> >> I think maintaining two security consideration sections will be >> confusing. Either document that *this* document introduces no new >> security issues or have the security considerations section summarize >> the security impacts of LISP. >> >> > Agreed, will do the latter (so Section 9 is now Section 7). >=20 >=20 >=20 >> Regards, >> Brian >> >> >> >> >=20 --2L2cEVkt3W2N8NC9I4N9bAOLbRpmcOv61 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUvlOaAAoJEBOZRqCi7goqB/YH/2C0MnSz/SIipcuwB258xtyK +5gsKd5o20eM7Tsb0xqE43IJkiF0mp9hMk83ayiiEcg4KX6aJfAJsphcJ9xcBIDb ylSN9VVSnmCkq7c198E9cCRaTHhYEPpY71/A3jR9k76kKF9EIZYW/9vj9ZyooVGe xAH5WGgOsZ0tTc8VK7nNW29WJsxRa/xtvL48cCuAPDDZigD2d1WveB4fSUG5bLsd ufp1SzPmT1qTJqzb+wYGGZWKRMOyGvTjGxVO8EqJpUJqtrNEf2UMzjeYTb7pUJXp Ph82G8++QG1w/NZ9qE3fyVGjcdJEYAjixGtdDnDpax1pEQ0KqUnZmnFs2J6E/GA= =BnA5 -----END PGP SIGNATURE----- --2L2cEVkt3W2N8NC9I4N9bAOLbRpmcOv61-- From nobody Wed Jan 21 10:21:38 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564F91A1B66; Wed, 21 Jan 2015 10:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWNN4dIMWaA1; Wed, 21 Jan 2015 10:21:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E2C1A1B49; Wed, 21 Jan 2015 10:21:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121182133.4161.29507.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 10:21:33 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-10.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 18:21:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : An Architectural Introduction to the Locator/ID Separation Protocol (LISP) Authors : Albert Cabellos Damien Saucez Filename : draft-ietf-lisp-introduction-10.txt Pages : 26 Date : 2015-01-21 Abstract: This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes, more details can be found in RFC6830, the protocol specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-introduction-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 21 10:21:44 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0BA1A1B71 for ; Wed, 21 Jan 2015 10:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hbnips4Ua41; Wed, 21 Jan 2015 10:21:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A321A1B60; Wed, 21 Jan 2015 10:21:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: ggx@gigix.net, draft-ietf-lisp-introduction.all@tools.ietf.org, lisp@ietf.org, lisp-chairs@tools.ietf.org, brian@innovationslab.net X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121182134.4161.20658.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 10:21:34 -0800 Archived-At: Subject: [lisp] New Version Notification - draft-ietf-lisp-introduction-10.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 18:21:41 -0000 A new version (-10) has been submitted for draft-ietf-lisp-introduction: http://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-10.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-10 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. IETF Secretariat. From nobody Wed Jan 21 10:25:50 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACB11A1B73 for ; Wed, 21 Jan 2015 10:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbaeDdhN45fR for ; Wed, 21 Jan 2015 10:25:45 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB891A1B70 for ; Wed, 21 Jan 2015 10:25:44 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id l6so28792603qcy.12 for ; Wed, 21 Jan 2015 10:25:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/3aPFuK0sAzNg8B2Nzcc+U6staL4j3C9esD78WswdbU=; b=XZK8mhONuHj1KnOqTpY0EkiGSBStaWrv7vH/NHB6SHbCZaRlD5zpSrdRFfz3mnkZfq gD7PDbvOHETpiXjPDKxXQAEmZ8ZUPCOM1Nd0XkvmOQodz+j0WfH1dMYpjdzElMnan8/z 5diXZUJq4VI3KQ7xsV3hq1A3DXcDaVhvN31u6z/BA0hjL4kFjCXtASrSy2Ycq9KlzPe7 O476/KR+Qi4QGvZauiIY2jvBz/49vqcYo60Dq1qx6CZUeqlKAo6Ibl1ccXbIT1sZwfjV 0WZ5sZH5pVchXcOiP4vzIavAtE+r8GplKQyxH8yvybzHl0WVL3EhwAJMya7GSjcIdf+c GeRQ== MIME-Version: 1.0 X-Received: by 10.140.38.114 with SMTP id s105mr67051174qgs.106.1421864742093; Wed, 21 Jan 2015 10:25:42 -0800 (PST) Received: by 10.96.67.101 with HTTP; Wed, 21 Jan 2015 10:25:41 -0800 (PST) In-Reply-To: <20150121182133.4161.29507.idtracker@ietfa.amsl.com> References: <20150121182133.4161.29507.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 19:25:41 +0100 Message-ID: From: Albert Cabellos To: "lisp@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1303edf0a66050d2dae61 Archived-At: Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-introduction-10.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 18:25:48 -0000 --001a11c1303edf0a66050d2dae61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all I=C2=B4ve just posted draft-ietf-lisp-introduction-10.txt following AD's comments. Albert ---------- Forwarded message ---------- From: Date: Wed, Jan 21, 2015 at 7:21 PM Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-10.txt To: i-d-announce@ietf.org Cc: lisp@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : An Architectural Introduction to the Locator/ID Separation Protocol (LISP) Authors : Albert Cabellos Damien Saucez Filename : draft-ietf-lisp-introduction-10.txt Pages : 26 Date : 2015-01-21 Abstract: This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes, more details can be found in RFC6830, the protocol specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-introduction-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-introduction-10 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --001a11c1303edf0a66050d2dae61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all

I=C2=B4ve just posted=C2=A0draft-ietf-lisp-introduction-10.txt following AD's com= ments.

Albert

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jan 21, 2= 015 at 7:21 PM
Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-= 10.txt
To: i-d-announce@ietf.or= g
Cc: lisp@ietf.org


=
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Locator/ID Separation Protocol Worki= ng Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= An Architectural Introduction to the Locator/ID Separation Protocol (LISP)=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Albe= rt Cabellos
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Damien Saucez
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-lisp-introduction-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 26
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-01-21

Abstract:
=C2=A0 =C2=A0This document describes the architecture of the Locator/ID Sep= aration
=C2=A0 =C2=A0Protocol (LISP), making it easier to read the rest of the LISP=
=C2=A0 =C2=A0specifications and providing a basis for discussion about the = details
=C2=A0 =C2=A0of the LISP protocols.=C2=A0 This document is used for introdu= ctory
=C2=A0 =C2=A0purposes, more details can be found in RFC6830, the protocol =C2=A0 =C2=A0specification.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-lisp-introduction-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-in= troduction-10


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

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

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

--001a11c1303edf0a66050d2dae61-- From nobody Wed Jan 21 10:31:43 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95471A1BE4 for ; Wed, 21 Jan 2015 10:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeW3OWmtPh16; Wed, 21 Jan 2015 10:31:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4051A1BBD; Wed, 21 Jan 2015 10:31:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ggx@gigix.net, draft-ietf-lisp-introduction.all@tools.ietf.org, lisp@ietf.org, lisp-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121183135.13484.64547.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 10:31:35 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 18:31:39 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Wed Jan 21 10:49:23 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EBE1A6F33; Wed, 21 Jan 2015 10:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7i2kQo_qv7J; Wed, 21 Jan 2015 10:49:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 018C01A6F17; Wed, 21 Jan 2015 10:49:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150121184913.19074.58661.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 10:49:14 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] Last Call: (An Architectural Introduction to the Locator/ID Separation Protocol (LISP)) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: 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 Jan 2015 18:49:16 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'An Architectural Introduction to the Locator/ID Separation Protocol (LISP)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes, more details can be found in RFC6830, the protocol specification. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jan 21 10:49:28 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AF81A6F38 for ; Wed, 21 Jan 2015 10:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZ5lpFCWJIl6; Wed, 21 Jan 2015 10:49:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0221A6F2B; Wed, 21 Jan 2015 10:49:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ggx@gigix.net, draft-ietf-lisp-introduction.all@tools.ietf.org, lisp@ietf.org, lisp-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121184914.19074.10713.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 10:49:14 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 18:49:19 -0000 Last call has been made for draft-ietf-lisp-introduction and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Fri Jan 23 08:52:35 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D54C1A87AC for ; Fri, 23 Jan 2015 08:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCOlBeAP5SB7; Fri, 23 Jan 2015 08:52:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F261A9121; Fri, 23 Jan 2015 08:52:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-lisp-eid-block-mgmnt.all@tools.ietf.org, damien.saucez@gmail.com, lisp@ietf.org, lisp-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150123165207.5571.82721.idtracker@ietfa.amsl.com> Date: Fri, 23 Jan 2015 08:52:07 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 16:52:12 -0000 IESG state changed to AD Evaluation::External Party from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ From nobody Fri Jan 23 09:59:12 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978651ACCE2 for ; Fri, 23 Jan 2015 09:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NE3aLhCNa4J for ; Fri, 23 Jan 2015 09:59:06 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471FE1ACCC7 for ; Fri, 23 Jan 2015 09:59:06 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id b16so3275128igk.1 for ; Fri, 23 Jan 2015 09:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=Oqg+6zKM4B68Lc2sBsr2cbvQt1to3bBWamJIZVZnzGg=; b=gOiPIiwNWn4bqiZ1858K+EbHOQ2mg+OkozcdeH+1k885CYTq6GySFZkUtKraksCaNu YH7FlIHN+5p3Ly+E+RngcBhj2s/CJm8iJ6oO+GEc78jhyLa106l/mq9SwPIfbOV7gGTM w2RSAT3sqz2D3rsxfwlDv/+ffL3T/L7KDoUfnIqEzcMgRyVAatw0i3y0JZ1HhLR5NZtu jk7sk/f9X77juwdESXHDhcAGndXqklrnPQEK0BTbJqj7dvUPCIzP5F/hiI4HIOjus+jA p+5r7i+J+f0FNtO4uaDMaP+ZkqQQBx/mPa/oCIs+7ajrLvxEgGixy9hdmahRupBgCdaB McZw== X-Received: by 10.107.5.85 with SMTP id 82mr5285149iof.41.1422035945438; Fri, 23 Jan 2015 09:59:05 -0800 (PST) Received: from [172.19.131.170] ([12.130.116.137]) by mx.google.com with ESMTPSA id aw9sm997525igc.18.2015.01.23.09.59.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Jan 2015 09:59:05 -0800 (PST) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <270570EF-D42E-41DA-8848-1510A2E32D27@gmail.com> Date: Fri, 23 Jan 2015 09:25:59 -0800 To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [lisp] draft-ietf-lisp-ddt-02 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 17:59:10 -0000 I would like to ask the working group if there are any issues with = draft-ietf-lisp-ddt-02 and if there is any reason to not send this = document for working group last call? It has been around for a while, has good implementation and deployment = support and hasn't been presented in a working group meeting for a = while. Dino= From nobody Fri Jan 23 14:39:22 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB7C1A3B9F for ; Fri, 23 Jan 2015 14:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzdyY2TKH3FA for ; Fri, 23 Jan 2015 14:39:17 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EAD1A1F01 for ; Fri, 23 Jan 2015 14:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=619; q=dns/txt; s=iport; t=1422052757; x=1423262357; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=wYhmxI9h4kMOPlauaJpaCRBlDecMsMDU0XCOMvpkywA=; b=S1aLBaV81N79URS0aSB1fGh3Ps/rUjbeCny4DfI7kkFOwrogQVnXyfEy 7592WflAU/BVAXPCu/8djUqWYtJWevbYn7Ie0OouAxdnImBCxU11L0t39 ls+Uzg2y1jbviRqLIlTd+5QsbWpxHCaZLROB+PxqaAv3cqcQcC1H27jTo Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAKjMwlStJA2K/2dsb2JhbABagwZSxx0KhWcBCQKBFUMBAQEBAX2EDQEBBAEBATU2GwsYCSUPAhYwEwYCAQGIKA3SVQEBAQEBBQEBAQEBGQSPfxaEEwEEigWOCIY0jAgihA8dMYJCAQEB X-IronPort-AV: E=Sophos;i="5.09,456,1418083200"; d="scan'208";a="390386714" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jan 2015 22:39:15 +0000 Received: from [10.24.182.20] ([10.24.182.20]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t0NMdEDn002985 for ; Fri, 23 Jan 2015 22:39:14 GMT Message-ID: <54C2CD91.50906@cisco.com> Date: Fri, 23 Jan 2015 14:39:13 -0800 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lisp@ietf.org References: <270570EF-D42E-41DA-8848-1510A2E32D27@gmail.com> In-Reply-To: <270570EF-D42E-41DA-8848-1510A2E32D27@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] draft-ietf-lisp-ddt-02 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 22:39:19 -0000 Agree. It was recently refreshed from expiration, and I believe it's ready for last call. Fabio On 1/23/15 9:25 AM, Dino Farinacci wrote: > I would like to ask the working group if there are any issues with draft-ietf-lisp-ddt-02 and if there is any reason to not send this document for working group last call? > > It has been around for a while, has good implementation and deployment support and hasn't been presented in a working group meeting for a while. > > Dino > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Jan 27 15:06:39 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7E81A90FC for ; Tue, 27 Jan 2015 15:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Itx8Zy-41MFI; Tue, 27 Jan 2015 15:06:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC2C1A9106; Tue, 27 Jan 2015 15:06:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ggx@gigix.net, draft-ietf-lisp-introduction.all@tools.ietf.org, lisp@ietf.org, lisp-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150127230615.18769.65453.idtracker@ietfa.amsl.com> Date: Tue, 27 Jan 2015 15:06:15 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 23:06:34 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Wed Jan 28 12:53:36 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E6F1A6FF3; Tue, 27 Jan 2015 14:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1J8o2G-0Hct; Tue, 27 Jan 2015 14:52:41 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6621A001C; Tue, 27 Jan 2015 14:52:41 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t0RMqftY017929; Tue, 27 Jan 2015 22:52:41 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 81E12C203E9; Tue, 27 Jan 2015 22:52:41 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150121184914.19074.74999.idtracker@ietfa.amsl.com> References: <20150121184914.19074.74999.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #804955 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 27 Jan 2015 22:52:41 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Wed, 28 Jan 2015 12:53:35 -0800 Cc: draft-ietf-lisp-introduction.all@tools.ietf.org, lisp@ietf.org, lisp-chairs@tools.ietf.org, iesg@ietf.org Subject: [lisp] [IANA #804955] Last Call: (An Architectural Introduction to the Locator/ID Separation Protocol (LISP)) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: 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, 27 Jan 2015 22:52:43 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-lisp-introduction-10, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Wed Jan 21 18:49:38 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Locator/ID Separation Protocol > WG (lisp) to consider the following document: > - 'An Architectural Introduction to the Locator/ID Separation Protocol > (LISP)' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-02-04. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes the architecture of the Locator/ID Separation > Protocol (LISP), making it easier to read the rest of the LISP > specifications and providing a basis for discussion about the details > of the LISP protocols. This document is used for introductory > purposes, more details can be found in RFC6830, the protocol > specification. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Thu Jan 29 02:12:21 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3BA1A0193 for ; Thu, 29 Jan 2015 02:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F80phpUqWP8W for ; Thu, 29 Jan 2015 02:12:14 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id F2CD21A0151 for ; Thu, 29 Jan 2015 02:12:13 -0800 (PST) Received: from gw-2.ac.upc.es (gw-2.ac.upc.es [147.83.30.8]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id t0TAC9Ft005062; Thu, 29 Jan 2015 11:12:09 +0100 Received: from [192.168.1.4] (unknown [89.123.99.190]) by gw-2.ac.upc.es (Postfix) with ESMTPSA id 0BF7CC0; Thu, 29 Jan 2015 11:12:08 +0100 (CET) Message-ID: <54CA0777.6040200@lispmob.org> Date: Thu, 29 Jan 2015 12:12:07 +0200 From: Lori Jakab Organization: LISPmob MIME-Version: 1.0 To: Fabio Maino , lisp@ietf.org References: <270570EF-D42E-41DA-8848-1510A2E32D27@gmail.com> <54C2CD91.50906@cisco.com> In-Reply-To: <54C2CD91.50906@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] draft-ietf-lisp-ddt-02 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 10:12:17 -0000 On 01/24/2015 12:39 AM, Fabio Maino wrote: > Agree. It was recently refreshed from expiration, and I believe it's > ready for last call. +1 There are several implementations, that have been thoroughly tested for interoperability, so I support this document going into working group last call. -Lori > > Fabio > > On 1/23/15 9:25 AM, Dino Farinacci wrote: >> I would like to ask the working group if there are any issues with >> draft-ietf-lisp-ddt-02 and if there is any reason to not send this >> document for working group last call? >> >> It has been around for a while, has good implementation and deployment >> support and hasn't been presented in a working group meeting for a while. >> >> Dino >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Jan 29 04:27:32 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C591A034F for ; Thu, 29 Jan 2015 04:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWbSpXxYOxkG for ; Thu, 29 Jan 2015 04:27:27 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF221A0362 for ; Thu, 29 Jan 2015 04:27:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1893; q=dns/txt; s=iport; t=1422534446; x=1423744046; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LbJIH2Hefp+s7gAFJeAzHZx7E4wsP5ODR1iyjGpBE+Q=; b=Xse7za/hmw0WFMDjt65tg4vmONfnX+PSuTw7Sz5gaHEwGK/eeJBkJ6LW TZsvzy9Szn3bEq7ohR1rD9Z4bjE1xjaDeGBVEt0Vwq1tgYRU5cGOyF2s5 njb9LzvKLSUrCMbmLjKMDdlGP+1kbaRQpiVMqU0zl498yY8yASsevSjeh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFABgmylStJV2T/2dsb2JhbABXA4MGUlkExE4KhXECgR9DAQEBAQF9hAwBAQEDAQEBAWsBCgULAgEIGC4nCyUCBA4FiCQIDdYHAQEBAQEBAQEBAQEBAQEBAQEBAQEBF48WEQEdIxACBRGDBYETBYVGiS6JIpJGIoNubwGBCjl+AQEB X-IronPort-AV: E=Sophos;i="5.09,485,1418083200"; d="scan'208";a="391813624" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jan 2015 12:27:25 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t0TCRP4D002079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Jan 2015 12:27:25 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 06:27:25 -0600 From: "Gregg Schudel (gschudel)" To: IETF Thread-Topic: [lisp] draft-ietf-lisp-ddt-02 Thread-Index: AQHQO6wWho31p8N2iECWirwThCtfSZzXaxiA Date: Thu, 29 Jan 2015 12:27:25 +0000 Message-ID: References: <270570EF-D42E-41DA-8848-1510A2E32D27@gmail.com> <54C2CD91.50906@cisco.com> <54CA0777.6040200@lispmob.org> In-Reply-To: <54CA0777.6040200@lispmob.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.117.98] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-ietf-lisp-ddt-02 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 12:27:29 -0000 +1 it=92s been deployed for several years and very stable (and simple to work = with). I support this going to last call. On Jan 29, 2015, at 11:12 AM, Lori Jakab wrote: > On 01/24/2015 12:39 AM, Fabio Maino wrote: >> Agree. It was recently refreshed from expiration, and I believe it's >> ready for last call. >=20 > +1 >=20 > There are several implementations, that have been thoroughly tested for > interoperability, so I support this document going into working group > last call. >=20 > -Lori >=20 >>=20 >> Fabio >>=20 >> On 1/23/15 9:25 AM, Dino Farinacci wrote: >>> I would like to ask the working group if there are any issues with >>> draft-ietf-lisp-ddt-02 and if there is any reason to not send this >>> document for working group last call? >>>=20 >>> It has been around for a while, has good implementation and deployment >>> support and hasn't been presented in a working group meeting for a whil= e. >>>=20 >>> Dino >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp Best regards, Gregg -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement:=20 http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From nobody Thu Jan 29 05:25:11 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919231A038E for ; Thu, 29 Jan 2015 05:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZmdBk0DVJhK for ; Thu, 29 Jan 2015 05:24:56 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433811A0389 for ; Thu, 29 Jan 2015 05:24:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id C5E013A; Thu, 29 Jan 2015 14:24:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1422537892; bh=3WckgA2YkFYa+2TkLHrPqNUPPAigNpwXg8GMoVHlaqY=; b=a KB6isqltcNcVJihDRiF9Tj6i+CF1YjYmY3zvjNEy4wdOm1+cBSLYhjN1opHm1bFU 74pdrH/qkgvoZwHsfSrOYsLt5YPIG8lJepIPSho+N9v7uCit+q2Y/aIav6DYbL9U RCeS07DwkDEMFFhIXWF91HVFjsuFtLRogJTYyfi6Hs= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id atwUQKNNDdyL; Thu, 29 Jan 2015 14:24:52 +0100 (CET) Received: from [IPv6:2a00:8640:1::4dd6:55b5:404b:f654] (unknown [IPv6:2a00:8640:1:0:4dd6:55b5:404b:f654]) by mail.sintact.nl (Postfix) with ESMTPSA id B851E34; Thu, 29 Jan 2015 14:24:51 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Sander Steffann In-Reply-To: Date: Thu, 29 Jan 2015 14:24:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05C1410D-655A-4EAB-BC57-8BAE43A4FEE7@steffann.nl> References: <270570EF-D42E-41DA-8848-1510A2E32D27@gmail.com> <54C2CD91.50906@cisco.com> <54CA0777.6040200@lispmob.org> To: Gregg Schudel X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IETF Subject: Re: [lisp] draft-ietf-lisp-ddt-02 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 13:24:57 -0000 Hi, > Op 29 jan. 2015, om 13:27 heeft Gregg Schudel (gschudel) = het volgende geschreven: >=20 > +1 > it=92s been deployed for several years and very stable (and simple to = work with). > I support this going to last call. +1 Sander From nobody Thu Jan 29 06:06:06 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A281A19E9 for ; Thu, 29 Jan 2015 06:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDttUAQM3Jni for ; Thu, 29 Jan 2015 06:05:58 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F761A0AF7 for ; Thu, 29 Jan 2015 06:05:57 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id fb4so25001986wid.2 for ; Thu, 29 Jan 2015 06:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jcVGWIhrMUN9+wpTNsdf7hzJ4tExhpGHVAO5El5UVFw=; b=GPXRy0HjaMEft8DpqI4lhShzXoUkRiNHEVYwBVhMURM2ArZHRdYE5M1riJaKh4Sxkw NGfjltPzKxAeiLo7VR9OIc4RPqzy46/L+Sn0cQuFKKtb8SsEdn7HOAFxwPG7ihKFyVc9 1mTp5Q+puZhyPhIU/y9omKezp/f0KdJj6FLa7B0sl1SpLL+PSnEIqDQWN4I292JwLL4G 0IAMnJT9dGMRKV4Ffr5rg0iMRoP4P3GorBFh6+rTk4Ls8N5gCT+LtFpRb5KDFhiuu0oJ 8BTUH4apym5Qr1yOVO7+ktT0HLQq+5xK2lcsQK8mydG+Ez8FDyfSfg5o6EK52y6J2D+9 jLJg== X-Received: by 10.194.205.228 with SMTP id lj4mr1192586wjc.77.1422540356191; Thu, 29 Jan 2015 06:05:56 -0800 (PST) Received: from saehrimnir.inria.fr (saehrimnir.inria.fr. [138.96.206.202]) by mx.google.com with ESMTPSA id kp10sm10380061wjc.45.2015.01.29.06.05.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Jan 2015 06:05:55 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: <05C1410D-655A-4EAB-BC57-8BAE43A4FEE7@steffann.nl> Date: Thu, 29 Jan 2015 15:05:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <270570EF-D42E-41DA-8848-1510A2E32D27@gmail.com> <54C2CD91.50906@cisco.com> <54CA0777.6040200@lispmob.org> <05C1410D-655A-4EAB-BC57-8BAE43A4FEE7@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-ddt-02 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 14:05:59 -0000 I support this option. Damien Saucez=20 On 29 Jan 2015, at 14:24, Sander Steffann wrote: > Hi, >=20 >> Op 29 jan. 2015, om 13:27 heeft Gregg Schudel (gschudel) = het volgende geschreven: >>=20 >> +1 >> it=92s been deployed for several years and very stable (and simple to = work with). >> I support this going to last call. >=20 > +1 > Sander >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Jan 29 06:13:57 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB101A19E5 for ; Thu, 29 Jan 2015 06:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VezrhhrSCqh for ; Thu, 29 Jan 2015 06:13:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C0C1A19EF for ; Thu, 29 Jan 2015 06:13:52 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 76E291B80F1 for ; Thu, 29 Jan 2015 15:13:50 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 5A809C8064 for ; Thu, 29 Jan 2015 15:13:50 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Thu, 29 Jan 2015 15:13:50 +0100 From: To: LISP mailing list list Thread-Topic: [lisp] draft-ietf-lisp-ddt-02 Thread-Index: AQHQO6wVNNkF5P9cQU+e4DaflExaepzW9cSAgAAQDICAAAt4AIAAErNg Date: Thu, 29 Jan 2015 14:13:50 +0000 Message-ID: <8384_1422540830_54CA401E_8384_3767_1_88132E969123D14D9BD844E1CD516EDE05D5D07F@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <270570EF-D42E-41DA-8848-1510A2E32D27@gmail.com> <54C2CD91.50906@cisco.com> <54CA0777.6040200@lispmob.org> <05C1410D-655A-4EAB-BC57-8BAE43A4FEE7@steffann.nl> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.29.124224 Archived-At: Subject: Re: [lisp] draft-ietf-lisp-ddt-02 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 14:13:54 -0000 Hello WG, I also think the DDT draft should move forward. Cheers, Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jan 29 07:36:16 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DCB1A1A15 for ; Thu, 29 Jan 2015 07:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWelEowBNT3Y for ; Thu, 29 Jan 2015 07:36:11 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486141A1AF0 for ; Thu, 29 Jan 2015 07:36:10 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so27968841wiv.0 for ; Thu, 29 Jan 2015 07:36:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:cc:to :mime-version; bh=nT7cbZV9wE9LAJISrJDMg9Se6hLUmthtmJtzmqmXHjI=; b=Ew0JjUZ5g3fiCVnxlJxpOCF1O9eBpvEojid7EigxwUsJ2xRZty9S1DMU+F2P9ZTj+i /AE85cQjUjZxOvh7AJs5WP3XljXQfEOlGEVuf6Twcr8DiZ4gVW9CajPgxejBoCN+8xxo ocd2pCcqu+JXaUioAbgNvBAwn4urCGnR5naa80fmWe1FmvGTDpPa5FLoRgAAnf/hU+Wv 7GH4P/Y+wgQ6AM3pj5fwEZAb8fuBuCxPxFCJ8rC+8zGCTb1thANfNKskt75ph/B301SA XB2w6DJ32mquPAwjSTFE9v67DODXx5Ulte5qEdph0gkXKD9FalMcpDFqspni9ljUYlVp Izgg== X-Gm-Message-State: ALoCoQnzBDhcAmVE4kFCOtoO9ic5VxUk8JvdP6egy9d6bSUI8CnWQvhOrSP7sKfpmJLLOvpV3HZp X-Received: by 10.180.160.166 with SMTP id xl6mr1295856wib.16.1422545768912; Thu, 29 Jan 2015 07:36:08 -0800 (PST) Received: from [132.227.125.186] ([132.227.125.186]) by mx.google.com with ESMTPSA id hr1sm2960659wib.1.2015.01.29.07.36.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Jan 2015 07:36:08 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_C0F06743-8A05-4B22-AD4A-7041F0686EF3" Date: Thu, 29 Jan 2015 16:36:06 +0100 Message-Id: <6673BF12-76F5-4E9F-BF3E-10F5E6F40334@gigix.net> To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Joel Halpern Direct , Damien Saucez Subject: [lisp] WG Last Call for draft-ietf-lisp-ddt-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 15:36:13 -0000 --Apple-Mail=_C0F06743-8A05-4B22-AD4A-7041F0686EF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, The authors of draft-ietf-lisp-ddt-02=20 [http://tools.ietf.org/html/draft-ietf-lisp-ddt-02 = ], as well as several active WG participants, requested the WG Last Call for this document. This email starts a 14 days WG Last Call, to end February 13th, 2015. Please review this WG document and let the WG know if you agree that it = is ready for handing to the AD. If you have objections, please state your reasons why, and explain what = it would take to address your concerns. Thanks Luigi & Joel= --Apple-Mail=_C0F06743-8A05-4B22-AD4A-7041F0686EF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

The authors of = draft-ietf-lisp-ddt-02 
[http://tools.ietf.org/html/draft-ietf-lisp-ddt-02],
as well as several active WG participants,
requested the WG Last Call for this = document.

This email = starts a 14 days WG Last Call, to end February 13th, 2015.

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

Thanks

Luigi & = Joel
= --Apple-Mail=_C0F06743-8A05-4B22-AD4A-7041F0686EF3--