From farinacci@gmail.com Mon Sep 2 09:08:23 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3237821F9EEE for ; Mon, 2 Sep 2013 09:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z20oQ+KIm97T for ; Mon, 2 Sep 2013 09:08:22 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEA821F9E99 for ; Mon, 2 Sep 2013 09:08:22 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id ld10so5344439pab.36 for ; Mon, 02 Sep 2013 09:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=JniqmTZnv82ATUGf3rZIJo9G+ACUy7EGKii7yq1io/0=; b=FFK8I1npsQXangLhX6+Cp3EfJGJVznkVfgsh7K8e6PQBGjPIpbaKUwsC0vCE+p3xiB l7VTwcvJ6HhwfPHu9Jq/ACl+RRXoIPksCsBI01J8kk21pOVi/ka9lPUWUQ138BMhI75U 1WE32ElO7G8eII9oaRYm/Wc1P1i0M1oUdmnutyQ37w2g1vaGLtry7jQpIi7aLTeKAA8C 3yYt1igCOUMXPfnrgSDCPe4JDxENcs8ixwKJ5TxrWG19NrLre4Qkx2CXqJwyAhCFOvCz ru4AtRmwix8UDM142loqxKdx+faqcKfNr1/hlneAEiu7opl6FoYWP+Toq/iz2cVF0KsD lRmw== X-Received: by 10.66.159.40 with SMTP id wz8mr4221665pab.135.1378138100975; Mon, 02 Sep 2013 09:08:20 -0700 (PDT) Received: from [10.216.45.180] (mobile-166-137-186-199.mycingular.net. [166.137.186.199]) by mx.google.com with ESMTPSA id fy4sm16758175pbb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Sep 2013 09:08:20 -0700 (PDT) References: <20130902114206.5817.81015.idtracker@ietfa.amsl.com> From: Dino Farinacci Content-Type: multipart/alternative; boundary=Apple-Mail-22CFF55A-2F0E-487F-B03A-CA44AF5A0298 X-Mailer: iPhone Mail (11A4449d) Message-Id: Date: Mon, 2 Sep 2013 09:08:17 -0700 To: "lisp@ietf.org list" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: [lisp] Fwd: Expiration impending: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 02 Sep 2013 16:08:23 -0000 --Apple-Mail-22CFF55A-2F0E-487F-B03A-CA44AF5A0298 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I have some updates that I will post to the list but if anyone thinks there a= re pending changes and you have told or requested of me to add text, can you= please repost in this list so the entire working group can see the request a= nd be part of the discussion.=20 Thanks, Dino Begin forwarded message: > From: IETF Secretariat > Date: September 2, 2013 at 4:42:06 AM PDT > To: "Dino Farinacci" , "David Meyer" ,= "Job Snijders" > Cc: "Terry Manderson" , "Joel M. Halpern" > Subject: Expiration impending: >=20 > The following draft will expire soon: >=20 > Name: draft-ietf-lisp-lcaf > Title: LISP Canonical Address Format (LCAF) > State: I-D Exists > Expires: 2013-09-11 (in 1 week, 1 day) >=20 --Apple-Mail-22CFF55A-2F0E-487F-B03A-CA44AF5A0298 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I have some updates that I will post t= o the list but if anyone thinks there are pending changes and you have told o= r requested of me to add text, can you please repost in this list so the ent= ire working group can see the request and be part of the discussion. 

Thanks,
Dino


Begin forwarded me= ssage:

From: IETF Secreta= riat <ietf-secretariat= -reply@ietf.org>
Date: September 2, 2013 at 4:42:06 AM PDT<= br>To: "Dino Farinacci" <fa= rinacci@gmail.com>, "David Meyer" <dmm@cisco.com>, "Job Snijders" <job@instituut.net>
Cc: "Terry Manderson" <terry.manderson@icann.org>, "Joel M= . Halpern" <jmh@joelhalpern.com>
Subject: Expiration impending: <draft-ietf-lisp-lcaf-0= 2.txt>

= --Apple-Mail-22CFF55A-2F0E-487F-B03A-CA44AF5A0298-- From arnatal@ac.upc.edu Mon Sep 2 10:22:08 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC26C11E8130 for ; Mon, 2 Sep 2013 10:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kg9IPuUKxQvy for ; Mon, 2 Sep 2013 10:22:04 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 725DD11E812F for ; Mon, 2 Sep 2013 10:21:57 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id r82HLtnw025420 for ; Mon, 2 Sep 2013 19:21:55 +0200 Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by gw.ac.upc.edu (Postfix) with ESMTP id 483C66B0291 for ; Mon, 2 Sep 2013 19:21:54 +0200 (CEST) Received: by mail-lb0-f171.google.com with SMTP id u14so4218746lbd.30 for ; Mon, 02 Sep 2013 10:21:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=brB9vXgnOuudIqUOZ+va43pSVwBcJcWescE4iPJblBU=; b=P17XieN9KdcWk7OYI1GSVBlY/95foEawmR03mjZvyyfLEyJ4NMqUByitZL/xX39JHw XxSTKKE0bvhaPm0hRy/3uFXxMzk7nUi0tp+yC5/42ia25fQO6PuhXOX8hGr2rsRn+KHb mYaLpQhyaFPKaKtW0fD3ZU/423tHC+/EvJIGKaooVto3jf99I36syC171h//I4poYnvo g+vn8/5+313QhhGsXuO4d6lasfT/1zvX2/0GkzudZ+z+q7bf8SUKAxetUjI4qvarLDB2 lPoslZgDOHdwGcTmqHku8oiH2AHhtvxSXUHams09EUjTlEziEQ6fVM4QlOfgEkXux3Tb vkQg== X-Received: by 10.152.8.12 with SMTP id n12mr22549223laa.10.1378142514189; Mon, 02 Sep 2013 10:21:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.160.100 with HTTP; Mon, 2 Sep 2013 10:21:34 -0700 (PDT) In-Reply-To: References: <20130902114206.5817.81015.idtracker@ietfa.amsl.com> From: Alberto Rodriguez-Natal Date: Mon, 2 Sep 2013 19:21:34 +0200 Message-ID: To: Dino Farinacci Content-Type: multipart/mixed; boundary=001a11c365b6021aa104e569cf9f Cc: "lisp@ietf.org list" Subject: Re: [lisp] Fwd: Expiration impending: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 02 Sep 2013 17:22:09 -0000 --001a11c365b6021aa104e569cf9f Content-Type: multipart/alternative; boundary=001a11c365b6021a9e04e569cf9d --001a11c365b6021a9e04e569cf9d Content-Type: text/plain; charset=ISO-8859-1 Dear Dino, all, Here are some ideas we have for new types of LCAFs. First, we will like to see a 5-tuple LCAF to allow mapping lookups based on flows. In the attached TXT there is a proposed format. It allows to perform exact match flow lookups, as well as best match lookups using port range and prefix mask length. The proposed 5-tuple LCAF is based on current types 4 and 12, and can be a new type itself, or be merged with those types. Second, we find interesting to have a generic (self-defined) LCAF type. A format like that will allow complex and/or experimental LISP applications. We aim for a binary JSON-like format. This LCAF type almost needs no definition, just a new LCAF type number and an agreement on the binary specification to use. Personally, I like the Universal Binary JSON Specification (http://ubjson.org/). I would like to know what the WG thinks of these proposals. Thanks, Alberto On 2 September 2013 18:08, Dino Farinacci wrote: > I have some updates that I will post to the list but if anyone thinks > there are pending changes and you have told or requested of me to add text, > can you please repost in this list so the entire working group can see the > request and be part of the discussion. > > Thanks, > Dino > > > Begin forwarded message: > > *From:* IETF Secretariat > *Date:* September 2, 2013 at 4:42:06 AM PDT > *To:* "Dino Farinacci" , "David Meyer" , > "Job Snijders" > *Cc:* "Terry Manderson" , "Joel M. Halpern" < > jmh@joelhalpern.com> > *Subject:* *Expiration impending: * > > The following draft will expire soon: > > Name: draft-ietf-lisp-lcaf > Title: LISP Canonical Address Format (LCAF) > State: I-D Exists > Expires: 2013-09-11 (in 1 week, 1 day) > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --001a11c365b6021a9e04e569cf9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Dino, all,

Here are some ideas we have for new= types of LCAFs.

First, we will like to see a 5-tuple LCAF to allow = mapping lookups based on flows. In the attached TXT there is a proposed for= mat. It allows to perform exact match flow lookups, as well as best match l= ookups using port range and prefix mask length. The proposed 5-tuple LCAF i= s based on current types 4 and 12, and can be a new type itself, or be merg= ed with those types.

Second, we find interesting to have a generic (self-defined) LCAF type.= A format like that will allow complex and/or experimental LISP application= s. We aim for a binary JSON-like format. This LCAF type almost needs no def= inition, just a new LCAF type number and an agreement on the binary specifi= cation to use. Personally, I like the Universal Binary JSON Specification (= http://ubjson.org/).

I would like to know what the WG thinks of these proposals.

Than= ks,
Alberto


On 2 September 2013 18:08, Di= no Farinacci <farinacci@gmail.com> wrote:
I have some updates t= hat I will post to the list but if anyone thinks there are pending changes = and you have told or requested of me to add text, can you please repost in = this list so the entire working group can see the request and be part of th= e discussion.=A0

Thanks,
Dino


Begin forwarded messa= ge:

From: IETF Secretari= at <ietf-secretariat-reply@ietf.org>
Date: September 2, 2013 at 4:42:06 AM PDT
To: "Dino F= arinacci" <farinacci@gmail.com>, "David Meyer" <dmm@cisco.com>, "Job Snijders= " <job@insti= tuut.net>
Cc: "Terry Manderson" <terry.manderson@icann.org>, "Joe= l M. Halpern" <jmh@joelhalpern.com>
Subject: Expiration impending: <draft-ietf-lisp-lcaf-02.txt>= ;

The fo= llowing draft will expire soon:

Name: =A0= =A0=A0=A0draft-ietf-lisp-lcaf
Title: =A0=A0=A0LISP Canonical Address Format (LCAF)
= State: =A0=A0=A0I-D Exists
Expires: =A02013-09-11 (in 1 wee= k, 1 day)


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


--001a11c365b6021a9e04e569cf9d-- --001a11c365b6021aa104e569cf9f Content-Type: text/plain; charset=US-ASCII; name="5tuple_LCAF.txt" Content-Disposition: attachment; filename="5tuple_LCAF.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hl3y6cnr0 ICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAg ICAgICAgICAzCiAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgQUZJID0g MTYzODcgICAgICAgICB8ICAgICBSc3ZkMSAgICAgfCAgICAgRmxhZ3MgICAgIHwKICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgICB8ICAgVHlwZSA9ID8gICAgfCAgICAgUnN2ZDIgICAgIHwgICAgICAgICAgICAgNCAr IG4gICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgIFNvdXJjZS1wb3J0 ICAgICAgICAgfCAgICAgICAgIFNyYy1wb3J0LXJhbmdlICAgICAgICB8CiAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICAgfCAgICAgICAgICAgIERlc3QtcG9ydCAgICAgICAgICB8ICAgICAgICAgRHN0LXBvcnQtcmFu Z2UgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgIFJlc2VydmVkICAgfCAgIFByb3RvY29s ICAgIHwgICBTb3VyY2UtTUwgICB8ICAgIERlc3QtTUwgICAgfAogICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwg ICAgICAgICAgICAgIEFGSSA9IHggICAgICAgICAgfCAgICAgICAgIFNvdXJjZS1QcmVmaXggLi4u ICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgQUZJID0geCAgICAgICAgICB8 ICAgICBEZXN0aW5hdGlvbi1QcmVmaXggLi4uICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r --001a11c365b6021aa104e569cf9f-- From jmh@joelhalpern.com Mon Sep 2 10:33:06 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC5711E8136 for ; Mon, 2 Sep 2013 10:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEs3iqSsyOdr for ; Mon, 2 Sep 2013 10:33:02 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 285F111E812C for ; Mon, 2 Sep 2013 10:33:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 19E051CC1316; Mon, 2 Sep 2013 10:33:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 636F21CC1314; Mon, 2 Sep 2013 10:33:01 -0700 (PDT) Message-ID: <5224CBCB.6090106@joelhalpern.com> Date: Mon, 02 Sep 2013 13:32:59 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alberto Rodriguez-Natal References: <20130902114206.5817.81015.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org list" Subject: Re: [lisp] Fwd: Expiration impending: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 02 Sep 2013 17:33:06 -0000 With regard to the generic LCAF, it seems that each usage would have to specify what it was actually going to use it for, but this would not be captured in the mapping system. This would seem to lead to the situation where one entity is looking things up with one purpose in mind, but finds mapping for some other purpose, which it can not support. Yours, Joel On 9/2/13 1:21 PM, Alberto Rodriguez-Natal wrote: > Dear Dino, all, > > Here are some ideas we have for new types of LCAFs. > > First, we will like to see a 5-tuple LCAF to allow mapping lookups based > on flows. In the attached TXT there is a proposed format. It allows to > perform exact match flow lookups, as well as best match lookups using > port range and prefix mask length. The proposed 5-tuple LCAF is based on > current types 4 and 12, and can be a new type itself, or be merged with > those types. > > Second, we find interesting to have a generic (self-defined) LCAF type. > A format like that will allow complex and/or experimental LISP > applications. We aim for a binary JSON-like format. This LCAF type > almost needs no definition, just a new LCAF type number and an agreement > on the binary specification to use. Personally, I like the Universal > Binary JSON Specification (http://ubjson.org/). > > I would like to know what the WG thinks of these proposals. > > Thanks, > Alberto > > > On 2 September 2013 18:08, Dino Farinacci > wrote: > > I have some updates that I will post to the list but if anyone > thinks there are pending changes and you have told or requested of > me to add text, can you please repost in this list so the entire > working group can see the request and be part of the discussion. > > Thanks, > Dino > > > Begin forwarded message: > >> *From:* IETF Secretariat > > >> *Date:* September 2, 2013 at 4:42:06 AM PDT >> *To:* "Dino Farinacci" > >, "David Meyer" > >, "Job Snijders" > > >> *Cc:* "Terry Manderson" > >, "Joel M. Halpern" >> > >> *Subject:* *Expiration impending: * >> >> The following draft will expire soon: >> >> Name: draft-ietf-lisp-lcaf >> Title: LISP Canonical Address Format (LCAF) >> State: I-D Exists >> Expires: 2013-09-11 (in 1 week, 1 day) >> > > _______________________________________________ > 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 arnatal@ac.upc.edu Wed Sep 4 06:18:36 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4670E11E81B0 for ; Wed, 4 Sep 2013 06:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.143 X-Spam-Level: X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klCIAuY47Zng for ; Wed, 4 Sep 2013 06:18:31 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0182621F9FF9 for ; Wed, 4 Sep 2013 06:18:29 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id r84DISJc004422 for ; Wed, 4 Sep 2013 15:18:28 +0200 Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by gw.ac.upc.edu (Postfix) with ESMTP id 21E286B02A7 for ; Wed, 4 Sep 2013 15:18:27 +0200 (CEST) Received: by mail-lb0-f170.google.com with SMTP id w7so379002lbi.1 for ; Wed, 04 Sep 2013 06:18:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=17vNVPbI7tCIQvOek+6lF/CEDY0/jfGXN68m9m2sfdo=; b=kNwnUnsqimTw3AZ0UlZV54gmIeBF4v8LDiApR2qV22yJQX9NNg1itLr1uTzADn+1A4 HjbsUbwBy7LO6TlrJjyR0NAPZKkp9acJcnzT1srVp5b3gGTyK/Z04Bjdc7y+xoyDvrof 0uVl8cecPmzWIpZIMUoQt+2NTh+h9oaNTihcOT4zMdxnEbNf25AtUA9uQHJ5BWq86bn7 ezV3gNNnOAEI0jgBp5aikBn3J1K1bg3LJBOWunYywpZ07agTlc97vEti0IBDZJHcBAGF RCm9jmhaFF7UMUVDZPE4Ny2P7rUeYhhI6Sq7bCU3I3SeEdJ2NjiRTbXICtQMBj5rmH3S airw== X-Received: by 10.112.150.97 with SMTP id uh1mr1840366lbb.34.1378300706821; Wed, 04 Sep 2013 06:18:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.160.100 with HTTP; Wed, 4 Sep 2013 06:18:06 -0700 (PDT) In-Reply-To: <5224CBCB.6090106@joelhalpern.com> References: <20130902114206.5817.81015.idtracker@ietfa.amsl.com> <5224CBCB.6090106@joelhalpern.com> From: Alberto Rodriguez-Natal Date: Wed, 4 Sep 2013 15:18:06 +0200 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=047d7b342d4a061d8104e58ea44e Cc: "lisp@ietf.org list" Subject: Re: [lisp] Fwd: Expiration impending: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 04 Sep 2013 13:18:36 -0000 --047d7b342d4a061d8104e58ea44e Content-Type: text/plain; charset=ISO-8859-1 Joel, The idea we have in mind for this generic LCAF is intradomain deployments where the same entity (or several entities with some sort of agreement) has control over both MS/MR and xTR/RTR devices. In that scenario the exact usage of the generic encoding will be arrange in advance. The value we see on the generic LCAF is that it allows the deployment of new applications without need to modify the mapping system. If an entity has a fresh idea involving LISP, and it has LISP devices that support a generic LCAF encoding, it can deploy its idea immediately. This a way to encourage the experimentation and innovation with LISP. For the scenario you propose (no beforehand agreement between entities), we can introduce some kind of "sub-type" to specify the exact purpose of the generic LCAF. This "sub-type" can be encoded as the very first field on the generic part. Let me know what you think. Alberto On 2 September 2013 19:32, Joel M. Halpern wrote: > With regard to the generic LCAF, it seems that each usage would have to > specify what it was actually going to use it for, but this would not be > captured in the mapping system. > This would seem to lead to the situation where one entity is looking > things up with one purpose in mind, but finds mapping for some other > purpose, which it can not support. > > Yours, > Joel > > > On 9/2/13 1:21 PM, Alberto Rodriguez-Natal wrote: > >> Dear Dino, all, >> >> Here are some ideas we have for new types of LCAFs. >> >> First, we will like to see a 5-tuple LCAF to allow mapping lookups based >> on flows. In the attached TXT there is a proposed format. It allows to >> perform exact match flow lookups, as well as best match lookups using >> port range and prefix mask length. The proposed 5-tuple LCAF is based on >> current types 4 and 12, and can be a new type itself, or be merged with >> those types. >> >> Second, we find interesting to have a generic (self-defined) LCAF type. >> A format like that will allow complex and/or experimental LISP >> applications. We aim for a binary JSON-like format. This LCAF type >> almost needs no definition, just a new LCAF type number and an agreement >> on the binary specification to use. Personally, I like the Universal >> Binary JSON Specification (http://ubjson.org/). >> >> I would like to know what the WG thinks of these proposals. >> >> Thanks, >> Alberto >> >> >> On 2 September 2013 18:08, Dino Farinacci > > wrote: >> >> I have some updates that I will post to the list but if anyone >> thinks there are pending changes and you have told or requested of >> me to add text, can you please repost in this list so the entire >> working group can see the request and be part of the discussion. >> >> Thanks, >> Dino >> >> >> Begin forwarded message: >> >> *From:* IETF Secretariat >>> >>> >> >>> *Date:* September 2, 2013 at 4:42:06 AM PDT >>> *To:* "Dino Farinacci" >> >, "David Meyer" >> >, "Job Snijders" >> > >>> *Cc:* "Terry Manderson" >> >>, >>> "Joel M. Halpern" >>> > >>> *Subject:* *Expiration impending: * >>> >>> >>> The following draft will expire soon: >>> >>> Name: draft-ietf-lisp-lcaf >>> Title: LISP Canonical Address Format (LCAF) >>> State: I-D Exists >>> Expires: 2013-09-11 (in 1 week, 1 day) >>> >>> >> ______________________________**_________________ >> 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 >> >> --047d7b342d4a061d8104e58ea44e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joel,

The idea we have in= mind for this generic LCAF is intradomain deployments where the same entit= y (or several entities with some sort of agreement) has control over both M= S/MR and xTR/RTR devices. In that scenario the exact usage of the generic e= ncoding will be arrange in advance.

The value we see on the generic LCAF is that it allows the d= eployment of new applications without need to modify the mapping system. If= an entity has a fresh idea involving LISP, and it has LISP devices that su= pport a generic LCAF encoding, it can deploy its idea immediately. This a w= ay to encourage the experimentation and innovation with LISP.

For the scenario you propose (no beforehand agreement = between entities), we can introduce some kind of "sub-type" to sp= ecify the exact purpose of the generic LCAF. This "sub-type" can = be encoded as the very first field on the generic part.

Let me know what you think.

Alberto



On 2 September 2013 19:32, Joel M. Halpern <jmh@joelhal= pern.com> wrote:
With regard to the generic LCAF, it seems th= at each usage would have to specify what it was actually going to use it fo= r, but this would not be captured in the mapping system.
This would seem to lead to the situation where one entity is looking things= up with one purpose in mind, but finds mapping for some other purpose, whi= ch it can not support.

Yours,
Joel


On 9/2/13 1:21 PM, Alberto Rodriguez-Natal wrote:
Dear Dino, all,

Here are some ideas we have for new types of LCAFs.

First, we will like to see a 5-tuple LCAF to allow mapping lookups based on flows. In the attached TXT there is a proposed format. It allows to
perform exact match flow lookups, as well as best match lookups using
port range and prefix mask length. The proposed 5-tuple LCAF is based on current types 4 and 12, and can be a new type itself, or be merged with
those types.

Second, we find interesting to have a generic (self-defined) LCAF type.
A format like that will allow complex and/or experimental LISP
applications. We aim for a binary JSON-like format. This LCAF type
almost needs no definition, just a new LCAF type number and an agreement on the binary specification to use. Personally, I like the Universal
Binary JSON Specification (http://ubjson.org/).

I would like to know what the WG thinks of these proposals.

Thanks,
Alberto


On 2 September 2013 18:08, Dino Farinacci <farinacci@gmail.com
<mailto:farinac= ci@gmail.com>> wrote:

=A0 =A0 I have some updates that I will post to the list but if anyone
=A0 =A0 thinks there are pending changes and you have told or requested of<= br> =A0 =A0 me to add text, can you please repost in this list so the entire =A0 =A0 working group can see the request and be part of the discussion.
=A0 =A0 Thanks,
=A0 =A0 Dino


=A0 =A0 Begin forwarded message:

=A0 =A0 *From:* IETF Secretariat <ietf-secretariat-reply@ietf.org =A0 =A0 <mailto:ietf-secretariat-reply@ietf.org>>
=A0 =A0 *Date:* September 2, 2013 at 4:42:06 AM PDT
=A0 =A0 *To:* "Dino Farinacci" <farinacci@gmail.com
=A0 =A0 <mailto:farinacci@gmail.com>>, "David Meyer" <dmm@cisco.com
=A0 =A0 <mailto:dmm@c= isco.com>>, "Job Snijders" <job@instituut.net
=A0 =A0 <mailto:j= ob@instituut.net>>
=A0 =A0 *Cc:* "Terry Manderson" <terry.manderson@icann.org
=A0 =A0 <mailto:terry.manderson@icann.org>>, "Joel M. Halpern&= quot;
=A0 =A0 <jmh@jo= elhalpern.com <mailto:jmh@joelhalpern.com>>
=A0 =A0 *Subject:* *Expiration impending: <draft-ietf-lisp-lcaf-02.txt&g= t;*


=A0 =A0 The following draft will expire soon:

=A0 =A0 Name: =A0 =A0 draft-ietf-lisp-lcaf
=A0 =A0 Title: =A0 =A0LISP Canonical Address Format (LCAF)
=A0 =A0 State: =A0 =A0I-D Exists
=A0 =A0 Expires: =A02013-09-11 (in 1 week, 1 day)


=A0 =A0 _______________________________________________
=A0 =A0 lisp mailing list
=A0 =A0 lisp@ietf.org <mailto:lisp@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/listinfo/lisp





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


--047d7b342d4a061d8104e58ea44e-- From elopez@fortinet.com Wed Sep 4 09:25:35 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AE721E80E8 for ; Wed, 4 Sep 2013 09:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssxEXdNZMqmo for ; Wed, 4 Sep 2013 09:25:30 -0700 (PDT) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) by ietfa.amsl.com (Postfix) with ESMTP id BF03821E80C9 for ; Wed, 4 Sep 2013 09:25:30 -0700 (PDT) From: Edward Lopez To: Alberto Rodriguez-Natal Thread-Topic: [lisp] Expiration impending: Thread-Index: AQHOqYthnpXl370oFUqIcZbkzM6PmA== Date: Wed, 4 Sep 2013 16:25:34 +0000 Message-ID: <43C5A7F8-E533-47FF-81D1-9D47D7BEBA57@fortinet.com> References: <20130902114206.5817.81015.idtracker@ietfa.amsl.com> <5224CBCB.6090106@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [65.115.88.15] Content-Type: multipart/alternative; boundary="_000_43C5A7F8E53347FF81D19D47D7BEBA57fortinetcom_" MIME-Version: 1.0 X-FEAS-SYSTEM-WL: 192.168.221.212 Cc: "lisp@ietf.org list" Subject: Re: [lisp] Expiration impending: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 04 Sep 2013 16:25:35 -0000 --_000_43C5A7F8E53347FF81D19D47D7BEBA57fortinetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I concur with Alberto in that we need to consider an intradomain deployme= nt scenario. For example, suppose I have a stateful firewall and a varie= ty of content inspection engines that are LISP-enabled. It would be desi= rable to have the firewall as an action LISP encapsulate traffic-of-inter= est and forward it to the appropriate content inspection engine for deepe= r inspection. A definable LCAF would be very useful in this case, and I = like the idea of using a JSON-like format Currently such scenarios are only feasible with a combination of policy-b= ased routing and VPN/GRE tunneling to establish one-hop adjacencies. An = intradomain LISP model could be used to develop highly resilient, central= ized content/application solutions Ed Lopez On Sep 4, 2013, at 9:18 AM, Alberto Rodriguez-Natal > wrote: Joel, The idea we have in mind for this generic LCAF is intradomain deployments= where the same entity (or several entities with some sort of agreement) = has control over both MS/MR and xTR/RTR devices. In that scenario the exa= ct usage of the generic encoding will be arrange in advance. The value we see on the generic LCAF is that it allows the deployment of = new applications without need to modify the mapping system. If an entity = has a fresh idea involving LISP, and it has LISP devices that support a g= eneric LCAF encoding, it can deploy its idea immediately. This a way to e= ncourage the experimentation and innovation with LISP. For the scenario you propose (no beforehand agreement between entities), = we can introduce some kind of "sub-type" to specify the exact purpose of = the generic LCAF. This "sub-type" can be encoded as the very first field = on the generic part. Let me know what you think. Alberto On 2 September 2013 19:32, Joel M. Halpern > wrote: With regard to the generic LCAF, it seems that each usage would have to s= pecify what it was actually going to use it for, but this would not be ca= ptured in the mapping system. This would seem to lead to the situation where one entity is looking thin= gs up with one purpose in mind, but finds mapping for some other purpose,= which it can not support. Yours, Joel On 9/2/13 1:21 PM, Alberto Rodriguez-Natal wrote: Dear Dino, all, Here are some ideas we have for new types of LCAFs. First, we will like to see a 5-tuple LCAF to allow mapping lookups based on flows. In the attached TXT there is a proposed format. It allows to perform exact match flow lookups, as well as best match lookups using port range and prefix mask length. The proposed 5-tuple LCAF is based on current types 4 and 12, and can be a new type itself, or be merged with those types. Second, we find interesting to have a generic (self-defined) LCAF type. A format like that will allow complex and/or experimental LISP applications. We aim for a binary JSON-like format. This LCAF type almost needs no definition, just a new LCAF type number and an agreement on the binary specification to use. Personally, I like the Universal Binary JSON Specification (http://ubjson.org/). I would like to know what the WG thinks of these proposals. Thanks, Alberto On 2 September 2013 18:08, Dino Farinacci >> wrote: I have some updates that I will post to the list but if anyone thinks there are pending changes and you have told or requested of me to add text, can you please repost in this list so the entire working group can see the request and be part of the discussion. Thanks, Dino Begin forwarded message: *From:* IETF Secretariat >> *Date:* September 2, 2013 at 4:42:06 AM PDT *To:* "Dino Farinacci" >>, "David Mey= er" >>, "Job Snijders" >> *Cc:* "Terry Manderson" >>= , "Joel M. Halpern" >> *Subject:* *Expiration impending: * The following draft will expire soon: Name: draft-ietf-lisp-lcaf Title: LISP Canonical Address Format (LCAF) State: I-D Exists Expires: 2013-09-11 (in 1 week, 1 day) _______________________________________________ lisp mailing list lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** --_000_43C5A7F8E53347FF81D19D47D7BEBA57fortinetcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable I concur with Alberto in that we need to consider an intradomain deployme= nt scenario.  For example, suppose I have a stateful firewall and a = variety of content inspection engines that are LISP-enabled.  It wou= ld be desirable to have the firewall as an action LISP encapsulate traffic-of-interest and forward it to the appropriate c= ontent inspection engine for deeper inspection.  A definable LCAF wo= uld be very useful in this case, and I like the idea of using a JSON-like= format

Currently such scenarios are only feasible with a combination of pol= icy-based routing and VPN/GRE tunneling to establish one-hop adjacencies.=  An intradomain LISP model could be used to develop highly resilien= t, centralized content/application solutions

Ed Lopez

On Sep 4, 2013, at 9:18 AM, Alberto Rodriguez-Natal <arnatal@ac.upc.edu> wrote:

Joel,

The idea we have in mind for this generic LCAF is intradomain deployments= where the same entity (or several entities with some sort of agreement) = has control over both MS/MR and xTR/RTR devices. In that scenario the exa= ct usage of the generic encoding will be arrange in advance.

The value we see on the generic LCAF is that it allows the deploymen= t of new applications without need to modify the mapping system. If an en= tity has a fresh idea involving LISP, and it has LISP devices that suppor= t a generic LCAF encoding, it can deploy its idea immediately. This a way to encourage the experimentation and in= novation with LISP.

For the scenario you propose (no beforehand agreement between entities), = we can introduce some kind of "sub-type" to specify the exact p= urpose of the generic LCAF. This "sub-type" can be encoded as t= he very first field on the generic part.

Let me know what you think.

Alberto



On 2 September 2013 19:32, Joel M. Halpern <jmh@joelhalp= ern.com> wrote:
With regard to the generic LCAF, it seems that each usage would have to s= pecify what it was actually going to use it for, but this would not be ca= ptured in the mapping system.
This would seem to lead to the situation where one entity is looking thin= gs up with one purpose in mind, but finds mapping for some other purpose,= which it can not support.

Yours,
Joel


On 9/2/13 1:21 PM, Alberto Rodriguez-Natal wrote:
Dear Dino, all,

Here are some ideas we have for new types of LCAFs.

First, we will like to see a 5-tuple LCAF to allow mapping lookups based<= br> on flows. In the attached TXT there is a proposed format. It allows to perform exact match flow lookups, as well as best match lookups using
= port range and prefix mask length. The proposed 5-tuple LCAF is based on<= br> current types 4 and 12, and can be a new type itself, or be merged with those types.

Second, we find interesting to have a generic (self-defined) LCAF type. A format like that will allow complex and/or experimental LISP
applications. We aim for a binary JSON-like format. This LCAF type
almost needs no definition, just a new LCAF type number and an agreement<= br> on the binary specification to use. Personally, I like the Universal
Binary JSON Specification (http://ubjson.org/).

I would like to know what the WG thinks of these proposals.

Thanks,
Alberto


On 2 September 2013 18:08, Dino Farinacci <farinacci@gmail.com
<mailto:farinacci@gmail.com>> wrote:

    I have some updates that I will post to the list but if any= one
    thinks there are pending changes and you have told or reque= sted of
    me to add text, can you please repost in this list so the e= ntire
    working group can see the request and be part of the discus= sion.

    Thanks,
    Dino


    Begin forwarded message:

    *From:* IETF Secretariat <ietf-secretariat-reply@ietf.org
    <mailto:ietf-secretariat-reply@ietf.org>>     *Date:* September 2, 2013 at 4:42:06 AM PDT
    *To:* "Dino Farinacci" <farinacci@gmail.com
    <mailto:farinacci@gmail.com>>, "David Meyer" <dmm@cisco.com
    <mailto:dmm@cisco.com>>, "Job Snijders" <job@instituut.net
    <mailto:job@instituut.net>>
    *Cc:* "Terry Manderson" <terry.manderson@icann.org     <mailto:terry.manderson@icann.org>>, "Joel M= . Halpern"
    <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
    *Subject:* *Expiration impending: <draft-ietf-lisp-lcaf-= 02.txt>*


    The following draft will expire soon:

    Name:     draft-ietf-lisp-lcaf
    Title:    LISP Canonical Address Format (LCAF)     State:    I-D Exists
    Expires:  2013-09-11 (in 1 week, 1 day)


    _______________________________________________
    lisp mailing list
    lisp@iet= f.org <mailto:l= isp@ietf.org>
    https://www.ietf.org/mailman/listinfo/lisp





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


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


*** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. ***
--_000_43C5A7F8E53347FF81D19D47D7BEBA57fortinetcom_-- From rogerj@gmail.com Sat Sep 7 03:30:25 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B1421E808E for ; Sat, 7 Sep 2013 03:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIOpkd1xfyhH for ; Sat, 7 Sep 2013 03:30:25 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BE86621E808F for ; Sat, 7 Sep 2013 03:30:24 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so2786267wes.33 for ; Sat, 07 Sep 2013 03:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=YDnmQ2tem+Pp5KB0+H9stXX1+gtRKd0fhD1Jmuf74vY=; b=Mcl3Hno6LSgGT5q0SSqJQI6qQKmnLgmpbA3Klw1MCdWi8/Efc41sgcB7skeMB7Ye8r Smg9tzNfLOMYX7zA+oeN00yz6Wuh5Kf9EzvcmuCK2kaqkPYQmIbo3xH7AdQngVyFZTcK a1ygswRptiwhjLVsjHmohMv+tAbogihFV/738qA1Cn/imHVj+3bUcFUcN/5r7nhBxFCy cA3+4zGeGT827pMT6fQIbR+e4ytSunV1RhZJ3DLRmCK6jKh7TQqch73I7jHi6jITE4I1 GH2l4et3rMRNF041ugPJNWPUDFUucTTU0yxHap2ecdPbqijcmjfLeoIu88ZJ49ZWo7Br Skcg== MIME-Version: 1.0 X-Received: by 10.180.208.7 with SMTP id ma7mr1685739wic.25.1378549820276; Sat, 07 Sep 2013 03:30:20 -0700 (PDT) Received: by 10.216.213.72 with HTTP; Sat, 7 Sep 2013 03:30:20 -0700 (PDT) In-Reply-To: References: <20130907030504.9447718C0EE@mercury.lcs.mit.edu> Date: Sat, 7 Sep 2013 12:30:20 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: "lisp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 07 Sep 2013 10:30:25 -0000 forward from a discussion on ietf@ ---------- Forwarded message ---------- From: Roger J=F8rgensen Date: Sat, Sep 7, 2013 at 12:30 PM Subject: Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA To: Noel Chiappa , IETF Discussion On Sat, Sep 7, 2013 at 5:05 AM, Noel Chiappa wrot= e: > > From: Scott Brim > > > The encapsulation is not much of an obstacle to packet examination. > > There was actually a proposal a couple of weeks back in the WG to encrypt= all > traffic on the inter-xTR stage. > > The win in doing it in the xTRs, of course, is that you don't have to go > change all the hosts, application by application: _all_ traffic, of any k= ind, > from that site to any/all other sites which are encryption-enabled, will = get > a certain degree of confidentiality. > > Does this count as something the IETF can do reasonably quickly that will > help somewhat? :-) One easy fix then would be to have a MUST encrypt traffic between xTRs, and that the encryption used MUST be strong. Are LISP@WG up for the challenge? :-) The userbase and deployment are relative small atm so it's doable to get fast deployment to. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no --=20 Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From jnc@mercury.lcs.mit.edu Sat Sep 7 05:36:29 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4336111E8130 for ; Sat, 7 Sep 2013 05:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.864 X-Spam-Level: X-Spam-Status: No, score=-5.864 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDFYx533wMOz for ; Sat, 7 Sep 2013 05:36:16 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id D25E211E80E2 for ; Sat, 7 Sep 2013 05:36:16 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 892ED18C0F1; Sat, 7 Sep 2013 08:36:16 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130907123616.892ED18C0F1@mercury.lcs.mit.edu> Date: Sat, 7 Sep 2013 08:36:16 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: [lisp] decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 07 Sep 2013 12:36:29 -0000 > From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= > The userbase and deployment are relative small atm so it's doable to > get fast deployment to. Alas, now that I think about the practicalities.... I don't think the average router has enough spare computing power to completely encrypt all the traffic. Whether or not encrypting just the source+dest addresses, and the sort+dest port (conviently next to each other in one block) is enough to do much good, and if the average router has enough spare crunch to do even that, is a good question. Noel From rogerj@gmail.com Sat Sep 7 06:05:53 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DC421E809A for ; Sat, 7 Sep 2013 06:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19Y0SIkD6U0y for ; Sat, 7 Sep 2013 06:05:51 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 15FF521E8099 for ; Sat, 7 Sep 2013 06:05:50 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id f12so3907187wgh.14 for ; Sat, 07 Sep 2013 06:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=xACeVrg1c4xJ/MbZuTDRnKPz04FQiEtLrTMzwIsxf34=; b=YC4emJOBeWPpnMDrqi0cUiUVTyzTHhbbNjcEfh8YeUaHgIfiUINut0LzgsI3R5KJMy S56+zK3a7B9YcGQ5Mb56yqS2uAjPKpW2fxgyQvAu4SuM69zUirHTCUT2i/7YqdgZ3R/O 69m9aQqX7Hbipmn1ZVPkMltdU0su3QnA99Pki+1zG0l6TbYMaz+pgTUy/9YfHS1vcPf7 8jvr5nk+KzLph4UuBX4rpqTGq/FB0zKhI0CUHERUezKdGFblbipfOlY6ODPQlBVklEL1 mwbmgr1FeeDqCZfAh1j1wQtuYZEKUzCLXL5aQL8rZigMfSyhywRaaLjONS23hs6CiiXC k98w== MIME-Version: 1.0 X-Received: by 10.180.11.37 with SMTP id n5mr2077804wib.25.1378559148946; Sat, 07 Sep 2013 06:05:48 -0700 (PDT) Received: by 10.216.213.72 with HTTP; Sat, 7 Sep 2013 06:05:48 -0700 (PDT) In-Reply-To: References: <20130907122051.D811818C0F1@mercury.lcs.mit.edu> Date: Sat, 7 Sep 2013 15:05:48 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: "lisp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 07 Sep 2013 13:05:54 -0000 ---------- Forwarded message ---------- From: Roger J=F8rgensen Date: Sat, Sep 7, 2013 at 3:05 PM Subject: Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA To: Noel Chiappa Cc: IETF Discussion On Sat, Sep 7, 2013 at 2:20 PM, Noel Chiappa wrot= e: > > From: =3D?ISO-8859-1?Q?Roger_J=3DF8rgensen?=3D > > > The userbase and deployment are relative small atm so it's doable t= o > > get fast deployment to. > > Alas, now that I think about the practicalities.... I don't think the ave= rage > router has enough spare computing power to completely encrypt all the tra= ffic. I don't really see that as an issue, it's just a matter of engineering and building the router in a way that they can do it. AFAIK I think most routers have th= e options of being extended by dedicated encrypt-all-traffic tasks? Probably = some changes needed on the software layer to use the extension but that's doable= . It is also just the situation right now on the router side. In general should our current technology and processing power be up for the job if needed. > Whether or not encrypting just the source+dest addresses, and the sort+de= st > port (conviently next to each other in one block) is enough to do much go= od, > and if the average router has enough spare crunch to do even that, is a g= ood > question. Isn't the payload the important part to protect? the content of the package= ? -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no --=20 Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From farinacci@gmail.com Sat Sep 7 08:59:04 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF3221F9F6F for ; Sat, 7 Sep 2013 08:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxhcNX-bGbr3 for ; Sat, 7 Sep 2013 08:59:03 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B3D2F21F9F1B for ; Sat, 7 Sep 2013 08:59:03 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lj1so4567016pab.29 for ; Sat, 07 Sep 2013 08:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=5vi5MKTXO6nqunoWKwEIFAJtCztax0zfUv9oGspEleI=; b=sjvVpojyGcwzMxYOKKgoXTmNm8khTwgtJeCfTVyjV0rFOPpI7mIY8LemeImx6knW4f cdCgbsZpKhX9f3wMnpdCyrtt+EH5e3OoGspUIDErLskljzayY4mEiRBg3aHJ2CLyvoDn PGpUC/iJr/4VVJ3nVTOejEd0A2Ec2vSrqnO/I8rlP72nN79vJiRJaoVu+ZWRTPlvFJJ6 QYbZ8B3BcGGoJcIEX1oIIgK3cU5PseNx2+Fr7KKZqI6Zj7XloGzytNEFpL1HxVnPbd2b ifIatiFii3Sdf2rWZqmGAZYVS9JP7GvzG99KLJqGbNGgYxSgmDsCgDnjnARYAPObn8UG Osvg== X-Received: by 10.68.197.229 with SMTP id ix5mr1223395pbc.203.1378569542395; Sat, 07 Sep 2013 08:59:02 -0700 (PDT) Received: from [10.250.117.102] (mobile-166-137-177-147.mycingular.net. [166.137.177.147]) by mx.google.com with ESMTPSA id nv6sm4965621pbc.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Sep 2013 08:59:01 -0700 (PDT) References: <20130907122051.D811818C0F1@mercury.lcs.mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <4242370A-B766-49C0-9FBA-45F8B8157F9A@gmail.com> X-Mailer: iPhone Mail (11A4449d) From: Dino Farinacci Date: Sat, 7 Sep 2013 08:59:00 -0700 To: =?utf-8?Q?Roger_J=C3=B8rgensen?= Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 07 Sep 2013 15:59:04 -0000 But what if the core didn't need to change and you key-n-encrypt before you m= ap-n-encap. In fact you could combine the "key" part and "map" part together= in the same lookup.=20 I'm just saying. :-) Dino > On Sep 7, 2013, at 6:05 AM, Roger J=C3=B8rgensen wrote:= >=20 > ---------- Forwarded message ---------- > From: Roger J=C3=B8rgensen > Date: Sat, Sep 7, 2013 at 3:05 PM > Subject: Re: decentralization of Internet (was Re: Bruce Schneier's > Proposal to dedicate November meeting to saving the Internet from the > NSA > To: Noel Chiappa > Cc: IETF Discussion >=20 >=20 > On Sat, Sep 7, 2013 at 2:20 PM, Noel Chiappa wro= te: >>> From: =3D?ISO-8859-1?Q?Roger_J=3DF8rgensen?=3D >>=20 >>> The userbase and deployment are relative small atm so it's doable to >>> get fast deployment to. >>=20 >> Alas, now that I think about the practicalities.... I don't think the ave= rage >> router has enough spare computing power to completely encrypt all the tra= ffic. >=20 > I don't really see that as an issue, it's just a matter of engineering > and building > the router in a way that they can do it. AFAIK I think most routers have t= he > options of being extended by dedicated encrypt-all-traffic tasks? Probably= some > changes needed on the software layer to use the extension but that's doabl= e. >=20 > It is also just the situation right now on the router side. In general > should our > current technology and processing power be up for the job if needed. >=20 >=20 >> Whether or not encrypting just the source+dest addresses, and the sort+de= st >> port (conviently next to each other in one block) is enough to do much go= od, >> and if the average router has enough spare crunch to do even that, is a g= ood >> question. >=20 > Isn't the payload the important part to protect? the content of the packag= e? >=20 >=20 > -- >=20 > Roger Jorgensen | ROJO9-RIPE > rogerj@gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger@jorgensen.no >=20 >=20 > --=20 >=20 > Roger Jorgensen | ROJO9-RIPE > rogerj@gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger@jorgensen.no > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From marc@sniff.de Sun Sep 8 01:54:51 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D92221F9DCB for ; Sun, 8 Sep 2013 01:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt7b7kIkYD31 for ; Sun, 8 Sep 2013 01:54:50 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D33E21F9DC7 for ; Sun, 8 Sep 2013 01:54:50 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id D0CBE2AA0F; Sun, 8 Sep 2013 08:54:43 +0000 (GMT) Date: Sun, 8 Sep 2013 10:54:47 +0200 From: Marc Binderberger To: =?iso-8859-1?Q?Roger_J=F8rgensen?= Message-ID: <20130908105447344146.a7cc0b9e@sniff.de> In-Reply-To: References: <20130907122051.D811818C0F1@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: GyazMail version 1.5.15 Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 08:54:51 -0000 Hello Roger et al., > Isn't the payload the important part to protect? the content of the packa= ge? that's not enough. If reports in the press are correct then just the=20 metadata alone, i.e. who is talking to whom, is valuable input for the=20 various agencies. True, for a court to judge you, harder evidence is necessary (or so I=20 think but maybe it's just the hope of me powerless citizen :-) So you would need to encrypt the whole original packet that is wrapped=20 into Lisp. And even then I doubt you can avoid Metadata to "leak": Lisp=20 is separating Identity from Location but this doesn't mean the RLOC can=20 not be used to identify you. In case of static setups this is obvious,=20 take the RLOC, go to the ISP, get the (physical) address and name. For=20 mobile Lisp you could correlate your RLOC changes with the changes on=20 the lower layers, i.e. when changing from one antenna to the next.=20 Gives you the mobile's identification number and finally your identity. You said in another email: > One easy fix then would be to have a MUST encrypt traffic between > xTRs, and that the encryption used MUST be strong. Are LISP@WG up for > the challenge? :-) I wouldn't be happy about the MUST (the first one ;-) to become part of=20 Lisp specifications - Lisp turns out to be a versatile tool, encryption=20 does not always fit the use cases and would turn into a deployment=20 roadblock. Different story is if Lisp and it's Database can support the=20 integration of encryption - that sounds reasonable to me. My $0.02 Regards, Marc On Sat, 7 Sep 2013 15:05:48 +0200, Roger J=F8rgensen wrote: > ---------- Forwarded message ---------- > From: Roger J=F8rgensen > Date: Sat, Sep 7, 2013 at 3:05 PM > Subject: Re: decentralization of Internet (was Re: Bruce Schneier's > Proposal to dedicate November meeting to saving the Internet from the > NSA > To: Noel Chiappa > Cc: IETF Discussion >=20 >=20 > On Sat, Sep 7, 2013 at 2:20 PM, Noel Chiappa=20 > wrote: >>> From: =3D?ISO-8859-1?Q?Roger_J=3DF8rgensen?=3D >>=20 >>> The userbase and deployment are relative small atm so it's doable to >>> get fast deployment to. >>=20 >> Alas, now that I think about the practicalities.... I don't think=20 >> the average >> router has enough spare computing power to completely encrypt all=20 >> the traffic. >=20 > I don't really see that as an issue, it's just a matter of engineering > and building > the router in a way that they can do it. AFAIK I think most routers have = the > options of being extended by dedicated encrypt-all-traffic tasks?=20 > Probably some > changes needed on the software layer to use the extension but that's doab= le. >=20 > It is also just the situation right now on the router side. In general > should our > current technology and processing power be up for the job if needed. >=20 >=20 >> Whether or not encrypting just the source+dest addresses, and the sort+d= est >> port (conviently next to each other in one block) is enough to do=20 >> much good, >> and if the average router has enough spare crunch to do even that,=20 >> is a good >> question. >=20 > Isn't the payload the important part to protect? the content of the packa= ge? >=20 >=20 From jnc@mercury.lcs.mit.edu Sun Sep 8 06:58:15 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD0B21E808D; Sun, 8 Sep 2013 06:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sDbirkorgFk; Sun, 8 Sep 2013 06:58:08 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 07B7E21E8082; Sun, 8 Sep 2013 06:58:07 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A866118C0CF; Sun, 8 Sep 2013 09:58:04 -0400 (EDT) To: ietf@ietf.org Message-Id: <20130908135804.A866118C0CF@mercury.lcs.mit.edu> Date: Sun, 8 Sep 2013 09:58:04 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [lisp] decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 13:58:15 -0000 > From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= > Isn't the payload the important part to protect? Ecrypting only the headers was a suggestion for the case where the routers don't have enough spare crunch to encrypt the entire payload of every packet. Whether that would do anything useful, or whether analysis of the payload could bypass that, making that limited step useless, I don't know. Noel From jnc@mercury.lcs.mit.edu Sun Sep 8 07:04:39 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3585A21F9F9E for ; Sun, 8 Sep 2013 07:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp5b590fGGxD for ; Sun, 8 Sep 2013 07:04:34 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 22A8321F9BD8 for ; Sun, 8 Sep 2013 07:04:34 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D217D18C0CE; Sun, 8 Sep 2013 10:04:33 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130908140433.D217D18C0CE@mercury.lcs.mit.edu> Date: Sun, 8 Sep 2013 10:04:33 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 14:04:39 -0000 > From: Marc Binderberger > Lisp is separating Identity from Location but this doesn't mean the > RLOC can not be used to identify you. In case of static setups this is > obvious, take the RLOC, go to the ISP, get the (physical) address and > name. Err, that would get the address and name of the ITR, not the actual source host. Depending on all sorts of factors, that plus the encrypted packet _might_ get them the identity of the actual originator (not, for example, if the ITR has discarded the key used to encrypt the packet by the time the subpoena arrives...) Noel From elopez@fortinet.com Sun Sep 8 08:04:42 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB9E21E809C for ; Sun, 8 Sep 2013 08:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3au7xyuxHNvr for ; Sun, 8 Sep 2013 08:04:38 -0700 (PDT) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) by ietfa.amsl.com (Postfix) with ESMTP id B8E8921F9BC1 for ; Sun, 8 Sep 2013 08:04:37 -0700 (PDT) From: Edward Lopez To: Noel Chiappa Thread-Topic: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA Thread-Index: AQHOrJxXOHW2nHyU/USLjCm1FKOKiZm78Ejz Date: Sun, 8 Sep 2013 15:04:44 +0000 Message-ID: <281739A7-17F1-494A-8667-94C3F258C072@fortinet.com> References: <20130908140433.D217D18C0CE@mercury.lcs.mit.edu> In-Reply-To: <20130908140433.D217D18C0CE@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FEAS-SYSTEM-WL: 192.168.221.213 Cc: "lisp@ietf.org" , "jnc@mercury.lcs.mit.edu" Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 15:04:42 -0000 Key generation/management/distribution would be the real difficulty. It = would be desirable to use symmetric encryption (Ex. AES256) to encrypt LI= SP payloads. Therefore, we use certs & asymmetric encryption (some form = of ECC) at the time of xTR registration to provide a method to distribute= keys to authenticated site members. Another consideration is to encrypt just the EID header, and have EIDs us= e IPSec (thus LISP would in effect encrypt the outer IPSec ESP header). = Someone in the RLOC space would then require two keys to decrypt the mess= age fully, and the encryption load would be distributed between EIDs and = xTRs Ed Lopez Sent from my iPhone ... Sorry for any auto-correct errors On Sep 8, 2013, at 10:04 AM, "Noel Chiappa" wro= te: >> From: Marc Binderberger > >> Lisp is separating Identity from Location but this doesn't mean the >> RLOC can not be used to identify you. In case of static setups this is= >> obvious, take the RLOC, go to the ISP, get the (physical) address and >> name. > > Err, that would get the address and name of the ITR, not the actual sou= rce > host. > > Depending on all sorts of factors, that plus the encrypted packet _migh= t_ get > them the identity of the actual originator (not, for example, if the IT= R has > discarded the key used to encrypt the packet by the time the subpoena > arrives...) > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** From mblokzij@cisco.com Sun Sep 8 11:30:31 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA6D11E8136 for ; Sun, 8 Sep 2013 11:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWMt5VOuIGWH for ; Sun, 8 Sep 2013 11:30:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 14DB411E8137 for ; Sun, 8 Sep 2013 11:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4981; q=dns/txt; s=iport; t=1378665026; x=1379874626; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fGfGrHCuJiwbcX8y3Q36RUkCbYo2C3uMUK6tQfmqE28=; b=WmUIFAUSG7DNqVbGKuvNCK2rY5P/hvKmL/UEg90ohieaw9E6vibQkorS Uyvh4BX5D24yolCkK1XDkc05dfz/9HYIVz3Uspj9NCFv/4nak5cjKf/PM 0M+p1KN9uOZNnrObypCHLSvAnuiq5m8RAfmB84xctt4yhLDP+2+21OIdv o=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAITBLFKtJXG8/2dsb2JhbABQAQmDBzhRwgyBJBZ0giUBAQEDAQEBAWsDCAULAgEIDgcDChkLJwslAgQOAwIIBoduBgzGDQSONwYBCYEIMQeDHYEAA5AjgS6YCoFjgT1AgTE5 X-IronPort-AV: E=Sophos;i="4.90,865,1371081600"; d="asc'?scan'208";a="257063425" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 08 Sep 2013 18:30:25 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r88IUPHs031902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Sep 2013 18:30:25 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.246]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Sun, 8 Sep 2013 13:30:24 -0500 From: "Michiel Blokzijl (mblokzij)" To: Edward Lopez Thread-Topic: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA Thread-Index: AQHOrKTKqrTDcDckzkWCbP89pAyEPJm8fYMA Date: Sun, 8 Sep 2013 18:30:24 +0000 Message-ID: <4ABB752A36221949A095CDE2C6DBB1C80982EC23@xmb-aln-x12.cisco.com> References: <20130908140433.D217D18C0CE@mercury.lcs.mit.edu> <281739A7-17F1-494A-8667-94C3F258C072@fortinet.com> In-Reply-To: <281739A7-17F1-494A-8667-94C3F258C072@fortinet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.202.68] Content-Type: multipart/signed; boundary="Apple-Mail=_795A4B33-B831-4617-8328-649A5B7A2EB5"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 18:30:31 -0000 --Apple-Mail=_795A4B33-B831-4617-8328-649A5B7A2EB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think it would actually be quite interesting to use "standard" public = key encryption, rather than symmetric encryption in LISP. This would = reduce the need for negotiations, not require pairs of ITRs and ETRs to = share the same map server, etc. Admittedly it might not be practical for = other reasons.. (may need to store lots of large keys, might be too = slow, etc) Here's one way to do it: You could easily attaching a PGP key id to the RLOCs in the mapping = record returned in map-replies. When an ITR receives a map-reply, the = ITR could grab the public key from one of the well-known keyservers, and = use that public key for encrypting traffic to that ETR. Best regards, Michiel On 8 Sep 2013, at 16:04, Edward Lopez wrote: > Key generation/management/distribution would be the real difficulty. = It would be desirable to use symmetric encryption (Ex. AES256) to = encrypt LISP payloads. Therefore, we use certs & asymmetric encryption = (some form of ECC) at the time of xTR registration to provide a method = to distribute keys to authenticated site members. >=20 > Another consideration is to encrypt just the EID header, and have EIDs = use IPSec (thus LISP would in effect encrypt the outer IPSec ESP = header). Someone in the RLOC space would then require two keys to = decrypt the message fully, and the encryption load would be distributed = between EIDs and xTRs >=20 > Ed Lopez >=20 > Sent from my iPhone ... Sorry for any auto-correct errors >=20 > On Sep 8, 2013, at 10:04 AM, "Noel Chiappa" = wrote: >=20 >>> From: Marc Binderberger >>=20 >>> Lisp is separating Identity from Location but this doesn't mean the >>> RLOC can not be used to identify you. In case of static setups this = is >>> obvious, take the RLOC, go to the ISP, get the (physical) address = and >>> name. >>=20 >> Err, that would get the address and name of the ITR, not the actual = source >> host. >>=20 >> Depending on all sorts of factors, that plus the encrypted packet = _might_ get >> them the identity of the actual originator (not, for example, if the = ITR has >> discarded the key used to encrypt the packet by the time the subpoena >> arrives...) >>=20 >> Noel >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > *** Please note that this message and any attachments may contain = confidential=20 > and proprietary material and information and are intended only for the = use of=20 > the intended recipient(s). If you are not the intended recipient, you = are hereby=20 > notified that any review, use, disclosure, dissemination, distribution = or copying=20 > of this message and any attachments is strictly prohibited. If you = have received=20 > this email in error, please immediately notify the sender and destroy = this e-mail=20 > and any attachments and all copies, whether electronic or printed. > Please also note that any views, opinions, conclusions or commitments = expressed=20 > in this message are those of the individual sender and do not = necessarily reflect=20 > the views of Fortinet, Inc., its affiliates, and emails are not = binding on=20 > Fortinet and only a writing manually signed by Fortinet's General = Counsel can be=20 > a binding commitment of Fortinet to Fortinet's customers or partners. = Thank you. *** >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_795A4B33-B831-4617-8328-649A5B7A2EB5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSLMJEAAoJEKSsLO5c6Acgl/8P/irFxCl74qukQHDmyVszTde+ VioG2PMFmHenZsfi/bGnrycb8Tc/mft5UpyTMr1NlM2/25vcfZ+RPEj6a2+4WMYt TFHDmmdu/yN8V80Zr7Lfv0PLFrWKYMvGJaYNT/DU4vExQu9zv/RSxG3O18AO2eN+ 6hMifsxOHAoFdhA5HSDylSSGQD8fsqfQJNpLUYgooXwFu1R+DEqkbZ+em+SbHOpt Ba1lfe0MCNa1QsjcKEWqfC9VHx3IEXhfcTAeAAHnejWigjO+vrWtI4KQYl6TJXpU 4gp9Emzw38OTWMZB3+R6GNiClZKgOVjpo0U5y5LoOZJjmrWiPQUX2J6FVGCDXNmn uHVhzlujeonv4v64UpQUSiJ/darsAxpFCQ+cGgPoIomqnJAyBvI7KnXFvSxiPkN5 NLV5HP4yYEZXwkIcosPuamESrUvbUvc8VTG8/72GdrUGe+VI/6CCccJP6OJBtgtl b7hZmzREnz479OApX+4fG97boSMmCB1JK3LKyrmrlAezEga7/Ozly924isNCrrzc yol5J6xaOF15rpvlJKVwMROVT9KpOsoezD4TQaiPzk73Am9IqD+RyNCE32pDUR1H uhkz6Rilsle8KpdIDjRLdbH2WSkAJ73Ice+U8fDILESr6zaMRBNeK5lyqzy5aum6 0W7BGUfP1bocxPvJOIIj =36bh -----END PGP SIGNATURE----- --Apple-Mail=_795A4B33-B831-4617-8328-649A5B7A2EB5-- From elopez@fortinet.com Sun Sep 8 13:10:01 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2184311E8158 for ; Sun, 8 Sep 2013 13:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndMVAzpalKXt for ; Sun, 8 Sep 2013 13:09:57 -0700 (PDT) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) by ietfa.amsl.com (Postfix) with ESMTP id ACFCF21E80D9 for ; Sun, 8 Sep 2013 13:09:56 -0700 (PDT) From: Edward Lopez To: "Michiel Blokzijl (mblokzij)" Thread-Topic: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA Thread-Index: AQHOrMGDm/QONZab9EKbi3g6AmcTKpm8RUrb Date: Sun, 8 Sep 2013 20:10:02 +0000 Message-ID: <2A99934B-6706-4281-9A14-4B4EA4F05F19@fortinet.com> References: <20130908140433.D217D18C0CE@mercury.lcs.mit.edu> <281739A7-17F1-494A-8667-94C3F258C072@fortinet.com>, <4ABB752A36221949A095CDE2C6DBB1C80982EC23@xmb-aln-x12.cisco.com> In-Reply-To: <4ABB752A36221949A095CDE2C6DBB1C80982EC23@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FEAS-SYSTEM-WL: 192.168.221.212 Cc: Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 20:10:01 -0000 I agree that asymmetric encryption may be more desirable in theory, but i= n practice symmetric encryption supports much higher performance loads Ed Lopez - Fortinet VP, Carrier Solutions 1090 Kifer Road Sunnyvale, CA 94086 +1 703 220 0988 Sent from my iPhone ... Sorry for any auto-correct errors On Sep 8, 2013, at 2:30 PM, "Michiel Blokzijl (mblokzij)" wrote: > I think it would actually be quite interesting to use "standard" public= key encryption, rather than symmetric encryption in LISP. This would red= uce the need for negotiations, not require pairs of ITRs and ETRs to shar= e the same map server, etc. Admittedly it might not be practical for othe= r reasons.. (may need to store lots of large keys, might be too slow, etc= ) > > Here's one way to do it: > You could easily attaching a PGP key id to the RLOCs in the mapping rec= ord returned in map-replies. When an ITR receives a map-reply, the ITR co= uld grab the public key from one of the well-known keyservers, and use th= at public key for encrypting traffic to that ETR. > > Best regards, > > Michiel > > On 8 Sep 2013, at 16:04, Edward Lopez > wrote: > >> Key generation/management/distribution would be the real difficulty. = It would be desirable to use symmetric encryption (Ex. AES256) to encrypt= LISP payloads. Therefore, we use certs & asymmetric encryption (some fo= rm of ECC) at the time of xTR registration to provide a method to distrib= ute keys to authenticated site members. >> >> Another consideration is to encrypt just the EID header, and have EIDs= use IPSec (thus LISP would in effect encrypt the outer IPSec ESP header)= . Someone in the RLOC space would then require two keys to decrypt the m= essage fully, and the encryption load would be distributed between EIDs a= nd xTRs >> >> Ed Lopez >> >> Sent from my iPhone ... Sorry for any auto-correct errors >> >> On Sep 8, 2013, at 10:04 AM, "Noel Chiappa" = wrote: >> >>>> From: Marc Binderberger >>> >>>> Lisp is separating Identity from Location but this doesn't mean the >>>> RLOC can not be used to identify you. In case of static setups this = is >>>> obvious, take the RLOC, go to the ISP, get the (physical) address an= d >>>> name. >>> >>> Err, that would get the address and name of the ITR, not the actual s= ource >>> host. >>> >>> Depending on all sorts of factors, that plus the encrypted packet _mi= ght_ get >>> them the identity of the actual originator (not, for example, if the = ITR has >>> discarded the key used to encrypt the packet by the time the subpoena= >>> arrives...) >>> >>> Noel >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> *** Please note that this message and any attachments may contain con= fidential >> and proprietary material and information and are intended only for the= use of >> the intended recipient(s). If you are not the intended recipient, you = are hereby >> notified that any review, use, disclosure, dissemination, distribution= or copying >> of this message and any attachments is strictly prohibited. If you hav= e received >> this email in error, please immediately notify the sender and destroy = this e-mail >> and any attachments and all copies, whether electronic or printed. >> Please also note that any views, opinions, conclusions or commitments = expressed >> in this message are those of the individual sender and do not necessar= ily reflect >> the views of Fortinet, Inc., its affiliates, and emails are not bindin= g on >> Fortinet and only a writing manually signed by Fortinet's General Coun= sel can be >> a binding commitment of Fortinet to Fortinet's customers or partners. = Thank you. *** >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** From jnc@mercury.lcs.mit.edu Sun Sep 8 13:20:23 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FCB21E80CE for ; Sun, 8 Sep 2013 13:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HOZ-jSMvc54 for ; Sun, 8 Sep 2013 13:20:18 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 44AB121F8904 for ; Sun, 8 Sep 2013 13:20:17 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B14DA18C0CF; Sun, 8 Sep 2013 16:20:14 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130908202014.B14DA18C0CF@mercury.lcs.mit.edu> Date: Sun, 8 Sep 2013 16:20:14 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 20:20:23 -0000 > From: Edward Lopez > I agree that asymmetric encryption may be more desirable in theory, but > in practice symmetric encryption supports much higher performance loads Use asymmetric encryption to exchance symmetric keys, switch to a new symmetric key every X hours, and throw away the old one. (You don't want to use one key for too much traffic, anyway.) Noel From marc@sniff.de Sun Sep 8 13:50:12 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E62021E80CE for ; Sun, 8 Sep 2013 13:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IErQicm1xWRd for ; Sun, 8 Sep 2013 13:50:11 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA48111E815E for ; Sun, 8 Sep 2013 13:50:11 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 26FBA2AA0F; Sun, 8 Sep 2013 20:50:09 +0000 (GMT) Date: Sun, 8 Sep 2013 22:50:14 +0200 From: Marc Binderberger To: Noel Chiappa Message-ID: <20130908225014145860.20554ab8@sniff.de> In-Reply-To: <20130908140433.D217D18C0CE@mercury.lcs.mit.edu> References: <20130908140433.D217D18C0CE@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: lisp@ietf.org Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 20:50:12 -0000 Hello Noel, > Err, that would get the address and name of the ITR, not the actual source > host. this thread started with a subject of how to save the Internet from the all-powerful agencies. Lisp was not invented to hide your identity, it's only separating it from the location - this doesn't mean the location information cannot reveal your (real life) identity. At the end the agencies want your name, not your (inner) IP address. If the xTR is close to you, e.g. your DSL router runs the xTR, then the locator is effectively a 1:1 mapping to your identity. If the xTR is your office branch router, well, then we have already (a) a router to try to break in and (b) a physical office location to look for you. And if the xTR is further away from your Internet connection point then chances are you can get wire-tapped on your way to/from the xTR, i.e. Lisp would not help you at all. That's all I wanted to say with my statement about "static setups". Complete different story is if Lisp could make encryption e.g. between company office sites much easier, more scalable etc.. Independent from the original subject that would be a real benefit. Regards, Marc > > Depending on all sorts of factors, that plus the encrypted packet > _might_ get > them the identity of the actual originator (not, for example, if the ITR has > discarded the key used to encrypt the packet by the time the subpoena > arrives...) > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From farinacci@gmail.com Sun Sep 8 19:04:29 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F0411E8139 for ; Sun, 8 Sep 2013 19:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su0glB4qGINa for ; Sun, 8 Sep 2013 19:04:28 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id A810C11E810C for ; Sun, 8 Sep 2013 19:04:28 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id r10so5578365pdi.14 for ; Sun, 08 Sep 2013 19:04:28 -0700 (PDT) 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=8iKjM4NM41Edtyn3YFBCwZe5sMz3O9FNPHB+3l9ejp8=; b=bTPkdcIumsLY9aOWkDY0tos416iQjOShrAjTSSC/Z0w++1aPNVsbl6qGPqSVOZx9sf LqoXaK3+07uXtFqSyrV3OTAO3KnwdYJ8pJLQT11YgemzC5hjTjDfZ+1VuK2eU7oLEHWq 4m/a22lrLDveVa/b8AiOQLcyi1pq7O2DK5kSX9hx/PgIljgbc9jsCnVAQ3nlaVzao08z waIVNrCWD420FV16gogbG3amMF5igUROUNiIAlsMkB9q+2a58kDqa8ukt6GVgyLGGERV 2zFqdhfz8CTxsdNcOo1Ec7EV0SQHptytoMkdxgfqAPaEZGqQDVp/KvvS+Ypx8FhsWbLW C6+Q== X-Received: by 10.66.175.133 with SMTP id ca5mr17655252pac.40.1378692268394; Sun, 08 Sep 2013 19:04:28 -0700 (PDT) Received: from [192.168.1.10] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id pu5sm14010321pac.21.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Sep 2013 19:04:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <4ABB752A36221949A095CDE2C6DBB1C80982EC23@xmb-aln-x12.cisco.com> Date: Sun, 8 Sep 2013 19:04:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <656FC147-9E4A-45A9-8ECF-9CEBB114696F@gmail.com> References: <20130908140433.D217D18C0CE@mercury.lcs.mit.edu> <281739A7-17F1-494A-8667-94C3F258C072@fortinet.com> <4ABB752A36221949A095CDE2C6DBB1C80982EC23@xmb-aln-x12.cisco.com> To: "Michiel Blokzijl (mblokzij)" X-Mailer: Apple Mail (2.1508) Cc: Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 09 Sep 2013 02:04:29 -0000 > I think it would actually be quite interesting to use "standard" = public key encryption, rather than symmetric encryption in LISP. This = would reduce the need for negotiations, not require pairs of ITRs and = ETRs to share the same map server, etc. Admittedly it might not be = practical for other reasons.. (may need to store lots of large keys, = might be too slow, etc) Correct. If we don't start with the above assumptions, anything else = will be too complicated to implement and deploy and therefore, corners = will be cut, and insecurity will continue. > Here's one way to do it: > You could easily attaching a PGP key id to the RLOCs in the mapping = record returned in map-replies. When an ITR receives a map-reply, the = ITR could grab the public key from one of the well-known keyservers, and = use that public key for encrypting traffic to that ETR. Do you not want to solve man-in-the-middle attacks? Is this = recommendation solely for providing data privacy? Dino >=20 > Best regards, >=20 > Michiel >=20 > On 8 Sep 2013, at 16:04, Edward Lopez > wrote: >=20 >> Key generation/management/distribution would be the real difficulty. = It would be desirable to use symmetric encryption (Ex. AES256) to = encrypt LISP payloads. Therefore, we use certs & asymmetric encryption = (some form of ECC) at the time of xTR registration to provide a method = to distribute keys to authenticated site members. >>=20 >> Another consideration is to encrypt just the EID header, and have = EIDs use IPSec (thus LISP would in effect encrypt the outer IPSec ESP = header). Someone in the RLOC space would then require two keys to = decrypt the message fully, and the encryption load would be distributed = between EIDs and xTRs >>=20 >> Ed Lopez >>=20 >> Sent from my iPhone ... Sorry for any auto-correct errors >>=20 >> On Sep 8, 2013, at 10:04 AM, "Noel Chiappa" = wrote: >>=20 >>>> From: Marc Binderberger >>>=20 >>>> Lisp is separating Identity from Location but this doesn't mean the >>>> RLOC can not be used to identify you. In case of static setups this = is >>>> obvious, take the RLOC, go to the ISP, get the (physical) address = and >>>> name. >>>=20 >>> Err, that would get the address and name of the ITR, not the actual = source >>> host. >>>=20 >>> Depending on all sorts of factors, that plus the encrypted packet = _might_ get >>> them the identity of the actual originator (not, for example, if the = ITR has >>> discarded the key used to encrypt the packet by the time the = subpoena >>> arrives...) >>>=20 >>> Noel >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> *** Please note that this message and any attachments may contain = confidential=20 >> and proprietary material and information and are intended only for = the use of=20 >> the intended recipient(s). If you are not the intended recipient, you = are hereby=20 >> notified that any review, use, disclosure, dissemination, = distribution or copying=20 >> of this message and any attachments is strictly prohibited. If you = have received=20 >> this email in error, please immediately notify the sender and destroy = this e-mail=20 >> and any attachments and all copies, whether electronic or printed. >> Please also note that any views, opinions, conclusions or commitments = expressed=20 >> in this message are those of the individual sender and do not = necessarily reflect=20 >> the views of Fortinet, Inc., its affiliates, and emails are not = binding on=20 >> Fortinet and only a writing manually signed by Fortinet's General = Counsel can be=20 >> a binding commitment of Fortinet to Fortinet's customers or partners. = Thank you. *** >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Sun Sep 8 19:06:32 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488C111E8139 for ; Sun, 8 Sep 2013 19:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi0wrUdw1clE for ; Sun, 8 Sep 2013 19:06:31 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDF611E810C for ; Sun, 8 Sep 2013 19:06:31 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bg4so5643697pad.32 for ; Sun, 08 Sep 2013 19:06:31 -0700 (PDT) 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=1feRNbDJW4rtJQyzMI34teQ7tC//VHbNinmLIxduNSs=; b=kAjQiV/IFw6XBDpYAB0Jkf3rHsHqtzdcexUg66McH57GveVjM+ndsQmzk9Wu37nTQL wwENc3u6lGMMQ5dVE3Oixv7bfeglb1ZbN71y+R08an/FVRmotGe61tgAx2g2ol3ZO/dz ilSpJv+DvYFRWMCbu3sTZYtiFqgCuWZeFIPZhpZsvr1W/ptv/2jIrdpgkGjE3HGqOwFp yVBfXEvhrXm6OMpT0J80xO8jbNL+x/UO1dBRMn9SWmx03zDwDiWMFl2JYnB4xN7uMLCI jDV3/9bm2Gm9rN9gLUnNsaAA/UEPgQEMD4IU1iVoopaHd98EAkSnbWoAU1FurMZ3Bria fN2Q== X-Received: by 10.66.149.231 with SMTP id ud7mr17664459pab.8.1378692390987; Sun, 08 Sep 2013 19:06:30 -0700 (PDT) Received: from [192.168.1.10] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id sy10sm138354pac.15.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Sep 2013 19:06:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <2A99934B-6706-4281-9A14-4B4EA4F05F19@fortinet.com> Date: Sun, 8 Sep 2013 19:06:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9A1C780A-78C7-4F33-B9F1-E5FEE106E259@gmail.com> References: <20130908140433.D217D18C0CE@mercury.lcs.mit.edu> <281739A7-17F1-494A-8667-94C3F258C072@fortinet.com>, <4ABB752A36221949A095CDE2C6DBB1C80982EC23@xmb-aln-x12.cisco.com> <2A99934B-6706-4281-9A14-4B4EA4F05F19@fortinet.com> To: Edward Lopez X-Mailer: Apple Mail (2.1508) Cc: Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 09 Sep 2013 02:06:32 -0000 > I agree that asymmetric encryption may be more desirable in theory, = but in practice symmetric encryption supports much higher performance = loads But with asymmetric we can use a two packet exchange (the Map-Request = and Map-Reply), store the public key only in the mapping database (no = other components necessary), allow an ITR to send Map-Requests to the = map-resolver where Map-Replies are sent from an ETR connected to another = map-server (the map-resolver is not the map-server for the ETR). Yes, it is slow, but that is the cost for the best security. Dino >=20 > Ed Lopez - Fortinet > VP, Carrier Solutions > 1090 Kifer Road > Sunnyvale, CA 94086 > +1 703 220 0988 >=20 > Sent from my iPhone ... Sorry for any auto-correct errors >=20 > On Sep 8, 2013, at 2:30 PM, "Michiel Blokzijl (mblokzij)" = wrote: >=20 >> I think it would actually be quite interesting to use "standard" = public key encryption, rather than symmetric encryption in LISP. This = would reduce the need for negotiations, not require pairs of ITRs and = ETRs to share the same map server, etc. Admittedly it might not be = practical for other reasons.. (may need to store lots of large keys, = might be too slow, etc) >>=20 >> Here's one way to do it: >> You could easily attaching a PGP key id to the RLOCs in the mapping = record returned in map-replies. When an ITR receives a map-reply, the = ITR could grab the public key from one of the well-known keyservers, and = use that public key for encrypting traffic to that ETR. >>=20 >> Best regards, >>=20 >> Michiel >>=20 >> On 8 Sep 2013, at 16:04, Edward Lopez >> wrote: >>=20 >>> Key generation/management/distribution would be the real difficulty. = It would be desirable to use symmetric encryption (Ex. AES256) to = encrypt LISP payloads. Therefore, we use certs & asymmetric encryption = (some form of ECC) at the time of xTR registration to provide a method = to distribute keys to authenticated site members. >>>=20 >>> Another consideration is to encrypt just the EID header, and have = EIDs use IPSec (thus LISP would in effect encrypt the outer IPSec ESP = header). Someone in the RLOC space would then require two keys to = decrypt the message fully, and the encryption load would be distributed = between EIDs and xTRs >>>=20 >>> Ed Lopez >>>=20 >>> Sent from my iPhone ... Sorry for any auto-correct errors >>>=20 >>> On Sep 8, 2013, at 10:04 AM, "Noel Chiappa" = wrote: >>>=20 >>>>> From: Marc Binderberger >>>>=20 >>>>> Lisp is separating Identity from Location but this doesn't mean = the >>>>> RLOC can not be used to identify you. In case of static setups = this is >>>>> obvious, take the RLOC, go to the ISP, get the (physical) address = and >>>>> name. >>>>=20 >>>> Err, that would get the address and name of the ITR, not the actual = source >>>> host. >>>>=20 >>>> Depending on all sorts of factors, that plus the encrypted packet = _might_ get >>>> them the identity of the actual originator (not, for example, if = the ITR has >>>> discarded the key used to encrypt the packet by the time the = subpoena >>>> arrives...) >>>>=20 >>>> Noel >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> *** Please note that this message and any attachments may contain = confidential=20 >>> and proprietary material and information and are intended only for = the use of=20 >>> the intended recipient(s). If you are not the intended recipient, = you are hereby=20 >>> notified that any review, use, disclosure, dissemination, = distribution or copying=20 >>> of this message and any attachments is strictly prohibited. If you = have received=20 >>> this email in error, please immediately notify the sender and = destroy this e-mail=20 >>> and any attachments and all copies, whether electronic or printed. >>> Please also note that any views, opinions, conclusions or = commitments expressed=20 >>> in this message are those of the individual sender and do not = necessarily reflect=20 >>> the views of Fortinet, Inc., its affiliates, and emails are not = binding on=20 >>> Fortinet and only a writing manually signed by Fortinet's General = Counsel can be=20 >>> a binding commitment of Fortinet to Fortinet's customers or = partners. Thank you. *** >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 > *** Please note that this message and any attachments may contain = confidential=20 > and proprietary material and information and are intended only for the = use of=20 > the intended recipient(s). If you are not the intended recipient, you = are hereby=20 > notified that any review, use, disclosure, dissemination, distribution = or copying=20 > of this message and any attachments is strictly prohibited. If you = have received=20 > this email in error, please immediately notify the sender and destroy = this e-mail=20 > and any attachments and all copies, whether electronic or printed. > Please also note that any views, opinions, conclusions or commitments = expressed=20 > in this message are those of the individual sender and do not = necessarily reflect=20 > the views of Fortinet, Inc., its affiliates, and emails are not = binding on=20 > Fortinet and only a writing manually signed by Fortinet's General = Counsel can be=20 > a binding commitment of Fortinet to Fortinet's customers or partners. = Thank you. *** >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Sun Sep 8 19:15:39 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658FA11E8139 for ; Sun, 8 Sep 2013 19:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUiA0i-j+lsn for ; Sun, 8 Sep 2013 19:15:38 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 84D1911E80EA for ; Sun, 8 Sep 2013 19:15:38 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id p10so5558627pdj.18 for ; Sun, 08 Sep 2013 19:15:38 -0700 (PDT) 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=Y8PkSAE8MQB/925veZASYx5wkk3kWN3Sb/TAsoOYdCs=; b=or6olYMF24ijmJHDCc0fAUj66NVM6tqWNp6tbtm8sgLciEdR4fMfX4EFD5L61Tt+mN 2ye1U+zBKoE3bAv/9XbhVi03JtBtb5cJ+NtE+RlcLUQihUY7POlim8V2hE4vtxsDHgKh egLbAmFnAwynpMmb1YIsaXDH69cFrAEKIh1s0rtOsY9JkECtRnSD76zejHMlQASZvI8T /V2H0mijHyzLdD0DiYFVh0OkoMHIojN5MrnOzbQkD3PfgvGfKhSDIU7kj26oXcA2EiY7 MXGErZMQ6N9+OKIRw/6omu/mS0goglZar7bhWBGvtId+OlzY64tAAgd9H6qYLnw2XUOJ Xvzw== X-Received: by 10.66.122.100 with SMTP id lr4mr248225pab.164.1378692938062; Sun, 08 Sep 2013 19:15:38 -0700 (PDT) Received: from [192.168.1.10] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id ta10sm14101579pab.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Sep 2013 19:15:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <20130908225014145860.20554ab8@sniff.de> Date: Sun, 8 Sep 2013 19:15:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <685A7A7F-53DD-4718-B1A5-659CDE723E2F@gmail.com> References: <20130908140433.D217D18C0CE@mercury.lcs.mit.edu> <20130908225014145860.20554ab8@sniff.de> To: Marc Binderberger X-Mailer: Apple Mail (2.1508) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 09 Sep 2013 02:15:39 -0000 > Hello Noel, >=20 >> Err, that would get the address and name of the ITR, not the actual = source >> host. >=20 > this thread started with a subject of how to save the Internet from = the=20 > all-powerful agencies. Lisp was not invented to hide your identity,=20 > it's only separating it from the location - this doesn't mean the=20 > location information cannot reveal your (real life) identity. At the=20= > end the agencies want your name, not your (inner) IP address. Marc, you may have not followed Noel's point. Let me explain with more = detail. (1) I sit at a LISP site, I have an EID assigned to me. I want to send = packet and don't want anyone in the core to know I am sending. (2) My EID comes out of an EID-prefix that is assigned to the site I = currently reside in. There are a pair of ITRs that encapsulate traffic = for packets I source. (3) When I source packets, my EID is known by routers inside of the = site, but when the packet hits the ITR, the ITR will encrypt the entire = packet it is about to encapsulate. So the outer IP header, the UDP = header, and the LISP header is sent in the clear. Everything after the = LISP header is encrypted. (4) I propose that the ITR use a public-key stored in the mapping = database. It does not need to be protected during transport. The only = parties that have the private-key the ETRs at the destination site (and = you can h a public/private pair per ETR). (5) Men in the middle cannot decrypt the encapsulated packet because = they don't have the private key and it is never transmitted on the = network. All they know is that a packet came from some site that is = connected to ISP foobar. So what, that is coarse information. (6) The key is obtained by the ITR the same time it is getting the RLOC = address for encapsulation. Both come together and if the EID or *key* = changes, we treat it as a mobility event where a new registration is = sent to the mapping database to advertise a new RLOC address and/or a = new key. This is pretty simple. Yes it is slow. But so what. We can throw = hardware technology at it or we can have th math guys come up with as = good but less expensive algorithms. > If the xTR is close to you, e.g. your DSL router runs the xTR, then = the=20 > locator is effectively a 1:1 mapping to your identity. If the xTR is=20= > your office branch router, well, then we have already (a) a router to=20= > try to break in and (b) a physical office location to look for you. It's not all that simple. EIDs can roam around. So if the RLOC at my = house is encapsulating packets because you came over for dinner, it = isn't me that is sourcing. I might be blamed for your wrong-doing, but = all I would say is "I only live there". ;-) Dino > And if the xTR is further away from your Internet connection point = then=20 > chances are you can get wire-tapped on your way to/from the xTR, i.e.=20= > Lisp would not help you at all. >=20 > That's all I wanted to say with my statement about "static setups". >=20 >=20 > Complete different story is if Lisp could make encryption e.g. between=20= > company office sites much easier, more scalable etc.. Independent from=20= > the original subject that would be a real benefit. >=20 >=20 > Regards, Marc >=20 >=20 >>=20 >> Depending on all sorts of factors, that plus the encrypted packet=20 >> _might_ get >> them the identity of the actual originator (not, for example, if the = ITR has >> discarded the key used to encrypt the packet by the time the subpoena >> arrives...) >>=20 >> Noel >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Mon Sep 9 02:01:47 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBFC11E81A5 for ; Mon, 9 Sep 2013 02:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eha5y9Mvyz8x for ; Mon, 9 Sep 2013 02:01:35 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5303411E81A2 for ; Mon, 9 Sep 2013 02:01:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 2F7EE1C06AA; Mon, 9 Sep 2013 02:01:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 20A001C06EF; Mon, 9 Sep 2013 02:01:29 -0700 (PDT) Message-ID: <522D8E6A.6080606@joelhalpern.com> Date: Mon, 09 Sep 2013 05:01:30 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dino Farinacci References: <20130908140433.D217D18C0CE@mercury.lcs.mit.edu> <20130908225014145860.20554ab8@sniff.de> <685A7A7F-53DD-4718-B1A5-659CDE723E2F@gmail.com> In-Reply-To: <685A7A7F-53DD-4718-B1A5-659CDE723E2F@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 09 Sep 2013 09:01:47 -0000 Doesn't this depend upon where the ITR is? If, as is usually proposed, the ITR is a piece of CPE, then it will hide the content of my message (good), and my individual EID (okay), but it won't hide which site is sending the packet, which is an awful lot of information. Also, moving the ITR to the PE router merely means that all the information is collectible at that point. And we have observable data that collectible => will be collected. Yours, Joel On 9/8/13 10:15 PM, Dino Farinacci wrote: >> Hello Noel, >> >>> Err, that would get the address and name of the ITR, not the actual source >>> host. >> >> this thread started with a subject of how to save the Internet from the >> all-powerful agencies. Lisp was not invented to hide your identity, >> it's only separating it from the location - this doesn't mean the >> location information cannot reveal your (real life) identity. At the >> end the agencies want your name, not your (inner) IP address. > > Marc, you may have not followed Noel's point. Let me explain with more detail. > > (1) I sit at a LISP site, I have an EID assigned to me. I want to send packet and don't want anyone in the core to know I am sending. > > (2) My EID comes out of an EID-prefix that is assigned to the site I currently reside in. There are a pair of ITRs that encapsulate traffic for packets I source. > > (3) When I source packets, my EID is known by routers inside of the site, but when the packet hits the ITR, the ITR will encrypt the entire packet it is about to encapsulate. So the outer IP header, the UDP header, and the LISP header is sent in the clear. Everything after the LISP header is encrypted. > > (4) I propose that the ITR use a public-key stored in the mapping database. It does not need to be protected during transport. The only parties that have the private-key the ETRs at the destination site (and you can h a public/private pair per ETR). > > (5) Men in the middle cannot decrypt the encapsulated packet because they don't have the private key and it is never transmitted on the network. All they know is that a packet came from some site that is connected to ISP foobar. So what, that is coarse information. > > (6) The key is obtained by the ITR the same time it is getting the RLOC address for encapsulation. Both come together and if the EID or *key* changes, we treat it as a mobility event where a new registration is sent to the mapping database to advertise a new RLOC address and/or a new key. > > This is pretty simple. Yes it is slow. But so what. We can throw hardware technology at it or we can have th math guys come up with as good but less expensive algorithms. > >> If the xTR is close to you, e.g. your DSL router runs the xTR, then the >> locator is effectively a 1:1 mapping to your identity. If the xTR is >> your office branch router, well, then we have already (a) a router to >> try to break in and (b) a physical office location to look for you. > > It's not all that simple. EIDs can roam around. So if the RLOC at my house is encapsulating packets because you came over for dinner, it isn't me that is sourcing. I might be blamed for your wrong-doing, but all I would say is "I only live there". ;-) > > Dino > >> And if the xTR is further away from your Internet connection point then >> chances are you can get wire-tapped on your way to/from the xTR, i.e. >> Lisp would not help you at all. >> >> That's all I wanted to say with my statement about "static setups". >> >> >> Complete different story is if Lisp could make encryption e.g. between >> company office sites much easier, more scalable etc.. Independent from >> the original subject that would be a real benefit. >> >> >> Regards, Marc >> >> >>> >>> Depending on all sorts of factors, that plus the encrypted packet >>> _might_ get >>> them the identity of the actual originator (not, for example, if the ITR has >>> discarded the key used to encrypt the packet by the time the subpoena >>> arrives...) >>> >>> Noel >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From mblokzij@cisco.com Mon Sep 9 03:28:53 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68EA21E815E for ; Mon, 9 Sep 2013 03:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lfU-vs-LnZQ for ; Mon, 9 Sep 2013 03:28:42 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B54B611E81B9 for ; Mon, 9 Sep 2013 03:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5370; q=dns/txt; s=iport; t=1378722516; x=1379932116; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MX9BJftY7QcMeQ680m+DI2NutYJelR1ZyQyBEbBOF7w=; b=jORyl8HhryORIz8/96COD76pFbhseuoSTXEM2j0jQqDc3pjssbsAdY4O ANnaUOHl1ZlPY+hFXO718PtBPIbyLR0FmpHNO4FMmD6yNir5qHl5CVA/6 /A6ZQcE3kxxj000cGhWDoUo2qnCzKsS1eyJ/0fybKq2+YUUfJREbfQVPx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAM+hLVKtJV2Z/2dsb2JhbABSCYMHOFHCFYEgFnSCJQEBAQQBAQE3NAsSAQgYChQFMgslAgQBDQUIEYdpDMUABI4+gRExB4MdgQADqVuBY4E9gWgkHg X-IronPort-AV: E=Sophos;i="4.90,866,1371081600"; d="scan'208";a="257263923" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 09 Sep 2013 10:28:33 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r89ASWgG006398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 10:28:32 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.246]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 05:28:32 -0500 From: "Michiel Blokzijl (mblokzij)" To: "Joel M. Halpern" , Dino Farinacci Thread-Topic: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA Thread-Index: AQHOrTs7YdAS7j266E2D9Mp+k4WMkpm9mM6A Date: Mon, 9 Sep 2013 10:28:32 +0000 Message-ID: <4ABB752A36221949A095CDE2C6DBB1C80982F67D@xmb-aln-x12.cisco.com> In-Reply-To: <522D8E6A.6080606@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [64.103.106.107] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 09 Sep 2013 10:28:54 -0000 Even in the case where the ITR is on the CPE we might be able to do better. For IPv6 RLOCs, we could use temporary IPv6 addresses (IPv6 privacy extension, rfc4941 I think) as the RLOCs in outgoing packets. That way, you couldn't discover the EID by doing a "reverse lookup" on the RLOC in the mapping system. This would be especially useful if the IPv6 prefix on your uplink is used on a multipoint link, if it's just used on a point-to-point link it's a bit pointless :) Best regards, Michiel On 09/09/2013 10:01, "Joel M. Halpern" wrote: >Doesn't this depend upon where the ITR is? >If, as is usually proposed, the ITR is a piece of CPE, then it will hide >the content of my message (good), and my individual EID (okay), but it >won't hide which site is sending the packet, which is an awful lot of >information. > >Also, moving the ITR to the PE router merely means that all the >information is collectible at that point. And we have observable data >that collectible =3D> will be collected. > >Yours, >Joel > >On 9/8/13 10:15 PM, Dino Farinacci wrote: >>> Hello Noel, >>> >>>> Err, that would get the address and name of the ITR, not the actual >>>>source >>>> host. >>> >>> this thread started with a subject of how to save the Internet from the >>> all-powerful agencies. Lisp was not invented to hide your identity, >>> it's only separating it from the location - this doesn't mean the >>> location information cannot reveal your (real life) identity. At the >>> end the agencies want your name, not your (inner) IP address. >> >> Marc, you may have not followed Noel's point. Let me explain with more >>detail. >> >> (1) I sit at a LISP site, I have an EID assigned to me. I want to send >>packet and don't want anyone in the core to know I am sending. >> >> (2) My EID comes out of an EID-prefix that is assigned to the site I >>currently reside in. There are a pair of ITRs that encapsulate traffic >>for packets I source. >> >> (3) When I source packets, my EID is known by routers inside of the >>site, but when the packet hits the ITR, the ITR will encrypt the entire >>packet it is about to encapsulate. So the outer IP header, the UDP >>header, and the LISP header is sent in the clear. Everything after the >>LISP header is encrypted. >> >> (4) I propose that the ITR use a public-key stored in the mapping >>database. It does not need to be protected during transport. The only >>parties that have the private-key the ETRs at the destination site (and >>you can h a public/private pair per ETR). >> >> (5) Men in the middle cannot decrypt the encapsulated packet because >>they don't have the private key and it is never transmitted on the >>network. All they know is that a packet came from some site that is >>connected to ISP foobar. So what, that is coarse information. >> >> (6) The key is obtained by the ITR the same time it is getting the RLOC >>address for encapsulation. Both come together and if the EID or *key* >>changes, we treat it as a mobility event where a new registration is >>sent to the mapping database to advertise a new RLOC address and/or a >>new key. >> >> This is pretty simple. Yes it is slow. But so what. We can throw >>hardware technology at it or we can have th math guys come up with as >>good but less expensive algorithms. >> >>> If the xTR is close to you, e.g. your DSL router runs the xTR, then the >>> locator is effectively a 1:1 mapping to your identity. If the xTR is >>> your office branch router, well, then we have already (a) a router to >>> try to break in and (b) a physical office location to look for you. >> >> It's not all that simple. EIDs can roam around. So if the RLOC at my >>house is encapsulating packets because you came over for dinner, it >>isn't me that is sourcing. I might be blamed for your wrong-doing, but >>all I would say is "I only live there". ;-) >> >> Dino >> >>> And if the xTR is further away from your Internet connection point then >>> chances are you can get wire-tapped on your way to/from the xTR, i.e. >>> Lisp would not help you at all. >>> >>> That's all I wanted to say with my statement about "static setups". >>> >>> >>> Complete different story is if Lisp could make encryption e.g. between >>> company office sites much easier, more scalable etc.. Independent from >>> the original subject that would be a real benefit. >>> >>> >>> Regards, Marc >>> >>> >>>> >>>> Depending on all sorts of factors, that plus the encrypted packet >>>> _might_ get >>>> them the identity of the actual originator (not, for example, if the >>>>ITR has >>>> discarded the key used to encrypt the packet by the time the subpoena >>>> arrives...) >>>> >>>> Noel >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> >_______________________________________________ >lisp mailing list >lisp@ietf.org >https://www.ietf.org/mailman/listinfo/lisp From internet-drafts@ietf.org Mon Sep 9 09:20:14 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A7A21F940D; Mon, 9 Sep 2013 09:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5KflYDp01zK; Mon, 9 Sep 2013 09:20:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 450DC21F99D0; Mon, 9 Sep 2013 09:18:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130909161838.12150.18175.idtracker@ietfa.amsl.com> Date: Mon, 09 Sep 2013 09:18:38 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-mib-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 09 Sep 2013 16:20:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : LISP MIB Author(s) : Gregg Schudel Amit Jain Victor Moreno Filename : draft-ietf-lisp-mib-12.txt Pages : 65 Date : 2013-09-09 Abstract: This document defines the MIB module that contains managed objects to support the monitoring devices that support the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-mib-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mib-12 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 farinacci@gmail.com Mon Sep 9 09:43:23 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0E221F9E63 for ; Mon, 9 Sep 2013 09:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jZgxcym1B1d for ; Mon, 9 Sep 2013 09:43:23 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3E64921F9D87 for ; Mon, 9 Sep 2013 09:43:23 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz10so6470272pad.2 for ; Mon, 09 Sep 2013 09:43:22 -0700 (PDT) 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=+F80JEYqdq3+xFdeQ5GQrvpMf56ubSxHtfC6cMCMpKE=; b=KqUfRht81IAM8hztUqeYuvrmeS7YW2wt5JhjAEiJuUYjzqNEXYWpPfhg+3qZ2RCqea 8M6PCzsZbKWxq2x749dK9h62fI+qujyOSsv9/aNzvhuEbqxND4AUWPyKIJqLE4vrFlPQ BaCxH8pEo1WFAfS2BPPopBbPacOuD5XwiOF9arRef3ved9hzan6TSQzDC6JAVoE7kFdf iLe6YzbCmVsT/AJdTofMokEWvxdA6EIltzLcNb8JiIHOSWlSri+UxLC1AcNLnoX6ECgB PjbDtzRRtES8Mz2J2DCgYwieEnKcX7k59KmqYUFIFe+Hz2g8/vkJ58gCklRsFbE10fZb hlVQ== X-Received: by 10.68.196.2 with SMTP id ii2mr20491590pbc.86.1378745002835; Mon, 09 Sep 2013 09:43:22 -0700 (PDT) Received: from [192.168.1.115] ([207.145.253.66]) by mx.google.com with ESMTPSA id fk4sm18629345pab.23.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 09:43:21 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <522D8E6A.6080606@joelhalpern.com> Date: Mon, 9 Sep 2013 09:43:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130908140433.D217D18C0CE@mercury.lcs.mit.edu> <20130908225014145860.20554ab8@sniff.de> <685A7A7F-53DD-4718-B1A5-659CDE723E2F@gmail.com> <522D8E6A.6080606@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1508) Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 09 Sep 2013 16:43:24 -0000 > Doesn't this depend upon where the ITR is? > If, as is usually proposed, the ITR is a piece of CPE, then it will = hide the content of my message (good), and my individual EID (okay), but = it won't hide which site is sending the packet, which is an awful lot of = information. Like I said, it depends on the granularity of hiding. > Also, moving the ITR to the PE router merely means that all the = information is collectible at that point. And we have observable data = that collectible =3D> will be collected. Right which I would not suggest. It looks like Crowcroft's source-less packets is the direction people = may want to go? Dino >=20 > Yours, > Joel >=20 > On 9/8/13 10:15 PM, Dino Farinacci wrote: >>> Hello Noel, >>>=20 >>>> Err, that would get the address and name of the ITR, not the actual = source >>>> host. >>>=20 >>> this thread started with a subject of how to save the Internet from = the >>> all-powerful agencies. Lisp was not invented to hide your identity, >>> it's only separating it from the location - this doesn't mean the >>> location information cannot reveal your (real life) identity. At the >>> end the agencies want your name, not your (inner) IP address. >>=20 >> Marc, you may have not followed Noel's point. Let me explain with = more detail. >>=20 >> (1) I sit at a LISP site, I have an EID assigned to me. I want to = send packet and don't want anyone in the core to know I am sending. >>=20 >> (2) My EID comes out of an EID-prefix that is assigned to the site I = currently reside in. There are a pair of ITRs that encapsulate traffic = for packets I source. >>=20 >> (3) When I source packets, my EID is known by routers inside of the = site, but when the packet hits the ITR, the ITR will encrypt the entire = packet it is about to encapsulate. So the outer IP header, the UDP = header, and the LISP header is sent in the clear. Everything after the = LISP header is encrypted. >>=20 >> (4) I propose that the ITR use a public-key stored in the mapping = database. It does not need to be protected during transport. The only = parties that have the private-key the ETRs at the destination site (and = you can h a public/private pair per ETR). >>=20 >> (5) Men in the middle cannot decrypt the encapsulated packet because = they don't have the private key and it is never transmitted on the = network. All they know is that a packet came from some site that is = connected to ISP foobar. So what, that is coarse information. >>=20 >> (6) The key is obtained by the ITR the same time it is getting the = RLOC address for encapsulation. Both come together and if the EID or = *key* changes, we treat it as a mobility event where a new registration = is sent to the mapping database to advertise a new RLOC address and/or a = new key. >>=20 >> This is pretty simple. Yes it is slow. But so what. We can throw = hardware technology at it or we can have th math guys come up with as = good but less expensive algorithms. >>=20 >>> If the xTR is close to you, e.g. your DSL router runs the xTR, then = the >>> locator is effectively a 1:1 mapping to your identity. If the xTR is >>> your office branch router, well, then we have already (a) a router = to >>> try to break in and (b) a physical office location to look for you. >>=20 >> It's not all that simple. EIDs can roam around. So if the RLOC at my = house is encapsulating packets because you came over for dinner, it = isn't me that is sourcing. I might be blamed for your wrong-doing, but = all I would say is "I only live there". ;-) >>=20 >> Dino >>=20 >>> And if the xTR is further away from your Internet connection point = then >>> chances are you can get wire-tapped on your way to/from the xTR, = i.e. >>> Lisp would not help you at all. >>>=20 >>> That's all I wanted to say with my statement about "static setups". >>>=20 >>>=20 >>> Complete different story is if Lisp could make encryption e.g. = between >>> company office sites much easier, more scalable etc.. Independent = from >>> the original subject that would be a real benefit. >>>=20 >>>=20 >>> Regards, Marc >>>=20 >>>=20 >>>>=20 >>>> Depending on all sorts of factors, that plus the encrypted packet >>>> _might_ get >>>> them the identity of the actual originator (not, for example, if = the ITR has >>>> discarded the key used to encrypt the packet by the time the = subpoena >>>> arrives...) >>>>=20 >>>> Noel >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 From farinacci@gmail.com Mon Sep 9 09:45:42 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D818711E81B2 for ; Mon, 9 Sep 2013 09:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYXo7vPXuA6R for ; Mon, 9 Sep 2013 09:45:40 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CD55511E8121 for ; Mon, 9 Sep 2013 09:45:40 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so6457234pdj.1 for ; Mon, 09 Sep 2013 09:45:40 -0700 (PDT) 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=jmVLs2zIGrCl8dXla6yYe5MiNyBlB23BniB9JWezSlY=; b=xoV2a61U2jrn5X3jN3sb7fpx4kpEIy72/vkWHWG7L2Y97kGSisUVW9QFddr5PUM3Dl tH/iydOHDU3P1Nr2PDcb4BgeamtMJBaHX8jpw64/z2mUd3CseOkzmFrVhbUkxLkuZGxh /S5J150lfJhAJ4Fv0j7WZ89b3l/mBWBSvsDmyCKS7mFYDM442z/6LvnE1oH9mSJYAH1S MyUhJdee2ZQMhxPKzqUgKagvQQaOxjJaUM2tQVDymwc7HwD+LXvTiMbDRh7zmG57smmn 74D0GscRHqlrFLeC3yjz31COZAR58uuN/bcoc5+tH6ulBgBpBvhDdN3fmlfCgklgcdFl SdcQ== X-Received: by 10.66.162.136 with SMTP id ya8mr9543797pab.110.1378745140575; Mon, 09 Sep 2013 09:45:40 -0700 (PDT) Received: from [192.168.1.115] ([207.145.253.66]) by mx.google.com with ESMTPSA id ve9sm17269267pbc.19.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 09:45:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <4ABB752A36221949A095CDE2C6DBB1C80982F67D@xmb-aln-x12.cisco.com> Date: Mon, 9 Sep 2013 09:45:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ABB752A36221949A095CDE2C6DBB1C80982F67D@xmb-aln-x12.cisco.com> To: "Michiel Blokzijl (mblokzij)" X-Mailer: Apple Mail (2.1508) Cc: Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 09 Sep 2013 16:45:42 -0000 > Even in the case where the ITR is on the CPE we might be able to do = better. >=20 > For IPv6 RLOCs, we could use temporary IPv6 addresses (IPv6 privacy > extension, rfc4941 I think) as the RLOCs in outgoing packets. That = way, > you couldn't discover the EID by doing a "reverse lookup" on the RLOC = in > the mapping system. Well in today's deployments there are no RLOC records in the mapping = database. So finding an EID associated with an RLOC is a different thing = to do today. And this is goodness. But not to take away from your point. But if those private addresses are = not injected into the underlying routing protocol and PE boxes run URPF, = those packets will be dropped. Dino > This would be especially useful if the IPv6 prefix on your uplink is = used > on a multipoint link, if it's just used on a point-to-point link it's = a > bit pointless :) >=20 > Best regards, >=20 > Michiel >=20 > On 09/09/2013 10:01, "Joel M. Halpern" wrote: >=20 >> Doesn't this depend upon where the ITR is? >> If, as is usually proposed, the ITR is a piece of CPE, then it will = hide >> the content of my message (good), and my individual EID (okay), but = it >> won't hide which site is sending the packet, which is an awful lot of >> information. >>=20 >> Also, moving the ITR to the PE router merely means that all the >> information is collectible at that point. And we have observable = data >> that collectible =3D> will be collected. >>=20 >> Yours, >> Joel >>=20 >> On 9/8/13 10:15 PM, Dino Farinacci wrote: >>>> Hello Noel, >>>>=20 >>>>> Err, that would get the address and name of the ITR, not the = actual >>>>> source >>>>> host. >>>>=20 >>>> this thread started with a subject of how to save the Internet from = the >>>> all-powerful agencies. Lisp was not invented to hide your identity, >>>> it's only separating it from the location - this doesn't mean the >>>> location information cannot reveal your (real life) identity. At = the >>>> end the agencies want your name, not your (inner) IP address. >>>=20 >>> Marc, you may have not followed Noel's point. Let me explain with = more >>> detail. >>>=20 >>> (1) I sit at a LISP site, I have an EID assigned to me. I want to = send >>> packet and don't want anyone in the core to know I am sending. >>>=20 >>> (2) My EID comes out of an EID-prefix that is assigned to the site I >>> currently reside in. There are a pair of ITRs that encapsulate = traffic >>> for packets I source. >>>=20 >>> (3) When I source packets, my EID is known by routers inside of the >>> site, but when the packet hits the ITR, the ITR will encrypt the = entire >>> packet it is about to encapsulate. So the outer IP header, the UDP >>> header, and the LISP header is sent in the clear. Everything after = the >>> LISP header is encrypted. >>>=20 >>> (4) I propose that the ITR use a public-key stored in the mapping >>> database. It does not need to be protected during transport. The = only >>> parties that have the private-key the ETRs at the destination site = (and >>> you can h a public/private pair per ETR). >>>=20 >>> (5) Men in the middle cannot decrypt the encapsulated packet because >>> they don't have the private key and it is never transmitted on the >>> network. All they know is that a packet came from some site that is >>> connected to ISP foobar. So what, that is coarse information. >>>=20 >>> (6) The key is obtained by the ITR the same time it is getting the = RLOC >>> address for encapsulation. Both come together and if the EID or = *key* >>> changes, we treat it as a mobility event where a new registration is >>> sent to the mapping database to advertise a new RLOC address and/or = a >>> new key. >>>=20 >>> This is pretty simple. Yes it is slow. But so what. We can throw >>> hardware technology at it or we can have th math guys come up with = as >>> good but less expensive algorithms. >>>=20 >>>> If the xTR is close to you, e.g. your DSL router runs the xTR, then = the >>>> locator is effectively a 1:1 mapping to your identity. If the xTR = is >>>> your office branch router, well, then we have already (a) a router = to >>>> try to break in and (b) a physical office location to look for = you. >>>=20 >>> It's not all that simple. EIDs can roam around. So if the RLOC at my >>> house is encapsulating packets because you came over for dinner, it >>> isn't me that is sourcing. I might be blamed for your wrong-doing, = but >>> all I would say is "I only live there". ;-) >>>=20 >>> Dino >>>=20 >>>> And if the xTR is further away from your Internet connection point = then >>>> chances are you can get wire-tapped on your way to/from the xTR, = i.e. >>>> Lisp would not help you at all. >>>>=20 >>>> That's all I wanted to say with my statement about "static setups". >>>>=20 >>>>=20 >>>> Complete different story is if Lisp could make encryption e.g. = between >>>> company office sites much easier, more scalable etc.. Independent = from >>>> the original subject that would be a real benefit. >>>>=20 >>>>=20 >>>> Regards, Marc >>>>=20 >>>>=20 >>>>>=20 >>>>> Depending on all sorts of factors, that plus the encrypted packet >>>>> _might_ get >>>>> them the identity of the actual originator (not, for example, if = the >>>>> ITR has >>>>> discarded the key used to encrypt the packet by the time the = subpoena >>>>> arrives...) >>>>>=20 >>>>> Noel >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From farinacci@gmail.com Mon Sep 9 20:07:23 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC11E11E812F for ; Mon, 9 Sep 2013 20:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P89ZO1EVNSRU for ; Mon, 9 Sep 2013 20:07:23 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0A96811E80FA for ; Mon, 9 Sep 2013 20:07:23 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fz6so7105090pac.31 for ; Mon, 09 Sep 2013 20:07:22 -0700 (PDT) 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=NXoUb1rAoNXhfX8hh9VUYy7b4Hep7TwS4ys+lF3dCe4=; b=b4C3Zv5p76f8db7/b0z/jihRLkv2BZfYkMhfSWb5y4aGBsdSjOhIw8nKdiu2WIxFlG ebTdzl1Fb3vcEsRgQYQs9sp90u5ivBCiqMfmM49cP4P1/wkVEblkYk+gz4z2UOtlz/zh we8NZxUaWWzT8c+OjrEUjW3PaEJYN0gNLao3/37BozDWHwAd6rXh5n0ecSlYGXb2RsYI 9xzNhJ0OmF/5aunbLNhZtxFg4ZO60DByRZlHZs02M3/120srT4m4ph4Z0KFDX6+tZND8 t7lZzz2UDz0/5+yycw7g2OCn6gJ79XDfdyrKMqO6L9IOyptgm4LprB+RIKnieWHqdZqW mJ5A== X-Received: by 10.68.189.229 with SMTP id gl5mr22202733pbc.77.1378782442678; Mon, 09 Sep 2013 20:07:22 -0700 (PDT) Received: from [192.168.1.10] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id py4sm19621501pbc.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 20:07:22 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: Date: Mon, 9 Sep 2013 20:07:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7330F9D1-803B-453C-8DE6-D206B8D1CA95@gmail.com> References: <20130902114206.5817.81015.idtracker@ietfa.amsl.com> To: Alberto Rodriguez-Natal X-Mailer: Apple Mail (2.1508) Cc: "lisp@ietf.org list" Subject: Re: [lisp] Expiration impending: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 10 Sep 2013 03:07:24 -0000 > First, we will like to see a 5-tuple LCAF to allow mapping lookups = based on flows. In the attached TXT there is a proposed format. It = allows to perform exact match flow lookups, as well as best match = lookups using port range and prefix mask length. The proposed 5-tuple = LCAF is based on current types 4 and 12, and can be a new type itself, = or be merged with those types. At the risk of adding too many new LCAFs with too many combinations, = this is what I propose. (1) Change Type 4 to include port ranges. (2) Use Type 4 and Type 12 together in a AFI-List type. That should serve all purposes. > Second, we find interesting to have a generic (self-defined) LCAF = type. A format like that will allow complex and/or experimental LISP = applications. We aim for a binary JSON-like format. This LCAF type = almost needs no definition, just a new LCAF type number and an agreement = on the binary specification to use. Personally, I like the Universal = Binary JSON Specification (http://ubjson.org/). I think we should call it the JSON LCAF type so an EID or RLOC encoding = is known to be JSON tuples. But I think they way this will be used is to = use a regularly encoded EID and what is returned is a JSON encoded RLOC. Also, I am not sure that binary coding is required. I can imagine some = people wanting a XML encoding as well. And that would be in ascii or = unicode. I will propose text and the working group can comment on the text. Dino From farinacci@gmail.com Mon Sep 9 21:36:03 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB6921E8106 for ; Mon, 9 Sep 2013 21:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-2.508, BAYES_50=0.001, HTML_COMMENT_SAVED_URL=0.114, HTML_MESSAGE=0.001, MANGLED_LIPS=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvvvQshAyzK3 for ; Mon, 9 Sep 2013 21:35:55 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF2C21E80FC for ; Mon, 9 Sep 2013 21:35:55 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so7216412pad.33 for ; Mon, 09 Sep 2013 21:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=QpJTwWUCCLym8/hBQdEG4p92I/etVyAllIpmF1jxE/A=; b=wJz7BugmLpqYrZrkK6XEP+YOmquPdcMxaEBiOaJAQP2PZi83/Plzw257Fob9OiouuQ ZWXbedKPQal2/sO1ZJb1LkFQVD1gDUJQAy7NtiE9b2pvqUHGnEZIqhyf8HsFPHAH0W2y yeaKWbM9uPeThjrdnIjZKR85A7Sr8ulTl//jTD4mjTW0jhHle4BqwRbq9TL423ENeFA1 RcZrGTKwHsqw02CWvZila+txGKfVWufM2QELMphTFNH3qQ5b4rta9MB3TtJN6Yxy3Bs3 lRWY/Em48n8LtrSjaBehyu3IAKXqtPgINaEtekgxPkcmEb84x0KaGcH8JGOTZDR9k4R8 tCwQ== X-Received: by 10.67.21.130 with SMTP id hk2mr24249223pad.76.1378787752122; Mon, 09 Sep 2013 21:35:52 -0700 (PDT) Received: from [192.168.1.10] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id fy4sm20080119pbb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 21:35:51 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/mixed; boundary="Apple-Mail=_9418C405-18CE-4851-AA09-89BEB6EF981A" Date: Mon, 9 Sep 2013 21:35:49 -0700 Message-Id: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com> To: "lisp@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: David Meyer Subject: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 10 Sep 2013 04:36:03 -0000 --Apple-Mail=_9418C405-18CE-4851-AA09-89BEB6EF981A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, I compiled all the input I received for updates to the LCAF = draft. Find enclosed the updated draft and a diff file. Deadline is tomorrow but we can have discussion before I post. So if = there are any changes or comments, I can add them into the -03 draft. So = I am not that worried about missing the deadline. Changes include: B.1. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affliations. o Added Instance-ID to the Multicast Info Type so there is relative ease in parsing (S,G) entries within a VPN. o Add port range encodings to the Application Data LCAF Type. o Add a new JSON LCAF Type. o Add Address Key/Value LCAF Type to allow attributes to be attached to an address. Dino --Apple-Mail=_9418C405-18CE-4851-AA09-89BEB6EF981A Content-Disposition: attachment; filename=draft-ietf-lisp-lcaf-03.txt Content-Type: text/plain; name="draft-ietf-lisp-lcaf-03.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft lispers.net Intended status: Experimental D. Meyer Expires: March 13, 2014 Brocade J. Snijders Hibernia Networks September 9, 2013 LISP Canonical Address Format (LCAF) draft-ietf-lisp-lcaf-03 Abstract This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 13, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Farinacci, et al. Expires March 13, 2014 [Page 1] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 4. LISP Canonical Address Applications . . . . . . . . . . . . . 7 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 8 4.3. Convey Application Specific Data . . . . . . . . . . . . . 9 4.4. Assigning Geo Coordinates to Locator Addresses . . . . . . 10 4.5. Generic Database Mapping Lookups . . . . . . . . . . . . . 12 4.6. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 13 4.7. PETR Admission Control Functionality . . . . . . . . . . . 15 4.8. Multicast Group Membership Information . . . . . . . . . . 16 4.9. Traffic Engineering using Re-encapsulating Tunnels . . . . 18 4.10. Storing Security Data in the Mapping Database . . . . . . 19 4.11. Source/Destination 2-Tuple Lookups . . . . . . . . . . . . 20 4.12. Replication List Entries for Multicast Forwarding . . . . 21 4.13. Data Model Encoding . . . . . . . . . . . . . . . . . . . 22 4.14. Encoding Key/Value Address Pairs . . . . . . . . . . . . . 23 4.15. Applications for AFI List Type . . . . . . . . . . . . . . 24 4.15.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 24 4.15.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 25 4.15.3. ASCII Names in the Mapping Database . . . . . . . . . 25 4.15.4. Using Recursive LISP Canonical Address Encodings . . 26 4.15.5. Compatibility Mode Use Case . . . . . . . . . . . . . 27 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30 7.2. Informative References . . . . . . . . . . . . . . . . . . 30 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 32 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 33 B.1. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . . 33 B.2. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . . 33 B.3. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . . 33 B.4. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Farinacci, et al. Expires March 13, 2014 [Page 2] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 1. Introduction The LISP architecture and protocols [RFC6830] introduces two new numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) which are intended to replace most use of IP addresses on the Internet. To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifier (AFI), length, and value fields. Currently defined AFIs include IPv4 and IPv6 addresses, which are formatted according to code-points assigned in [AFI] as follows: IPv4 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 2 | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document describes the currently-defined AFIs the LISP protocol uses along with their encodings and introduces the LISP Canonical Address Format (LCAF) that can be used to define the LISP-specific encodings for arbitrary AFI values. Farinacci, et al. Expires March 13, 2014 [Page 3] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 2. Definition of Terms Address Family Identifier (AFI): a term used to describe an address encoding in a packet. An address family currently defined for IPv4 or IPv6 addresses. See [AFI] and [RFC1700] for details. The reserved AFI value of 0 is used in this specification to indicate an unspecified encoded address where the the length of the address is 0 bytes following the 16-bit AFI value of 0. Unspecified Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Farinacci, et al. Expires March 13, 2014 [Page 4] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 3. LISP Canonical Address Format Encodings IANA has assigned AFI value 16387 (0x4003) to the LISP architecture and protocols. This specification defines the encoding format of the LISP Canonical Address (LCA). The first 4 bytes of an LISP Canonical Address are followed by a variable length of fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Flags: this 8-bit field is for future definition and use. For now, set to zero on transmission and ignored on receipt. Type: this 8-bit field is specific to the LISP Canonical Address formatted encodings, values are: Type 0: Null Body Type Type 1: AFI List Type Type 2: Instance ID Type Type 3: AS Number Type Type 4: Application Data Type Type 5: Geo Coordinates Type Type 6: Opaque Key Type Type 7: NAT-Traversal Type Type 8: Nonce Locator Type Type 9: Multicast Info Type Farinacci, et al. Expires March 13, 2014 [Page 5] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 Type 10: Explicit Locator Path Type Type 11: Security Key Type Type 12: Source/Dest Key Type Type 13: Replication List Entry Type Type 14: JSON Data Model Type Type 15: Key/Value Address Pair Type Rsvd2: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Length: this 16-bit field is in units of bytes and covers all of the LISP Canonical Address payload, starting and including the byte after the Length field. So any LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. The 8 bytes include the AFI, Flags, Type, Reserved, and Length fields. When the AFI is not next to encoded address in a control message, then the encoded address will have a minimum length of 6 bytes when the Length field is 0. The 6 bytes include the Flags, Type, Reserved, and Length fields. Farinacci, et al. Expires March 13, 2014 [Page 6] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4. LISP Canonical Address Applications 4.1. Segmentation using LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces must remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. Another use for the Instance ID LISP Canonical Address Format is when creating multiple segmented VPNs inside of a LISP site where keeping EID-prefix based subnets is desirable. Instance ID LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 2 | IID mask-len | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IID mask-len: if the AFI is set to 0, then this format is not encoding an extended EID-prefix but rather an instance-ID range where the 'IID mask-len' indicates the number of high-order bits used in the Instance ID field for the range. Length value n: length in bytes of the AFI address that follows the Instance ID field including the AFI field itself. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. AFI =3D x: x can be any AFI value from [AFI]. This LISP Canonical Address Type can be used to encode either EID or RLOC addresses. Farinacci, et al. Expires March 13, 2014 [Page 7] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.2. Carrying AS Numbers in the Mapping Database When an AS number is stored in the LISP Mapping Database System for either policy or documentation reasons, it can be encoded in a LISP Canonical Address. AS Number LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 3 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the AS Number field including the AFI field itself. AS Number: the 32-bit AS number of the autonomous system that has been assigned either the EID or RLOC that follows. AFI =3D x: x can be any AFI value from [AFI]. The AS Number Canonical Address Type can be used to encode either EID or RLOC addresses. The former is used to describe the LISP-ALT AS number the EID-prefix for the site is being carried for. The latter is used to describe the AS that is carrying RLOC based prefixes in the underlying routing system. Farinacci, et al. Expires March 13, 2014 [Page 8] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.3. Convey Application Specific Data When a locator-set needs to be conveyed based on the type of application or the Per-Hop Behavior (PHB) of a packet, the Application Data Type can be used. Application Data LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 8 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 TC, or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Application Data fields including the AFI field itself. IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow Label used in an IPv6 header. Local Port/Remote Port Ranges: these fields are from the TCP, UDP, or SCTP transport header. A range can be specified by using a lower value and an upper value. When a single port is encoded, the lower and upper value fields are the same. AFI =3D x: x can be any AFI value from [AFI]. The Application Data Canonical Address Type is used for an EID encoding when an ITR wants a locator-set for a specific application. When used for an RLOC encoding, the ETR is supplying a locator-set for each specific application is has been configured to advertise. Farinacci, et al. Expires March 13, 2014 [Page 9] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.4. Assigning Geo Coordinates to Locator Addresses If an ETR desires to send a Map-Reply describing the Geo Coordinates for each locator in its locator-set, it can use the Geo Coordinate Type to convey physical location information. Coordinates are specified using the WGS-84 (World Geodetic System) reference coordinate system [WGS-84]. Geo Coordinate LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Longitude and Latitude fields including the AFI field itself. N: When set to 1 means North, otherwise South. Latitude Degrees: Valid values range from 0 to 90 degrees above or below the equator (northern or southern hemisphere, respectively). Latitude Minutes: Valid values range from 0 to 59. Latitude Seconds: Valid values range from 0 to 59. E: When set to 1 means East, otherwise West. Longitude Degrees: Value values are from 0 to 180 degrees right or left of the Prime Meridian. Farinacci, et al. Expires March 13, 2014 [Page 10] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 Longitude Minutes: Valid values range from 0 to 59. Longitude Seconds: Valid values range from 0 to 59. Altitude: Height relative to sea level in meters. This is a signed integer meaning that the altitude could be below sea level. A value of 0x7fffffff indicates no Altitude value is encoded. AFI =3D x: x can be any AFI value from [AFI]. The Geo Coordinates Canonical Address Type can be used to encode either EID or RLOC addresses. When used for EID encodings, you can determine the physical location of an EID along with the topological location by observing the locator-set. Farinacci, et al. Expires March 13, 2014 [Page 11] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.5. Generic Database Mapping Lookups When the LISP Mapping Database system holds information accessed by a generic formatted key (where the key is not the usual IPv4 or IPv6 address), an opaque key may be desirable. Opaque Key LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 6 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Field Num | Key Wildcard Fields | Key . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the type's payload. The value n is the number of bytes that follow this Length field. Key Field Num: the number of fields (minus 1) the key can be broken up into. The width of the fields are fixed length. So for a key size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 bytes in length. Valid values for this field range from 0 to 15 supporting a maximum of 16 field separations. Key Wildcard Fields: describes which fields in the key are not used as part of the key lookup. This wildcard encoding is a bitfield. Each bit is a don't-care bit for a corresponding field in the key. Bit 0 (the low-order bit) in this bitfield corresponds the first field, right-justified in the key, bit 1 the second field, and so on. When a bit is set in the bitfield it is a don't-care bit and should not be considered as part of the database lookup. When the entire 16-bits is set to 0, then all bits of the key are used for the database lookup. Key: the variable length key used to do a LISP Database Mapping lookup. The length of the key is the value n (shown above) minus 3. Farinacci, et al. Expires March 13, 2014 [Page 12] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.6. NAT Traversal Scenarios When a LISP system is conveying global address and mapped port information when traversing through a NAT device, the NAT-Traversal LCAF Type is used. See [LISP-NATT] for details. NAT-Traversal Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 7 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MS UDP Port Number | ETR UDP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Global ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | MS RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Private ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI addresses that follows the UDP Port Number field including the AFI fields themselves. MS UDP Port Number: this is the UDP port number of the Map-Server and is set to 4342. ETR UDP Port Number: this is the port number returned to a LISP system which was copied from the source port from a packet that has flowed through a NAT device. AFI =3D x: x can be any AFI value from [AFI]. Global ETR RLOC Address: this is an address known to be globally unique built by NAT-traversal functionality in a LISP router. MS RLOC Address: this is the address of the Map-Server used in the destination RLOC of a packet that has flowed through a NAT device. Farinacci, et al. Expires March 13, 2014 [Page 13] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 Private ETR RLOC Address: this is an address known to be a private address inserted in this LCAF format by a LISP router that resides on the private side of a NAT device. RTR RLOC Address: this is an encapsulation address used by an ITR or PITR which resides behind a NAT device. This address is known to have state in a NAT device so packets can flow from it to the LISP ETR behind the NAT. There can be one or more NTR addresses supplied in these set of fields. The number of NTRs encoded is determined by the LCAF length field. When there are no NTRs supplied, the NTR fields can be omitted and reflected by the LCAF length field or an AFI of 0 can be used to indicate zero NTRs encoded. Farinacci, et al. Expires March 13, 2014 [Page 14] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.7. PETR Admission Control Functionality When a public PETR device wants to verify who is encapsulating to it, it can check for a specific nonce value in the LISP encapsulated packet. To convey the nonce to admitted ITRs or PITRs, this LCAF format is used in a Map-Register or Map-Reply locator-record. Nonce Locator Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 8 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the Nonce field including the AFI field itself. Reserved: must be set to zero and ignore on receipt. Nonce: this is a nonce value returned by an ETR in a Map-Reply locator-record to be used by an ITR or PITR when encapsulating to the locator address encoded in the AFI field of this LCAF type. AFI =3D x: x can be any AFI value from [AFI]. Farinacci, et al. Expires March 13, 2014 [Page 15] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.8. Multicast Group Membership Information Multicast group information can be published in the mapping database so a lookup on an EID based group address can return a replication list of group addresses or a unicast addresses for single replication or multiple head-end replications. The intent of this type of unicast replication is to deliver packets to multiple ETRs at receiver LISP multicast sites. The locator-set encoding for this EID record type can be a list of ETRs when they each register with "Merge Semantics". The encoding can be a typical AFI encoded locator address. When an RTR list is being registered (with multiple levels according to [LISP-RE]), the Replication List Entry LCAF type is used for locator encoding. This LCAF encoding can be used to send broadcast packets to all members of a subnet when each EIDs are away from their home subnet location. Multicast Info Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 9 | Rsvd2 |R|L|J| 8 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source MaskLen| Group MaskLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source/Subnet Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Group Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. R-bit: this is the RP-bit that represents PIM (S,G,RP-bit) multicast state. This bit can be set for Joins (when the J-bit is set) or for Leaves (when the L-bit is set). See [LISP-MRSIG] for more usage details. Farinacci, et al. Expires March 13, 2014 [Page 16] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 L-bit: this is the Leave-Request bit and is used when this LCAF type is present in the destination EID-prefix field of a Map-Request. See [LISP-MRSIG] for details. J-bit: this is the Join-Request bit and is used when this LCAF type is present in the destination EID-prefix field of a Map-Request. See [LISP-MRSIG] for details. The J-bit MUST not be set when the L-bit is also set in the same LCAF block. A receiver should not take any specific Join or Leave action when both bits are set. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The use of the Instance-ID in this LCAF type is to associate a multicast forwarding entry for a given VPN. The instance-ID describes the VPN and is registered to the mapping database system as a 3-tuple of (Instance-ID, S-prefix, G-prefix). Source MaskLen: the mask length of the source prefix that follows. Group MaskLen: the mask length of the group prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Farinacci, et al. Expires March 13, 2014 [Page 17] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.9. Traffic Engineering using Re-encapsulating Tunnels For a given EID lookup into the mapping database, this LCAF format can be returned to provide a list of locators in an explicit re- encapsulation path. See [LISP-TE] for details. Explicit Locator Path (ELP) Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 10 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Rsvd3 |L|P|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Rsvd3 |L|P|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Lookup bit (L): this is the Lookup bit used to indicate to the user of the ELP to not use this address for encapsulation but to look it up in the mapping database system to obtain an encapsulating RLOC address. RLOC-Probe bit (P): this is the RLOC-probe bit which means the Reencap Hop allows RLOC-probe messages to be sent to it. When the R-bit is set to 0, RLOC-probes must not be sent. When a Reencap Hop is an anycast address then multiple physical Reencap Hops are using the same RLOC address. In this case, RLOC-probes are not needed because when the closest RLOC address is not reachable another RLOC address can reachable. Strict bit (S): this the strict bit which means the associated Rencap Hop is required to be used. If this bit is 0, the reencapsulator can skip this Reencap Hop and go to the next one in the list. Farinacci, et al. Expires March 13, 2014 [Page 18] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.10. Storing Security Data in the Mapping Database When a locator in a locator-set has a security key associated with it, this LCAF format will be used to encode key material. See [LISP-DDT] for details. Security Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 11 | Rsvd2 | 6 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Length | Key Material ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Key Material | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Locator Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that start with the Key Material field. Key Count: the Key Count field declares the number of Key sections included in this LCAF. Key Algorithm: the Algorithm field identifies the key's cryptographic algorithm and specifies the format of the Public Key field. R bit: this is the revoke bit and, if set, it specifies that this Key is being Revoked. Key Length: this field determines the length in bytes of the Key Material field. Key Material: the Key Material field stores the key material. The format of the key material stored depends on the Key Algorithm field. AFI =3D x: x can be any AFI value from [AFI].This is the locator address that owns the encoded security key. Farinacci, et al. Expires March 13, 2014 [Page 19] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.11. Source/Destination 2-Tuple Lookups When both a source and destination address of a flow needs consideration for different locator-sets, this 2-tuple key is used in EID fields in LISP control messages. When the Source/Dest key is registered to the mapping database, it can be encoded as a source- prefix and destination-prefix. When the Source/Dest is used as a key for a mapping database lookup the source and destination come from a data packet. Source/Dest Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 12 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source-ML | Dest-ML | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Destination-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Source-ML: the mask length of the source prefix that follows. Dest-ML: the mask length of the destination prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Refer to [LISP-TE] for usage details. Farinacci, et al. Expires March 13, 2014 [Page 20] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.12. Replication List Entries for Multicast Forwarding The Replication List Entry LCAF type is an encoding for a locator being used for unicast replication according to the specification in [LISP-RE]. This locator encoding is pointed to by a Multicast Info LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs) that are participating in an overlay distribution tree. Each RTR will register its locator address and its configured level in the distribution tree. Replication List Entry Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 13 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2,3,4}: must be set to zero and ignore on receipt. Level Value: this value is associated with the level of hierarchy the RTR resides in an overlay distribution tree. The level numbers are ordered from lowest value being close to the ITR (meaning that ITRs replicate to level-0 RTRs) and higher levels are further downstream on the distribution tree closer to ETRs of multicast receiver sites. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Farinacci, et al. Expires March 13, 2014 [Page 21] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.13. Data Model Encoding This type allows a JSON data model to be encoded either as an EID or RLOC. JSON Data Model Type Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 14 | Rsvd2 |B| n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JSON binary or text encoding ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Optional Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2}: must be set to zero and ignore on receipt. B bit: indicates that the JSON field is binary encoded according to [JSON-BINARY] when the bit is set to 1. Otherwise the encoding is based on text encoding according to [RFC4627]. JSON field: a variable length field that contains either binary or text encodings. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Farinacci, et al. Expires March 13, 2014 [Page 22] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.14. Encoding Key/Value Address Pairs The Key/Value pair is for example useful for attaching attributes to other elements of LISP packets, such as EIDs or RLOCs. When attaching attributes to EIDs or RLOCs, it's necessary to distinguish between the element that should be used as EID or RLOC, and hence as key for lookups, and additional attributes. This is especially the case when the difference cannot be determined from the types of the elements, such as when two IP addresses are being used. Key/Value Pair Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 15 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address as Key(1) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address as Value(1) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address as Key(n) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address as Value(n) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2}: must be set to zero and ignore on receipt. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Address as Key(1): this AFI encoded address will be attached with the attributes encoded in "Address as Value(1)" which follows this field. Address as Value(1): this AFI encoded address will be teh attribute address that goes along with "Address as Key(1)" which precedes this field. Multiple Key/Value pairs can be included in a single LCAF encoding. Farinacci, et al. Expires March 13, 2014 [Page 23] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.15. Applications for AFI List Type 4.15.1. Binding IPv4 and IPv6 Addresses When header translation between IPv4 and IPv6 is desirable a LISP Canonical Address can use the AFI List Type to carry multiple AFIs in one LCA AFI. Bounded Address LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 4 + 2 + 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | AFI =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI encoded addresses are used. This type of address format can be included in a Map-Request when the address is being used as an EID, but the Mapping Database System lookup destination can use only the IPv4 address. This is so a Mapping Database Service Transport System, such as LISP-ALT [RFC6836], can use the Map-Request destination address to route the control message to the desired LISP site. Farinacci, et al. Expires March 13, 2014 [Page 24] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.15.2. Layer-2 VPNs When MAC addresses are stored in the LISP Mapping Database System, the AFI List Type can be used to carry AFI 6. MAC Address LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 6 | Layer-2 MAC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Layer-2 MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 8 when MAC address AFI encoded addresses are used. This address format can be used to connect layer-2 domains together using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. In this use-case, a MAC address is being used as an EID, and the locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or even another MAC address being used as an RLOC. 4.15.3. ASCII Names in the Mapping Database If DNS names or URIs are stored in the LISP Mapping Database System, the AFI List Type can be used to carry an ASCII string where it is delimited by length 'n' of the LCAF Length encoding. ASCII LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 17 | DNS Name or URI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 13, 2014 [Page 25] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 Length value n: length in bytes AFI=3D17 field and the = null-terminated ASCII string (the last byte of 0 is included). 4.15.4. Using Recursive LISP Canonical Address Encodings When any combination of above is desirable, the AFI List Type value can be used to carry within the LCA AFI another LCA AFI. Recursive LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 4 + 8 + 2 + 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 QQS or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port | Remote Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 18 when an AFI=3D1 IPv4 address = is included. This format could be used by a Mapping Database Transport System, such as LISP-ALT [RFC6836], where the AFI=3D1 IPv4 address is used as an EID and placed in the Map-Request destination address by the sending LISP system. The ALT system can deliver the Map-Request to the LISP destination site independent of the Application Data Type AFI payload values. When this AFI is processed by the destination LISP site, it can return different locator-sets based on the type of application or level of service that is being requested. Farinacci, et al. Expires March 13, 2014 [Page 26] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 4.15.5. Compatibility Mode Use Case A LISP system should use the AFI List Type format when sending to LISP systems that do not support a particular LCAF Type used to encode locators. This allows the receiving system to be able to parse a locator address for encapsulation purposes. The list of AFIs in an AFI List LCAF Type has no semantic ordering and a receiver should parse each AFI element no matter what the ordering. Compatibility Mode Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 22 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | AFI =3D 1 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a system does not recognized the Geo Coordinate LCAF Type that is accompanying a locator address, an encoder can include the Geo Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in the list is encoded with a valid AFI value to identify the locator address. A LISP system is required to support the AFI List LCAF Type to use this procedure. It would skip over 10 bytes of the Geo Coordinate LCAF Type to get to the locator address encoding (an IPv4 locator address). A LISP system that does support the Geo Coordinate LCAF Type can support parsing the locator address within the Geo Coordinate LCAF encoding or in the locator encoding that follows in the AFI List LCAF. Farinacci, et al. Expires March 13, 2014 [Page 27] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 5. Security Considerations There are no security considerations for this specification. The security considerations are documented for the protocols that use LISP Canonical Addressing. Refer to the those relevant specifications. Farinacci, et al. Expires March 13, 2014 [Page 28] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 6. IANA Considerations The Address Family AFI definitions from [AFI] only allocate code- points for the AFI value itself. The length of the address or entity that follows is not defined and is implied based on conventional experience. Where the LISP protocol uses LISP Canonical Addresses specifically, the address length definitions will be in this specification and take precedent over any other specification. An IANA Registry for LCAF Type values will be created. The values that are considered for use by the main LISP specification [RFC6830] will be in the IANA Registry. Other Type values used for experimentation will be defined and described in this document. Farinacci, et al. Expires March 13, 2014 [Page 29] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 7. References 7.1. Normative References [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013. 7.2. Informative References [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/numbers.html, Febuary 2007. [JSON-BINARY] "Universal Binary JSON Specification", URL http://ubjson.org. [LISP-DDT] Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated Database Tree", draft-ietf-lisp-ddt-01.txt (work in progress). [LISP-MRSIG] Farinacci, D. and M. Napierala, "LISP Control-Plane Multicast Signaling", draft-farinacci-lisp-mr-signaling-03.txt (work in progress). [LISP-NATT] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, F., and C. White, "NAT traversal for LISP", draft-ermagan-lisp-nat-traversal-03.txt (work in progress). Farinacci, et al. Expires March 13, 2014 [Page 30] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", draft-coras-lisp-re-03.txt (work in progress). [LISP-TE] Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic Engineering Use-Cases", draft-farinacci-lisp-te-03.txt (work in progress). [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic System 1984", NIMA TR8350.2, January 2000, . Farinacci, et al. Expires March 13, 2014 [Page 31] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 Appendix A. Acknowledgments The authors would like to thank Vince Fuller, Gregg Schudel, Jesper Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for their technical and editorial commentary. The authors would like to thank Victor Moreno for discussions that lead to the definition of the Multicast Info LCAF type. The authors would like to thank Parantap Lahiri and Michael Kowal for discussions that lead to the definition of the Explicit Locator Path (ELP) LCAF type. The authors would like to thank Fabio Maino and Vina Ermagan for discussions that lead to the definition of the Security Key LCAF type. The authors would like to thank Albert Cabellos-Aparicio and Florin Coras for discussions that lead to the definition of the Replication List Entry LCAF type. Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for suggesting new LCAF types. Thanks also goes to Terry Manderson for assistance obtaining a LISP AFI value from IANA. Farinacci, et al. Expires March 13, 2014 [Page 32] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affilations. o Added Instance-ID to the Multicast Info Type so there is relative ease in parsing (S,G) entries within a VPN. o Add port range encodings to the Application Data LCAF Type. o Add a new JSON LCAF Type. o Add Address Key/Value LCAF Type to allow attributes to be attached to an address. B.2. Changes to draft-ietf-lisp-lcaf-02.txt o Submitted March 2013. o Added new LCAF Type "Replication List Entry" to support LISP replication engineering use-cases. o Changed references to new LISP RFCs. B.3. Changes to draft-ietf-lisp-lcaf-01.txt o Submitted January 2013. o Change longitude range from 0-90 to 0-180 in section 4.4. o Added reference to WGS-84 in section 4.4. B.4. Changes to draft-ietf-lisp-lcaf-00.txt o Posted first working group draft August 2012. o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. Farinacci, et al. Expires March 13, 2014 [Page 33] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2013 Authors' Addresses Dino Farinacci lispers.net San Jose, CA USA Email: farinacci@gmail.com Dave Meyer Brocade San Jose, CA USA Email: dmm@1-4-5.net Job Snijders Hibernia Networks Tupolevlaan 103a Schiphol-Rijk, 1119 PA NL Email: job.snijders@hibernianetworks.com Farinacci, et al. Expires March 13, 2014 [Page 34] =0C --Apple-Mail=_9418C405-18CE-4851-AA09-89BEB6EF981A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_9418C405-18CE-4851-AA09-89BEB6EF981A Content-Disposition: attachment; filename=rfcdiff-lisp-lcaf-02-to-03.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-lcaf-02-to-03.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-lcaf-02.txt draft-ietf-lisp-lcaf-03.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                  D. Meyer                                               lispers.net
Intended status: Experimental                              cisco Systems                                   D. Meyer
Expires: September 11, 2013 March 13, 2014                                          Brocade
                                                             J. Snijders
                                                            InTouch N.V.
                                                          March 10,
                                                       Hibernia Networks
                                                       September 9, 2013

                  LISP Canonical Address Format (LCAF)
                        draft-ietf-lisp-lcaf-02
                        draft-ietf-lisp-lcaf-03

Abstract

   This draft defines a canonical address format encoding used in LISP
   control messages and in the encoding of lookup keys for the LISP
   Mapping Database System.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 11, 2013. March 13, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  4
   3.  LISP Canonical Address Format Encodings  . . . . . . . . . . .  5
   4.  LISP Canonical Address Applications  . . . . . . . . . . . . .  7
     4.1.  Segmentation using LISP  . . . . . . . . . . . . . . . . .  7
     4.2.  Carrying AS Numbers in the Mapping Database  . . . . . . .  8
     4.3.  Convey Application Specific Data . . . . . . . . . . . . .  9
     4.4.  Assigning Geo Coordinates to Locator Addresses . . . . . . 10
     4.5.  Generic Database Mapping Lookups . . . . . . . . . . . . . 12
     4.6.  NAT Traversal Scenarios  . . . . . . . . . . . . . . . . . 13
     4.7.  PETR Admission Control Functionality . . . . . . . . . . . 15
     4.8.  Multicast Group Membership Information . . . . . . . . . . 16
     4.9.  Traffic Engineering using Re-encapsulating Tunnels . . . . 18
     4.10. Storing Security Data in the Mapping Database  . . . . . . 19
     4.11. Source/Destination 2-Tuple Lookups . . . . . . . . . . . . 20
     4.12. Replication List Entries for Multicast Forwarding  . . . . 21
     4.13. Data Model Encoding  . . . . . . . . . . . . . . . . . . . 22
     4.14. Encoding Key/Value Address Pairs . . . . . . . . . . . . . 23
     4.15. Applications for AFI List Type . . . . . . . . . . . . . . 22
       4.13.1. 24
       4.15.1.  Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 22
       4.13.2. 24
       4.15.2.  Layer-2 VPNs  . . . . . . . . . . . . . . . . . . . . 23
       4.13.3. 25
       4.15.3.  ASCII Names in the Mapping Database . . . . . . . . . 23
       4.13.4. 25
       4.15.4.  Using Recursive LISP Canonical Address Encodings  . . 24
       4.13.5. 26
       4.15.5.  Compatibility Mode Use Case . . . . . . . . . . . . . 25 27
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26 28
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27 29
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 30
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 28 30
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 28 30
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 30 32
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 31 33
     B.1.  Changes to draft-ietf-lisp-lcaf-02.txt draft-ietf-lisp-lcaf-03.txt . . . . . . . . . . 31 33
     B.2.  Changes to draft-ietf-lisp-lcaf-01.txt draft-ietf-lisp-lcaf-02.txt . . . . . . . . . . 31 33
     B.3.  Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . . 33
     B.4.  Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . . 31 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 34

1.  Introduction

   The LISP architecture and protocols [RFC6830] introduces two new
   numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators
   (RLOCs) which are intended to replace most use of IP addresses on the
   Internet.  To provide flexibility for current and future
   applications, these values can be encoded in LISP control messages
   using a general syntax that includes Address Family Identifier (AFI),
   length, and value fields.

   Currently defined AFIs include IPv4 and IPv6 addresses, which are
   formatted according to code-points assigned in [AFI] as follows:

   IPv4 Encoded Address:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 1            |       IPv4 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv4 Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Encoded Address:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 2            |       IPv6 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv6 Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This document describes the currently-defined AFIs the LISP protocol
   uses along with their encodings and introduces the LISP Canonical
   Address Format (LCAF) that can be used to define the LISP-specific
   encodings for arbitrary AFI values.

2.  Definition of Terms

   Address Family Identifier (AFI):  a term used to describe an address
      encoding in a packet.  An address family currently defined for
      IPv4 or IPv6 addresses.  See [AFI] and [RFC1700] for details.  The
      reserved AFI value of 0 is used in this specification to indicate
      an unspecified encoded address where the the length of the address
      is 0 bytes following the 16-bit AFI value of 0.

   Unspecified Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 0            |    <nothing follows AFI=0>    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source and destination address fields of the first
      (most inner) LISP header of a packet.  The host obtains a
      destination EID the same way it obtains a destination address
      today, for example through a DNS lookup or SIP exchange.  The
      source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an egress
      tunnel router (ETR).  It is the output of a EID-to-RLOC mapping
      lookup.  An EID maps to one or more RLOCs.  Typically, RLOCs are
      numbered from topologically aggregatable blocks that are assigned
      to a site at each point to which it attaches to the global
      Internet; where the topology is defined by the connectivity of
      provider networks, RLOCs can be thought of as PA addresses.
      Multiple RLOCs can be assigned to the same ETR device or to
      multiple ETR devices at a site.

3.  LISP Canonical Address Format Encodings

   IANA has assigned AFI value 16387 (0x4003) to the LISP architecture
   and protocols.  This specification defines the encoding format of the
   LISP Canonical Address (LCA).

   The first 4 bytes of an LISP Canonical Address are followed by a
   variable length of fields:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       |     Rsvd2     |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Rsvd1:  this 8-bit field is reserved for future use and MUST be
      transmitted as 0 and ignored on receipt.

   Flags:  this 8-bit field is for future definition and use.  For now,
      set to zero on transmission and ignored on receipt.

   Type:  this 8-bit field is specific to the LISP Canonical Address
      formatted encodings, values are:

     Type 0:  Null Body Type

     Type 1:  AFI List Type

     Type 2:  Instance ID Type

     Type 3:  AS Number Type

     Type 4:  Application Data Type

     Type 5:  Geo Coordinates Type

     Type 6:  Opaque Key Type

     Type 7:  NAT-Traversal Type

     Type 8:  Nonce Locator Type

     Type 9:  Multicast Info Type
     Type 10:  Explicit Locator Path Type

     Type 11:  Security Key Type

     Type 12:  Source/Dest Key Type

     Type 13:  Replication List Entry Type

     Type 14:  JSON Data Model Type

     Type 15:  Key/Value Address Pair Type

   Rsvd2:  this 8-bit field is reserved for future use and MUST be
      transmitted as 0 and ignored on receipt.

   Length:  this 16-bit field is in units of bytes and covers all of the
      LISP Canonical Address payload, starting and including the byte
      after the Length field.  So any LCAF encoded address will have a
      minimum length of 8 bytes when the Length field is 0.  The 8 bytes
      include the AFI, Flags, Type, Reserved, and Length fields.  When
      the AFI is not next to encoded address in a control message, then
      the encoded address will have a minimum length of 6 bytes when the
      Length field is 0.  The 6 bytes include the Flags, Type, Reserved,
      and Length fields.

4.  LISP Canonical Address Applications

4.1.  Segmentation using LISP

   When multiple organizations inside of a LISP site are using private
   addresses [RFC1918] as EID-prefixes, their address spaces must remain
   segregated due to possible address duplication.  An Instance ID in
   the address encoding can aid in making the entire AFI based address
   unique.

   Another use for the Instance ID LISP Canonical Address Format is when
   creating multiple segmented VPNs inside of a LISP site where keeping
   EID-prefix based subnets is desirable.

   Instance ID LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 2    | IID mask-len  |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Instance ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IID mask-len:  if the AFI is set to 0, then this format is not
      encoding an extended EID-prefix but rather an instance-ID range
      where the 'IID mask-len' indicates the number of high-order bits
      used in the Instance ID field for the range.

   Length value n:  length in bytes of the AFI address that follows the
      Instance ID field including the AFI field itself.

   Instance ID:  the low-order 24-bits that can go into a LISP data
      header when the I-bit is set.  See [RFC6830] for details.

   AFI = x:  x can be any AFI value from [AFI].

   This LISP Canonical Address Type can be used to encode either EID or
   RLOC addresses.

4.2.  Carrying AS Numbers in the Mapping Database

   When an AS number is stored in the LISP Mapping Database System for
   either policy or documentation reasons, it can be encoded in a LISP
   Canonical Address.

   AS Number LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 3    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           AS Number                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      AS Number field including the AFI field itself.

   AS Number:  the 32-bit AS number of the autonomous system that has
      been assigned either the EID or RLOC that follows.

   AFI = x:  x can be any AFI value from [AFI].

   The AS Number Canonical Address Type can be used to encode either EID
   or RLOC addresses.  The former is used to describe the LISP-ALT AS
   number the EID-prefix for the site is being carried for.  The latter
   is used to describe the AS that is carrying RLOC based prefixes in
   the underlying routing system.

4.3.  Convey Application Specific Data

   When a locator-set needs to be conveyed based on the type of
   application or the Per-Hop Behavior (PHB) of a packet, the
   Application Data Type can be used.

   Application Data LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 4    |     Rsvd2     |             8 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       IP TOS, IPv6 TC, or Flow Label          |    Protocol   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Local Port (lower-range)   |    Local Port (upper-range)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Remote Port (lower-range)   |   Remote Port (upper-range)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      8-byte Application Data fields including the AFI field itself.

   IP TOS, IPv6 TC, or Flow Label:  this field stores the 8-bit IPv4 TOS
      field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow
      Label used in an IPv6 header.

   Local Port/Remote Port: Port Ranges:  these fields are from the TCP, UDP,
      or SCTP transport header.  A range can be specified by using a
      lower value and an upper value.  When a single port is encoded,
      the lower and upper value fields are the same.

   AFI = x:  x can be any AFI value from [AFI].

   The Application Data Canonical Address Type is used for an EID
   encoding when an ITR wants a locator-set for a specific application.
   When used for an RLOC encoding, the ETR is supplying a locator-set
   for each specific application is has been configured to advertise.

4.4.  Assigning Geo Coordinates to Locator Addresses

   If an ETR desires to send a Map-Reply describing the Geo Coordinates
   for each locator in its locator-set, it can use the Geo Coordinate
   Type to convey physical location information.

   Coordinates are specified using the WGS-84 (World Geodetic System)
   reference coordinate system [WGS-84].

   Geo Coordinate LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 5    |     Rsvd2     |            12 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|     Latitude Degrees        |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |E|     Longitude Degrees       |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Altitude                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      8-byte Longitude and Latitude fields including the AFI field
      itself.

   N: When set to 1 means North, otherwise South.

   Latitude Degrees:  Valid values range from 0 to 90 degrees above or
      below the equator (northern or southern hemisphere, respectively).

   Latitude Minutes:  Valid values range from 0 to 59.

   Latitude Seconds:  Valid values range from 0 to 59.

   E: When set to 1 means East, otherwise West.

   Longitude Degrees:  Value values are from 0 to 180 degrees right or
      left of the Prime Meridian.

   Longitude Minutes:  Valid values range from 0 to 59.

   Longitude Seconds:  Valid values range from 0 to 59.

   Altitude:  Height relative to sea level in meters.  This is a signed
      integer meaning that the altitude could be below sea level.  A
      value of 0x7fffffff indicates no Altitude value is encoded.

   AFI = x:  x can be any AFI value from [AFI].

   The Geo Coordinates Canonical Address Type can be used to encode
   either EID or RLOC addresses.  When used for EID encodings, you can
   determine the physical location of an EID along with the topological
   location by observing the locator-set.

4.5.  Generic Database Mapping Lookups

   When the LISP Mapping Database system holds information accessed by a
   generic formatted key (where the key is not the usual IPv4 or IPv6
   address), an opaque key may be desirable.

   Opaque Key LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 6    |     Rsvd2     |               n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Key Field Num |      Key Wildcard Fields      |   Key . . .   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       . . . Key                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the type's payload.  The value n
      is the number of bytes that follow this Length field.

   Key Field Num:  the number of fields (minus 1) the key can be broken
      up into.  The width of the fields are fixed length.  So for a key
      size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2
      bytes in length.  Valid values for this field range from 0 to 15
      supporting a maximum of 16 field separations.

   Key Wildcard Fields:  describes which fields in the key are not used
      as part of the key lookup.  This wildcard encoding is a bitfield.
      Each bit is a don't-care bit for a corresponding field in the key.
      Bit 0 (the low-order bit) in this bitfield corresponds the first
      field, right-justified in the key, bit 1 the second field, and so
      on.  When a bit is set in the bitfield it is a don't-care bit and
      should not be considered as part of the database lookup.  When the
      entire 16-bits is set to 0, then all bits of the key are used for
      the database lookup.

   Key:  the variable length key used to do a LISP Database Mapping
      lookup.  The length of the key is the value n (shown above) minus
      3.

4.6.  NAT Traversal Scenarios

   When a LISP system is conveying global address and mapped port
   information when traversing through a NAT device, the NAT-Traversal
   LCAF Type is used.  See [LISP-NATT] for details.

   NAT-Traversal Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 7    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       MS UDP Port Number      |      ETR UDP Port Number      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |  Global ETR RLOC Address  ... |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       MS RLOC Address  ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          | Private ETR RLOC Address  ... |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |      RTR RLOC Address 1 ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |      RTR RLOC Address k ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI addresses that follows
      the UDP Port Number field including the AFI fields themselves.

   MS UDP Port Number:  this is the UDP port number of the Map-Server
      and is set to 4342.

   ETR UDP Port Number:  this is the port number returned to a LISP
      system which was copied from the source port from a packet that
      has flowed through a NAT device.

   AFI = x:  x can be any AFI value from [AFI].

   Global ETR RLOC Address:  this is an address known to be globally
      unique built by NAT-traversal functionality in a LISP router.

   MS RLOC Address:  this is the address of the Map-Server used in the
      destination RLOC of a packet that has flowed through a NAT device.

   Private ETR RLOC Address:  this is an address known to be a private
      address inserted in this LCAF format by a LISP router that resides
      on the private side of a NAT device.

   RTR RLOC Address:  this is an encapsulation address used by an ITR or
      PITR which resides behind a NAT device.  This address is known to
      have state in a NAT device so packets can flow from it to the LISP
      ETR behind the NAT.  There can be one or more NTR addresses
      supplied in these set of fields.  The number of NTRs encoded is
      determined by the LCAF length field.  When there are no NTRs
      supplied, the NTR fields can be omitted and reflected by the LCAF
      length field or an AFI of 0 can be used to indicate zero NTRs
      encoded.

4.7.  PETR Admission Control Functionality

   When a public PETR device wants to verify who is encapsulating to it,
   it can check for a specific nonce value in the LISP encapsulated
   packet.  To convey the nonce to admitted ITRs or PITRs, this LCAF
   format is used in a Map-Register or Map-Reply locator-record.

   Nonce Locator Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 8    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Reserved    |                  Nonce                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      Nonce field including the AFI field itself.

   Reserved:  must be set to zero and ignore on receipt.

   Nonce:  this is a nonce value returned by an ETR in a Map-Reply
      locator-record to be used by an ITR or PITR when encapsulating to
      the locator address encoded in the AFI field of this LCAF type.

   AFI = x:  x can be any AFI value from [AFI].

4.8.  Multicast Group Membership Information

   Multicast group information can be published in the mapping database
   so a lookup on an EID based group address can return a replication
   list of group addresses or a unicast addresses for single replication
   or multiple head-end replications.  The intent of this type of
   unicast replication is to deliver packets to multiple ETRs at
   receiver LISP multicast sites.  The locator-set encoding for this EID
   record type can be a list of ETRs when they each regsiter register with "Merge
   Semantics".  The encoding can be a typical AFI encoded locator
   address.  When an RTR list is being registered (with multiple levels
   acccording
   according to [LISP-RE]), the Replication List Entry LCAF type is used
   for locator encoding.

   This LCAF encoding can be used to send broadcast packets to all
   members of a subnet when each EIDs are away from their home subnet
   location.

   Multicast Info Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 9    |  Rsvd2  |R|L|J|             4             8 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Instance-ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved           | Source MaskLen| Group MaskLen |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |   Source/Subnet Address  ...  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Group Address  ...      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Reserved:  must be set to zero and ignore on receipt.

   R-bit:  this is the RP-bit that represents PIM (S,G,RP-bit) multicast
      state.  This bit can be set for Joins (when the J-bit is set) or
      for Leaves (when the L-bit is set).  See [LISP-MRSIG] for more
      usage details.

   L-bit:  this is the Leave-Request bit and is used when this LCAF type
      is present in the destination EID-prefix field of a Map-Request.
      See [LISP-MRSIG] for details.

   J-bit:  this is the Join-Request bit and is used when this LCAF type
      is present in the destination EID-prefix field of a Map-Request.
      See [LISP-MRSIG] for details.  The J-bit MUST not be set when the
      L-bit is also set in the same LCAF block.  A receiver should not
      take any specific Join or Leave action when both bits are set.

   Instance ID:  the low-order 24-bits that can go into a LISP data
      header when the I-bit is set.  See [RFC6830] for details.  The use
      of the Instance-ID in this LCAF type is to associate a multicast
      forwarding entry for a given VPN.  The instance-ID describes the
      VPN and is registered to the mapping database system as a 3-tuple
      of (Instance-ID, S-prefix, G-prefix).

   Source MaskLen:  the mask length of the source prefix that follows.

   Group MaskLen:  the mask length of the group prefix that follows.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

4.9.  Traffic Engineering using Re-encapsulating Tunnels

   For a given EID lookup into the mapping database, this LCAF format
   can be returned to provide a list of locators in an explicit re-
   encapsulation path.  See [LISP-TE] for details.

   Explicit Locator Path (ELP) Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 10   |     Rsvd2     |               n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           Rsvd3         |L|P|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reencap Hop 1  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           Rsvd3         |L|P|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reencap Hop k  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

   Lookup bit (L):  this is the Lookup bit used to indicate to the user
      of the ELP to not use this address for encapsulation but to look
      it up in the mapping database system to obtain an encapsulating
      RLOC address.

   RLOC-Probe bit (P):  this is the RLOC-probe bit which means the
      Reencap Hop allows RLOC-probe messages to be sent to it.  When the
      R-bit is set to 0, RLOC-probes must not be sent.  When a Reencap
      Hop is an anycast address then multiple physical Reencap Hops are
      using the same RLOC address.  In this case, RLOC-probes are not
      needed because when the closest RLOC address is not reachable
      another RLOC address can reachable.

   Strict bit (S):  this the strict bit which means the associated
      Rencap Hop is required to be used.  If this bit is 0, the
      reencapsulator can skip this Reencap Hop and go to the next one in
      the list.

4.10.  Storing Security Data in the Mapping Database

   When a locator in a locator-set has a security key associated with
   it, this LCAF format will be used to encode key material.  See
   [LISP-DDT] for details.

   Security Key Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 11   |      Rsvd2    |             6 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Key Count   |      Rsvd3    | Key Algorithm |   Rsvd4     |R|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Key Length          |       Key Material ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        ... Key Material                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Locator Address ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that start with the Key
      Material field.

   Key Count:  the Key Count field declares the number of Key sections
      included in this LCAF.

   Key Algorithm:  the Algorithm field identifies the key's
      cryptographic algorithm and specifies the format of the Public Key
      field.

   R bit:  this is the revoke bit and, if set, it specifies that this
      Key is being Revoked.

   Key Length:  this field determines the length in bytes of the Key
      Material field.

   Key Material:  the Key Material field stores the key material.  The
      format of the key material stored depends on the Key Algorithm
      field.

   AFI = x:  x can be any AFI value from [AFI].This is the locator
      address that owns the encoded security key.

4.11.  Source/Destination 2-Tuple Lookups

   When both a source and destination address of a flow needs
   consideration for different locator-sets, this 2-tuple key is used in
   EID fields in LISP control messages.  When the Source/Dest key is
   registered to the mapping database, it can be encoded as a source-
   prefix and destination-prefix.  When the Source/Dest is used as a key
   for a mapping database lookup the source and destination come from a
   data packet.

   Source/Dest Key Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 12   |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved           |   Source-ML   |    Dest-ML    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Source-Prefix ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |     Destination-Prefix ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Reserved:  must be set to zero and ignore on receipt.

   Source-ML:  the mask length of the source prefix that follows.

   Dest-ML:  the mask length of the destination prefix that follows.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

   Refer to [LISP-TE] for usage details.

4.12.  Replication List Entries for Multicast Forwarding

   The Replication List Entry LCAF type is an encoding for a locator
   being used for unicast replication according to the specification in
   [LISP-RE].  This locator encoding is pointed to by a Multicast Info
   LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs)
   that are participating in an overlay distribution tree.  Each RTR
   will register its locator address and its configured level in the
   distribution tree.

   Replication List Entry Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 13   |    Rsvd2      |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Rsvd3            |     Rsvd4     |  Level Value  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           RTR/ETR #1 ...      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Rsvd3            |     Rsvd4     |  Level Value  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           RTR/ETR  #n ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Rsvd{1,2,3,4}:  must be set to zero and ignore on receipt.

   Level Value:  this value is associated with the level of hierarchy
      the RTR resides in an overlay distribution tree.  The level
      numbers are ordered from lowest value being close to the ITR
      (meaning that ITRs replicate to level-0 RTRs) and higher levels
      are further downstream on the distribution tree closer to ETRs of
      multicast receiver sites.

   AFI = x:  x can be any AFI value from [AFI].  A specific AFI has its
      own encoding of either a unicast or multicast locator address.
      All RTR/ETR entries for the same level should be combined together
      by a Map-Server to avoid searching through the entire multi-level
      list of locator entries in a Map-Reply message.

4.13.  Applications for AFI List Type

4.13.1.  Binding IPv4 and IPv6 Addresses

   When header translation between IPv4 and IPv6 is desirable  Data Model Encoding

   This type allows a LISP
   Canonical Address can use the AFI List Type JSON data model to carry multiple AFIs in
   one LCA AFI.

   Bounded Address LISP Canonical be encoded either as an EID or
   RLOC.

   JSON Data Model Type Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1 14   |    Rsvd2    |B|               n               |         2 + 4 + 2 + 16
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                JSON binary or text encoding ...               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = 1 x          |       Optional Address ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Rsvd{1,2}:  must be set to zero and ignore on receipt.

   B bit:  indicates that the JSON field is binary encoded according to
      [JSON-BINARY] when the bit is set to 1.  Otherwise the encoding is
      based on text encoding according to [RFC4627].

   JSON field:  a variable length field that contains either binary or
      text encodings.

   AFI = x:  x can be any AFI value from [AFI].  A specific AFI has its
      own encoding of either a unicast or multicast locator address.
      All RTR/ETR entries for the same level should be combined together
      by a Map-Server to avoid searching through the entire multi-level
      list of locator entries in a Map-Reply message.

4.14.  Encoding Key/Value Address Pairs

   The Key/Value pair is for example useful for attaching attributes to
   other elements of LISP packets, such as EIDs or RLOCs.  When
   attaching attributes to EIDs or RLOCs, it's necessary to distinguish
   between the element that should be used as EID or RLOC, and hence as
   key for lookups, and additional attributes.  This is especially the
   case when the difference cannot be determined from the types of the
   elements, such as when two IP addresses are being used.

   Key/Value Pair Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 15   |     Rsvd2     |               n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Address as Key(1) ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |     Address as Value(1) ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             . . .                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Address as Key(n) ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |     Address as Value(n) ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Rsvd{1,2}:  must be set to zero and ignore on receipt.

   AFI = x:  x can be any AFI value from [AFI].  A specific AFI has its
      own encoding of either a unicast or multicast locator address.
      All RTR/ETR entries for the same level should be combined together
      by a Map-Server to avoid searching through the entire multi-level
      list of locator entries in a Map-Reply message.

   Address as Key(1):  this AFI encoded address will be attached with
      the attributes encoded in "Address as Value(1)" which follows this
      field.

   Address as Value(1):  this AFI encoded address will be teh attribute
      address that goes along with "Address as Key(1)" which precedes
      this field.  Multiple Key/Value pairs can be included in a single
      LCAF encoding.

4.15.  Applications for AFI List Type

4.15.1.  Binding IPv4 and IPv6 Addresses

   When header translation between IPv4 and IPv6 is desirable a LISP
   Canonical Address can use the AFI List Type to carry multiple AFIs in
   one LCA AFI.

   Bounded Address LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |         2 + 4 + 2 + 16        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 1            |       IPv4 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv4 Address         |            AFI = 2            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          IPv6 Address ...                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  length in bytes is fixed at 24 when IPv4 and IPv6 AFI
      encoded addresses are used.

   This type of address format can be included in a Map-Request when the
   address is being used as an EID, but the Mapping Database System
   lookup destination can use only the IPv4 address.  This is so a
   Mapping Database Service Transport System, such as LISP-ALT
   [RFC6836], can use the Map-Request destination address to route the
   control message to the desired LISP site.

4.13.2.

4.15.2.  Layer-2 VPNs

   When MAC addresses are stored in the LISP Mapping Database System,
   the AFI List Type can be used to carry AFI 6.

   MAC Address LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |             2 + 6             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             AFI = 6           |    Layer-2 MAC Address  ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    ... Layer-2 MAC Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  length in bytes is fixed at 8 when MAC address AFI encoded
      addresses are used.

   This address format can be used to connect layer-2 domains together
   using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN.
   In this use-case, a MAC address is being used as an EID, and the
   locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or
   even another MAC address being used as an RLOC.

4.13.3.

4.15.3.  ASCII Names in the Mapping Database

   If DNS names or URIs are stored in the LISP Mapping Database System,
   the AFI List Type can be used to carry an ASCII string where it is
   delimited by length 'n' of the LCAF Length encoding.

   ASCII LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |             2 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             AFI = 17          |      DNS Name or URI  ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes AFI=17 field and the null-terminated
      ASCII string (the last byte of 0 is included).

4.13.4.

4.15.4.  Using Recursive LISP Canonical Address Encodings

   When any combination of above is desirable, the AFI List Type value
   can be used to carry within the LCA AFI another LCA AFI.

   Recursive LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |         4 + 8 + 2 + 4         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 4    |     Rsvd2     |              12               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   IP TOS, IPv6 QQS or Flow Label              |    Protocol   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Local Port          |         Remote Port           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 1            |       IPv4 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv4 Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  length in bytes is fixed at 18 when an AFI=1 IPv4 address is
      included.

   This format could be used by a Mapping Database Transport System,
   such as LISP-ALT [RFC6836], where the AFI=1 IPv4 address is used as
   an EID and placed in the Map-Request destination address by the
   sending LISP system.  The ALT system can deliver the Map-Request to
   the LISP destination site independent of the Application Data Type
   AFI payload values.  When this AFI is processed by the destination
   LISP site, it can return different locator-sets based on the type of
   application or level of service that is being requested.

4.13.5.

4.15.5.  Compatibility Mode Use Case

   A LISP system should use the AFI List Type format when sending to
   LISP systems that do not support a particular LCAF Type used to
   encode locators.  This allows the receiving system to be able to
   parse a locator address for encapsulation purposes.  The list of AFIs
   in an AFI List LCAF Type has no semantic ordering and a receiver
   should parse each AFI element no matter what the ordering.

   Compatibility Mode Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |            22 + 6             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 5    |     Rsvd2     |            12 + 2             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|     Latitude Degrees        |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |E|     Longitude Degrees       |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Altitude                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = 0          |           AFI = 1             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          IPv4 Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If a system does not recognized the Geo Coordinate LCAF Type that is
   accompanying a locator address, an encoder can include the Geo
   Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI
   in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in
   the list is encoded with a valid AFI value to identify the locator
   address.

   A LISP system is required to support the AFI List LCAF Type to use
   this procedure.  It would skip over 10 bytes of the Geo Coordinate
   LCAF Type to get to the locator address encoding (an IPv4 locator
   address).  A LISP system that does support the Geo Coordinate LCAF
   Type can support parsing the locator address within the Geo
   Coordinate LCAF encoding or in the locator encoding that follows in
   the AFI List LCAF.

5.  Security Considerations

   There are no security considerations for this specification.  The
   security considerations are documented for the protocols that use
   LISP Canonical Addressing.  Refer to the those relevant
   specifications.

6.  IANA Considerations

   The Address Family AFI definitions from [AFI] only allocate code-
   points for the AFI value itself.  The length of the address or entity
   that follows is not defined and is implied based on conventional
   experience.  Where the LISP protocol uses LISP Canonical Addresses
   specifically, the address length definitions will be in this
   specification and take precedent over any other specification.

   An IANA Registry for LCAF Type values will be created.  The values
   that are considered for use by the main LISP specification [RFC6830]
   will be in the IANA Registry.  Other Type values used for
   experimentation will be defined and described in this document.

7.  References

7.1.  Normative References

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              January 2013.

   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol Alternative Logical
              Topology (LISP+ALT)", RFC 6836, January 2013.

7.2.  Informative References

   [AFI]      IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/numbers.html, Febuary 2007.

   [JSON-BINARY]
              "Universal Binary JSON Specification",
              URL http://ubjson.org.

   [LISP-DDT]
              Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated
              Database Tree", draft-fuller-lisp-ddt-01.txt draft-ietf-lisp-ddt-01.txt (work in
              progress).

   [LISP-MRSIG]
              Farinacci, D. and M. Napierala, "LISP Control-Plane
              Multicast Signaling",
              draft-farinacci-lisp-mr-signaling-00.txt
              draft-farinacci-lisp-mr-signaling-03.txt (work in
              progress).

   [LISP-NATT]
              Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
              F., and C. White, "NAT traversal for LISP",
              draft-ermagan-lisp-nat-traversal-00.txt
              draft-ermagan-lisp-nat-traversal-03.txt (work in
              progress).

   [LISP-RE]  Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
              Maino, F., and D. Farinacci, "LISP Replication
              Engineering", draft-coras-lisp-re-02.txt draft-coras-lisp-re-03.txt (work in
              progress).

   [LISP-TE]  Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic
              Engineering Use-Cases", draft-farinacci-lisp-te-01.txt draft-farinacci-lisp-te-03.txt
              (work in progress).

   [WGS-84]   Geodesy and Geophysics Department, DoD., "World Geodetic
              System 1984", NIMA TR8350.2, January 2000, <http://
              earth-info.nga.mil/GandG/publications/tr8350.2/
              wgs84fin.pdf>.

Appendix A.  Acknowledgments

   The authors would like to thank Vince Fuller, Gregg Schudel, Jesper
   Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for
   their technical and editorial commentary.

   The authors would like to thank Victor Moreno for discussions that
   lead to the definition of the Multicast Info LCAF type.

   The authors would like to thank Parantap Lahiri and Michael Kowal for
   discussions that lead to the definition of the Explicit Locator Path
   (ELP) LCAF type.

   The authors would like to thank Fabio Maino and Vina Ermagan for
   discussions that lead to the definition of the Security Key LCAF
   type.

   The authors would like to thank Albert Cabellos-Aparicio and Florin
   Coras for discussions that lead to the definition of the Replication
   List Entry LCAF type.

   Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for
   suggesting new LCAF types.

   Thanks also goes to Terry Manderson for assistance obtaining a LISP
   AFI value from IANA.

Appendix B.  Document Change Log

B.1.  Changes to draft-ietf-lisp-lcaf-03.txt

   o  Submitted September 2013.

   o  Updated references and author's affilations.

   o  Added Instance-ID to the Multicast Info Type so there is relative
      ease in parsing (S,G) entries within a VPN.

   o  Add port range encodings to the Application Data LCAF Type.

   o  Add a new JSON LCAF Type.

   o  Add Address Key/Value LCAF Type to allow attributes to be attached
      to an address.

B.2.  Changes to draft-ietf-lisp-lcaf-02.txt

   o  Submitted March 2013.

   o  Added new LCAF Type "Replication List Entry" to support LISP
      replication engineering use-cases.

   o  Changed references to new LISP RFCs.

B.2.

B.3.  Changes to draft-ietf-lisp-lcaf-01.txt

   o  Submitted January 2013.

   o  Change longitude range from 0-90 to 0-180 in section 4.4.

   o  Added reference to WGS-84 in section 4.4.

B.3.

B.4.  Changes to draft-ietf-lisp-lcaf-00.txt

   o  Posted first working group draft August 2012.

   o  This draft was renamed from draft-farinacci-lisp-lcaf-10.txt.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   lispers.net
   San Jose, CA  95134
   USA

   Email: farinacci@gmail.com

   Dave Meyer
   cisco Systems
   170 Tasman Drive
   Brocade
   San Jose, CA
   USA

   Email: dmm@cisco.com dmm@1-4-5.net

   Job Snijders
   InTouch N.V.
   Middenweg 76
   1097 BS Amsterdam
   The Netherlands
   Hibernia Networks
   Tupolevlaan 103a
   Schiphol-Rijk,   1119 PA
   NL

   Email: job@instituut.net job.snijders@hibernianetworks.com
--Apple-Mail=_9418C405-18CE-4851-AA09-89BEB6EF981A-- From jmh@joelhalpern.com Tue Sep 10 01:30:31 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D6A21F9F9D for ; Tue, 10 Sep 2013 01:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48FfQDaNojXg for ; Tue, 10 Sep 2013 01:30:27 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4E25D21F9C6A for ; Tue, 10 Sep 2013 01:30:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 392AA1C056D; Tue, 10 Sep 2013 01:30:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 53C4B1C05EA; Tue, 10 Sep 2013 01:30:20 -0700 (PDT) Message-ID: <522ED89E.3050901@joelhalpern.com> Date: Tue, 10 Sep 2013 04:30:22 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dino Farinacci References: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com> In-Reply-To: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Meyer , "lisp@ietf.org list" Subject: Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 10 Sep 2013 08:30:32 -0000 Speaking personally, I have some concerns about this. I think my concerns can be lumped into two related categories. Bother are about interoperability. Firstly, I find the registration of LCAFs without any explanation of how or why they would be used to be awkward. I know that some members of the WG like to have everything in one document. But this is why we maintain registries. Once we have defined LCAFs, it is quite sensible for documents which need LCAFs to add them to the registry, with the explanation of how and why the particular LCAF is beign defined. Note that unlike base protocol mechanisms, the set of LCAFs is not something that all implementations need to understand. A LISP implementation that is never going to do 5-tuple lookup does not need to know about LCAFs that are designed to handle that. And conversely defining new LCAFs ought in my view create an obligation for new behavior in all LISP devices. (I don't think the authors intend that kind of obligation.) On a related note, I find very general LCAFs a cause for concern. Particular the JSON LCAF, which seems to allow the mapping system to reprogram the packet processing hardware on the fly seems excessive. I understand it is neat for experimentation. But how does something injecting a JSON LCAF have a reasonable judgment about whether the ITR which will receive it will be able to implement the processing required? If we are assuming particular deployment models, we need to describe that. (Which leads to the question as to why it is in this document.) I may be in the rough on these concerns. Yours, Joel On 9/10/13 12:35 AM, Dino Farinacci wrote: > Folks, I compiled all the input I received for updates to the LCAF draft. Find enclosed the updated draft and a diff file. > > Deadline is tomorrow but we can have discussion before I post. So if there are any changes or comments, I can add them into the -03 draft. So I am not that worried about missing the deadline. > > Changes include: > > B.1. Changes to draft-ietf-lisp-lcaf-03.txt > > o Submitted September 2013. > > o Updated references and author's affliations. > > o Added Instance-ID to the Multicast Info Type so there is relative > ease in parsing (S,G) entries within a VPN. > > o Add port range encodings to the Application Data LCAF Type. > > o Add a new JSON LCAF Type. > > o Add Address Key/Value LCAF Type to allow attributes to be attached > to an address. > > Dino > > > > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From acabello@ac.upc.edu Tue Sep 10 05:46:52 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B9C21F99D5 for ; Tue, 10 Sep 2013 05:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXtQPwq5tbvf for ; Tue, 10 Sep 2013 05:46:46 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 560DC11E80E4 for ; Tue, 10 Sep 2013 05:46:45 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id r8ACkiTk014204 for ; Tue, 10 Sep 2013 14:46:44 +0200 Received: from [192.168.0.200] (unknown [46.27.20.114]) by gw.ac.upc.edu (Postfix) with ESMTP id 809366B020C for ; Tue, 10 Sep 2013 14:46:43 +0200 (CEST) Message-ID: <522F14B0.6010600@ac.upc.edu> Date: Tue, 10 Sep 2013 14:46:40 +0200 From: Albert Cabellos User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: lisp@ietf.org References: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com> <522ED89E.3050901@joelhalpern.com> In-Reply-To: <522ED89E.3050901@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 10 Sep 2013 12:46:52 -0000 El 10/09/2013 10:30, Joel M. Halpern escribió: > Speaking personally, I have some concerns about this. > > I think my concerns can be lumped into two related categories. Bother > are about interoperability. > > Firstly, I find the registration of LCAFs without any explanation of > how or why they would be used to be awkward. I know that some members > of the WG like to have everything in one document. But this is why we > maintain registries. Once we have defined LCAFs, it is quite sensible > for documents which need LCAFs to add them to the registry, with the > explanation of how and why the particular LCAF is beign defined. > Note that unlike base protocol mechanisms, the set of LCAFs is not > something that all implementations need to understand. A LISP > implementation that is never going to do 5-tuple lookup does not need > to know about LCAFs that are designed to handle that. And conversely > defining new LCAFs ought in my view create an obligation for new > behavior in all LISP devices. (I don't think the authors intend that > kind of obligation.) > This is precisely the reason to standardize a flexible LCAF, there is no obligation to implement all the LCAFs defined, but just the ones that are used by a particular ITR. Pretty much like XML and the XML applications. > On a related note, I find very general LCAFs a cause for concern. > Particular the JSON LCAF, which seems to allow the mapping system to > reprogram the packet processing hardware on the fly seems excessive. > I understand it is neat for experimentation. But how does something > injecting a JSON LCAF have a reasonable judgment about whether the ITR > which will receive it will be able to implement the processing required? Beyond the LCAF type, we can include a fixed size type that will tell the ITR if it is able to implement the processing required. From there we can define types that can be only used intra-domain or that are maningful inter-domain, again like XML applications. > If we are assuming particular deployment models, we need to describe > that. (Which leads to the question as to why it is in this document.) > Fully agree with this, two of the main reasons are flexiblity and to reduce the deployment cost of new applications of LISP. With the flexible LCAF we only need to update the ITR, not the mapping system. This is an important barrier for experimentation or new uses right now. Otherwise and as you mention, we will have to face and endless amount of LCAF types, one for each LISP use. Regards Albert > I may be in the rough on these concerns. > > Yours, > Joel > > On 9/10/13 12:35 AM, Dino Farinacci wrote: >> Folks, I compiled all the input I received for updates to the LCAF >> draft. Find enclosed the updated draft and a diff file. >> >> Deadline is tomorrow but we can have discussion before I post. So if >> there are any changes or comments, I can add them into the -03 draft. >> So I am not that worried about missing the deadline. >> >> Changes include: >> >> B.1. Changes to draft-ietf-lisp-lcaf-03.txt >> >> o Submitted September 2013. >> >> o Updated references and author's affliations. >> >> o Added Instance-ID to the Multicast Info Type so there is relative >> ease in parsing (S,G) entries within a VPN. >> >> o Add port range encodings to the Application Data LCAF Type. >> >> o Add a new JSON LCAF Type. >> >> o Add Address Key/Value LCAF Type to allow attributes to be >> attached >> to an address. >> >> 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 mblokzij@cisco.com Tue Sep 10 07:39:17 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3458011E81D3 for ; Tue, 10 Sep 2013 07:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7IncZwjIv0O for ; Tue, 10 Sep 2013 07:39:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC8211E81C1 for ; Tue, 10 Sep 2013 07:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8787; q=dns/txt; s=iport; t=1378823952; x=1380033552; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cz8hRweNgNFHbW/OtLCwzTVs/fE/TcTO6HHi+7WyEEE=; b=cvJGb4oyUPTh5fiXfwFj5JhVKqmVktm/O0Nt9upuA+A3JM/bQUwQHHtM 1EDUjZTU1LBbKNIs+4bfJK2pUKZEu2TGxWQYoLkF6brmI91T84axz3SRA F3MJIz534pdpYuUEPWftfDpyA9QQm+eLgjLraRt6fpLggEJ/x8Yhzg7wB U=; X-Files: signature.asc : 801 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAJcuL1KtJV2a/2dsb2JhbABSCYMHOFHCO4EkFnSCJQEBAQMBAQEBJEcLBQsCAQgYChkLIQYLJQIEDgUIBguHVwMJBgy2dQ2IcoxwgSmBETEHCYMUgQADkCSBLoQ7gxiLDIUwgWOBPYFoJB4 X-IronPort-AV: E=Sophos;i="4.90,878,1371081600"; d="asc'?scan'208";a="257859832" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 10 Sep 2013 14:39:11 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8AEdBlK010131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Sep 2013 14:39:11 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.246]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 10 Sep 2013 09:39:10 -0500 From: "Michiel Blokzijl (mblokzij)" To: Dino Farinacci Thread-Topic: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA Thread-Index: AQHOrTs7YdAS7j266E2D9Mp+k4WMkpm9mM6AgABYlICAAW8FAA== Date: Tue, 10 Sep 2013 14:39:10 +0000 Message-ID: <4ABB752A36221949A095CDE2C6DBB1C8098421F3@xmb-aln-x12.cisco.com> References: <4ABB752A36221949A095CDE2C6DBB1C80982F67D@xmb-aln-x12.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.103.106.110] Content-Type: multipart/signed; boundary="Apple-Mail=_077F2AFF-DA63-47D0-A449-28AE0745089E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 10 Sep 2013 14:39:17 -0000 --Apple-Mail=_077F2AFF-DA63-47D0-A449-28AE0745089E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Dino, You're right in the sense that the mapping system doesn't expose an = "API" for doing reverse lookups. It would however be possible to do reverse lookups on the map servers = (since we register EID->RLOC mappings), or based on aggregate EID->RLOC = mapping data, such as from what lispmon.net provides - the latter = basically does address-space scans as far as I know. I guess as long as = you don't have access to the map-servers, it will become more and more = difficult and to do this as LISP becomes more widely deployed. As it = takes longer to compile this kind of a database, the time accuracy also = decreases. All of this is probably a good thing indeed :-) > But not to take away from your point. But if those private addresses = are not injected into the underlying routing protocol and PE boxes run = URPF, those packets will be dropped. As long as you use private addresses from the IPv6 prefix(es) you're = allowed to use I don't think uRPF will be an issue, but I suppose the = benefit would also be marginal :( Best regards, Michiel On 9 Sep 2013, at 17:45, Dino Farinacci wrote: >> Even in the case where the ITR is on the CPE we might be able to do = better. >>=20 >> For IPv6 RLOCs, we could use temporary IPv6 addresses (IPv6 privacy >> extension, rfc4941 I think) as the RLOCs in outgoing packets. That = way, >> you couldn't discover the EID by doing a "reverse lookup" on the RLOC = in >> the mapping system. >=20 > Well in today's deployments there are no RLOC records in the mapping = database. So finding an EID associated with an RLOC is a different thing = to do today. And this is goodness. >=20 > But not to take away from your point. But if those private addresses = are not injected into the underlying routing protocol and PE boxes run = URPF, those packets will be dropped. >=20 > Dino >=20 >> This would be especially useful if the IPv6 prefix on your uplink is = used >> on a multipoint link, if it's just used on a point-to-point link it's = a >> bit pointless :) >>=20 >> Best regards, >>=20 >> Michiel >>=20 >> On 09/09/2013 10:01, "Joel M. Halpern" wrote: >>=20 >>> Doesn't this depend upon where the ITR is? >>> If, as is usually proposed, the ITR is a piece of CPE, then it will = hide >>> the content of my message (good), and my individual EID (okay), but = it >>> won't hide which site is sending the packet, which is an awful lot = of >>> information. >>>=20 >>> Also, moving the ITR to the PE router merely means that all the >>> information is collectible at that point. And we have observable = data >>> that collectible =3D> will be collected. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 9/8/13 10:15 PM, Dino Farinacci wrote: >>>>> Hello Noel, >>>>>=20 >>>>>> Err, that would get the address and name of the ITR, not the = actual >>>>>> source >>>>>> host. >>>>>=20 >>>>> this thread started with a subject of how to save the Internet = from the >>>>> all-powerful agencies. Lisp was not invented to hide your = identity, >>>>> it's only separating it from the location - this doesn't mean the >>>>> location information cannot reveal your (real life) identity. At = the >>>>> end the agencies want your name, not your (inner) IP address. >>>>=20 >>>> Marc, you may have not followed Noel's point. Let me explain with = more >>>> detail. >>>>=20 >>>> (1) I sit at a LISP site, I have an EID assigned to me. I want to = send >>>> packet and don't want anyone in the core to know I am sending. >>>>=20 >>>> (2) My EID comes out of an EID-prefix that is assigned to the site = I >>>> currently reside in. There are a pair of ITRs that encapsulate = traffic >>>> for packets I source. >>>>=20 >>>> (3) When I source packets, my EID is known by routers inside of the >>>> site, but when the packet hits the ITR, the ITR will encrypt the = entire >>>> packet it is about to encapsulate. So the outer IP header, the UDP >>>> header, and the LISP header is sent in the clear. Everything after = the >>>> LISP header is encrypted. >>>>=20 >>>> (4) I propose that the ITR use a public-key stored in the mapping >>>> database. It does not need to be protected during transport. The = only >>>> parties that have the private-key the ETRs at the destination site = (and >>>> you can h a public/private pair per ETR). >>>>=20 >>>> (5) Men in the middle cannot decrypt the encapsulated packet = because >>>> they don't have the private key and it is never transmitted on the >>>> network. All they know is that a packet came from some site that is >>>> connected to ISP foobar. So what, that is coarse information. >>>>=20 >>>> (6) The key is obtained by the ITR the same time it is getting the = RLOC >>>> address for encapsulation. Both come together and if the EID or = *key* >>>> changes, we treat it as a mobility event where a new registration = is >>>> sent to the mapping database to advertise a new RLOC address and/or = a >>>> new key. >>>>=20 >>>> This is pretty simple. Yes it is slow. But so what. We can throw >>>> hardware technology at it or we can have th math guys come up with = as >>>> good but less expensive algorithms. >>>>=20 >>>>> If the xTR is close to you, e.g. your DSL router runs the xTR, = then the >>>>> locator is effectively a 1:1 mapping to your identity. If the xTR = is >>>>> your office branch router, well, then we have already (a) a = router to >>>>> try to break in and (b) a physical office location to look for = you. >>>>=20 >>>> It's not all that simple. EIDs can roam around. So if the RLOC at = my >>>> house is encapsulating packets because you came over for dinner, it >>>> isn't me that is sourcing. I might be blamed for your wrong-doing, = but >>>> all I would say is "I only live there". ;-) >>>>=20 >>>> Dino >>>>=20 >>>>> And if the xTR is further away from your Internet connection point = then >>>>> chances are you can get wire-tapped on your way to/from the xTR, = i.e. >>>>> Lisp would not help you at all. >>>>>=20 >>>>> That's all I wanted to say with my statement about "static = setups". >>>>>=20 >>>>>=20 >>>>> Complete different story is if Lisp could make encryption e.g. = between >>>>> company office sites much easier, more scalable etc.. Independent = from >>>>> the original subject that would be a real benefit. >>>>>=20 >>>>>=20 >>>>> Regards, Marc >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Depending on all sorts of factors, that plus the encrypted packet >>>>>> _might_ get >>>>>> them the identity of the actual originator (not, for example, if = the >>>>>> ITR has >>>>>> discarded the key used to encrypt the packet by the time the = subpoena >>>>>> arrives...) >>>>>>=20 >>>>>> Noel >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 --Apple-Mail=_077F2AFF-DA63-47D0-A449-28AE0745089E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJSLy8VAAoJEKSsLO5c6AcgUYgP/1/LIpiIKEAdK8mQThiPsbGa R1XdH72XcJ9DSIlmwXEeP7LeFZi0hsrtcIORzi/CBmP6s/BbukiY44Ae7fc/3qHU cNjHoRhmab3kIUJvO94LNTWok1G6PSBBdUiqfpIu/OGhTLxckSf5gPVJZCtz1+La KwRoXVu8y1X2Z02RXEzn2/lxLtzqWq0+KGk8/MarP5pYo5Nsd4zBduLkdmErAikZ mmr2gQZIRMgDxQbFVY+x0IN18UE6AgeNRcjjpnlVorEW1OSyZ1PMaDN/5fIkXhvQ pDIQjrlkJOtK9eA4ObUBkazcw1opICRgFaNu4wsXDcJgp9oXfxijw+TdO5TxbjHo vPQmn3Oyhbdv11odB8ScDgJqnYbtI8fRUiOufXXw3TSDVN+qItyavfb9ur23tSyZ g0WpdiPUfjZ65MeLTlnOiCorcqk9614mhXC4ZbHgG4wnm/xTSJrkCjT+S3gJT1IK fR+WNmJBgswcRFeXyEMMQGb8qvGwTysNaCIjPGy2cX++p7fdx0x2ZZKkkLOZk/Tq Xi4sW7CFrETSLL0/i1MwjSD/xXhzYIj3Ntk3hPOl5BUmeRGjgfsED5XjhLuvfOwI 8rCYJ8RHkINg9B6EhKJ0qsDKK/E+g6n3lssV/P2Y493dQ0Kg+fBCQx3dNEeomTPa r6vAurTWa0/sMyhGQWEQ =dpLH -----END PGP SIGNATURE----- --Apple-Mail=_077F2AFF-DA63-47D0-A449-28AE0745089E-- From farinacci@gmail.com Tue Sep 10 08:01:14 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7E011E81E1 for ; Tue, 10 Sep 2013 08:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI-NwlkUB1ud for ; Tue, 10 Sep 2013 08:01:13 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C6D1911E81B9 for ; Tue, 10 Sep 2013 08:01:07 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so7784820pdj.17 for ; Tue, 10 Sep 2013 08:01:06 -0700 (PDT) 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=Sa4RaVaIqyAHdBO0FdVt7RsHyhgLNAeg49w9gNzTI04=; b=Q9in5f3zXGspq277HAckgcWVv2b7BWQJP45iWQTjMQaE+XFNplmA1LiW7uJf3g9Pzx 4Rwef0xpATmSyL09UHR6n1sMjgCpgpE2zOrjc8Pm9ZbsJuhN5FS2ms/IojKy2cvPAUUQ NpCIEB5Ah/yRwFyzf5zRdcbOacItxA5SnpFLQTUxdmjz8GMja0NoLJTrTs4MYW9KOUbM j3kj+TGVlNFnnUCANt22Kee9mr+q60s9G4swrlTpXM6gTaN+APhpG/l4OAUQxr4KQ2r8 yhRjh4tQoNPLz2hQ6/uWZEXxGk6GKr6Jgb7csGItPEhFFvpBz4o2mN+6f9Ue9bZUML/P QgZQ== X-Received: by 10.68.180.100 with SMTP id dn4mr3920505pbc.178.1378825266152; Tue, 10 Sep 2013 08:01:06 -0700 (PDT) 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 a5sm23573725pbw.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 08:01:05 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <522ED89E.3050901@joelhalpern.com> Date: Tue, 10 Sep 2013 08:01:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com> <522ED89E.3050901@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1508) Cc: David Meyer , "lisp@ietf.org list" Subject: Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 10 Sep 2013 15:01:14 -0000 > Speaking personally, I have some concerns about this. >=20 > I think my concerns can be lumped into two related categories. Bother = are about interoperability. >=20 > Firstly, I find the registration of LCAFs without any explanation of = how or why they would be used to be awkward. I know that some members = of the WG like to have everything in one document. But this is why we = maintain We have companion documents (that are not working group chartered = documents). Here are some examples: (1) The draft-ermagen-nat-travesal draft states how to use the = NAT-Traversal LCAF type. (2) The draft-farinacci-lisp-te draft states how to use the Explicit = Locator Path (ELP) LCAF type. (3) The draft-codas-lisp-re draft states how to use the Replication List = Entry (RLE) LCAF type. (4) The draft-ietf-lisp-ddt draft stats how to use the Security LCAF = type for LISP-DDT-sec. > registries. Once we have defined LCAFs, it is quite sensible for = documents which need LCAFs to add them to the registry, with the = explanation of how and why the particular LCAF is beign defined. So I would suspect that the JSON Data Model Type would have a companion = document. > Note that unlike base protocol mechanisms, the set of LCAFs is not = something that all implementations need to understand. A LISP = implementation that is never going to do 5-tuple lookup does not need to = know about LCAFs Correct. > that are designed to handle that. And conversely defining new LCAFs = ought in my view create an obligation for new behavior in all LISP = devices. (I don't think the authors intend that kind of obligation.) This is generally true but I am finding more use-cases, where people = just want to store data in the RLOC LCAF encoding for easier management = and network-self-documentation. > On a related note, I find very general LCAFs a cause for concern. = Particular the JSON LCAF, which seems to allow the mapping system to = reprogram the packet processing hardware on the fly seems excessive. I = understand it is The LCAF document doesn't say how the JSON Data Model LCAF will be used = so we can't assume it is for the case you state above. > neat for experimentation. But how does something injecting a JSON = LCAF have a reasonable judgment about whether the ITR which will receive = it will be able to implement the processing required? If we are = assuming particular deployment models, we need to describe that. (Which = leads to the question as to why it is in this document.) What we have done in two cases for similar compatibility issues is this: (1) For wanting to store Geo-Coordinates with RLOCs for ITRs that do not = understand it, you encode the Geo-Coordinates LCAF type along with an = AFI=3D1 or AFI=3D2 RLOC address in a AFI-List LCAF RLOC record. Then the = ITR that doesn't understand the first AFI in the AFI-List (the = Geo-Coordinate encoding), skips over it and goes to the next AFI in the = AFI-List LCAF, where low and behold, there is an address it can = encapsulate to. (2) The above is done for ELP encodings too. Dino > I may be in the rough on these concerns. >=20 > Yours, > Joel >=20 > On 9/10/13 12:35 AM, Dino Farinacci wrote: >> Folks, I compiled all the input I received for updates to the LCAF = draft. Find enclosed the updated draft and a diff file. >>=20 >> Deadline is tomorrow but we can have discussion before I post. So if = there are any changes or comments, I can add them into the -03 draft. So = I am not that worried about missing the deadline. >>=20 >> Changes include: >>=20 >> B.1. Changes to draft-ietf-lisp-lcaf-03.txt >>=20 >> o Submitted September 2013. >>=20 >> o Updated references and author's affliations. >>=20 >> o Added Instance-ID to the Multicast Info Type so there is = relative >> ease in parsing (S,G) entries within a VPN. >>=20 >> o Add port range encodings to the Application Data LCAF Type. >>=20 >> o Add a new JSON LCAF Type. >>=20 >> o Add Address Key/Value LCAF Type to allow attributes to be = attached >> to an address. >>=20 >> Dino >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 From jmh@joelhalpern.com Tue Sep 10 08:04:59 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BE421E80F7 for ; Tue, 10 Sep 2013 08:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.365 X-Spam-Level: X-Spam-Status: No, score=-101.365 tagged_above=-999 required=5 tests=[AWL=1.235, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCc0VRf-beAq for ; Tue, 10 Sep 2013 08:04:51 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id DDB6E21E8136 for ; Tue, 10 Sep 2013 08:04:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 80F651C02DB; Tue, 10 Sep 2013 08:04:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 147461C01E1; Tue, 10 Sep 2013 08:04:30 -0700 (PDT) Message-ID: <522F34FC.1090504@joelhalpern.com> Date: Tue, 10 Sep 2013 11:04:28 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dino Farinacci References: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com> <522ED89E.3050901@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Meyer , "lisp@ietf.org list" Subject: Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 10 Sep 2013 15:05:00 -0000 If I were writing these things, I would put the registration for each of those types in the companion document. That way, a reader could judge the safety and utility of the proposed usage. Otherwise, the registration itself is not understandable. Asked backwards, why is there value in putting a bunch of IDs that are not needed in base implementation into a spec that does not explain what they are for? Yours, Joel On 9/10/13 11:01 AM, Dino Farinacci wrote: >> Speaking personally, I have some concerns about this. >> >> I think my concerns can be lumped into two related categories. Bother are about interoperability. >> >> Firstly, I find the registration of LCAFs without any explanation of how or why they would be used to be awkward. I know that some members of the WG like to have everything in one document. But this is why we maintain > > We have companion documents (that are not working group chartered documents). Here are some examples: > > (1) The draft-ermagen-nat-travesal draft states how to use the NAT-Traversal LCAF type. > (2) The draft-farinacci-lisp-te draft states how to use the Explicit Locator Path (ELP) LCAF type. > (3) The draft-codas-lisp-re draft states how to use the Replication List Entry (RLE) LCAF type. > (4) The draft-ietf-lisp-ddt draft stats how to use the Security LCAF type for LISP-DDT-sec. > >> registries. Once we have defined LCAFs, it is quite sensible for documents which need LCAFs to add them to the registry, with the explanation of how and why the particular LCAF is beign defined. > > So I would suspect that the JSON Data Model Type would have a companion document. > >> Note that unlike base protocol mechanisms, the set of LCAFs is not something that all implementations need to understand. A LISP implementation that is never going to do 5-tuple lookup does not need to know about LCAFs > > Correct. > >> that are designed to handle that. And conversely defining new LCAFs ought in my view create an obligation for new behavior in all LISP devices. (I don't think the authors intend that kind of obligation.) > > This is generally true but I am finding more use-cases, where people just want to store data in the RLOC LCAF encoding for easier management and network-self-documentation. > >> On a related note, I find very general LCAFs a cause for concern. Particular the JSON LCAF, which seems to allow the mapping system to reprogram the packet processing hardware on the fly seems excessive. I understand it is > > The LCAF document doesn't say how the JSON Data Model LCAF will be used so we can't assume it is for the case you state above. > >> neat for experimentation. But how does something injecting a JSON LCAF have a reasonable judgment about whether the ITR which will receive it will be able to implement the processing required? If we are assuming particular deployment models, we need to describe that. (Which leads to the question as to why it is in this document.) > > What we have done in two cases for similar compatibility issues is this: > > (1) For wanting to store Geo-Coordinates with RLOCs for ITRs that do not understand it, you encode the Geo-Coordinates LCAF type along with an AFI=1 or AFI=2 RLOC address in a AFI-List LCAF RLOC record. Then the ITR that doesn't understand the first AFI in the AFI-List (the Geo-Coordinate encoding), skips over it and goes to the next AFI in the AFI-List LCAF, where low and behold, there is an address it can encapsulate to. > > (2) The above is done for ELP encodings too. > > Dino > >> I may be in the rough on these concerns. >> >> Yours, >> Joel >> >> On 9/10/13 12:35 AM, Dino Farinacci wrote: >>> Folks, I compiled all the input I received for updates to the LCAF draft. Find enclosed the updated draft and a diff file. >>> >>> Deadline is tomorrow but we can have discussion before I post. So if there are any changes or comments, I can add them into the -03 draft. So I am not that worried about missing the deadline. >>> >>> Changes include: >>> >>> B.1. Changes to draft-ietf-lisp-lcaf-03.txt >>> >>> o Submitted September 2013. >>> >>> o Updated references and author's affliations. >>> >>> o Added Instance-ID to the Multicast Info Type so there is relative >>> ease in parsing (S,G) entries within a VPN. >>> >>> o Add port range encodings to the Application Data LCAF Type. >>> >>> o Add a new JSON LCAF Type. >>> >>> o Add Address Key/Value LCAF Type to allow attributes to be attached >>> to an address. >>> >>> Dino >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>> > > From farinacci@gmail.com Tue Sep 10 08:08:36 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9EF21E80F7 for ; Tue, 10 Sep 2013 08:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ronrotKePaC for ; Tue, 10 Sep 2013 08:08:35 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 41AFA21E812C for ; Tue, 10 Sep 2013 08:08:35 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so7689453pbc.31 for ; Tue, 10 Sep 2013 08:08:22 -0700 (PDT) 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=m9rlWaidZOblpGRobbVmWxZNhYoGHylN+XW94fTozBQ=; b=0MGhxtmDilQX/hVQpMpQFCrgezSozjDFHsytcTpHq2s6zV8fe5C3Z3x3lMQarlxv1r 5uFTZyOlopQ/H9lu6rouXjOM/zWwG1FJHB7TmYVMopPP0+O0SNkz8Rlrc/05ObsDL0tJ nLiXEr5OW706xq6IEIODwaLy6BLYaLp+LSkMrkMgOnfRlHkpvDYccBRcphFMcg0NSW8v tYQHGwUIBVk0iQOnIUjBQh7yAGWUKEU8taIn+LA6RUVZjfMSmTE353jpxmCY2r5gs6/i XCr4M7zPNW79eDv6Z2lTPC1OY/MjXYzTYZTFxa4FGoBCTtvxQBrS9ze36nSoLxJ1AkmA aAkA== X-Received: by 10.66.227.194 with SMTP id sc2mr27243756pac.41.1378825702557; Tue, 10 Sep 2013 08:08:22 -0700 (PDT) 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 u7sm5648549pbf.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 08:08:20 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <522F14B0.6010600@ac.upc.edu> Date: Tue, 10 Sep 2013 08:08:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <512511C9-7E47-4767-8BD9-B0042E9DB32F@gmail.com> References: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com> <522ED89E.3050901@joelhalpern.com> <522F14B0.6010600@ac.upc.edu> To: Albert Cabellos X-Mailer: Apple Mail (2.1508) Cc: lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 10 Sep 2013 15:08:36 -0000 >> On a related note, I find very general LCAFs a cause for concern. = Particular the JSON LCAF, which seems to allow the mapping system to = reprogram the packet processing hardware on the fly seems excessive. I = understand it is neat for experimentation. But how does something = injecting a JSON LCAF have a reasonable judgment about whether the ITR = which will receive it will be able to implement the processing required? >=20 > Beyond the LCAF type, we can include a fixed size type that will tell = the ITR if it is able to implement the processing required. =46rom there = we can define types that can be only used intra-domain or that are = maningful inter-domain, again like XML applications. It has been suggested before that we should define an LCAF type that = identifies the capabilities an xTR can support. It should be clear what = an ETR supports by what it registers, but one cannot tell if the ITR can = use the information an ETR has registered.=20 So I am not sure how this could be useful. I guess an ITR could register = "I support AFI=3D1 and Geo only" and if the ETR registered {AFI=3D1, = AFI-2, Geo, and ELP}, that it would only return in a Map-Reply to the = ITR {AFI=3D1 and Geo}. Just thinking out loud. Dino From farinacci@gmail.com Tue Sep 10 08:12:02 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311AB21E80DF for ; Tue, 10 Sep 2013 08:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYSelLC1rhOC for ; Tue, 10 Sep 2013 08:12:01 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD2521F9D39 for ; Tue, 10 Sep 2013 08:12:01 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id q10so7740364pdj.20 for ; Tue, 10 Sep 2013 08:12:01 -0700 (PDT) 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=bjlTjR5r+rslhQTFl0ujEryQwt2rIQjJalECSe5LwHg=; b=tSsMoCb86J89H/r43iwDOWXtwutAYPYYp8SDjsoOjIw3kmdudA4ucVQamxYvHLxtgy CJpdH30A8NAGHVWOuJDiF1bUB/P/KDw/gFDa0Lip8vc3t6dTp68xbDbPYHc+rDNe2N8O 1Behh+tuDuwaeyh2mQoBEGEHFWro8NWXG1Msbq3mOrpBzLEP8fJdwHmqe1ZWRtSg9yHs sTyOKg1XO3GZVSUFQV70ZdhI16OyhEjSaKgA92xdvQZ51smcO4ePdxw7YI7kMlQ+5DdF WjgAmlQcTtbaiw9+lT5ScZagWMOipwoYN0d3Hyff2fbHG+gTKCBl4BMr5Op+NwEjk98t qqgg== X-Received: by 10.67.1.203 with SMTP id bi11mr10429012pad.137.1378825921023; Tue, 10 Sep 2013 08:12:01 -0700 (PDT) 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 xl3sm23616526pbb.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 08:12:00 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <522F34FC.1090504@joelhalpern.com> Date: Tue, 10 Sep 2013 08:11:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com> <522ED89E.3050901@joelhalpern.com> <522F34FC.1090504@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1508) Cc: David Meyer , "lisp@ietf.org list" Subject: Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 10 Sep 2013 15:12:02 -0000 > If I were writing these things, I would put the registration for each = of those types in the companion document. That way, a reader could = judge the safety and utility of the proposed usage. Otherwise, the = registration itself is not understandable. I found putting them in one document, as an implementor, was extremely = useful. Because if I do multiple LCAF features, I want to see how the = designs can work either side-by-side or integrated with each other.=20 Here is an example. There is no reason that one leg of an RLE could not = be an Explicit Locator Path. > Asked backwards, why is there value in putting a bunch of IDs that are = not needed in base implementation into a spec that does not explain what = they are for? The LCAF, in a coarse matter, describes what an LCAF coding could be = used for. And the companion document goes into way more detail and = precisely specs the operation. Dino >=20 > Yours, > Joel >=20 > On 9/10/13 11:01 AM, Dino Farinacci wrote: >>> Speaking personally, I have some concerns about this. >>>=20 >>> I think my concerns can be lumped into two related categories. = Bother are about interoperability. >>>=20 >>> Firstly, I find the registration of LCAFs without any explanation of = how or why they would be used to be awkward. I know that some members = of the WG like to have everything in one document. But this is why we = maintain >>=20 >> We have companion documents (that are not working group chartered = documents). Here are some examples: >>=20 >> (1) The draft-ermagen-nat-travesal draft states how to use the = NAT-Traversal LCAF type. >> (2) The draft-farinacci-lisp-te draft states how to use the Explicit = Locator Path (ELP) LCAF type. >> (3) The draft-codas-lisp-re draft states how to use the Replication = List Entry (RLE) LCAF type. >> (4) The draft-ietf-lisp-ddt draft stats how to use the Security LCAF = type for LISP-DDT-sec. >>=20 >>> registries. Once we have defined LCAFs, it is quite sensible for = documents which need LCAFs to add them to the registry, with the = explanation of how and why the particular LCAF is beign defined. >>=20 >> So I would suspect that the JSON Data Model Type would have a = companion document. >>=20 >>> Note that unlike base protocol mechanisms, the set of LCAFs is not = something that all implementations need to understand. A LISP = implementation that is never going to do 5-tuple lookup does not need to = know about LCAFs >>=20 >> Correct. >>=20 >>> that are designed to handle that. And conversely defining new LCAFs = ought in my view create an obligation for new behavior in all LISP = devices. (I don't think the authors intend that kind of obligation.) >>=20 >> This is generally true but I am finding more use-cases, where people = just want to store data in the RLOC LCAF encoding for easier management = and network-self-documentation. >>=20 >>> On a related note, I find very general LCAFs a cause for concern. = Particular the JSON LCAF, which seems to allow the mapping system to = reprogram the packet processing hardware on the fly seems excessive. I = understand it is >>=20 >> The LCAF document doesn't say how the JSON Data Model LCAF will be = used so we can't assume it is for the case you state above. >>=20 >>> neat for experimentation. But how does something injecting a JSON = LCAF have a reasonable judgment about whether the ITR which will receive = it will be able to implement the processing required? If we are = assuming particular deployment models, we need to describe that. (Which = leads to the question as to why it is in this document.) >>=20 >> What we have done in two cases for similar compatibility issues is = this: >>=20 >> (1) For wanting to store Geo-Coordinates with RLOCs for ITRs that do = not understand it, you encode the Geo-Coordinates LCAF type along with = an AFI=3D1 or AFI=3D2 RLOC address in a AFI-List LCAF RLOC record. Then = the ITR that doesn't understand the first AFI in the AFI-List (the = Geo-Coordinate encoding), skips over it and goes to the next AFI in the = AFI-List LCAF, where low and behold, there is an address it can = encapsulate to. >>=20 >> (2) The above is done for ELP encodings too. >>=20 >> Dino >>=20 >>> I may be in the rough on these concerns. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 9/10/13 12:35 AM, Dino Farinacci wrote: >>>> Folks, I compiled all the input I received for updates to the LCAF = draft. Find enclosed the updated draft and a diff file. >>>>=20 >>>> Deadline is tomorrow but we can have discussion before I post. So = if there are any changes or comments, I can add them into the -03 draft. = So I am not that worried about missing the deadline. >>>>=20 >>>> Changes include: >>>>=20 >>>> B.1. Changes to draft-ietf-lisp-lcaf-03.txt >>>>=20 >>>> o Submitted September 2013. >>>>=20 >>>> o Updated references and author's affliations. >>>>=20 >>>> o Added Instance-ID to the Multicast Info Type so there is = relative >>>> ease in parsing (S,G) entries within a VPN. >>>>=20 >>>> o Add port range encodings to the Application Data LCAF Type. >>>>=20 >>>> o Add a new JSON LCAF Type. >>>>=20 >>>> o Add Address Key/Value LCAF Type to allow attributes to be = attached >>>> to an address. >>>>=20 >>>> Dino >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>=20 >>=20 From farinacci@gmail.com Tue Sep 10 10:19:27 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2353921F941F; Tue, 10 Sep 2013 10:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtVlAaSDJdDC; Tue, 10 Sep 2013 10:19:26 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 632A721F84B6; Tue, 10 Sep 2013 10:19:26 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz10so8036156pad.16 for ; Tue, 10 Sep 2013 10:19:26 -0700 (PDT) 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=So0OUzbuYiRgj5YLUCbrANBOWre8SVzk8y6UqZwAqtc=; b=uifGD3RMDd4MTOCXkYV1ZQOSHrLRUykhy5m70OMc9GmMbpDy7NryQpQu8YSCAP58D7 9Q/o+rKpyjv4nhrm/ScCoR20Xhns4M3U4AhhdftDPI4sr0x0adWSiYCrU7TVkYPb0DOZ FflitVAfxZD8QY8pcNK5Bqh/ZezTb/d4K3prZVtucHoTVOaNGkcNjgouDe8rUA8a84O+ QTGalzoGYmOY8DOiTvusHFRy1qmoy/MuG6NiHszO44wJkP2hlcUvvC0mq2Lvk4dka/gd HGMhbL8PZaNQohTd95yTbWIVlqyG7uS9UZWQAVcxEsabMdAELwRNdF9vCRM95S/s7Obs w/RQ== X-Received: by 10.66.221.8 with SMTP id qa8mr3142684pac.188.1378833565909; Tue, 10 Sep 2013 10:19:25 -0700 (PDT) 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 f2sm23281932pbg.44.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 10:19:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452C3627@dfweml509-mbb.china.huawei.com> Date: Tue, 10 Sep 2013 10:19:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D25752D-8556-4A89-80A3-EC28F94437EF@gmail.com> References: <20130827170744.22874.97003.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D452B3D74@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452C25C3@dfweml509-mbb.china.huawei.com> <1619DC43-A6B8-4DD2-8875-A2FA57A85E82@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D452C360E@dfweml509-mbb.china.huawei.com> <0E854774-B26D-4FEF-A810-A8383CB9A288@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D452C3627@dfweml509-mbb.china.huawei.com> To: Lucy yong X-Mailer: Apple Mail (2.1508) Cc: nvo3@ietf.org, "Paul Quinn \(paulq\)" , "lisp@ietf.org list" Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 10 Sep 2013 17:19:27 -0000 Copying the LISP working group mailing list. >> This implies that both gpe LISP and legacy LISP may be used in the = market. Is that true only IP-in-IP application need nonce feature? = Mobility is important requirement for cloud applications, so gpe LISP = needs to develop other solution for this feature? Sorry, this is a hard = sale. >=20 > If you use IP-in-IP you don't need to set the P-bit, making the nonce = available for use. Yes, there are applications where the nonce is = useful. > [Lucy] Yes, I agree that the nonce is useful. But gpe LISP router will = not support that. Why do we want to remove this in the protocol = evolution?=20 Lucy, we are not removing anything. Like I said (and I don't want to = continually repeat myself) that the features are tradeoffs. The motivation for the change was to get VXLAN to have protocol = demuxing. And in the spirit of keeping the packet formats for VXLAN and = LISP as identical as VXLAN will have it, the P-bit is being proposed for = LISP. This is a proposal. The LISP working group must decide if the draft = becomes a working group document. Dino >=20 > Lucy >=20 > Dino >=20 >>=20 >> Regards, >> Lucy >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com]=20 >> Sent: Tuesday, September 10, 2013 10:56 AM >> To: Lucy yong >> Cc: Paul Quinn (paulq); nvo3@ietf.org >> Subject: Re: [nvo3] New Version Notification for = draft-quinn-vxlan-gpe-00.txt >>=20 >>> Regarding to the protocol evolution, does this mean that = nonce/map-version features in LISP will be deprecated? IMO: Having the = same field overloaded for many difference purposes is not good way for = the protocol evolution, it becomes messy. >>=20 >> No it does not mean that. It means that the features need to be = traded off. So the market/user-base will decide what it wants to use = that field for. >>=20 >> Dino >>=20 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From sander@steffann.nl Tue Sep 10 12:44:06 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A4621E8184 for ; Tue, 10 Sep 2013 12:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKYa3D7sFL+Q for ; Tue, 10 Sep 2013 12:44:05 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC3721E817E for ; Tue, 10 Sep 2013 12:44:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 540006F; Tue, 10 Sep 2013 21:44:02 +0200 (CEST) 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 10024) with ESMTP id Rk8tOlhXXNYS; Tue, 10 Sep 2013 21:44:00 +0200 (CEST) Received: from [127.0.0.1] (cypher.steffann.nl [IPv6:2a02:898:148::216]) by mail.sintact.nl (Postfix) with ESMTPSA id C04D26D; Tue, 10 Sep 2013 21:43:57 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Sander Steffann In-Reply-To: <522ED89E.3050901@joelhalpern.com> Date: Tue, 10 Sep 2013 21:43:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F760019-251B-4B09-8403-C7356408CB73@steffann.nl> References: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com> <522ED89E.3050901@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1508) Cc: David Meyer , "lisp@ietf.org list" Subject: Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 10 Sep 2013 19:44:06 -0000 Hi, > Speaking personally, I have some concerns about this. >=20 > I think my concerns can be lumped into two related categories. Bother = are about interoperability. >=20 > Firstly, I find the registration of LCAFs without any explanation of = how or why they would be used to be awkward. I have implemented some Python code that tries to use LCAFs, and I can = only say that it is very difficult as an implementer to deal with LCAFs. = Often I have no idea where I can expect which LCAF type. The RFCs don't = give enough guidance here in my opinion. The specs allow way too much. As an implementer I don't want to be = surprised because some other implementation suddenly decides to use LCAF = type 3 to add the ASN to the address. Not to mention that an LCAF = address can contain another LCAF address. So should all implementations = now support type-2 LCAF address within type-3 LCAF addresses in case = some implementation decides to add both an instance-id and an ASN? And = will that be encoded as type-2 in type-3 or as type-3 in type-2? What = about when someone decides to add type-5 Geo information to the mix? = Should all implementations support all possible combinations?=20 This will make it much too hard to write a good implementation. Looking at the actual text there is something else that concerns me. = LCAF type-1 (AFI List Type) is defined in a very confusing way. It is = described in multiple use cases with different semantics, but I see no = way for the receiver to know what is actually meant. Section 4.13.5. = "Compatibility Mode Use Case" also confuses me: "A LISP system should use the AFI List Type format when sending to LISP = systems that do not support a particular LCAF Type used to encode = locators." How does the sender know what the receiver will support? And then there seems to be a contradiction: "The list of AFIs in an AFI List LCAF Type has no semantic ordering = [...]" "[...] where the AFI in the Geo Coordinate LCAF is set to 0 and the AFI = encoded next in the list is encoded with a valid AFI value to identify = the locator address." So the ordering does seem to be important after all... Is it the intention to make this the default behaviour? That all such = extra information should be encoded in a list with an AFI 0 address in = the i.e. Geo LCAF address and the IP address that should be used in a = AFI 1 or 2 address that follows next? Is this also meant to be supported = in multiple layers, for example by sending a list with first a Geo LCAF, = then an ASN LCAF and then a plain address? In that case it might be = better to remove the addresses from all the 'annotation' types = completely and define them to always be used in a list. Then the sender = could always send it like that, and the receiver could skip over all = annotations that it doesn't understand until it finds a non-LCAF AFI = address. I understand that the authors want to define a very flexible address = format, but without any rules or guidelines on how to encode address and = in which circumstances it will be too hard for implementors to implement = correctly in an interoperable way. There are now too many different ways = to encode the same information, and that must be fixed. Either by = changing the format (which I would strongly prefer) or by giving strict = guidelines on how the current flexibility is to be used. Cheers, Sander From arnatal@ac.upc.edu Wed Sep 11 12:46:26 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF24B21F92B9 for ; Wed, 11 Sep 2013 12:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubw4foSqE30v for ; Wed, 11 Sep 2013 12:46:19 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id E057211E80EE for ; Wed, 11 Sep 2013 12:46:15 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id r8BJkDAW007967 for ; Wed, 11 Sep 2013 21:46:13 +0200 Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by gw.ac.upc.edu (Postfix) with ESMTP id 628C76B028F for ; Wed, 11 Sep 2013 21:46:13 +0200 (CEST) Received: by mail-la0-f48.google.com with SMTP id er20so7717601lab.7 for ; Wed, 11 Sep 2013 12:46:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rKIX8DNCKFXPuOnzLrBA9tPrjT6yOuPBE3S1US2dIns=; b=hNfV6goZjVTo9zTPmS/J1BOFQgjX7YdkhlAeIJ9CA8/HkEHKnGTlqeiOQGIkOtmRed Pr/YRuqkGxNke9j6/8ohAaAZqxh6XeAYmnZcz/ed7LUccP0a663ZNgsMJ68iXe1BsuqE vG+4BeX+TLO9RasU/h+isBp3TIECHbVz4zM1DTLXbgyIRTcZb4tG4+Xkr/jkRfFf2DyV Lyokbk71JBOm3bVks+SA+pzwerCE77SY3zhCCE0jUxMmqVlJnXWgeGZThcCWOGFajyEa n804xdcsT6gLoZzRDXBJb6MkaAyQAGyTacs+ZVZpaAMBm0j/3ffHzFrJuicq2Cq1+B/m iNag== X-Received: by 10.112.172.137 with SMTP id bc9mr3992290lbc.21.1378928772460; Wed, 11 Sep 2013 12:46:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.160.100 with HTTP; Wed, 11 Sep 2013 12:45:52 -0700 (PDT) In-Reply-To: <6F760019-251B-4B09-8403-C7356408CB73@steffann.nl> References: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com> <522ED89E.3050901@joelhalpern.com> <6F760019-251B-4B09-8403-C7356408CB73@steffann.nl> From: Alberto Rodriguez-Natal Date: Wed, 11 Sep 2013 21:45:52 +0200 Message-ID: To: Sander Steffann Content-Type: multipart/alternative; boundary=001a11c26456a737da04e620dff5 Cc: David Meyer , "lisp@ietf.org list" Subject: Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 11 Sep 2013 19:46:26 -0000 --001a11c26456a737da04e620dff5 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 10 September 2013 21:43, Sander Steffann wrote: > Hi, > > > Speaking personally, I have some concerns about this. > > > > I think my concerns can be lumped into two related categories. Bother > are about interoperability. > > > > Firstly, I find the registration of LCAFs without any explanation of how > or why they would be used to be awkward. > > I have implemented some Python code that tries to use LCAFs, and I can > only say that it is very difficult as an implementer to deal with LCAFs. > Often I have no idea where I can expect which LCAF type. The RFCs don't > give enough guidance here in my opinion. > > The specs allow way too much. As an implementer I don't want to be > surprised because some other implementation suddenly decides to use LCAF > type 3 to add the ASN to the address. Not to mention that an LCAF address > can contain another LCAF address. So should all implementations now support > type-2 LCAF address within type-3 LCAF addresses in case some > implementation decides to add both an instance-id and an ASN? And will that > be encoded as type-2 in type-3 or as type-3 in type-2? What about when > someone decides to add type-5 Geo information to the mix? Should all > implementations support all possible combinations? > > This will make it much too hard to write a good implementation. > First, I must say that I strongly share with this view regarding implementation. I have faced the very same concerns while dealing with LCAFs on the code, specially with nested LCAFs. Regarding the JSON LCAF, I think we all agree that a LCAF format must have a companion document describing its usage. However I believe this does not apply (at least directly) to the JSON format. The idea of this format is to be not constrained by any specification to allow total freedom on its usage. It has been said that this format will be mostly used for experimentation or in intra-domain deployments. Since in these cases there is no interoperation between entities beyond the ones involved in the experiment or the domain, there is no need for a standard. These entities will agree on how to use the format. What should be provided by LISP manufacturers/implementors is an interface to program the LISP device to use and understand the concrete JSON LCAF usage. I think this interface is out of scope of LISP WG. In any case, if the WG feels that there is a need to standardize the JSON LCAF usage, I believe this should be done per use-case. Either a document covering different use-cases in just one place (as the LCAF document does with LCAF formats) or different documents covering different use-cases. Alberto --001a11c26456a737da04e620dff5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

On 10 September 2013 21:43, Sander Steffann <sander@ste= ffann.nl> wrote:
Hi,

> Speaking personally, I have some concerns about this.
>
> I think my concerns can be lumped into two related categories. =A0Both= er are about interoperability.
>
> Firstly, I find the registration of LCAFs without any explanation of h= ow or why they would be used to be awkward.

I have implemented some Python code that tries to use LCAFs, and I ca= n only say that it is very difficult as an implementer to deal with LCAFs. = Often I have no idea where I can expect which LCAF type. The RFCs don't= give enough guidance here in my opinion.

The specs allow way too much. As an implementer I don't want to be surp= rised because some other implementation suddenly decides to use LCAF type 3= to add the ASN to the address. Not to mention that an LCAF address can con= tain another LCAF address. So should all implementations now support type-2= LCAF address within type-3 LCAF addresses in case some implementation deci= des to add both an instance-id and an ASN? And will that be encoded as type= -2 in type-3 or as type-3 in type-2? What about when someone decides to add= type-5 Geo information to the mix? Should all implementations support all = possible combinations?

This will make it much too hard to write a good implementation.

First, I must say that I strongly share with this view regard= ing=20 implementation. I have faced the very same concerns while dealing with LCAF= s on the code, specially with nested LCAFs.


Regarding the JSON LCAF, I think we all agree that a LCAF = format must have a companion document describing its usage. However I belie= ve this does not apply (at least directly) to the JSON format. The idea of = this format is to be not constrained by any specification to allow total fr= eedom on its usage.

It has been said that this format will= be mostly used for experimentation or in intra-domain deployments. Since i= n these cases there is no interoperation between entities beyond the ones i= nvolved in the experiment or the domain, there is no need for a standard. T= hese entities will agree on how to use the format.=A0 What should be provid= ed by LISP manufacturers/implementors is an interface to program the LISP d= evice to use and understand the concrete JSON LCAF usage. I think this inte= rface is out of scope of LISP WG.

In any case, if the WG feels that ther= e is a need to standardize the JSON LCAF usage, I believe this should be do= ne per use-case. Either a document covering different use-cases in just one= place (as the LCAF document does with LCAF formats) or different documents= covering different use-cases.

Alberto



--001a11c26456a737da04e620dff5-- From lucy.yong@huawei.com Tue Sep 10 11:18:42 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AC011E80F4; Tue, 10 Sep 2013 11:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.031 X-Spam-Level: X-Spam-Status: No, score=-6.031 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVeqoJNL0gLJ; Tue, 10 Sep 2013 11:18:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E3F7011E8115; Tue, 10 Sep 2013 11:18:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVG75693; Tue, 10 Sep 2013 18:18:33 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 19:18:25 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 19:18:32 +0100 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.225]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Tue, 10 Sep 2013 11:18:25 -0700 From: Lucy yong To: Dino Farinacci Thread-Topic: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt Thread-Index: AQHOrcn8Dqq3wHN+XEid0pUVKpjnj5m/AbvQgACUYgD//4r78IAAeYaA//+LFxCAAIfYgP//lMNQ Date: Tue, 10 Sep 2013 18:18:25 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452C36FC@dfweml509-mbb.china.huawei.com> References: <20130827170744.22874.97003.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D452B3D74@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452C25C3@dfweml509-mbb.china.huawei.com> <1619DC43-A6B8-4DD2-8875-A2FA57A85E82@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D452C360E@dfweml509-mbb.china.huawei.com> <0E854774-B26D-4FEF-A810-A8383CB9A288@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D452C3627@dfweml509-mbb.china.huawei.com> <3D25752D-8556-4A89-80A3-EC28F94437EF@gmail.com> In-Reply-To: <3D25752D-8556-4A89-80A3-EC28F94437EF@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 11 Sep 2013 12:47:04 -0700 Cc: "nvo3@ietf.org" , "Paul Quinn \(paulq\)" , "lisp@ietf.org list" Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 10 Sep 2013 18:18:42 -0000 Copying the LISP working group mailing list. >> This implies that both gpe LISP and legacy LISP may be used in the marke= t. Is that true only IP-in-IP application need nonce feature? Mobility is i= mportant requirement for cloud applications, so gpe LISP needs to develop o= ther solution for this feature? Sorry, this is a hard sale. >=20 > If you use IP-in-IP you don't need to set the P-bit, making the nonce ava= ilable for use. Yes, there are applications where the nonce is useful. > [Lucy] Yes, I agree that the nonce is useful. But gpe LISP router will no= t support that. Why do we want to remove this in the protocol evolution?=20 Lucy, we are not removing anything. Like I said (and I don't want to contin= ually repeat myself) that the features are tradeoffs. The motivation for the change was to get VXLAN to have protocol demuxing.=20 [Lucy] For VXLAN to support protocol demuxing, no need to use P bit. We hav= e the proposal (https://datatracker.ietf.org/doc/draft-yong-l3vpn-nvgre-vxl= an-encap/). And in the spirit of keeping the packet formats for VXLAN and LISP as ident= ical as VXLAN will have it, the P-bit is being proposed for LISP. [Lucy] This logic means that if VXLAN does not need P bit, LISP does not ha= ve to have it either, right? It also indicates that you do not see the appl= ications for gpe LISP router, is that right? IMO: LISP and VXLAN have diffe= rent UDP port numbers, which is sufficient to differentiate the two. This is a proposal. The LISP working group must decide if the draft becomes= a working group document. [Lucy] People need carefully evaluation this proposal impact on LISP.=20 Regards, Lucy Dino >=20 > Lucy >=20 > Dino >=20 >>=20 >> Regards, >> Lucy >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com]=20 >> Sent: Tuesday, September 10, 2013 10:56 AM >> To: Lucy yong >> Cc: Paul Quinn (paulq); nvo3@ietf.org >> Subject: Re: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-0= 0.txt >>=20 >>> Regarding to the protocol evolution, does this mean that nonce/map-vers= ion features in LISP will be deprecated? IMO: Having the same field overloa= ded for many difference purposes is not good way for the protocol evolution= , it becomes messy. >>=20 >> No it does not mean that. It means that the features need to be traded o= ff. So the market/user-base will decide what it wants to use that field for= . >>=20 >> Dino >>=20 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From farinacci@gmail.com Thu Sep 12 11:14:58 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCFE11E81A3 for ; Thu, 12 Sep 2013 11:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nzLB8MHxzPH for ; Thu, 12 Sep 2013 11:14:57 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F180811E81E2 for ; Thu, 12 Sep 2013 11:14:54 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so1446994pad.5 for ; Thu, 12 Sep 2013 11:14:54 -0700 (PDT) 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=bF3DE7LyTzgVJel9b2jUZN0l58lzNYA8E/WNTsAFdVc=; b=ocLL4R2+hHP83PPDVkKSCrFv4ATKaSA08taS3c209VO4fxYvlVzq2+Sp8HEO4qysVv sr3NWGr2JvipAdJ225IQ6+xNAifvqjE5U2ryWw+MbaNTKYSGjHHjzN4a2OcCgbyip02D t4ikZMMycJuGNsFfTdsc3Bq7YSLGlURWcm4+FYvm2Ar3jBoEep9bDjWsToRFJwTtmg/O 1PIC6roNLaWTTlcoAWt1T3dvw1KY97EXL1MFezPDUuChtXrhS+PNw2sFn0EVa4ucCEEt YbGHsU19BNg0RbklJruuCsHt16f69gLv6MZburI+YfPq7lVmKmClpakEaM3Q0Vl1naUY 8xdw== X-Received: by 10.68.220.1 with SMTP id ps1mr9093691pbc.30.1379009694650; Thu, 12 Sep 2013 11:14:54 -0700 (PDT) Received: from [192.168.1.10] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id ha10sm6310569pbc.23.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 11:14:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <6F760019-251B-4B09-8403-C7356408CB73@steffann.nl> Date: Thu, 12 Sep 2013 11:14:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <629FC192-93FE-4CEA-9386-DEB6F8EDC43C@gmail.com> References: <2D469D0C-2E41-42C7-8907-7FADD8C39B53@gmail.com> <522ED89E.3050901@joelhalpern.com> <6F760019-251B-4B09-8403-C7356408CB73@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1508) Cc: David Meyer , "lisp@ietf.org list" Subject: Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 12 Sep 2013 18:14:58 -0000 > Hi, >=20 >> Speaking personally, I have some concerns about this. >>=20 >> I think my concerns can be lumped into two related categories. = Bother are about interoperability. >>=20 >> Firstly, I find the registration of LCAFs without any explanation of = how or why they would be used to be awkward. >=20 > I have implemented some Python code that tries to use LCAFs, and I can = only say that it is very difficult as an implementer to deal with LCAFs. = Often I have no idea where I can expect which LCAF type. The RFCs don't = give enough guidance here in my opinion. I have implemented a slew of LCAFs as well. But with any general design, = it is usually hard to nail down specific combination use-cases. So = rather than try to build the LCAF implementation directly from the LCAF = spec, you should first keep in mind and design what use-case you want to = solve. Then you decide what LCAF is needed for EID encoding and RLOC = encoding. This is precisely the reason we have will continue to need companion = documents. I have found in my implementation experience, that doing LCAF encoding = was not that bad. That is because I had precisely in mind what I wanted = to do. Here are some examples: (1) I wanted to support VPNs, so I had to do was support the Instance-ID = LCAF for EID encoding only. (2) I wanted to know physically where RLOCs (ETRs, RTRs, or PETRs) = resided so I wanted to have a 2-tuple RLOC encoding of RLOC address and = Geo-Coordinates. So I implemented the Geo-Coordinate LCAF for RLOC = encoding only. > The specs allow way too much. As an implementer I don't want to be = surprised because some other implementation suddenly decides to use LCAF = type 3 to add the ASN to the address. Not to mention that an LCAF = address can There will be other configuration and product details that will dictate = what you think you need to support versus having a general = implementation that will get very complex. The LCAF spec says what one COULD do, not that you should do it or it is = the last word on the examples given within. > contain another LCAF address. So should all implementations now = support type-2 LCAF address within type-3 LCAF addresses in case some = implementation decides to add both an instance-id and an ASN? And will = that be encoded as type-2 in type-3 or as type-3 in type-2? What about = when someone decides to add type-5 Geo information to the mix? Should = all implementations support all possible combinations?=20 We did this at cisco because one OS wanted to prototype something and = still interoperate with the other OS. So it was useful to do the = recursion in the AFI-List LCAF. But we did one level and kept it simple. > This will make it much too hard to write a good implementation. A good implementation is not one that tries to do everything. But this discussion is begging the question, "it would be nice to know = what LCAFs I can return to a requesting system". And hence I would like = to propose a Capabilities Type LCAF. I will send another email detailing = what I'm suggesting. And even more importantly, one needs to ask what the mapping system = supports in terms of the various combinations of LCAF encoding for an = EID, or I should call it, as the DDT spec calls it, a "extended-EID". = However, the RLOC format of any combination of LCAFs is less important = to the mapping system because it is just the output of the lookup which = either an ETR is doing or a map-server is doing as part of = proxy-replying. But the structure of the DDT with respect to multi-tuple = nature an LCAF encoded EID address can be is crucial to figure out. We do have some experience on the LISP pilot network with 2-tuple EIDs = where and type extended EIDs are = deployed (where is an instance-id). > Looking at the actual text there is something else that concerns me. = LCAF type-1 (AFI List Type) is defined in a very confusing way. It is = described in multiple use cases with different semantics, but I see no = way for the receiver to know what is actually meant. Section 4.13.5. = "Compatibility Mode Use Case" also confuses me: Right, because it is a package. And how you interpret it depends on the = feature that uses such a package. > "A LISP system should use the AFI List Type format when sending to = LISP systems that do not support a particular LCAF Type used to encode = locators." >=20 > How does the sender know what the receiver will support? If it is in the mapping system, the receiver (ETR, RTR, PETR, SDN = controller) registered it. The question is does the encapsulator know = how to use the information. > And then there seems to be a contradiction: >=20 > "The list of AFIs in an AFI List LCAF Type has no semantic ordering = [...]" > "[...] where the AFI in the Geo Coordinate LCAF is set to 0 and the = AFI encoded next in the list is encoded with a valid AFI value to = identify the locator address." >=20 > So the ordering does seem to be important after all... The ordering does not matter. You can put the Geo-Coordinate entry = before the AFI encoded RLOC address or afterwards and an implementation = that can parse an AFI-List Type should be able to get what it wants = wherever it is located. > Is it the intention to make this the default behaviour? That all such = extra information should be encoded in a No, that is not the intention. You have to look at each use-case. One = can merely program Geo-Coordinates as RLOC entries with no RLOC address = creating a control-plane only function using the mapping database. So = again, it depends what one is trying to accomplish. > list with an AFI 0 address in the i.e. Geo LCAF address and the IP = address that should be used in a AFI 1 or 2 address that follows next? = Is this also meant to be supported in multiple layers, for example by = sending a list with first a Geo LCAF, then an ASN LCAF and then a plain = address? In that case it might be better to remove the addresses from = all the 'annotation' types completely and define them to always be used = in a list. Then the sender could always send it like that, and the = receiver could skip over all annotations that it doesn't understand = until it finds a non-LCAF AFI address. You use the AFI-List Type when you have a multi-tuple RLOC encoding that = contains multiple LCAFs. But if you have one LCAF you want to use, each = have AFI encoded RLOC addresses that accompany them. That is, the more = popular case. > I understand that the authors want to define a very flexible address = format, but without any rules or guidelines on how to encode address and = in which circumstances it will be too hard for implementors to implement = correctly in an interoperable way. There are now too many different ways = to encode the same information, and that must be fixed. Either by = changing the format (which I would strongly prefer) or by giving strict = guidelines on how the current flexibility is to be used. We need companion documents. And I believe the working group will = embrace the concept once the critical work is complete. Right now we are = at a timing rock and hard place where the working group process cannot = support accepting more work. I wish the process could be more parallel = but the chairs want to meet the chartered items first. I can understand = that and support that. Deadlines are good. Job was taken off the cc list. I added him back on. I'm sure he is on = the mailing list but since he is an author I wanted to explicitly copy = him (as I did Dave). Dino >=20 > Cheers, > Sander >=20 From farinacci@gmail.com Thu Sep 12 11:29:31 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3CD11E81B3 for ; Thu, 12 Sep 2013 11:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LawYMq4KA6K1 for ; Thu, 12 Sep 2013 11:29:30 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 97C8C21F9D68 for ; Thu, 12 Sep 2013 11:29:30 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fz6so1473135pac.31 for ; Thu, 12 Sep 2013 11:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=i6HiqqIfdO3aouuDIyRhFdyPBatvwbkWV359bHum98U=; b=IxJI8SbaiVm9Mvo7XWefMKVejzQgsRWvzR26XjBIqLyfEIMuq5hCnX79c5VPct8Yxi Jb/To/ZXrfpKgpOBc15rll+kBmmol7gDfQh97jEmAM9niuyQ/Vh6CK+jepeSfRfHFPEM eEav66iRDiVBo0uqJ9IkpYAv0cUOfuI9xbnV6ytLGWv4eICSnP2ZYrA/zw91/VLwt2KJ J+KvzUMZMNpsdCo8OCImdCbT8P19qVFYrIU4XUANtGmdeuOjXe+Cni6XP35Ie3WhgRXR hFESTzLH1wI2qyLl2Ots4RZvot7xGeOd+QonmuA5vZqMdGIYMKGJrkUdt/00a5N2iwnJ iRJw== X-Received: by 10.68.134.133 with SMTP id pk5mr9083646pbb.89.1379010570331; Thu, 12 Sep 2013 11:29:30 -0700 (PDT) Received: from [192.168.1.10] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id f2sm6342539pbg.44.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 11:29:29 -0700 (PDT) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Sep 2013 11:29:26 -0700 Message-Id: <5FB6E5C2-AF6A-415A-8DE4-5958961A6661@gmail.com> To: "lisp@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [lisp] Capabilities Type LCAF - a proposal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 12 Sep 2013 18:29:31 -0000 So wouldn't be useful if an ITR which sends a Map-Request to the mapping = system, could say "I know Mr. ETR that you have registered a bunch of = stuff to the mapping system, but can you return just the stuff I care = about and more importantly the stuff I support in my implementation?". So I was thinking (and talking to several others about this), if we = could have a Capabilities Type LCAF that is encoded in an address field = of the Map-Request. I would like to propose that it get encoded in the = ITR-RLOCs field of a Map-Request. This way, each ITR in the ITR-RLOCs = list could tell a Map-Replier what they support. I would propose that the Capabilities Type LCAF be encoded as a = bit-string. Where each bit position indicates the LCAF Type value. We = would have 2 fields, an EID field and a RLOC field so it can be conveyed = which Types are supported for EID encoded fields or RLOC encoded fields = in any LISP control message. It would be required of every implementation to support the Capabilities = Type LCAF if nothing else would be supported. That would get the = implementations to do the general parsing work so they could skip over = LCAFs they don't understand and get to the ones they do understand while = conveying what they support. Also I find that this may be useful for this world of multiple = encapsulations. Rather than register UDP port numbers, a decapsulator = could convey what encapsulations it supports (i.e. L3-LISP, L2-LISP, = VXLAN, NVGRE, IPsec, GRE, whatever-new-thing-nv03-comes-up-with). The Capabilities Type LCAF could also be used by the mapping system. So = when an ETR sends an Info-Request, an Info-Reply from the map-server = could tell the registering system what LCAFs it supported. Ditto, for = asking map-resolvers what types of EID encodings they could support = (maybe the mapping system can support more LCAF encodings then the = map-resolvers, so you can choose a different map-resolver if you wanted = more). And arguably, the Capabilities Type LCAF could be put in RLOC-probes. It = could go anywhere with the address you wanted to encode as a 2-tuple. Comments? If people are interested I can draft up the details for the -03 version. = Or if you think we should post the -03 version just with the current = changes, I can do that. And also comment if you think we should go with = the JSON Data Model Type for -03 or put it into -04 with perhaps this = Capabilities LCAF. Thanks, Dino= From sander@steffann.nl Thu Sep 12 15:06:02 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C5521E81F4 for ; Thu, 12 Sep 2013 15:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZLZIH7Za5Uq for ; Thu, 12 Sep 2013 15:06:01 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id A19A121E80DF for ; Thu, 12 Sep 2013 15:06:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 9C4643A; Fri, 13 Sep 2013 00:05:59 +0200 (CEST) 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 10024) with ESMTP id 8Ch9FlAnLo9c; Fri, 13 Sep 2013 00:05:57 +0200 (CEST) Received: from [127.0.0.1] (cypher.steffann.nl [94.142.242.216]) by mail.sintact.nl (Postfix) with ESMTPSA id 772E516; Fri, 13 Sep 2013 00:05:57 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Sander Steffann In-Reply-To: <5FB6E5C2-AF6A-415A-8DE4-5958961A6661@gmail.com> Date: Fri, 13 Sep 2013 02:06:02 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7778D231-CF61-4BFE-8657-48CB1190224A@steffann.nl> References: <5FB6E5C2-AF6A-415A-8DE4-5958961A6661@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1508) Cc: "lisp@ietf.org list" Subject: Re: [lisp] Capabilities Type LCAF - a proposal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 12 Sep 2013 22:06:02 -0000 Hi Dino, > I would propose that the Capabilities Type LCAF be encoded as a = bit-string. Where each bit position indicates the LCAF Type value. We = would have 2 fields, an EID field and a RLOC field so it can be conveyed = which Types are supported for EID encoded fields or RLOC encoded fields = in any LISP control message. >=20 > [...] >=20 > Comments? Will a bit string be able to provide enough detail? LCAF types can be = combined in many ways... > If people are interested I can draft up the details for the -03 = version. Or if you think we should post the -03 version just with the = current changes, I can do that. I would like to see it in -03 > And also comment if you think we should go with the JSON Data Model = Type for -03 or put it into -04 with perhaps this Capabilities LCAF. Also for -03 I would say. This will very probably not be the final = draft, so why publish -03 now when we know that this will be added to = -04 :-) Thanks, Sander. From farinacci@gmail.com Thu Sep 12 16:34:39 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D542B11E81BB for ; Thu, 12 Sep 2013 16:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zp6cj+gMwZPP for ; Thu, 12 Sep 2013 16:34:39 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D164911E8152 for ; Thu, 12 Sep 2013 16:34:38 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so456632pbb.19 for ; Thu, 12 Sep 2013 16:34:38 -0700 (PDT) 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=Q1+wn1F5DElDnHvmsrrvbiTHRHyVjoF7T0X6+gqF/mU=; b=ShnPksTMARQPfFImmX5HbTe3Z3Z4G2aXRb9Fb9orb9B7Bnei6XtWhP5reFX6N/BiMS H3s/EOOiRiTaOTLsDQvew72hQAqREGhN/uwbBPTt2uOlQz9EoTXjaPVJyAGg7MEqM4QF VcA+wCPeGaRCirfWIEdooohkSTHGHqqrq0Z3jzdFSAOyecXq/DqEbDACAS+A0HC29ay5 MA8GIEoL0wI7FxARmUoMcy7ewaBqksYmTU9LsibYG0LQ7tdu/AqlHrZ9xdVJMziNDzYs iM1g3+6e0FNYDuXLXEHx67+8eA32E2LIfqzYCdLT2n1/BQemRa2/QtbDzBvS7leD+B0N OvnQ== X-Received: by 10.68.113.99 with SMTP id ix3mr104290pbb.180.1379028878534; Thu, 12 Sep 2013 16:34:38 -0700 (PDT) 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 b4sm7452559pbc.22.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 16:34:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <7778D231-CF61-4BFE-8657-48CB1190224A@steffann.nl> Date: Thu, 12 Sep 2013 16:34:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <878D9F8A-BC29-49CD-BF19-47146AB5C489@gmail.com> References: <5FB6E5C2-AF6A-415A-8DE4-5958961A6661@gmail.com> <7778D231-CF61-4BFE-8657-48CB1190224A@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1508) Cc: "lisp@ietf.org list" Subject: Re: [lisp] Capabilities Type LCAF - a proposal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 12 Sep 2013 23:34:40 -0000 > Hi Dino, >=20 >> I would propose that the Capabilities Type LCAF be encoded as a = bit-string. Where each bit position indicates the LCAF Type value. We = would have 2 fields, an EID field and a RLOC field so it can be conveyed = which Types are supported for EID encoded fields or RLOC encoded fields = in any LISP control message. >>=20 >> [...] >>=20 >> Comments? >=20 > Will a bit string be able to provide enough detail? LCAF types can be = combined in many ways... Well I knew someone would ask that. LOL. ;-) I think it provides sufficient detail without getting out of hand. >> If people are interested I can draft up the details for the -03 = version. Or if you think we should post the -03 version just with the = current changes, I can do that. >=20 > I would like to see it in -03 >=20 >> And also comment if you think we should go with the JSON Data Model = Type for -03 or put it into -04 with perhaps this Capabilities LCAF. >=20 > Also for -03 I would say. This will very probably not be the final = draft, so why publish -03 now when we know that this will be added to = -04 :-) I can go along with this. Dino >=20 > Thanks, > Sander. >=20 From jmh@joelhalpern.com Fri Sep 13 00:51:29 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A948A11E815C for ; Fri, 13 Sep 2013 00:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5P1c5+-9H2Y9 for ; Fri, 13 Sep 2013 00:51:11 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9645721E8097 for ; Fri, 13 Sep 2013 00:51:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 2D076661A60 for ; Fri, 13 Sep 2013 00:51:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id A3DF4661A5F for ; Fri, 13 Sep 2013 00:51:01 -0700 (PDT) Message-ID: <5232C3E4.2000207@joelhalpern.com> Date: Fri, 13 Sep 2013 03:51:00 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "lisp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] LCAF X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 13 Sep 2013 07:51:30 -0000 I was reminded in recent discussion that the LCAF AFI is allowed both for RLOCs and for EIDs. For RLOCs, I have raised the concern that when an ETR injects RLOCs using various LCAFs, it has no way to know whether the receiving ITRs will be able to understand the LCAF. For some cases, this is actually a benefit. But particularly if the structure within the LCAF gets more diverse, it seems to get difficult. I do see the argument for flexibility here. But then my naive participant head exploded when I tried to apply this to an EID. Are all mapping systems required to handle all LCAFs? At first, this seems reasonable. As long as you are just doing pure prefix matching, it is just a variable length "address". But then we see things which have internal mask lengths. Or might need prefixing on multiple fields. Or might have even more complex match criteria. If the mapping system can always treat and LCAF EID as a prefix-matched bit string, I get it. But if not, how is this supposed to work? Sorry for a basic question, Joel From internet-drafts@ietf.org Fri Sep 13 08:52:30 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD4921E8055; Fri, 13 Sep 2013 08:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNdiZue+CNfY; Fri, 13 Sep 2013 08:52:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 206AB21F9360; Fri, 13 Sep 2013 08:52:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130913155229.5101.8671.idtracker@ietfa.amsl.com> Date: Fri, 13 Sep 2013 08:52:29 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-mib-13.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: 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, 13 Sep 2013 15:52:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : LISP MIB Author(s) : Gregg Schudel Amit Jain Victor Moreno Filename : draft-ietf-lisp-mib-13.txt Pages : 65 Date : 2013-09-13 Abstract: This document defines the MIB module that contains managed objects to support the monitoring devices that support the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-mib-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mib-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From farinacci@gmail.com Fri Sep 13 09:48:13 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25FF21E80F0 for ; Fri, 13 Sep 2013 09:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDCTcq6G1AKB for ; Fri, 13 Sep 2013 09:48:13 -0700 (PDT) Received: from mail-ye0-x22e.google.com (mail-ye0-x22e.google.com [IPv6:2607:f8b0:4002:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1321E80AA for ; Fri, 13 Sep 2013 09:48:13 -0700 (PDT) Received: by mail-ye0-f174.google.com with SMTP id q4so566816yen.19 for ; Fri, 13 Sep 2013 09:48:07 -0700 (PDT) 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=A6hHWVIzG7yTwPFyNetAiGLL0myMkX8s6f02jeX9nkk=; b=gg0UhDpaF05BGUU+1RdwmEt4lVyU2e4Z9tDKnTlV6+2f+FYNwP8H2kIQePSNkVLcJ3 /9PCZdvB5NHAIPc4jLBHpcUQ5lu5cReqvE9kTlvH0O9/PXnoXPAgdG8EVfMwTB1YAYYT 2K8JSjQvCZbIhQYcA0icnBR35AMaOV2rHhWrWMogbJKj2qUmBHAuwrfRLCpHM1gZKtp6 jR0OqcWosWQbNaR89QTq9z2KOggashn7l9tGQ2UtYB6lUvZtjmtsEqNAymX/7vj8ubtc 4cIyq+R1brVdsiUlGNrpH9dmhcOkkqqQu5rw03honu9Iss4o5orD+xAlb24HgEni0iWo 2IWw== X-Received: by 10.236.231.212 with SMTP id l80mr1600499yhq.123.1379090887907; Fri, 13 Sep 2013 09:48:07 -0700 (PDT) Received: from [192.168.1.115] ([207.145.253.66]) by mx.google.com with ESMTPSA id r1sm13996647yhf.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 09:48:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <5232C3E4.2000207@joelhalpern.com> Date: Fri, 13 Sep 2013 09:48:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <47215950-AF06-4B0E-90FA-C2F0A31B13ED@gmail.com> References: <5232C3E4.2000207@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1508) Cc: "lisp@ietf.org" Subject: Re: [lisp] LCAF X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 13 Sep 2013 16:48:14 -0000 > I was reminded in recent discussion that the LCAF AFI is allowed both = for RLOCs and for EIDs. >=20 > For RLOCs, I have raised the concern that when an ETR injects RLOCs = using various LCAFs, it has no way to know whether the receiving ITRs = will be able to understand the LCAF. For some cases, this is actually a = benefit. But particularly if the structure within the LCAF gets more = diverse, it seems to get difficult. I do see the argument for = flexibility here. Right, agree. > But then my naive participant head exploded when I tried to apply this = to an EID. Are all mapping systems required to handle all LCAFs? At = first, this seems reasonable. As long as you are just doing pure prefix = matching, it is just a variable length "address". It can be worse Joel. It can be a non-contiguous address.=20 > But then we see things which have internal mask lengths. Or might = need prefixing on multiple fields. Or might have even more complex = match criteria. Right. Think of an extended-EID being just a prefix-tuple like a = (S-prefix, G-prefix) entry. Or a flow entry that could look like this = (S-prefix, D-prefix, sport=3D1024-65535, dport=3D*). The pilot network today supports an instance-ID prefix or an = (instance-ID, EID-prefix). The LISP-RE authors and the signal-less = multicast stuff I have presented would require (S-prefix, G-prefix). > If the mapping system can always treat and LCAF EID as a = prefix-matched bit string, I get it. But if not, how is this supposed = to work? I think it can work, but my gut is that it has to be treated as a = n-tuple entity, rather than a string of bits. And if the n-tuple can be = configured, then you could include < n elements in the n-tuple to = delegate to child referrals. I am wondering if the DHT advocates on this list believe that DHTs make = this simpler (or even harder). Dino >=20 > Sorry for a basic question, > Joel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From iesg-secretary@ietf.org Fri Sep 13 12:59:54 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5340511E8129; Fri, 13 Sep 2013 12:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9FNRvzXrAql; Fri, 13 Sep 2013 12:59:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A8911E80A2; Fri, 13 Sep 2013 12:59:53 -0700 (PDT) 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: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130913195953.9210.59739.idtracker@ietfa.amsl.com> Date: Fri, 13 Sep 2013 12:59:53 -0700 Cc: lisp mailing list , lisp chair , RFC Editor Subject: [lisp] Document Action: 'LISP MIB' to Experimental RFC (draft-ietf-lisp-mib-13.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: 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, 13 Sep 2013 19:59:54 -0000 The IESG has approved the following document: - 'LISP MIB' (draft-ietf-lisp-mib-13.txt) as Experimental RFC This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-lisp-mib/ Technical Summary: The document describes the Management Information Base (MIB) module for the Locator/ID Separation Protocol (LISP), to be used with management protocols in the Internet community. The document introduces managed objects for LISP, LISP Map Server, and LISP Interworking. Working Group Summary: WG process, beside normal document evolution discussions, was uneventful. Document Quality: The document is well written and of a high standard. No special review was performed nor is needed. Feedback in the group indicates willingness to implement the LISP MIB once the final document is published. Harrie Hazewinkel performed a MIB Doctor review that resulted in several changes that improved the quality of the document. Personnel: Who is the Document Shepherd? Luigi Iannone Who is the Responsible Area Director? Brian Haberman From jmh@joelhalpern.com Fri Sep 13 13:25:21 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DEC11E80D3 for ; Fri, 13 Sep 2013 13:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4J5fZ2epz1cx for ; Fri, 13 Sep 2013 13:25:16 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id C858121F9D0E for ; Fri, 13 Sep 2013 13:25:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B83961C07D0; Fri, 13 Sep 2013 13:25:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BFFB61C0079; Fri, 13 Sep 2013 13:25:14 -0700 (PDT) Message-ID: <523374A8.3000603@joelhalpern.com> Date: Fri, 13 Sep 2013 16:25:12 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: lisp mailing list References: <20130913195953.9210.59739.idtracker@ietfa.amsl.com> In-Reply-To: <20130913195953.9210.59739.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp chair , RFC Editor Subject: Re: [lisp] Document Action: 'LISP MIB' to Experimental RFC (draft-ietf-lisp-mib-13.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 13 Sep 2013 20:25:21 -0000 Congratulations to the authors, and thanks for their diligent work. Particularly when we got conflicting OPS Area advice on some things. Yours, Joel On 9/13/13 3:59 PM, The IESG wrote: > The IESG has approved the following document: > - 'LISP MIB' > (draft-ietf-lisp-mib-13.txt) as Experimental RFC > > This document is the product of the Locator/ID Separation Protocol > Working Group. > > The IESG contact persons are Brian Haberman and Ted Lemon. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-lisp-mib/ > > > > > Technical Summary: > > The document describes the Management Information Base (MIB) > module for the Locator/ID Separation Protocol (LISP), to be > used with management protocols in the Internet community. > The document introduces managed objects for LISP, LISP Map > Server, and LISP Interworking. > > > Working Group Summary: > > WG process, beside normal document evolution discussions, > was uneventful. > > Document Quality: > > The document is well written and of a high standard. > No special review was performed nor is needed. > Feedback in the group indicates willingness to implement the LISP MIB > once the final document is published. Harrie Hazewinkel performed a > MIB Doctor review that resulted in several changes that improved the > quality of the document. > > Personnel: > > Who is the Document Shepherd? > > Luigi Iannone > > > Who is the Responsible Area Director? > > Brian Haberman > From farinacci@gmail.com Sat Sep 14 11:34:07 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3862721E80AE for ; Sat, 14 Sep 2013 11:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_50=0.001, GB_I_INVITATION=-2, HTML_COMMENT_SAVED_URL=0.114, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU8rSl8oUaeZ for ; Sat, 14 Sep 2013 11:34:04 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4428511E81B7 for ; Sat, 14 Sep 2013 11:34:04 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bg4so3797310pad.4 for ; Sat, 14 Sep 2013 11:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=6PRDq3mgRRZjNiMSigGFe09UWZFYhk428EbLdSfZ0dw=; b=MJ5xdZP+O49Wo66c34CLLaaadXosSbL8IeLkiDU9cqoSNZ+LLE1zP/jb+mDiE6nJE7 QY0AjMw5MDNi3BRE7vDWugqJtB56vCg2ontHLf/rX9i/T+AD5VTl7VGAg2TpoHFMthPO ld42Se0BsRlZ3+dJqTjGtbW5UPYSv4e11rhwUw/vd8OfadstAUtJzPN9A+sT04EYeJX6 tHN8ONy0HYOUT82leyWo9ky5e+sQmZpqF5KolJ55Dv8ob4an33Ojc/rFICIPEshNvYtW fy6vnIBAA+iVKSTx8ZBcT/1I1eayDc0qhIyzU43AI+6x4NNlprebSlcXZZ8fphyFqXSU RC7A== X-Received: by 10.66.121.131 with SMTP id lk3mr21888793pab.61.1379183643996; Sat, 14 Sep 2013 11:34:03 -0700 (PDT) Received: from [192.168.1.10] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id dw3sm19834109pbc.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Sep 2013 11:34:03 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/mixed; boundary="Apple-Mail=_DFAAC008-3F02-40DA-94BE-12EDF669B1EF" Message-Id: Date: Sat, 14 Sep 2013 11:34:02 -0700 To: "lisp@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [lisp] Posting draft-farinacci-lisp-rig-03 --- it was expired X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 14 Sep 2013 18:34:07 -0000 --Apple-Mail=_DFAAC008-3F02-40DA-94BE-12EDF669B1EF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii B.1. Changes to draft-farinacci-lisp-rig-02.txt o Draft posted September 2013. o Resetting timer for expired draft. o Update author affliations and reference RFCs. Dino --Apple-Mail=_DFAAC008-3F02-40DA-94BE-12EDF669B1EF Content-Disposition: attachment; filename=rfcdiff-lisp-rig-01-to-02.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-rig-01-to-02.html" Content-Transfer-Encoding: 7bit wdiff draft-farinacci-lisp-rig-01.txt draft-farinacci-lisp-rig-02.txt 
Internet Engineering Task Force                             D. Farinacci
Internet-Draft                                                   A. Jain                                               lispers.net
Intended status: Experimental                                    A. Jain
Expires: March 18, 2014                                 Juniper Networks
                                                             I. Kouvelas
Expires: September 2, 2012
                                                                D. Lewis
                                                           cisco Systems
                                                              March 2012
                                                      September 14, 2013

                LISP-DDT Referral Internet Groper (RIG)
                      draft-farinacci-lisp-rig-01
                      draft-farinacci-lisp-rig-02

Abstract

   A simple tool called the LISP-DDT Referral Internet Groper or 'rig'
   can be used to query the LISP-DDT hierarchy.  This draft describes
   how the 'rig' tool works.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 2, 2012. March 18, 2014.

Copyright Notice

   Copyright (c) 2012 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  5
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Implementation Details . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 15
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 16
     B.1.  Changes to draft-farinacci-lisp-rig-02.txt . . . . . . . . 16
     B.2.  Changes to draft-farinacci-lisp-rig-01.txt . . . . . . . . 16
     B.3.  Changes to draft-farinacci-lisp-rig-00.txt . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17

1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Introduction

   LISP [LISP] [RFC6830] specifies an architecture and mechanism for replacing
   the addresses currently used by IP with two separate name spaces:
   Endpoint IDs (EIDs), used within sites, and Routing Locators (RLOCs),
   used on the transit networks that make up the Internet
   infrastructure.  To achieve this separation, the Locator/ID
   Separation Protocol (LISP) defines protocol mechanisms for mapping
   from EIDs to RLOCs.  In addition, LISP assumes the existence of a
   database to store and propagate those mappings globally.  This
   document focuses on the LISP-DDT [LISP-DDT] mapping database system.

   The 'rig' is a manual management tool to query LISP-DDT mapping
   database hierarchy.  It can be run by all devices which implement
   LISP, including ITRs, ETRs, PITRs, PETRs, Map-Resolvers, Map-Servers,
   and LISP-DDT nodes, as well as by a host system at either a LISP-
   capable or non-LISP-capable site.

   The LISP-DDT 'rig' tool is similar to the 'lig' [LISP-LIG] [RFC6835] tool in
   that they are both diagnostic tools to query a distributed database.
   However, 'rig' is used to find Map-Servers serving an EID-prefix,
   specifically within a LISP-DDT mapping database framework.  And 'lig'
   can be used on top of any mapping database system to retrieve
   locators used for packet encapsulation.

3.  Definition of Terms

   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  The host obtains
      a destination EID the same way it obtains an destination address
      today, for example through a Domain Name System (DNS) [RFC1034]
      lookup or Session Invitation Protocol (SIP) [RFC3261] exchange.
      The source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID used on the public Internet
      must have the same properties as any other IP address used in that
      manner; this means, among other things, that it must be globally
      unique.  An EID is allocated to a host from an EID-prefix block
      associated with the site where the host is located.  An EID can be
      used by a host to refer to other hosts.  EIDs MUST NOT be used as
      LISP RLOCs.  Note that EID blocks MAY be assigned in a
      hierarchical manner, independent of the network topology, to
      facilitate scaling of the mapping database.  In addition, an EID
      block assigned to a site may have site-local structure
      (subnetting) for routing within the site; this structure is not
      visible to the global routing system.  In theory, the bit string
      that represents an EID for one device can represent an RLOC for a
      different device.  As the architecture is realized, if a given bit
      string is both an RLOC and an EID, it must refer to the same
      entity in both cases.  When used in discussions with other
      Locator/ID separation proposals, a LISP EID will be called a
      "LEID".  Throughout this document, any references to "EID" refers
      to an LEID.

   Extended EID (XEID):   A LISP EID, optionally extended with a non-
      zero Instance ID (IID) if the EID is intended for use in a context
      where it may not be a unique value, such as on a Virtual Private
      Network where "private" address space is used.  See "Using
      Virtualization and Segmentation with LISP" in [LISP] [RFC6830] for more
      discussion of Instance IDs.

   Routing Locator (RLOC):   A RLOC is an IPv4 [RFC0791] or IPv6
      [RFC2460] address of an egress tunnel router (ETR).  A RLOC is the
      output of an EID-to-RLOC mapping lookup.  An EID maps to one or
      more RLOCs.  Typically, RLOCs are numbered from topologically-
      aggregatable blocks that are assigned to a site at each point to
      which it attaches to the global Internet; where the topology is
      defined by the connectivity of provider networks, RLOCs can be
      thought of as PA addresses.  Multiple RLOCs can be assigned to the
      same ETR device or to multiple ETR devices at a site.

   DDT Node:   A network infrastructure component responsible for
      specific XEID-prefix and for delegation of more-specific sub-
      prefixes to other DDT nodes.

   DDT Client:   A network infrastructure component that sends Map-
      Request messages and implements the iterative following of Map-
      Referral results.  Typically, a DDT client will be a Map Resolver
      but it is also possible for an ITR to implement DDT client
      functionality.  A DDT client can be a device that is originating
      'rig' requests.

   DDT Map Server:   A DDT node that also implements Map Server
      functionality (forwarding Map-Requests and/or returning Map-
      Replies if offering proxy-mode service) for a subset of its
      delegated prefixes.

   DDT Map Resolver:   A network infrastructure element that accepts a
      Map-Request, adds the XEID to its lookup queue, then queries one
      or more DDT nodes for the requested EID, following returned
      referrals until it receives one with the the ms-ack action.  This
      indicates that the Map-Request has been sent to a Map-Server that
      will forward it to an ETR that, in turn, will provide a Map-Reply
      to the original sender.  A DDT Map Resolver maintains both a cache
      of Map-Referral message results containing RLOCs for DDT nodes
      responsible for XEID-prefixes of interest (termed the "referral
      cache") plus a lookup queue of XEIDs that are being resolved
      through iterative querying of DDT nodes.

   Encapsulated Map-Request:   A LISP Map-Request carried within an
      Encapsulated Control Message, which has an additional LISP header
      prepended.  Sent to UDP destination port 4342.  The "outer"
      addresses are globally-routable IP addresses, also known as RLOCs.
      Used by an ITR when sending to a Map-Resolver and by a Map-Server
      when forwarding a Map-Request to an ETR as documented in
      [LISP-MS].
      [RFC6833].

   Map-Referral:   A LISP message sent by a DDT node when it receives a
      DDT Map-Request for an XEID that matches a configured XEID-prefix
      delegation.  The Map-Referral message includes a "referral", a set
      of RLOCs for DDT nodes that have more information about the sub-
      prefix; a DDT client "follows the referral" by sending another DDT
      Map-Request to one of those RLOCs to obtain either an answer or
      another referral to DDT nodes responsible for a more-specific
      XEID-prefix.

   Authoritative XEID-prefix:   An XEID-prefix delegated to a DDT node
      and for which the DDT node may provide further delegations of
      more-specific sub-prefixes.

4.  Basic Overview

   When the rig command is run, an Encapsulated Control Message Map-
   Request is sent for a destination EID.  When a LISP-DDT Map-Referral
   is returned, the contents are displayed to the user.  The information
   displayed includes:

   o  A delegated EID-prefix configured in a DDT-node or a configured
      site EID-prefix in a DDT Map-Server that matches the requested
      EID.

   o  The type of DDT-node which sent the Map-Referral.

   o  The action code and ttl set by the sender of the Map-Referral.

   o  The referral RLOC addresses from the Map-Referral message.

   o  An round-trip-time estimate for the ECM-Map-Request/Map-Referral
      message exchange.

   A possible syntax for a rig command could be:

   rig [instance-id <iid>] <eid> to <ddt-node> [follow-all-referrals]

   Parameter description:

   [instance-id <iid>]:   is the instance-ID portion of the Extended EID
      used as VPN identifer.  When the DDT hierarchy is not configured
      with instance-IDs, this argument is omitted from the command line.

   <eid>:   is either a Fully Qualified Domain Name or a destination EID
      that is being queried in the LISP-DDT mapping database.

   <ddt-node>:   is the RLOC address of any DDT-node in the DDT
      hierarchy.  This can be the DDT root node, a DDT transit node, or
      a DDT Map-Server.

   [follow-all-referrals]:   when this keyword is used each referral
      RLOC is queried so rig can descend the entire DDT hierarchy
      starting from the node <ddt-node>.  When this keyword is not used,
      one of the referral RLOCs will be selected to descend a branch of
      the DDT hierarchy.

   The rig utility not only shows you branches of the delegation
   hierarchy but can also report:

   o  When a DDT Map-Server would forward a Map-Request to the ETRs at a
      registered LISP site.  This is known as an 'ms-acknowledgement'
      action.

   o  When a DDT Map-Server sends a negative referral indicating a
      requested EID is configured but not registered to the mapping
      database system.  This is known as an 'ms-not-registered' action.

   o  When a DDT node is sending referrals for a transit or leaf node in
      the hierarchy.  These are known as 'node-referral' and 'ms-
      referral' actions, respectively.

   o  When a DDT-node finds a hole in the address space that has not
      been allocated or configured in the delegation hierarchy.  This is
      typically associated with a hole in a DDT node's configured
      authoritative prefix.  This is known as a 'delegation-hole'
      action.

   o  When a DDT-node finds a hole in the address space that has not
      been allocated or configured in the delegation hierarchy at all.
      This is typically associated with a hole that is outside of a DDT
      node's authoritative prefix.  This is known as 'non-authoritative'
      action.

   Refer to [LISP-DDT] for more detail about Map-Referral actions.

5.  Implementation Details

   The cisco LISP prototype implementations on IOS and NX-OS has rig
   support for IPv4 and IPv6 EIDs in either the default instance or a
   non-zero instance-ID.

   The IOS syntax is:

   rig [instance-id <iid>] <eid> to <ddt-node> [follow-all-referrals]

   The NX-OS syntax is:

   rig [instance-id <iid>] <hostname> | {<eid> | <eid6>}}
                           to {<ddt-hostname> | {<ddt> | <ddt6>}}

   Here is some sample IOS output:

   Router# rig 12.0.1.1 to 1.1.1.1

   Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 0 ms
   EID-prefix: [0] 12.0.0.0/16, ttl: 1440
   referrals: 2.2.2.2

   Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms
   EID-prefix: [0] 12.0.1.0/24, ttl: 1440
   referrals: 4.4.4.4, 5.5.5.5

   Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement,
                                            rtt: 0 ms
   EID-prefix: [0] 12.0.1.0/28, ttl: 1440
   referrals: 4.4.4.4, 5.5.5.5
   Router# rig 12.0.1.1 to 1.1.1.1 follow-all-referrals

   Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 4 ms
   EID-prefix: [0] 12.0.0.0/16, ttl: 1440
   referrals: 2.2.2.2

   Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms
   EID-prefix: [0] 12.0.1.0/24, ttl: 1440
   referrals: 4.4.4.4, 5.5.5.5

   Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement,
                                            rtt: 0 ms
   EID-prefix: [0] 12.0.1.0/28, ttl: 1440
   referrals: 4.4.4.4, 5.5.5.5

   Send Map-Request to DDT-node 5.5.5.5 ... map-server acknowledgement,
                                            rtt: 0 ms
   EID-prefix: [0] 12.0.1.0/28, ttl: 1440
   referrals: 4.4.4.4, 5.5.5.5

   No more referrals to pursue.

   Here is some sample NX-OS output:

   Router# rig 12.0.1.1 to 1.1.1.1

   rig LISP-DDT hierarchy for EID [0] 12.0.1.1
   Send Map-Request to DDT-node 1.1.1.1 ... replied, rtt: 0.003509 secs
   EID-prefix [0] *, ttl: 1440, action: node-referral, referrals:
     2.2.2.2, priority/weight: 0/0

   Send Map-Request to DDT-node 2.2.2.2 ... replied, rtt: 0.003173 secs
   EID-prefix [0] 12.0.0.0/20, ttl: 1440, action: node-referral,
     referrals:
     3.3.3.3, priority/weight: 0/0

   Send Map-Request to DDT-node 3.3.3.3 ... replied, rtt: 0.004145 secs
   EID-prefix [0] 12.0.1.0/24, ttl: 1440, action: node-referral,
     referrals:
     5.5.5.5, priority/weight: 0/0
     6.6.6.6, priority/weight: 0/0

   Send Map-Request to DDT-node 6.6.6.6 ... replied, rtt: 0.005800 secs
   EID-prefix [0] 12.0.1.0/28, ttl: 1440, action: ms-ack, referrals:
     5.5.5.5, priority/weight: 0/0
     6.6.6.6, priority/weight: 0/0

6.  Security Considerations

   The use of rig does not affect the security of the LISP
   infrastructure as it is simply a tool that facilities diagnostic
   querying.  See [LISP], [RFC6830], [LISP-DDT], and [LISP-MS] [RFC6833] for descriptions
   of the security properties of the LISP infrastructure.

   LISP rig provides easy access to the information in the public
   mapping database.  Therefore, it is important to protect the mapping
   information for private use.  This can be provided by disallowing
   access to specific mapping entries or to place such entries in a
   private mapping database system.

7.  IANA Considerations

   This document makes no request of the IANA.

8.  References

8.1.  Normative References

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-23.txt (work in progress).

   [LISP-LIG]
              Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
              draft-ietf-lisp-lig-06.txt (work in progress).

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-16.txt (work in progress).

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              January 2013.

   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
              Protocol (LISP) Map-Server Interface", RFC 6833,
              January 2013.

   [RFC6835]  Farinacci, D. and D. Meyer, "The Locator/ID Separation
              Protocol Internet Groper (LIG)", RFC 6835, January 2013.

8.2.  Informative References

   [LISP-DDT]
              Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
              Delegated Database Tree", draft-fuller-lisp-ddt-03.txt draft-ietf-lisp-ddt-01.txt (work
              in progress).

Appendix A.  Acknowledgments

   The authors would like to thank the following people for their ideas
   and comments.  They are TBD.

Appendix B.  Document Change Log

B.1.  Changes to draft-farinacci-lisp-rig-02.txt

   o  Draft posted September 2013.

   o  Resetting timer for expired draft.

   o  Update author affliations and reference RFCs.

B.2.  Changes to draft-farinacci-lisp-rig-01.txt

   o  Draft posted March 2012.

   o  Updated reference to LISP-DDT".

B.3.  Changes to draft-farinacci-lisp-rig-00.txt

   o  Initial draft posted March 2012.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Ave.
   lispers.net
   San Jose, California
   USA

   Phone: 408-718-2001
   Email: dino@cisco.com farinacci@gmail.com

   Amit Jain
   cisco Systems
   Tasman Ave.
   Juniper Networks
   San Jose, California
   USA

   Phone:
   Email: amijain@cisco.com atjain@juniper.net

   Isidor Kouvelas
   cisco Systems
   Tasman Ave.
   San Jose, California
   USA

   Phone:
   Email: kouvelas@cisco.com

   Darrel Lewis
   cisco Systems
   Tasman Ave.
   San Jose, California
   USA

   Phone:
   Email: darlewis@cisco.com
--Apple-Mail=_DFAAC008-3F02-40DA-94BE-12EDF669B1EF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_DFAAC008-3F02-40DA-94BE-12EDF669B1EF Content-Disposition: attachment; filename=draft-farinacci-lisp-rig-02.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-farinacci-lisp-rig-02.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force D. Farinacci Internet-Draft lispers.net Intended status: Experimental A. Jain Expires: March 18, 2014 Juniper Networks I. Kouvelas D. Lewis cisco Systems September 14, 2013 LISP-DDT Referral Internet Groper (RIG) draft-farinacci-lisp-rig-02 Abstract A simple tool called the LISP-DDT Referral Internet Groper or 'rig' can be used to query the LISP-DDT hierarchy. This draft describes how the 'rig' tool works. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 18, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Farinacci, et al. Expires March 18, 2014 [Page 1] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Implementation Details . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 16 B.1. Changes to draft-farinacci-lisp-rig-02.txt . . . . . . . . 16 B.2. Changes to draft-farinacci-lisp-rig-01.txt . . . . . . . . 16 B.3. Changes to draft-farinacci-lisp-rig-00.txt . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Farinacci, et al. Expires March 18, 2014 [Page 2] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Farinacci, et al. Expires March 18, 2014 [Page 3] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 2. Introduction LISP [RFC6830] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate name spaces: Endpoint IDs (EIDs), used within sites, and Routing Locators (RLOCs), used on the transit networks that make up the Internet infrastructure. To achieve this separation, the Locator/ID Separation Protocol (LISP) defines protocol mechanisms for mapping from EIDs to RLOCs. In addition, LISP assumes the existence of a database to store and propagate those mappings globally. This document focuses on the LISP-DDT [LISP-DDT] mapping database system. The 'rig' is a manual management tool to query LISP-DDT mapping database hierarchy. It can be run by all devices which implement LISP, including ITRs, ETRs, PITRs, PETRs, Map-Resolvers, Map-Servers, and LISP-DDT nodes, as well as by a host system at either a LISP- capable or non-LISP-capable site. The LISP-DDT 'rig' tool is similar to the 'lig' [RFC6835] tool in that they are both diagnostic tools to query a distributed database. However, 'rig' is used to find Map-Servers serving an EID-prefix, specifically within a LISP-DDT mapping database framework. And 'lig' can be used on top of any mapping database system to retrieve locators used for packet encapsulation. Farinacci, et al. Expires March 18, 2014 [Page 4] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 3. Definition of Terms Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains an destination address today, for example through a Domain Name System (DNS) [RFC1034] lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID used on the public Internet must have the same properties as any other IP address used in that manner; this means, among other things, that it must be globally unique. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks MAY be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. As the architecture is realized, if a given bit string is both an RLOC and an EID, it must refer to the same entity in both cases. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called a "LEID". Throughout this document, any references to "EID" refers to an LEID. Extended EID (XEID): A LISP EID, optionally extended with a non- zero Instance ID (IID) if the EID is intended for use in a context where it may not be a unique value, such as on a Virtual Private Network where "private" address space is used. See "Using Virtualization and Segmentation with LISP" in [RFC6830] for more discussion of Instance IDs. Routing Locator (RLOC): A RLOC is an IPv4 [RFC0791] or IPv6 [RFC2460] address of an egress tunnel router (ETR). A RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically- aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Farinacci, et al. Expires March 18, 2014 [Page 5] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 DDT Node: A network infrastructure component responsible for specific XEID-prefix and for delegation of more-specific sub- prefixes to other DDT nodes. DDT Client: A network infrastructure component that sends Map- Request messages and implements the iterative following of Map- Referral results. Typically, a DDT client will be a Map Resolver but it is also possible for an ITR to implement DDT client functionality. A DDT client can be a device that is originating 'rig' requests. DDT Map Server: A DDT node that also implements Map Server functionality (forwarding Map-Requests and/or returning Map- Replies if offering proxy-mode service) for a subset of its delegated prefixes. DDT Map Resolver: A network infrastructure element that accepts a Map-Request, adds the XEID to its lookup queue, then queries one or more DDT nodes for the requested EID, following returned referrals until it receives one with the the ms-ack action. This indicates that the Map-Request has been sent to a Map-Server that will forward it to an ETR that, in turn, will provide a Map-Reply to the original sender. A DDT Map Resolver maintains both a cache of Map-Referral message results containing RLOCs for DDT nodes responsible for XEID-prefixes of interest (termed the "referral cache") plus a lookup queue of XEIDs that are being resolved through iterative querying of DDT nodes. Encapsulated Map-Request: A LISP Map-Request carried within an Encapsulated Control Message, which has an additional LISP header prepended. Sent to UDP destination port 4342. The "outer" addresses are globally-routable IP addresses, also known as RLOCs. Used by an ITR when sending to a Map-Resolver and by a Map-Server when forwarding a Map-Request to an ETR as documented in [RFC6833]. Map-Referral: A LISP message sent by a DDT node when it receives a DDT Map-Request for an XEID that matches a configured XEID-prefix delegation. The Map-Referral message includes a "referral", a set of RLOCs for DDT nodes that have more information about the sub- prefix; a DDT client "follows the referral" by sending another DDT Map-Request to one of those RLOCs to obtain either an answer or another referral to DDT nodes responsible for a more-specific XEID-prefix. Farinacci, et al. Expires March 18, 2014 [Page 6] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 Authoritative XEID-prefix: An XEID-prefix delegated to a DDT node and for which the DDT node may provide further delegations of more-specific sub-prefixes. Farinacci, et al. Expires March 18, 2014 [Page 7] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 4. Basic Overview When the rig command is run, an Encapsulated Control Message Map- Request is sent for a destination EID. When a LISP-DDT Map-Referral is returned, the contents are displayed to the user. The information displayed includes: o A delegated EID-prefix configured in a DDT-node or a configured site EID-prefix in a DDT Map-Server that matches the requested EID. o The type of DDT-node which sent the Map-Referral. o The action code and ttl set by the sender of the Map-Referral. o The referral RLOC addresses from the Map-Referral message. o An round-trip-time estimate for the ECM-Map-Request/Map-Referral message exchange. A possible syntax for a rig command could be: rig [instance-id ] to [follow-all-referrals] Parameter description: [instance-id ]: is the instance-ID portion of the Extended EID used as VPN identifer. When the DDT hierarchy is not configured with instance-IDs, this argument is omitted from the command line. : is either a Fully Qualified Domain Name or a destination EID that is being queried in the LISP-DDT mapping database. : is the RLOC address of any DDT-node in the DDT hierarchy. This can be the DDT root node, a DDT transit node, or a DDT Map-Server. [follow-all-referrals]: when this keyword is used each referral RLOC is queried so rig can descend the entire DDT hierarchy starting from the node . When this keyword is not used, one of the referral RLOCs will be selected to descend a branch of the DDT hierarchy. The rig utility not only shows you branches of the delegation hierarchy but can also report: Farinacci, et al. Expires March 18, 2014 [Page 8] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 o When a DDT Map-Server would forward a Map-Request to the ETRs at a registered LISP site. This is known as an 'ms-acknowledgement' action. o When a DDT Map-Server sends a negative referral indicating a requested EID is configured but not registered to the mapping database system. This is known as an 'ms-not-registered' action. o When a DDT node is sending referrals for a transit or leaf node in the hierarchy. These are known as 'node-referral' and 'ms- referral' actions, respectively. o When a DDT-node finds a hole in the address space that has not been allocated or configured in the delegation hierarchy. This is typically associated with a hole in a DDT node's configured authoritative prefix. This is known as a 'delegation-hole' action. o When a DDT-node finds a hole in the address space that has not been allocated or configured in the delegation hierarchy at all. This is typically associated with a hole that is outside of a DDT node's authoritative prefix. This is known as 'non-authoritative' action. Refer to [LISP-DDT] for more detail about Map-Referral actions. Farinacci, et al. Expires March 18, 2014 [Page 9] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 5. Implementation Details The cisco LISP prototype implementations on IOS and NX-OS has rig support for IPv4 and IPv6 EIDs in either the default instance or a non-zero instance-ID. The IOS syntax is: rig [instance-id ] to [follow-all-referrals] The NX-OS syntax is: rig [instance-id ] | { | }} to { | { | }} Here is some sample IOS output: Router# rig 12.0.1.1 to 1.1.1.1 Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 0 ms EID-prefix: [0] 12.0.0.0/16, ttl: 1440 referrals: 2.2.2.2 Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms EID-prefix: [0] 12.0.1.0/24, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5 Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement, rtt: 0 ms EID-prefix: [0] 12.0.1.0/28, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5 Farinacci, et al. Expires March 18, 2014 [Page 10] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 Router# rig 12.0.1.1 to 1.1.1.1 follow-all-referrals Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 4 ms EID-prefix: [0] 12.0.0.0/16, ttl: 1440 referrals: 2.2.2.2 Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms EID-prefix: [0] 12.0.1.0/24, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5 Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement, rtt: 0 ms EID-prefix: [0] 12.0.1.0/28, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5 Send Map-Request to DDT-node 5.5.5.5 ... map-server acknowledgement, rtt: 0 ms EID-prefix: [0] 12.0.1.0/28, ttl: 1440 referrals: 4.4.4.4, 5.5.5.5 No more referrals to pursue. Here is some sample NX-OS output: Router# rig 12.0.1.1 to 1.1.1.1 rig LISP-DDT hierarchy for EID [0] 12.0.1.1 Send Map-Request to DDT-node 1.1.1.1 ... replied, rtt: 0.003509 secs EID-prefix [0] *, ttl: 1440, action: node-referral, referrals: 2.2.2.2, priority/weight: 0/0 Send Map-Request to DDT-node 2.2.2.2 ... replied, rtt: 0.003173 secs EID-prefix [0] 12.0.0.0/20, ttl: 1440, action: node-referral, referrals: 3.3.3.3, priority/weight: 0/0 Send Map-Request to DDT-node 3.3.3.3 ... replied, rtt: 0.004145 secs EID-prefix [0] 12.0.1.0/24, ttl: 1440, action: node-referral, referrals: 5.5.5.5, priority/weight: 0/0 6.6.6.6, priority/weight: 0/0 Send Map-Request to DDT-node 6.6.6.6 ... replied, rtt: 0.005800 secs EID-prefix [0] 12.0.1.0/28, ttl: 1440, action: ms-ack, referrals: 5.5.5.5, priority/weight: 0/0 6.6.6.6, priority/weight: 0/0 Farinacci, et al. Expires March 18, 2014 [Page 11] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 6. Security Considerations The use of rig does not affect the security of the LISP infrastructure as it is simply a tool that facilities diagnostic querying. See [RFC6830], [LISP-DDT], and [RFC6833] for descriptions of the security properties of the LISP infrastructure. LISP rig provides easy access to the information in the public mapping database. Therefore, it is important to protect the mapping information for private use. This can be provided by disallowing access to specific mapping entries or to place such entries in a private mapping database system. Farinacci, et al. Expires March 18, 2014 [Page 12] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 7. IANA Considerations This document makes no request of the IANA. Farinacci, et al. Expires March 18, 2014 [Page 13] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 8. References 8.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013. [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, January 2013. 8.2. Informative References [LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", draft-ietf-lisp-ddt-01.txt (work in progress). Farinacci, et al. Expires March 18, 2014 [Page 14] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 Appendix A. Acknowledgments The authors would like to thank the following people for their ideas and comments. They are TBD. Farinacci, et al. Expires March 18, 2014 [Page 15] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 Appendix B. Document Change Log B.1. Changes to draft-farinacci-lisp-rig-02.txt o Draft posted September 2013. o Resetting timer for expired draft. o Update author affliations and reference RFCs. B.2. Changes to draft-farinacci-lisp-rig-01.txt o Draft posted March 2012. o Updated reference to LISP-DDT". B.3. Changes to draft-farinacci-lisp-rig-00.txt o Initial draft posted March 2012. Farinacci, et al. Expires March 18, 2014 [Page 16] =0C Internet-Draft LISP-DDT Referral Internet Groper (RIG) September 2013 Authors' Addresses Dino Farinacci lispers.net San Jose, California USA Phone: 408-718-2001 Email: farinacci@gmail.com Amit Jain Juniper Networks San Jose, California USA Phone: Email: atjain@juniper.net Isidor Kouvelas cisco Systems Tasman Ave. San Jose, California USA Phone: Email: kouvelas@cisco.com Darrel Lewis cisco Systems Tasman Ave. San Jose, California USA Phone: Email: darlewis@cisco.com Farinacci, et al. Expires March 18, 2014 [Page 17] =0C --Apple-Mail=_DFAAC008-3F02-40DA-94BE-12EDF669B1EF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_DFAAC008-3F02-40DA-94BE-12EDF669B1EF-- From jmh@joelhalpern.com Sun Sep 15 08:18:08 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B85721F9FED for ; Sun, 15 Sep 2013 08:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.592 X-Spam-Level: X-Spam-Status: No, score=-101.592 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZgRQZtGMxha for ; Sun, 15 Sep 2013 08:18:02 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 1568021F9F9D for ; Sun, 15 Sep 2013 08:17:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 0EBE91BD6AC8 for ; Sun, 15 Sep 2013 08:17:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 75A2C1BD6AB8 for ; Sun, 15 Sep 2013 08:17:55 -0700 (PDT) Message-ID: <5235CFA0.4030902@joelhalpern.com> Date: Sun, 15 Sep 2013 11:17:52 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "lisp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] LCAF question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 15:18:08 -0000 It seems to me that there are three related technical problems or general concerns. 1) We need to be clear about which LCAFs can be used as EIDs, which as RLOC, and which as both. 2) We need to be clear about how the mapping system is to support any given LCAF as an EID. For Example, if one prohibits the IID mask length then an IID + Address LCAF can be be supported by the mapping system as a simple prefix. But, if we have to match on both IID prefixes and Address prefixes then this requires more support from the mapping system. 2a) Specifically, for any LCAF on which there can be multiple partial matches we have to specify what "longest match" means. Does longer IID trump longer Address? 3) If we have LCAFs for EIDs which need support from the mapping system then the EID needs to know what LCAFs the mapping system supports. It seems likely that special-purpose cases will use separate mapping systems tied to separate authorities. But how will the ETR that is registering or the ITR that is asking know which mapping system supports which set? Configuration seems a VERY bad answer. Note that this is separate from the question of whether an ETR using a complex LCAF RLOC can reasonably expect the ITR to understand it. Comments, opinions, or rotten tomatoes? Yours, Joel M. Halpern From farinacci@gmail.com Sun Sep 15 11:49:36 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5816C11E8192 for ; Sun, 15 Sep 2013 11:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.039 X-Spam-Level: X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_20=-0.74, HTML_COMMENT_SAVED_URL=0.114, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wneYTQzIhcGA for ; Sun, 15 Sep 2013 11:49:34 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id C2AC911E8185 for ; Sun, 15 Sep 2013 11:49:34 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y10so3212749pdj.8 for ; Sun, 15 Sep 2013 11:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=0y8ikEEwATPx/q8vMEJEcU13kiEYAwb1wyUXTuSUG6U=; b=Yj2Hyicz+v5BFCpOF3rxkdeyuOK9KA3osOe9+0iDIPwalsnzRhCaKJsOx5xRD5WmXd IuyjBUu+LX4NP+2lM4YMA+tRiw9R/QVIwhoOZdGJGesFqARXpESElU9nRc4Kd/MEwypQ wSKOPSfqNwgZU2kgb8hz9wiCCx+1VB2JIpRlPlcvBU0i+iUGUTA2jbUDfCOwxmnHvHGI gWFiA+jtbMhQpAxLrjp2t3xJHuO/OOsgnR6WNzZlPvqOqqOHRSScapDQvScauUC71pSk DDectD9fMw63YQQGowOFMn5xKxdmiW52c/L+KHNcQhxQdRA2nVOCqP9UZekHs/qT8W4d 7SDQ== X-Received: by 10.66.249.134 with SMTP id yu6mr27143826pac.37.1379270974328; Sun, 15 Sep 2013 11:49:34 -0700 (PDT) Received: from [10.0.1.2] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id gg10sm25850453pbc.46.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 11:49:33 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/mixed; boundary="Apple-Mail=_BA6F54A6-84A4-4BA9-A161-98FD63404578" Date: Sun, 15 Sep 2013 11:49:32 -0700 References: <20130915184700.11116.34903.idtracker@ietfa.amsl.com> To: "lisp@ietf.org list" Message-Id: <579141EB-E43F-4425-87CF-2D133ACEC49A@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [lisp] Fwd: I-D Action: draft-farinacci-lisp-mr-signaling-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 18:49:36 -0000 --Apple-Mail=_BA6F54A6-84A4-4BA9-A161-98FD63404578 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Updated draft based on comments from Noel. Diff file enclosed. Dino --Apple-Mail=_BA6F54A6-84A4-4BA9-A161-98FD63404578 Content-Disposition: attachment; filename=rfcdiff-lisp-mr-signaling-02-to-03.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-mr-signaling-02-to-03.html" Content-Transfer-Encoding: 7bit wdiff draft-farinacci-lisp-mr-signaling-02.txt draft-farinacci-lisp-mr-signaling-03.txt 
Internet Engineering Task Force                             D. Farinacci
Internet-Draft                                               lispers.net
Intended status: Experimental                               M. Napierala
Expires: January 11, March 18, 2014                                             AT&T
                                                           July 10,
                                                      September 14, 2013

                 LISP Control-Plane Multicast Signaling
                  draft-farinacci-lisp-mr-signaling-02
                  draft-farinacci-lisp-mr-signaling-03

Abstract

   This document describes an alternate method to signal multicast tree
   building among xTRs in multicast capable LISP sites.  This approach
   avoids the need to run a multicast routing protocol on the LISP
   overlay.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 11, March 18, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  6
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Join-Request/Leave-Request Encoding Formats  . . . . . . . . .  9
   6.  Replication Considerations . . . . . . . . . . . . . . . . . . 11
   7.  Interworking Considerations  . . . . . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 15
     10.2.  Informative References  . . . . . . . . . . . . . . . . . 15
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 16
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 17
     B.1.   Changes to draft-farinacci-lisp-mr-signaling-02.txt draft-farinacci-lisp-mr-signaling-03.txt . . . 17
     B.2.   Changes to draft-farinacci-lisp-mr-signaling-01.txt draft-farinacci-lisp-mr-signaling-02.txt . . . 17
     B.3.   Changes to draft-farinacci-lisp-mr-signaling-01.txt . . . 17
     B.4.   Changes to draft-farinacci-lisp-mr-signaling-00.txt . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Introduction

   The Locator/ID Separation Architecture [RFC6830] provides a mechanism
   to separate out Identification and Location semantics from the
   current definition of an IP address.  By creating two namespaces, an
   Endpoint ID (EID) namespace used by sites and a Routing Locator
   (RLOC) namespace used by core routing, the core routing
   infrastructure can scale by doing topological aggregation of routing
   information.

   Since LISP creates a new namespace, a mapping function must exist to
   map a site's EID prefixes to its associated locators.  For unicast
   packets, both the source address and destination address must be
   mapped.  For multicast packets, only the source address needs to be
   mapped.  The destination group address doesn't need to be mapped
   because the semantics of an IPv4 or IPv6 group address are logical in
   nature and not topology-dependent.  Therefore, this specification
   focuses on the procedures of how to map a source EID address and
   destination group address of a multicast flow during distribution
   tree setup and packet delivery.

   The LISP Multicast specification [RFC6831] addresses the following
   procedures:

   1.  How a multicast source host in a LISP site sends multicast
       packets to receivers inside of its site as well as to receivers
       in other sites that are LISP enabled.

   2.  How inter-domain (or inter-LISP sites) multicast distribution
       trees are built and how forwarding of multicast packets leaving a
       source site toward receivers sites is performed.

   3.  What protocols are affected and what changes are required to such
       multicast protocols.

   4.  How ASM-mode (Any Source Multicast), SSM-mode (Single Source
       Multicast), and Bidir-mode (Bidirectional Shared Trees) service
       models will operate.

   5.  How multicast packet flow will occur for multiple combinations of
       LISP and non-LISP capable source and receiver sites.

   The distribution tree mechanism in [RFC6831] specifies the use of the
   PIM multicast routing protocol and how PIM is used between xTRs
   connecting multicast capable source sites and receiver sites
   together.

   This specification will describe an alternate method for connecting
   multicast capable sites together by using Map-Requests instead of the
   PIM protocol.  The advantages this brings is a single LISP control-
   plane mechanism used for both unicast and multicast packet flow.

   This specification does not describe how (S-EID,G) multicast
   distribution tree state is built in multicast receiver sites and in
   multicast source sites.  This specification also does not describe
   how (S-RLOC,G) or (S-RLOC,DG) multicast distribution tree state is
   built in the core network.  This specification defines how (S-EID,G)
   state is propagated from multicast receiver site resident ETRs to
   multicast ITRs.  This signaling is needed so the (S-EID,G) state can
   be propagated from the ITR to the source host in the multicast source
   site.

3.  Definition of Terms

   Note that all the definitions that apply in [RFC6831] apply in this
   specification as well.  And the following definitions are specific to
   this specification.

   Join-Request:   This is a reference to a Map-Request that allows the
      joining to a multicast tree by an ETR to an ITR (or PITR) for a
      given (S-EID,G) entry.

   Leave-Request:   This is a reference to a Map-Request that allows the
      leaving from a multicast tree by an ETR to an ITR (or PITR) for a
      given (S-EID,G) entry.

   LISP-RE:   RE stands for "Replication Engineering" which is a term
      used to design algorithms, protocols, and networks to optimize
      where multicast packet replication is performed in the network.

   Unicast Replication:   Is the notion of replicating a multicast
      packet at an ITR (or PITR) by encapsulating it into a unicast
      packet.  That is, the oif-list of a multicast routing table entry
      can not only have interfaces present for link-layer replication
      and for multicast encapsulation but also for unicast
      encapsulation.

   Delivery Group:   This is the outer packet's (or encapsulating
      header's) destination address when encapsulating a multicast
      packet inside of a multicast packet.  There is a one-to-one and
      one-to-many relationship between the inner header's destination
      group address and the outer header's destination group address.
      Notation for a delivery group entry is (S-RLOC,DG).

   (S-EID,G):  This is multicast state notation which is signaled from
      ETR to ITR in Map-Request messages.  'G' is the group address
      multicast hosts send and/or join to.  'S-EID' can be a host EID
      that sends multicast packets.  'S-EID' can be a Rendezvous Point
      (RP) that resides in the LISP multicast site so (*,G) state can be
      signaled from ETR to ITR.  All of PIM (S,G), (*,G), and (S,G,RP-
      bit) state can be conveyed via the Multicast Info Type format
      [LISP-LCAF] in Map-Request messages.

   (S-RLOC,DG):  This is multicast state notation which is kept by the
      multicast core network.  An (S-EID,G) packet originated by a
      multicast source is encapsulated by an ITR (or PITR) which maps
      the source EID (S-EID) to a source RLOC (S-RLOC) and the
      destination group address G to a Delivery Group address (DG).

4.  Overview

   In [RFC6831], there is a two step approach for an ETR to join the
   distribution tree (S-EID,G) to at an ITR. ITR where that distribution tree
   connects to a core distribution tree.  In the first step, the ETR
   must look up which ITR is associated with S-EID.  That is performed
   with a mapping database lookup and having the ETR select an ITR from
   the list of high priority RLOCs.  In the second step, a unicast PIM
   join must be sent by the ETR to the ITR.

   In the design here within, we transmit the join and leave semantic in
   a Map-Request message.  In this case, both the S-EID lookup and the
   the fact the ETR wants to join the distribution tree S-EID for a
   particular multicast group can be conveyed in one message exchange.
   The advantages of this are:

   1.  Less message overhead used for signaling.

   2.  State signaling comes together in a single message.  If an ETR
       has a map-cache entry for the S-EID, it also knows that the Join
       for (S-EID,G) reliably made it to the ITR.  If there is message
       loss both pieces of state fate-share the loss.

   3.  The Map-Reply is used as an acknowledgement where as with unicast
       PIM Join-Prune messages, they must be sent periodically which may
       create scalability problems in networks with a lot of multicast
       state.

   Here is the basic procedure that a multicast ETR or multicast PETR
   uses to convey (S-EID,G) join state to a multicast ITR or multicast
   PITR:

   1.  When an ETR creates (S-EID,G) from a site based PIM Join message
       and the oif-list goes non-empty, a Join-Request is sent.  If a
       map-cache entry exists for S-EID, then the Map-Request is sent to
       the highest multicast priority RLOC.  If a map-cache entry does
       not exist, the Map-Request is sent to the mapping database
       system.

   2.  When a Map-Reply is not returned, the Map-Request is
       retransmitted.  When a Map-Reply is returned, the ETR can be
       assured that the ITR will replicate packets to the ETR.

   3.  When unicast replication is performed, no additional action needs
       to be performed by the ETR.

   4.  When multicast replication is performed, the ETR must send a PIM
       Join message for (S-RLOC,G) or (S-RLOC,DG) into the core as
       specified in [RFC6831].  See Section 6 for details when ITR
       unicast and/or multicast replication is done and how it is
       decided.

   An ETR must detect when an ITR has reloaded or cleared its state so
   that the ETR can resend Join-Requests for all the (S-EID,G) state it
   has cached.  Procedures for how to achieve this will be discussed in
   future versions of this specification.

   Here is the basic procedure a multicast ETR or multicast PETR uses to
   convey (S-EID,G) leave state to a multicast ITR or multicast PITR:

   1.  When an ETR (S-EID,G) oif-list state goes empty, a Leave-Request
       is sent.  If a map-cache entry exists for S-EID, then the Map-
       Request is sent to the highest multicast priority RLOC.  If a
       map-cache entry does not exist, the Map-Request is sent to the
       mapping database system.

   2.  When a Map-Reply is not returned, the Map-Request is
       retransmitted.  When a Map-Reply is returned, the ETR can be
       assured that the ITR will no longer replicate packets to the ETR.

   3.  When unicast replication is performed, no additional action needs
       to be performed by the ETR.

   4.  When multicast replication is performed, the ETR must send a PIM
       Leave message for (S-RLOC,G) or (S-RLOC,DG) into the core network
       as specified in [RFC6831].

5.  Join-Request/Leave-Request Encoding Formats

   A Join-Request and Leave-Request are encoded as follows:

   o  (S-EID,G) is encoded in the destination EID-prefix field of a Map-
      Request [RFC6830].

   o  The encoding format of the destination EID-prefix is in LCAF
      format Type 'Multicast Info' [LISP-LCAF].  The J-bit and L-bit
      indicate if the Map-Request is a Join-Request or a Leave-Request,
      respectively.

   o  (S-RLOC,DG) is encoded in the Source EID Address field of the Map-
      Request.  It is also encoded in the same LCAF Type 'Multicast
      Info'.

   o  If S-RLOC is not known, then AFI=0 is encoded in the Source
      Address field of the LCAF type.

   o  If S-RLOC is known, then the RLOC of the ITR is encoded in the
      Source Address field of the LCAF type.

   o  If a Delivery Group is being requested by the ETR, then DG is
      encoded in the Group Address field of the LCAF type.

   o  If a unicast replication is being requested by the ETR, then ETR
      encodes a unicast RLOC address in the Group Address field of the
      LCAF type.

   A Map-Reply is returned for a Join-Request or a Leave-Request with
   the following format encoding:

   1.  The destination EID-prefix encoding in the Map-Request is copied
       and encoded in the Source EID Address field of the Map-Reply.
       This is so the ETR can match Map-Replies with Map-Requests.  The
       nonce field may be used for this purpose as well.  The address
       encoding is (S-EID,G).

   2.  The destination EID-prefix in the Map-Reply is the multicast
       information the ITR is conveying to ETR.  It can be (ITR-RLOC,DG)
       or (ITR-RLOC,ETR-RLOC).

   3.  When the ETR requested unicast replication, then the returned
       destination EID-prefix contains (ITR-RLOC,ETR-RLOC)

   4.  When the ETR requested a DG for multicast replication, then the
       returned destination EID-prefix contains (ITR-RLOC,DG).

   5.  When the ITR overrides a requested (ITR-RLOC,ETR-RLOC) with a
       returned (ITR-RLOC,DG), then the ETR must send a join (or leave)
       for (ITR-RLOC,DG) into the core network.

   6.  When the ITR overrides a join-requested (ITR-RLOC,DG1) with a
       returned value of (ITR-RLOC,DG2), then the ETR must send a Join-
       Request for (ITR-RLOC,DG2) and send a Leave-Request for (ITR-
       RLOC,DG1) into the core network.

   7.  When the ITR with RLOC 'RLOC-ITR1' returns (RLOC-ITR2,DG) in a
       Map-Reply, the ETR must send a Join-Request to RLOC-ITR2 and send
       a Leave-Request to RLOC-ITR1 for (RLOC-ITR1,DG).  Same action is
       performed when (RLOC-ITR2,ETR-RLOC) is returned for a join-
       requested value of (RLOC-ITR1,ETR-RLOC).

6.  Replication Considerations

   When an ITR processes a received multicast packet sourced by a host
   in its site, the oif-list for the (S-EID,G) entry it maintains can
   have the following entries:

   1.  An interface entry that leads to multicast receivers inside of
       the site.

   2.  An encapsulation entry that can be targeted to a Delivery Group
       or a unicast RLOC.  The Delivery Group can either be the same or
       map from the group address of the packet originated by the
       multicast source host.

   The oif-list entries can be created by the signaling mechanisms
   defined in [RFC6831] using the PIM protocol or by the signaling
   mechanisms in this specification using Map-Requests.

   Another option is to have an external orchestration system program
   the mapping database explicitly so ETR signaling to the ITR can be
   reduced or even eliminated.  Also by the use of Explicit-Locator-
   Paths (ELPs) [LISP-TE], LISP-RE capabilities can be explored.  For
   more details see [LISP-RE].

   Since an oif-list can contain either a Delivery Group or a unicast
   RLOC as a destination address for the outer header, a question is
   raised where the decision is made to use one or the other, or both.

   It is desirable to use multicast routing in the core network where it
   is available.  However, if ETRs are attached to a multicast capable
   core network, the ITR may not be.  In this case, unicast RLOC
   encapsulation will be necessary to deliver multicast packets directly
   to the ETR.  It will left to the network administrator to configure
   the decision on Delivery Group versus unicast RLOCs is done by the
   ETRs, the ITR, or an orchestration system directly programming the
   mapping database.  This specification allows and permits for the ETR
   to request the encapsulation destination address as well as allowing
   the ITR to override it.

7.  Interworking Considerations

   The Map-Request multicast signaling between ETR(s) and an ITR
   described in this specification is also used by ETR(s) to multicast
   PITRs which are deployed to support non-LISP multicast source sites.
   This is true for multicast PETRs that signal to an ITR or mPITR which
   support non-LISP multicast receiver sites.

8.  Security Considerations

   The security concerns for LISP multicast are mainly the same as for
   the base LISP specification [RFC6830] and the LISP multicast
   specification [RFC6831], including PIM-ASM [RFC4601].

   Where there are security concerns with respect to unicast PIM
   messages, as discussed in [RFC6831], the same may also be true for
   multicast signaling with Map-Request messages.

9.  IANA Considerations

   At this time there are no requests for IANA.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              January 2013.

   [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
              Locator/ID Separation Protocol (LISP) for Multicast
              Environments", RFC 6831, January 2013.

10.2.  Informative References

   [LISP-LCAF]
              Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format", draft-ietf-lisp-lcaf-00.txt (work in
              progress).

   [LISP-RE]  Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
              Maino, F., and D. Farinacci, "LISP Replication
              Engineering", draft-coras-lisp-re-01.txt (work in
              progress).

   [LISP-TE]  Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic
              Engineering Use-Cases", draft-farinacci-lisp-te-02.txt
              (work in progress).

Appendix A.  Acknowledgments

   The authors would like to thank the following people for their
   participation in conversations on the topic.  They are Gregg Schudel,
   Florin Coras, Darrel Lewis, and Fabio Maino. Maino, and Noel Chiappa.

Appendix B.  Document Change Log

B.1.  Changes to draft-farinacci-lisp-mr-signaling-03.txt

   o  Posted September 2013.

   o  Add clarificaiton text through out to reflect comments from Noel
      Chiappa.

B.2.  Changes to draft-farinacci-lisp-mr-signaling-02.txt

   o  Refreshing references and document timer.

B.2.

B.3.  Changes to draft-farinacci-lisp-mr-signaling-01.txt

   o  Refreshing references and document timer.

B.3.

B.4.  Changes to draft-farinacci-lisp-mr-signaling-00.txt

   o  Initial draft posted July 2012.

Authors' Addresses

   Dino Farinacci
   lispers.net
   San Jose, California
   USA

   Phone: 408-718-2001
   Email: farinacci@gmail.com

   Maria Napierala
   AT&T
   Middletown, NJ
   USA

   Email: mnapierala@att.com
--Apple-Mail=_BA6F54A6-84A4-4BA9-A161-98FD63404578 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-farinacci-lisp-mr-signaling-03.txt > Date: September 15, 2013 11:47:00 AM PDT > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : LISP Control-Plane Multicast Signaling > Author(s) : Dino Farinacci > Maria Napierala > Filename : draft-farinacci-lisp-mr-signaling-03.txt > Pages : 18 > Date : 2013-09-15 >=20 > Abstract: > This document describes an alternate method to signal multicast tree > building among xTRs in multicast capable LISP sites. This approach > avoids the need to run a multicast routing protocol on the LISP > overlay. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farinacci-lisp-mr-signaling >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-farinacci-lisp-mr-signaling-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-mr-signaling-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_BA6F54A6-84A4-4BA9-A161-98FD63404578-- From rogerj@gmail.com Sun Sep 15 12:13:49 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6DD11E8178 for ; Sun, 15 Sep 2013 12:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTD2gwLTa7vm for ; Sun, 15 Sep 2013 12:13:48 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3E75111E810A for ; Sun, 15 Sep 2013 12:13:36 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ez12so2599633wid.8 for ; Sun, 15 Sep 2013 12:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OEzDXMbOgxu5mGFP74DS0xj4hROSwIfa6SC1IqlHGsY=; b=TDdA2lLruwBOlZAefofiUm9Dnl7yW2U8r72wGyw08z3kzmyTPxEQBpylt0SIeJVAHi Rm6xgXpcWzGzBG2580mqBP8X5PEQHgwOnpqrRtB7hp6venavZIyDx9XJDr4tq4EUgPhA r5cFW2gtkdZxgkT4ctAduOUjU2wF8cCCedJRag1dzYc1mSQDQMRMoLmaWXHCdl9+6IuP 48VcqmIjiOcXad7GBQrCsOC2W9GvQ6vBFH59Wtrqoi4jfEe03fCDeyIDvcSWvkgJA5jF uJhnCCE1yqtjyaBdBFnq9A3nqxbbCR8dhM9tyzWzQ+ce5OYoTQT4UbZvOyW3cMhppjDE 9r/w== MIME-Version: 1.0 X-Received: by 10.180.20.163 with SMTP id o3mr2234323wie.1.1379272414040; Sun, 15 Sep 2013 12:13:34 -0700 (PDT) Received: by 10.216.213.72 with HTTP; Sun, 15 Sep 2013 12:13:33 -0700 (PDT) In-Reply-To: <5235CFA0.4030902@joelhalpern.com> References: <5235CFA0.4030902@joelhalpern.com> Date: Sun, 15 Sep 2013 21:13:33 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Cc: "lisp@ietf.org" Subject: Re: [lisp] LCAF question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 19:13:50 -0000 On Sun, Sep 15, 2013 at 5:17 PM, Joel M. Halpern wrote: > 1) We need to be clear about which LCAFs can be used as EIDs, which as RLOC, > and which as both. If we're not clear it will lead to confusing later on, or no deployment because no one know what todo. Another scenario are that we get issue to get different vendors to talk with each other.... and some more issues. All in all, either should all LCAF work for all cases, or some indicator, or some sort of table to indicate what can work where. > Note that this is separate from the question of whether an ETR using a > complex LCAF RLOC can reasonably expect the ITR to understand it. Either way we need a clear understanding of how LCAF are to be understood by different part of the systems. > Comments, opinions, or rotten tomatoes? what about onions?;) -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From farinacci@gmail.com Sun Sep 15 20:53:53 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E7821F9AB4 for ; Sun, 15 Sep 2013 20:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9abgJhi8dMBu for ; Sun, 15 Sep 2013 20:53:52 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C10D521F9A6C for ; Sun, 15 Sep 2013 20:53:52 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id lb1so4858224pab.12 for ; Sun, 15 Sep 2013 20:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version; bh=vuzaNzg+z1864H/+M6ivvrFXZRaQd93cWWwyWEzvEms=; b=PxLCJcFlItFh7jdfzEldrTPfFFkLYWBneLrx2FFoOQFYgjUd1FHl0L2VqbuZ754F8b c99mCCdqlnsA7R3pU7srwwx90Fv+decOW/WUiF+GKtojs+COlkcVoTY6siCVCEnOkkw3 4e4e3nxWRaGMhzlk70i/dxgrmEcRiZyGFlfVkMBvBRIlgkHqUZLGJWdVLA+IVG7OlQll C+XtyguD/2u3nojKWtuf/mpOyD7VoiUbb6AvSbANiem/oNR20bjUILDQRtibfvFpA6yR hKYdMIa8s6jBYP9bMWHj9gyWxOuDnjP+7plw4w3O7SN16vqmFvKdcnydPxx2NX0XySaa HMvA== X-Received: by 10.68.196.138 with SMTP id im10mr787390pbc.127.1379303632458; Sun, 15 Sep 2013 20:53:52 -0700 (PDT) Received: from [10.0.1.2] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id sy10sm35197893pac.15.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 20:53:52 -0700 (PDT) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Sep 2013 20:53:51 -0700 References: <20130916034430.17965.56031.idtracker@ietfa.amsl.com> To: "lisp@ietf.org list" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [lisp] Fwd: I-D Action: draft-farinacci-lisp-rig-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 16 Sep 2013 03:53:53 -0000 Re-posting an expired draft. Dino Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-farinacci-lisp-rig-02.txt > Date: September 15, 2013 8:44:30 PM PDT > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : LISP-DDT Referral Internet Groper (RIG) > Author(s) : Dino Farinacci > Amit Jain > Isidor Kouvelas > Darrel Lewis > Filename : draft-farinacci-lisp-rig-02.txt > Pages : 17 > Date : 2013-09-14 >=20 > Abstract: > A simple tool called the LISP-DDT Referral Internet Groper or 'rig' > can be used to query the LISP-DDT hierarchy. This draft describes > how the 'rig' tool works. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farinacci-lisp-rig >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-farinacci-lisp-rig-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-farinacci-lisp-rig-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From farinacci@gmail.com Mon Sep 16 10:41:37 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E756021F8BCE for ; Mon, 16 Sep 2013 10:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-2.507, BAYES_50=0.001, HTML_COMMENT_SAVED_URL=0.114, HTML_MESSAGE=0.001, MANGLED_LIPS=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdJIcUmLuQCX for ; Mon, 16 Sep 2013 10:41:34 -0700 (PDT) Received: from mail-ye0-x230.google.com (mail-ye0-x230.google.com [IPv6:2607:f8b0:4002:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id D51D821F9D42 for ; Mon, 16 Sep 2013 10:41:26 -0700 (PDT) Received: by mail-ye0-f176.google.com with SMTP id m4so1832776yen.35 for ; Mon, 16 Sep 2013 10:41:25 -0700 (PDT) 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 :message-id:references:to; bh=L+2dEngn95+Ri9upIyZEPFa5r3rrZY4aAYYwqmoe5YM=; b=WP8CEqKfdAxfKv4dJsTe1fHboFs9NzouK+gzQ3PHlmeHIDu+PXX3UVrS5UFMWNJlF8 ZIF1oYLXid+rVqoRwDMkG5z5loRauEWAzHN4MJVfLNoJGYHZn7CZwkeiQNSq3ozslWom 9397J1GvOFiDIsD5x994hPMe6FKG3YtU+odSl3vzFlBhZ89CA1ZIj0sH4uYfWOQdk9oy X6iZrAiEzobHUFhcxhinl6OpdKLVTvB8/rFEkYshBTpCpXQ15JMhErHAGQgPJ7yDycG/ QOne0XrEU6bvdpSVvaGrjKwmbyYaD3cPJUF4QkQ71pLEPe7a1bITnV9/3uAhtUjxaNil ENzw== X-Received: by 10.236.130.52 with SMTP id j40mr1715665yhi.151.1379353285237; Mon, 16 Sep 2013 10:41:25 -0700 (PDT) Received: from [192.168.1.77] ([207.145.253.66]) by mx.google.com with ESMTPSA id r39sm39506157yhp.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Sep 2013 10:41:24 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_1364D4AE-1619-4753-A28D-10B3F189A5B6" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <5235CFA0.4030902@joelhalpern.com> Date: Mon, 16 Sep 2013 10:41:19 -0700 Message-Id: <8F4028ED-D913-4387-9D09-94A7EAB297EB@gmail.com> References: <5235CFA0.4030902@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1508) Cc: "lisp@ietf.org" Subject: Re: [lisp] LCAF question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 16 Sep 2013 17:41:38 -0000 --Apple-Mail=_1364D4AE-1619-4753-A28D-10B3F189A5B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > It seems to me that there are three related technical problems or = general concerns. >=20 > 1) We need to be clear about which LCAFs can be used as EIDs, which as = RLOC, and which as both. That is made clear in the LCAF draft but the companion document should = provide detail as to why. > 2) We need to be clear about how the mapping system is to support any = given LCAF as an EID. For Example, if one prohibits the IID mask length = then an IID + Address LCAF can be be supported by the mapping system as = a simple prefix. But, if we have to match on both IID prefixes and = Address prefixes then this requires more support from the mapping = system. An IID mask-length is only implemented by the nodes that do LISP-DDT. = Because they are delegating ranges of the instance-ID space to child = DDT-nodes (including a DDT-node enabled map-server). So the xTRs don't = need to worry about this. > 2a) Specifically, for any LCAF on which there can be multiple partial = matches we have to specify what "longest match" means. Does longer IID = trump longer Address? We have found cases where something like an IID is a bit-extension of an = address so you can do longest match when you concatenate the instance-ID = and the power-of-2 EID-prefix. We have found cases where an ordering is = necessary such as in a Multicast Info Type that can be encoded as = (S-prefix, G-prefix) as well as an Application Data Type that can be = encoded with all of (S-prefix, D-prefix, sport-range, dport-range). > 3) If we have LCAFs for EIDs which need support from the mapping = system then the EID needs to know what LCAFs the mapping system = supports. It seems likely that special-purpose cases will use separate = mapping systems tied to separate authorities. But how will the ETR that = is registering or the ITR that is asking know which mapping system = supports which set? Configuration seems a VERY bad answer. Well we do have this flexible message that xTRs send to a mapping system = called Info-Request and Info-Reply. So it could ask. > Note that this is separate from the question of whether an ETR using a = complex LCAF RLOC can reasonably expect the ITR to understand it. >=20 > Comments, opinions, or rotten tomatoes? So from public opinion and many private email exchanges, I am getting = the impression that the simple encoding of the Capabilities Type may not = be useful enough and that the more complex combinations are dependent on = the feature being implemented. So I would like to leave the Capabilities Type LCAF out of the -03 so we = can have more discussion.=20 Any objections if I publish what I posted last week. Here is the latest = diff. Dino --Apple-Mail=_1364D4AE-1619-4753-A28D-10B3F189A5B6 Content-Disposition: attachment; filename=rfcdiff-lisp-lcaf-02-to-03.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-lcaf-02-to-03.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-lcaf-02.txt draft-ietf-lisp-lcaf-03.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                  D. Meyer                                               lispers.net
Intended status: Experimental                              cisco Systems                                   D. Meyer
Expires: September 11, 2013 March 20, 2014                                          Brocade
                                                             J. Snijders
                                                            InTouch N.V.
                                                          March 10,
                                                       Hibernia Networks
                                                      September 16, 2013

                  LISP Canonical Address Format (LCAF)
                        draft-ietf-lisp-lcaf-02
                        draft-ietf-lisp-lcaf-03

Abstract

   This draft defines a canonical address format encoding used in LISP
   control messages and in the encoding of lookup keys for the LISP
   Mapping Database System.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 11, 2013. March 20, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  4
   3.  LISP Canonical Address Format Encodings  . . . . . . . . . . .  5
   4.  LISP Canonical Address Applications  . . . . . . . . . . . . .  7
     4.1.  Segmentation using LISP  . . . . . . . . . . . . . . . . .  7
     4.2.  Carrying AS Numbers in the Mapping Database  . . . . . . .  8
     4.3.  Convey Application Specific Data . . . . . . . . . . . . .  9
     4.4.  Assigning Geo Coordinates to Locator Addresses . . . . . . 10
     4.5.  Generic Database Mapping Lookups . . . . . . . . . . . . . 12
     4.6.  NAT Traversal Scenarios  . . . . . . . . . . . . . . . . . 13
     4.7.  PETR Admission Control Functionality . . . . . . . . . . . 15
     4.8.  Multicast Group Membership Information . . . . . . . . . . 16
     4.9.  Traffic Engineering using Re-encapsulating Tunnels . . . . 18
     4.10. Storing Security Data in the Mapping Database  . . . . . . 19
     4.11. Source/Destination 2-Tuple Lookups . . . . . . . . . . . . 20
     4.12. Replication List Entries for Multicast Forwarding  . . . . 21
     4.13. Data Model Encoding  . . . . . . . . . . . . . . . . . . . 22
     4.14. Encoding Key/Value Address Pairs . . . . . . . . . . . . . 23
     4.15. Applications for AFI List Type . . . . . . . . . . . . . . 22
       4.13.1. 24
       4.15.1.  Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 22
       4.13.2. 24
       4.15.2.  Layer-2 VPNs  . . . . . . . . . . . . . . . . . . . . 23
       4.13.3. 25
       4.15.3.  ASCII Names in the Mapping Database . . . . . . . . . 23
       4.13.4. 25
       4.15.4.  Using Recursive LISP Canonical Address Encodings  . . 24
       4.13.5. 26
       4.15.5.  Compatibility Mode Use Case . . . . . . . . . . . . . 25 27
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26 28
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27 29
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 30
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 28 30
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 28 30
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 30 32
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 31 33
     B.1.  Changes to draft-ietf-lisp-lcaf-02.txt draft-ietf-lisp-lcaf-03.txt . . . . . . . . . . 31 33
     B.2.  Changes to draft-ietf-lisp-lcaf-01.txt draft-ietf-lisp-lcaf-02.txt . . . . . . . . . . 31 33
     B.3.  Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . . 33
     B.4.  Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . . 31 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 34

1.  Introduction

   The LISP architecture and protocols [RFC6830] introduces two new
   numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators
   (RLOCs) which are intended to replace most use of IP addresses on the
   Internet.  To provide flexibility for current and future
   applications, these values can be encoded in LISP control messages
   using a general syntax that includes Address Family Identifier (AFI),
   length, and value fields.

   Currently defined AFIs include IPv4 and IPv6 addresses, which are
   formatted according to code-points assigned in [AFI] as follows:

   IPv4 Encoded Address:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 1            |       IPv4 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv4 Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Encoded Address:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 2            |       IPv6 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv6 Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This document describes the currently-defined AFIs the LISP protocol
   uses along with their encodings and introduces the LISP Canonical
   Address Format (LCAF) that can be used to define the LISP-specific
   encodings for arbitrary AFI values.

2.  Definition of Terms

   Address Family Identifier (AFI):  a term used to describe an address
      encoding in a packet.  An address family currently defined for
      IPv4 or IPv6 addresses.  See [AFI] and [RFC1700] for details.  The
      reserved AFI value of 0 is used in this specification to indicate
      an unspecified encoded address where the the length of the address
      is 0 bytes following the 16-bit AFI value of 0.

   Unspecified Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 0            |    <nothing follows AFI=0>    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source and destination address fields of the first
      (most inner) LISP header of a packet.  The host obtains a
      destination EID the same way it obtains a destination address
      today, for example through a DNS lookup or SIP exchange.  The
      source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an egress
      tunnel router (ETR).  It is the output of a EID-to-RLOC mapping
      lookup.  An EID maps to one or more RLOCs.  Typically, RLOCs are
      numbered from topologically aggregatable blocks that are assigned
      to a site at each point to which it attaches to the global
      Internet; where the topology is defined by the connectivity of
      provider networks, RLOCs can be thought of as PA addresses.
      Multiple RLOCs can be assigned to the same ETR device or to
      multiple ETR devices at a site.

3.  LISP Canonical Address Format Encodings

   IANA has assigned AFI value 16387 (0x4003) to the LISP architecture
   and protocols.  This specification defines the encoding format of the
   LISP Canonical Address (LCA).

   The first 4 bytes of an LISP Canonical Address are followed by a
   variable length of fields:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       |     Rsvd2     |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Rsvd1:  this 8-bit field is reserved for future use and MUST be
      transmitted as 0 and ignored on receipt.

   Flags:  this 8-bit field is for future definition and use.  For now,
      set to zero on transmission and ignored on receipt.

   Type:  this 8-bit field is specific to the LISP Canonical Address
      formatted encodings, values are:

     Type 0:  Null Body Type

     Type 1:  AFI List Type

     Type 2:  Instance ID Type

     Type 3:  AS Number Type

     Type 4:  Application Data Type

     Type 5:  Geo Coordinates Type

     Type 6:  Opaque Key Type

     Type 7:  NAT-Traversal Type

     Type 8:  Nonce Locator Type

     Type 9:  Multicast Info Type
     Type 10:  Explicit Locator Path Type

     Type 11:  Security Key Type

     Type 12:  Source/Dest Key Type

     Type 13:  Replication List Entry Type

     Type 14:  JSON Data Model Type

     Type 15:  Key/Value Address Pair Type

   Rsvd2:  this 8-bit field is reserved for future use and MUST be
      transmitted as 0 and ignored on receipt.

   Length:  this 16-bit field is in units of bytes and covers all of the
      LISP Canonical Address payload, starting and including the byte
      after the Length field.  So any LCAF encoded address will have a
      minimum length of 8 bytes when the Length field is 0.  The 8 bytes
      include the AFI, Flags, Type, Reserved, and Length fields.  When
      the AFI is not next to encoded address in a control message, then
      the encoded address will have a minimum length of 6 bytes when the
      Length field is 0.  The 6 bytes include the Flags, Type, Reserved,
      and Length fields.

4.  LISP Canonical Address Applications

4.1.  Segmentation using LISP

   When multiple organizations inside of a LISP site are using private
   addresses [RFC1918] as EID-prefixes, their address spaces must remain
   segregated due to possible address duplication.  An Instance ID in
   the address encoding can aid in making the entire AFI based address
   unique.

   Another use for the Instance ID LISP Canonical Address Format is when
   creating multiple segmented VPNs inside of a LISP site where keeping
   EID-prefix based subnets is desirable.

   Instance ID LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 2    | IID mask-len  |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Instance ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IID mask-len:  if the AFI is set to 0, then this format is not
      encoding an extended EID-prefix but rather an instance-ID range
      where the 'IID mask-len' indicates the number of high-order bits
      used in the Instance ID field for the range.

   Length value n:  length in bytes of the AFI address that follows the
      Instance ID field including the AFI field itself.

   Instance ID:  the low-order 24-bits that can go into a LISP data
      header when the I-bit is set.  See [RFC6830] for details.

   AFI = x:  x can be any AFI value from [AFI].

   This LISP Canonical Address Type can be used to encode either EID or
   RLOC addresses.

4.2.  Carrying AS Numbers in the Mapping Database

   When an AS number is stored in the LISP Mapping Database System for
   either policy or documentation reasons, it can be encoded in a LISP
   Canonical Address.

   AS Number LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 3    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           AS Number                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      AS Number field including the AFI field itself.

   AS Number:  the 32-bit AS number of the autonomous system that has
      been assigned either the EID or RLOC that follows.

   AFI = x:  x can be any AFI value from [AFI].

   The AS Number Canonical Address Type can be used to encode either EID
   or RLOC addresses.  The former is used to describe the LISP-ALT AS
   number the EID-prefix for the site is being carried for.  The latter
   is used to describe the AS that is carrying RLOC based prefixes in
   the underlying routing system.

4.3.  Convey Application Specific Data

   When a locator-set needs to be conveyed based on the type of
   application or the Per-Hop Behavior (PHB) of a packet, the
   Application Data Type can be used.

   Application Data LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 4    |     Rsvd2     |             8 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       IP TOS, IPv6 TC, or Flow Label          |    Protocol   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Local Port (lower-range)   |    Local Port (upper-range)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Remote Port (lower-range)   |   Remote Port (upper-range)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      8-byte Application Data fields including the AFI field itself.

   IP TOS, IPv6 TC, or Flow Label:  this field stores the 8-bit IPv4 TOS
      field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow
      Label used in an IPv6 header.

   Local Port/Remote Port: Port Ranges:  these fields are from the TCP, UDP,
      or SCTP transport header.  A range can be specified by using a
      lower value and an upper value.  When a single port is encoded,
      the lower and upper value fields are the same.

   AFI = x:  x can be any AFI value from [AFI].

   The Application Data Canonical Address Type is used for an EID
   encoding when an ITR wants a locator-set for a specific application.
   When used for an RLOC encoding, the ETR is supplying a locator-set
   for each specific application is has been configured to advertise.

4.4.  Assigning Geo Coordinates to Locator Addresses

   If an ETR desires to send a Map-Reply describing the Geo Coordinates
   for each locator in its locator-set, it can use the Geo Coordinate
   Type to convey physical location information.

   Coordinates are specified using the WGS-84 (World Geodetic System)
   reference coordinate system [WGS-84].

   Geo Coordinate LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 5    |     Rsvd2     |            12 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|     Latitude Degrees        |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |E|     Longitude Degrees       |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Altitude                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      8-byte Longitude and Latitude fields including the AFI field
      itself.

   N: When set to 1 means North, otherwise South.

   Latitude Degrees:  Valid values range from 0 to 90 degrees above or
      below the equator (northern or southern hemisphere, respectively).

   Latitude Minutes:  Valid values range from 0 to 59.

   Latitude Seconds:  Valid values range from 0 to 59.

   E: When set to 1 means East, otherwise West.

   Longitude Degrees:  Value values are from 0 to 180 degrees right or
      left of the Prime Meridian.

   Longitude Minutes:  Valid values range from 0 to 59.

   Longitude Seconds:  Valid values range from 0 to 59.

   Altitude:  Height relative to sea level in meters.  This is a signed
      integer meaning that the altitude could be below sea level.  A
      value of 0x7fffffff indicates no Altitude value is encoded.

   AFI = x:  x can be any AFI value from [AFI].

   The Geo Coordinates Canonical Address Type can be used to encode
   either EID or RLOC addresses.  When used for EID encodings, you can
   determine the physical location of an EID along with the topological
   location by observing the locator-set.

4.5.  Generic Database Mapping Lookups

   When the LISP Mapping Database system holds information accessed by a
   generic formatted key (where the key is not the usual IPv4 or IPv6
   address), an opaque key may be desirable.

   Opaque Key LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 6    |     Rsvd2     |               n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Key Field Num |      Key Wildcard Fields      |   Key . . .   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       . . . Key                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the type's payload.  The value n
      is the number of bytes that follow this Length field.

   Key Field Num:  the number of fields (minus 1) the key can be broken
      up into.  The width of the fields are fixed length.  So for a key
      size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2
      bytes in length.  Valid values for this field range from 0 to 15
      supporting a maximum of 16 field separations.

   Key Wildcard Fields:  describes which fields in the key are not used
      as part of the key lookup.  This wildcard encoding is a bitfield.
      Each bit is a don't-care bit for a corresponding field in the key.
      Bit 0 (the low-order bit) in this bitfield corresponds the first
      field, right-justified in the key, bit 1 the second field, and so
      on.  When a bit is set in the bitfield it is a don't-care bit and
      should not be considered as part of the database lookup.  When the
      entire 16-bits is set to 0, then all bits of the key are used for
      the database lookup.

   Key:  the variable length key used to do a LISP Database Mapping
      lookup.  The length of the key is the value n (shown above) minus
      3.

4.6.  NAT Traversal Scenarios

   When a LISP system is conveying global address and mapped port
   information when traversing through a NAT device, the NAT-Traversal
   LCAF Type is used.  See [LISP-NATT] for details.

   NAT-Traversal Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 7    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       MS UDP Port Number      |      ETR UDP Port Number      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |  Global ETR RLOC Address  ... |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       MS RLOC Address  ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          | Private ETR RLOC Address  ... |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |      RTR RLOC Address 1 ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |      RTR RLOC Address k ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI addresses that follows
      the UDP Port Number field including the AFI fields themselves.

   MS UDP Port Number:  this is the UDP port number of the Map-Server
      and is set to 4342.

   ETR UDP Port Number:  this is the port number returned to a LISP
      system which was copied from the source port from a packet that
      has flowed through a NAT device.

   AFI = x:  x can be any AFI value from [AFI].

   Global ETR RLOC Address:  this is an address known to be globally
      unique built by NAT-traversal functionality in a LISP router.

   MS RLOC Address:  this is the address of the Map-Server used in the
      destination RLOC of a packet that has flowed through a NAT device.

   Private ETR RLOC Address:  this is an address known to be a private
      address inserted in this LCAF format by a LISP router that resides
      on the private side of a NAT device.

   RTR RLOC Address:  this is an encapsulation address used by an ITR or
      PITR which resides behind a NAT device.  This address is known to
      have state in a NAT device so packets can flow from it to the LISP
      ETR behind the NAT.  There can be one or more NTR addresses
      supplied in these set of fields.  The number of NTRs encoded is
      determined by the LCAF length field.  When there are no NTRs
      supplied, the NTR fields can be omitted and reflected by the LCAF
      length field or an AFI of 0 can be used to indicate zero NTRs
      encoded.

4.7.  PETR Admission Control Functionality

   When a public PETR device wants to verify who is encapsulating to it,
   it can check for a specific nonce value in the LISP encapsulated
   packet.  To convey the nonce to admitted ITRs or PITRs, this LCAF
   format is used in a Map-Register or Map-Reply locator-record.

   Nonce Locator Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 8    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Reserved    |                  Nonce                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      Nonce field including the AFI field itself.

   Reserved:  must be set to zero and ignore on receipt.

   Nonce:  this is a nonce value returned by an ETR in a Map-Reply
      locator-record to be used by an ITR or PITR when encapsulating to
      the locator address encoded in the AFI field of this LCAF type.

   AFI = x:  x can be any AFI value from [AFI].

4.8.  Multicast Group Membership Information

   Multicast group information can be published in the mapping database
   so a lookup on an EID based group address can return a replication
   list of group addresses or a unicast addresses for single replication
   or multiple head-end replications.  The intent of this type of
   unicast replication is to deliver packets to multiple ETRs at
   receiver LISP multicast sites.  The locator-set encoding for this EID
   record type can be a list of ETRs when they each regsiter register with "Merge
   Semantics".  The encoding can be a typical AFI encoded locator
   address.  When an RTR list is being registered (with multiple levels
   acccording
   according to [LISP-RE]), the Replication List Entry LCAF type is used
   for locator encoding.

   This LCAF encoding can be used to send broadcast packets to all
   members of a subnet when each EIDs are away from their home subnet
   location.

   Multicast Info Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 9    |  Rsvd2  |R|L|J|             4             8 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Instance-ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved           | Source MaskLen| Group MaskLen |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |   Source/Subnet Address  ...  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Group Address  ...      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Reserved:  must be set to zero and ignore on receipt.

   R-bit:  this is the RP-bit that represents PIM (S,G,RP-bit) multicast
      state.  This bit can be set for Joins (when the J-bit is set) or
      for Leaves (when the L-bit is set).  See [LISP-MRSIG] for more
      usage details.

   L-bit:  this is the Leave-Request bit and is used when this LCAF type
      is present in the destination EID-prefix field of a Map-Request.
      See [LISP-MRSIG] for details.

   J-bit:  this is the Join-Request bit and is used when this LCAF type
      is present in the destination EID-prefix field of a Map-Request.
      See [LISP-MRSIG] for details.  The J-bit MUST not be set when the
      L-bit is also set in the same LCAF block.  A receiver should not
      take any specific Join or Leave action when both bits are set.

   Instance ID:  the low-order 24-bits that can go into a LISP data
      header when the I-bit is set.  See [RFC6830] for details.  The use
      of the Instance-ID in this LCAF type is to associate a multicast
      forwarding entry for a given VPN.  The instance-ID describes the
      VPN and is registered to the mapping database system as a 3-tuple
      of (Instance-ID, S-prefix, G-prefix).

   Source MaskLen:  the mask length of the source prefix that follows.

   Group MaskLen:  the mask length of the group prefix that follows.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

4.9.  Traffic Engineering using Re-encapsulating Tunnels

   For a given EID lookup into the mapping database, this LCAF format
   can be returned to provide a list of locators in an explicit re-
   encapsulation path.  See [LISP-TE] for details.

   Explicit Locator Path (ELP) Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 10   |     Rsvd2     |               n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           Rsvd3         |L|P|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reencap Hop 1  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           Rsvd3         |L|P|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reencap Hop k  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

   Lookup bit (L):  this is the Lookup bit used to indicate to the user
      of the ELP to not use this address for encapsulation but to look
      it up in the mapping database system to obtain an encapsulating
      RLOC address.

   RLOC-Probe bit (P):  this is the RLOC-probe bit which means the
      Reencap Hop allows RLOC-probe messages to be sent to it.  When the
      R-bit is set to 0, RLOC-probes must not be sent.  When a Reencap
      Hop is an anycast address then multiple physical Reencap Hops are
      using the same RLOC address.  In this case, RLOC-probes are not
      needed because when the closest RLOC address is not reachable
      another RLOC address can reachable.

   Strict bit (S):  this the strict bit which means the associated
      Rencap Hop is required to be used.  If this bit is 0, the
      reencapsulator can skip this Reencap Hop and go to the next one in
      the list.

4.10.  Storing Security Data in the Mapping Database

   When a locator in a locator-set has a security key associated with
   it, this LCAF format will be used to encode key material.  See
   [LISP-DDT] for details.

   Security Key Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 11   |      Rsvd2    |             6 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Key Count   |      Rsvd3    | Key Algorithm |   Rsvd4     |R|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Key Length          |       Key Material ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        ... Key Material                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Locator Address ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that start with the Key
      Material field.

   Key Count:  the Key Count field declares the number of Key sections
      included in this LCAF.

   Key Algorithm:  the Algorithm field identifies the key's
      cryptographic algorithm and specifies the format of the Public Key
      field.

   R bit:  this is the revoke bit and, if set, it specifies that this
      Key is being Revoked.

   Key Length:  this field determines the length in bytes of the Key
      Material field.

   Key Material:  the Key Material field stores the key material.  The
      format of the key material stored depends on the Key Algorithm
      field.

   AFI = x:  x can be any AFI value from [AFI].This is the locator
      address that owns the encoded security key.

4.11.  Source/Destination 2-Tuple Lookups

   When both a source and destination address of a flow needs
   consideration for different locator-sets, this 2-tuple key is used in
   EID fields in LISP control messages.  When the Source/Dest key is
   registered to the mapping database, it can be encoded as a source-
   prefix and destination-prefix.  When the Source/Dest is used as a key
   for a mapping database lookup the source and destination come from a
   data packet.

   Source/Dest Key Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 12   |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved           |   Source-ML   |    Dest-ML    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Source-Prefix ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |     Destination-Prefix ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Reserved:  must be set to zero and ignore on receipt.

   Source-ML:  the mask length of the source prefix that follows.

   Dest-ML:  the mask length of the destination prefix that follows.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

   Refer to [LISP-TE] for usage details.

4.12.  Replication List Entries for Multicast Forwarding

   The Replication List Entry LCAF type is an encoding for a locator
   being used for unicast replication according to the specification in
   [LISP-RE].  This locator encoding is pointed to by a Multicast Info
   LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs)
   that are participating in an overlay distribution tree.  Each RTR
   will register its locator address and its configured level in the
   distribution tree.

   Replication List Entry Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 13   |    Rsvd2      |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Rsvd3            |     Rsvd4     |  Level Value  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           RTR/ETR #1 ...      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Rsvd3            |     Rsvd4     |  Level Value  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           RTR/ETR  #n ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Rsvd{1,2,3,4}:  must be set to zero and ignore on receipt.

   Level Value:  this value is associated with the level of hierarchy within the RTR resides in an
      overlay distribution tree. tree hierarchy where the RTR resides.  The
      level numbers are ordered from lowest value being close to the ITR
      (meaning that ITRs replicate to level-0 RTRs) and higher levels
      are further downstream on the distribution tree closer to ETRs of
      multicast receiver sites.

   AFI = x:  x can be any AFI value from [AFI].  A specific AFI has its
      own encoding of either a unicast or multicast locator address.
      All RTR/ETR entries for the same level should be combined together
      by a Map-Server to avoid searching through the entire multi-level
      list of locator entries in a Map-Reply message.

4.13.  Applications for AFI List Type

4.13.1.  Binding IPv4 and IPv6 Addresses

   When header translation between IPv4 and IPv6 is desirable  Data Model Encoding

   This type allows a LISP
   Canonical Address can use the AFI List Type JSON data model to carry multiple AFIs in
   one LCA AFI.

   Bounded Address LISP Canonical be encoded either as an EID or
   RLOC.

   JSON Data Model Type Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1 14   |    Rsvd2    |B|               n               |         2 + 4 +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                JSON binary or text encoding ...               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Optional Address ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Rsvd{1,2}:  must be set to zero and ignore on receipt.

   B bit:  indicates that the JSON field is binary encoded according to
      [JSON-BINARY] when the bit is set to 1.  Otherwise the encoding is
      based on text encoding according to [RFC4627].

   JSON field:  a variable length field that contains either binary or
      text encodings.

   AFI = x:  x can be any AFI value from [AFI].  A specific AFI has its
      own encoding of either a unicast or multicast locator address.
      All RTR/ETR entries for the same level should be combined together
      by a Map-Server to avoid searching through the entire multi-level
      list of locator entries in a Map-Reply message.

4.14.  Encoding Key/Value Address Pairs

   The Key/Value pair is for example useful for attaching attributes to
   other elements of LISP packets, such as EIDs or RLOCs.  When
   attaching attributes to EIDs or RLOCs, it's necessary to distinguish
   between the element that should be used as EID or RLOC, and hence as
   key for lookups, and additional attributes.  This is especially the
   case when the difference cannot be determined from the types of the
   elements, such as when two IP addresses are being used.

   Key/Value Pair Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 15   |     Rsvd2     |               n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Address as Key(1) ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |     Address as Value(1) ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             . . .                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Address as Key(n) ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |     Address as Value(n) ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Rsvd{1,2}:  must be set to zero and ignore on receipt.

   AFI = x:  x can be any AFI value from [AFI].  A specific AFI has its
      own encoding of either a unicast or multicast locator address.
      All RTR/ETR entries for the same level should be combined together
      by a Map-Server to avoid searching through the entire multi-level
      list of locator entries in a Map-Reply message.

   Address as Key(1):  this AFI encoded address will be attached with
      the attributes encoded in "Address as Value(1)" which follows this
      field.

   Address as Value(1):  this AFI encoded address will be the attribute
      address that goes along with "Address as Key(1)" which precedes
      this field.  Multiple Key/Value pairs can be included in a single
      LCAF encoding.

4.15.  Applications for AFI List Type

4.15.1.  Binding IPv4 and IPv6 Addresses

   When header translation between IPv4 and IPv6 is desirable a LISP
   Canonical Address can use the AFI List Type to carry multiple AFIs in
   one LCAF AFI.

   Address Binding LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |         2 + 4 + 2 + 16        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 1            |       IPv4 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv4 Address         |            AFI = 2            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          IPv6 Address ...                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  length in bytes is fixed at 24 when IPv4 and IPv6 AFI
      encoded addresses are used.

   This type of address format can be included in a Map-Request when the
   address is being used as an EID, but the Mapping Database System
   lookup destination can use only the IPv4 address.  This is so a
   Mapping Database Service Transport System, such as LISP-ALT
   [RFC6836], can use the Map-Request destination address to route the
   control message to the desired LISP site.

4.13.2.

4.15.2.  Layer-2 VPNs

   When MAC addresses are stored in the LISP Mapping Database System,
   the AFI List Type can be used to carry AFI 6.

   MAC Address LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |             2 + 6             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             AFI = 6           |    Layer-2 MAC Address  ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    ... Layer-2 MAC Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  length in bytes is fixed at 8 when MAC address AFI encoded
      addresses are used.

   This address format can be used to connect layer-2 domains together
   using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN.
   In this use-case, a MAC address is being used as an EID, and the
   locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or
   even another MAC address being used as an RLOC.

4.13.3.

4.15.3.  ASCII Names in the Mapping Database

   If DNS names or URIs are stored in the LISP Mapping Database System,
   the AFI List Type can be used to carry an ASCII string where it is
   delimited by length 'n' of the LCAF Length encoding.

   ASCII LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |             2 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             AFI = 17          |      DNS Name or URI  ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes AFI=17 field and the null-terminated
      ASCII string (the last byte of 0 is included).

4.13.4.

4.15.4.  Using Recursive LISP Canonical Address Encodings

   When any combination of above is desirable, the AFI List Type value
   can be used to carry within the LCA LCAF AFI another LCA LCAF AFI.

   Recursive LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |         4 + 8 + 2 + 4         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 4    |     Rsvd2     |              12               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   IP TOS, IPv6 QQS or Flow Label              |    Protocol   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Local Port          |         Remote Port           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 1            |       IPv4 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv4 Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  length in bytes is fixed at 18 when an AFI=1 IPv4 address is
      included.

   This format could be used by a Mapping Database Transport System,
   such as LISP-ALT [RFC6836], where the AFI=1 IPv4 address is used as
   an EID and placed in the Map-Request destination address by the
   sending LISP system.  The ALT system can deliver the Map-Request to
   the LISP destination site independent of the Application Data Type
   AFI payload values.  When this AFI is processed by the destination
   LISP site, it can return different locator-sets based on the type of
   application or level of service that is being requested.

4.13.5.

4.15.5.  Compatibility Mode Use Case

   A LISP system should use the AFI List Type format when sending to
   LISP systems that do not support a particular LCAF Type used to
   encode locators.  This allows the receiving system to be able to
   parse a locator address for encapsulation purposes.  The list of AFIs
   in an AFI List LCAF Type has no semantic ordering and a receiver
   should parse each AFI element no matter what the ordering.

   Compatibility Mode Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |            22 + 6             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 5    |     Rsvd2     |            12 + 2             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|     Latitude Degrees        |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |E|     Longitude Degrees       |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Altitude                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = 0          |           AFI = 1             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          IPv4 Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If a system does not recognized the Geo Coordinate LCAF Type that is
   accompanying a locator address, an encoder can include the Geo
   Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI
   in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in
   the list is encoded with a valid AFI value to identify the locator
   address.

   A LISP system is required to support the AFI List LCAF Type to use
   this procedure.  It would skip over 10 bytes of the Geo Coordinate
   LCAF Type to get to the locator address encoding (an IPv4 locator
   address).  A LISP system that does support the Geo Coordinate LCAF
   Type can support parsing the locator address within the Geo
   Coordinate LCAF encoding or in the locator encoding that follows in
   the AFI List LCAF.

5.  Security Considerations

   There are no security considerations for this specification.  The
   security considerations are documented for the protocols that use
   LISP Canonical Addressing.  Refer to the those relevant
   specifications.

6.  IANA Considerations

   The Address Family AFI definitions from [AFI] only allocate code-
   points for the AFI value itself.  The length of the address or entity
   that follows is not defined and is implied based on conventional
   experience.  Where the LISP protocol uses LISP Canonical Addresses
   specifically, the address length definitions will be in this
   specification and take precedent over any other specification.

   An IANA Registry for LCAF Type values will be created.  The values
   that are considered for use by the main LISP specification [RFC6830]
   will be in the IANA Registry.  Other Type values used for
   experimentation will be defined and described in this document.

7.  References

7.1.  Normative References

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              January 2013.

   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol Alternative Logical
              Topology (LISP+ALT)", RFC 6836, January 2013.

7.2.  Informative References

   [AFI]      IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/numbers.html, Febuary 2007.

   [JSON-BINARY]
              "Universal Binary JSON Specification",
              URL http://ubjson.org.

   [LISP-DDT]
              Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated
              Database Tree", draft-fuller-lisp-ddt-01.txt draft-ietf-lisp-ddt-01.txt (work in
              progress).

   [LISP-MRSIG]
              Farinacci, D. and M. Napierala, "LISP Control-Plane
              Multicast Signaling",
              draft-farinacci-lisp-mr-signaling-00.txt
              draft-farinacci-lisp-mr-signaling-03.txt (work in
              progress).

   [LISP-NATT]
              Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
              F., and C. White, "NAT traversal for LISP",
              draft-ermagan-lisp-nat-traversal-00.txt
              draft-ermagan-lisp-nat-traversal-03.txt (work in
              progress).

   [LISP-RE]  Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
              Maino, F., and D. Farinacci, "LISP Replication
              Engineering", draft-coras-lisp-re-02.txt draft-coras-lisp-re-03.txt (work in
              progress).

   [LISP-TE]  Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic
              Engineering Use-Cases", draft-farinacci-lisp-te-01.txt draft-farinacci-lisp-te-03.txt
              (work in progress).

   [WGS-84]   Geodesy and Geophysics Department, DoD., "World Geodetic
              System 1984", NIMA TR8350.2, January 2000, <http://
              earth-info.nga.mil/GandG/publications/tr8350.2/
              wgs84fin.pdf>.

Appendix A.  Acknowledgments

   The authors would like to thank Vince Fuller, Gregg Schudel, Jesper
   Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for
   their technical and editorial commentary.

   The authors would like to thank Victor Moreno for discussions that
   lead to the definition of the Multicast Info LCAF type.

   The authors would like to thank Parantap Lahiri and Michael Kowal for
   discussions that lead to the definition of the Explicit Locator Path
   (ELP) LCAF type.

   The authors would like to thank Fabio Maino and Vina Ermagan for
   discussions that lead to the definition of the Security Key LCAF
   type.

   The authors would like to thank Albert Cabellos-Aparicio and Florin
   Coras for discussions that lead to the definition of the Replication
   List Entry LCAF type.

   Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for
   suggesting new LCAF types.

   Thanks also goes to Terry Manderson for assistance obtaining a LISP
   AFI value from IANA.

Appendix B.  Document Change Log

B.1.  Changes to draft-ietf-lisp-lcaf-03.txt

   o  Submitted September 2013.

   o  Updated references and author's affilations.

   o  Added Instance-ID to the Multicast Info Type so there is relative
      ease in parsing (S,G) entries within a VPN.

   o  Add port range encodings to the Application Data LCAF Type.

   o  Add a new JSON LCAF Type.

   o  Add Address Key/Value LCAF Type to allow attributes to be attached
      to an address.

B.2.  Changes to draft-ietf-lisp-lcaf-02.txt

   o  Submitted March 2013.

   o  Added new LCAF Type "Replication List Entry" to support LISP
      replication engineering use-cases.

   o  Changed references to new LISP RFCs.

B.2.

B.3.  Changes to draft-ietf-lisp-lcaf-01.txt

   o  Submitted January 2013.

   o  Change longitude range from 0-90 to 0-180 in section 4.4.

   o  Added reference to WGS-84 in section 4.4.

B.3.

B.4.  Changes to draft-ietf-lisp-lcaf-00.txt

   o  Posted first working group draft August 2012.

   o  This draft was renamed from draft-farinacci-lisp-lcaf-10.txt.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   lispers.net
   San Jose, CA  95134
   USA

   Email: farinacci@gmail.com

   Dave Meyer
   cisco Systems
   170 Tasman Drive
   Brocade
   San Jose, CA
   USA

   Email: dmm@cisco.com dmm@1-4-5.net

   Job Snijders
   InTouch N.V.
   Middenweg 76
   1097 BS Amsterdam
   The Netherlands
   Hibernia Networks
   Tupolevlaan 103a
   Schiphol-Rijk,   1119 PA
   NL

   Email: job@instituut.net job.snijders@hibernianetworks.com
--Apple-Mail=_1364D4AE-1619-4753-A28D-10B3F189A5B6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > > Yours, > Joel M. Halpern > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_1364D4AE-1619-4753-A28D-10B3F189A5B6-- From internet-drafts@ietf.org Mon Sep 16 15:38:52 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DD011E812F; Mon, 16 Sep 2013 15:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5t6ssSEqNlT; Mon, 16 Sep 2013 15:38:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E79021F9FCA; Mon, 16 Sep 2013 15:38:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130916223852.28803.15358.idtracker@ietfa.amsl.com> Date: Mon, 16 Sep 2013 15:38:52 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-lcaf-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: 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, 16 Sep 2013 22:38:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : LISP Canonical Address Format (LCAF) Author(s) : Dino Farinacci Dave Meyer Job Snijders Filename : draft-ietf-lisp-lcaf-03.txt Pages : 34 Date : 2013-09-16 Abstract: This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-lcaf-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-lcaf-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sander@steffann.nl Mon Sep 16 23:15:35 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D58711E836A for ; Mon, 16 Sep 2013 23:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjybgMhoMbVo for ; Mon, 16 Sep 2013 23:15:35 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 4F15411E8370 for ; Mon, 16 Sep 2013 23:15:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 4B55C3A; Tue, 17 Sep 2013 08:15:29 +0200 (CEST) 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 10024) with ESMTP id YyInpxTEmMdi; Tue, 17 Sep 2013 08:15:27 +0200 (CEST) Received: from [192.168.88.190] (unknown [192.168.88.190]) by mail.sintact.nl (Postfix) with ESMTPSA id 99DEE38; Tue, 17 Sep 2013 08:15:26 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Sander Steffann In-Reply-To: <8F4028ED-D913-4387-9D09-94A7EAB297EB@gmail.com> Date: Tue, 17 Sep 2013 09:15:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4E65C5D1-00E0-49AD-A07B-27B35D032D19@steffann.nl> References: <5235CFA0.4030902@joelhalpern.com> <8F4028ED-D913-4387-9D09-94A7EAB297EB@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1508) Cc: "lisp@ietf.org" Subject: Re: [lisp] LCAF question X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 17 Sep 2013 06:15:35 -0000 Hi Dino, > So I would like to leave the Capabilities Type LCAF out of the -03 so = we can have more discussion.=20 Agree, Sander] From jmh@joelhalpern.com Wed Sep 18 04:29:27 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D421B11E8236 for ; Wed, 18 Sep 2013 04:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XiP8TGhGIKl for ; Wed, 18 Sep 2013 04:29:22 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 1C28911E822C for ; Wed, 18 Sep 2013 04:29:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 0CCCF1C00E93 for ; Wed, 18 Sep 2013 04:29:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 979411C00E92 for ; Wed, 18 Sep 2013 04:29:21 -0700 (PDT) Message-ID: <52398E91.1050705@joelhalpern.com> Date: Wed, 18 Sep 2013 07:29:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "lisp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] WG Scheduling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 18 Sep 2013 11:29:27 -0000 I have submitted a request for scheduling the working group session. I have requested one slot of 2 hours. The conflict list I gave it is: Conflicts to Avoid: First Priority: rtgwg karp nvo3 i2rs sidr nsc iprbis grow Second Priority: forces intarea If there are other important conflicts, please contact me or Terry with comments. Note that scheduling IETF WG sessions is quite messy, so we only list conflicts that are really critical. Yorus, Joel PS: I thought I had done this two weeks abo, but apparently I forgot a step. From jmh@joelhalpern.com Fri Sep 20 10:44:26 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65DD21F96ED for ; Fri, 20 Sep 2013 10:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mou3W1muPWSX for ; Fri, 20 Sep 2013 10:44:22 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 33E0221F9642 for ; Fri, 20 Sep 2013 10:44:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 245381C069A for ; Fri, 20 Sep 2013 10:44:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9B49A1C068A for ; Fri, 20 Sep 2013 10:44:21 -0700 (PDT) Message-ID: <523C8975.3050003@joelhalpern.com> Date: Fri, 20 Sep 2013 13:44:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "lisp@ietf.org" References: <523C887B.308@cisco.com> In-Reply-To: <523C887B.308@cisco.com> X-Forwarded-Message-Id: <523C887B.308@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [lisp] Fwd: Re: LISP Interim X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 20 Sep 2013 17:44:27 -0000 Here is the webex and venue procedures. See folks on the 3rd. Yours, Joel -------- Original Message -------- Subject: Re: LISP Interim Date: Fri, 20 Sep 2013 10:40:11 -0700 From: Fabio Maino To: Joel M. Halpern CC: Terry Manderson Hi there, once in the lobby people can call me at 408 332 9024, and I'll pick them up. I'll have temporary badge ready for those that RSVPd. Webex info for thursday and friday: THURSDAY ======= Topic: LISP WG Interim Date: Thursday, October 3, 2013 Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 202 554 736 Meeting Password: lisp Host Key: 378028 (use this to reclaim host privileges) ------------------------------------------------------- To start the online meeting ------------------------------------------------------- 1. Go to https://cisco.webex.com/cisco/j.php?ED=235837812&UID=484339687&PW=NZjRjNzE5YjQ2&RT=MiM0 2. Log in to your account. 3. Click "Start Now". 4. Follow the instructions that appear on your screen. FRIDAY ===== Topic: LISP WG Interim Date: Friday, October 4, 2013 Time: 5:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 206 145 606 Meeting Password: lisp Host Key: 264402 (use this to reclaim host privileges) ------------------------------------------------------- To start the online meeting ------------------------------------------------------- 1. Go to https://cisco.webex.com/cisco/j.php?ED=235837932&UID=484339687&PW=NNzljOTBmNTAz&RT=MiM0 2. Log in to your account. 3. Click "Start Now". 4. Follow the instructions that appear on your screen. ---------------------------------------------------------------- ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/cisco/mc 2. On the left navigation bar, click "Support". To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://cisco.webex.com/cisco/j.php?ED=235837812&UID=484339687&ICS=MS&LD=1&RD=2&SHA2=AAAAAu9x/ImnHNvzEl1jC5P6RJAfxAzL5qMtneiDDO/ymndP&ST=1 To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://cisco.webex.com/cisco/systemdiagnosis.php. http://www.webex.com On 9/19/13 10:56 AM, Joel M. Halpern wrote: > Thanks again for hosting the LISP interim. > A couple of more specific questions: > 1) Who should we ask for, or what room, when we get there on October > 3? You? > > And can you provide us with the webex details so we can circulate > those to the list? > > Thank you, > Joel From fmaino@cisco.com Mon Sep 23 14:31:41 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4928D21F9E68 for ; Mon, 23 Sep 2013 14:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyTkGgAwpu4T for ; Mon, 23 Sep 2013 14:31:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id ACB0D21F9E52 for ; Mon, 23 Sep 2013 14:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4929; q=dns/txt; s=iport; t=1379971896; x=1381181496; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=x/Ryukj5kqYcS9bsVGg00hn/V+2d21ggdC9ZPf9doXM=; b=ddrptozQ8Rw3Tw5cxPG3ID6R2EZz4OQsySsuHRUn+egzntVCLiyUVR3d gj/D/xtWL0Ri7fF9YtZ7Ro5NsqLFOQ5+FY3f8/OwfbXQI37EnhHO6GEcQ KDT51Gxeh+sBKpZY3sSh7A9em+mKEt62YQGf9XHHxl8LYeYYu97EGbSvd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAKyyQFKQ/khR/2dsb2JhbAA/FwODBzjBe4EjFnSCJQEBAQQBAQEbFAEFEA0RCAoNBAsRAwECAQkLAQMHBQoJAwIBAgEVKAcBAxAGAgEBiAEMNq1GEY4Njjd7IxcGBAcHhAYDiTiORIEvhQOLRYJSchyBLAkXBIEX X-IronPort-AV: E=Sophos;i="4.90,965,1371081600"; d="scan'208";a="159923787" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 23 Sep 2013 21:31:11 +0000 Received: from [10.61.168.27] ([10.61.168.27]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8NLV9ER006172 for ; Mon, 23 Sep 2013 21:31:09 GMT Message-ID: <5240B31D.2050203@cisco.com> Date: Mon, 23 Sep 2013 14:31:09 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: lisp@ietf.org References: <523C887B.308@cisco.com> <523C8975.3050003@joelhalpern.com> In-Reply-To: <523C8975.3050003@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [lisp] Fwd: Re: LISP Interim X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 23 Sep 2013 21:31:41 -0000 This is the list of on-site attendees that I've got so far. If you plan to attend in person, and you're not listed below please unicast me: Sharon Barkai Noel Chiappa Dino Farinacci Joel Halpern Ed Lopez Fabio Maino Terry Manderson Damien Saucez For those who plan to attend remotely, webex info are below. Regards, Fabio On 9/20/13 10:44 AM, Joel M. Halpern wrote: > Here is the webex and venue procedures. > See folks on the 3rd. > > Yours, > Joel > > > -------- Original Message -------- > Subject: Re: LISP Interim > Date: Fri, 20 Sep 2013 10:40:11 -0700 > From: Fabio Maino > To: Joel M. Halpern > CC: Terry Manderson > > Hi there, > once in the lobby people can call me at 408 332 9024, and I'll pick them > up. I'll have temporary badge ready for those that RSVPd. > > Webex info for thursday and friday: > > THURSDAY > ======= > Topic: LISP WG Interim > Date: Thursday, October 3, 2013 > Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) > Meeting Number: 202 554 736 > Meeting Password: lisp > Host Key: 378028 (use this to reclaim host privileges) > > ------------------------------------------------------- > To start the online meeting > ------------------------------------------------------- > 1. Go to > https://cisco.webex.com/cisco/j.php?ED=235837812&UID=484339687&PW=NZjRjNzE5YjQ2&RT=MiM0 > > 2. Log in to your account. > 3. Click "Start Now". > 4. Follow the instructions that appear on your screen. > > > > > FRIDAY > ===== > Topic: LISP WG Interim > Date: Friday, October 4, 2013 > Time: 5:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) > Meeting Number: 206 145 606 > Meeting Password: lisp > Host Key: 264402 (use this to reclaim host privileges) > > ------------------------------------------------------- > To start the online meeting > ------------------------------------------------------- > 1. Go to > https://cisco.webex.com/cisco/j.php?ED=235837932&UID=484339687&PW=NNzljOTBmNTAz&RT=MiM0 > > 2. Log in to your account. > 3. Click "Start Now". > 4. Follow the instructions that appear on your screen. > > > > > > ---------------------------------------------------------------- > ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE > (408) OR (919) AREA CODES > ---------------------------------------------------------------- > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 > Dialing the WebEx toll free numbers from within 408 or 919 area codes is > not enabled (non-Cisco phones). “ If you dial the toll-free numbers > within the 408 or 919 area codes you will be instructed to hang up and > dial the local access number.” Please use the call-back option whenever > possible and otherwise dial local numbers only. The affected toll free > numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) > 349-3520 for the RTP area. > > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or > Access Code followed by the # sign. > > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > > India: +91.80.4350.1111 Germany: +49.619.6773.9002 > > Japan: +81.3.5763.9394 China: +86.10.8515.5666 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://cisco.webex.com/cisco/mc > 2. On the left navigation bar, click "Support". > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://cisco.webex.com/cisco/j.php?ED=235837812&UID=484339687&ICS=MS&LD=1&RD=2&SHA2=AAAAAu9x/ImnHNvzEl1jC5P6RJAfxAzL5qMtneiDDO/ymndP&ST=1 > > > To check whether you have the appropriate players installed for UCF > (Universal Communications Format) rich media files, go to > https://cisco.webex.com/cisco/systemdiagnosis.php. > > http://www.webex.com > > > > > > > On 9/19/13 10:56 AM, Joel M. Halpern wrote: >> Thanks again for hosting the LISP interim. >> A couple of more specific questions: >> 1) Who should we ask for, or what room, when we get there on October >> 3? You? >> >> And can you provide us with the webex details so we can circulate >> those to the list? >> >> Thank you, >> Joel > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Tue Sep 24 08:07:18 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438C311E815B; Tue, 24 Sep 2013 08:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E26-UAZ2HYrK; Tue, 24 Sep 2013 08:07:14 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAED11E8156; Tue, 24 Sep 2013 08:07:14 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B45F118C094; Tue, 24 Sep 2013 11:07:10 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130924150710.B45F118C094@mercury.lcs.mit.edu> Date: Tue, 24 Sep 2013 11:07:10 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: nvo3@ietf.org, jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 24 Sep 2013 15:07:18 -0000 {This is mostly to the LISP WG; NVO3 - which I candidly admit to knowing almost nothing about, but which I justt joined - may or may not care. Sorry this goes on for a bit, but this is important. I hope people will take the time to read it - it's not _that_ long.} > From: Dino Farinacci > the P-bit is being proposed for LISP. For those who missed what this was all about (I sure did), there is a new ID: http://tools.ietf.org/html/draft-lewis-lisp-gpe-00 "LISP Generic Protocol Extension" As a personal ID, this ID was not automagically announced to the LISP WG; I only happened to just see it when I was updating the LISP bibliography this weekend. May I suggest that in the future, anyone posting a personal draft _send a message to the WG_ - for people who are not subscibed to the full ID announcement feed (I'm not, it's way too much traffic, 97% of which I don't care about); otherwise, many people will have no idea that it's there. Even better, run the basic idea through the WG _before_ you write the draft; it may have a major flaw (as this one, I believe, does), or it may be a direction we just don't want to go (in which case there's no use putting in the effort to write an ID). To briefly let people know what this is about, it allows carriage of non-IP packets in LISP. This, I think, is basically a very good idea. However, the particular proposal in this ID is, IMO, very badly flawed. It proposes to take over the field used to carry i) the nonce (for neighbour xTR reachability detection), and ii) the version of the mapping entry, and use that field to carry the Ethertype. Obviously, then, since one _cannot_ carry a non-IP packet without making it _impossible_ to perform either of these functions: if only non-IP traffic is being carried over a particular link, these two (important, IMO) control functions will be _permanently_ disabled. I don't believe this is acceptable. >> From: Lucy yong >> Regarding to the protocol evolution, does this mean that >> nonce/map-version features in LISP will be deprecated? >> IMO: Having the same field overloaded for many differen[t] purposes >> is not good way for the protocol evolution, it becomes messy. Yes and no. The engineering analysis on this sort of thing is subtle. With a limited length header, if you have several control functions that do not need to be applied _on every packet_, I think it's reasonable to share a field between them. One does have to carefully look at the functions to decide if they really are things that one doesn't have to do on every packet. The thing is that putting a separate field in for every possible function will make the header a lot longer, which will have an impact on overhead (somewhat problematic), and also MTU (even more problematic, especially if MTU Discovery is not working properly). I am given to understand that a number of organizations have hardware which looks at the first two 32-bit words, so unfortunately making the header longer is not available as a _short-term_ answer. (Although I think we're just about reaching the limits of what we can cram into a 2-word header, so it's probably time to start thinking about a longer one.) > It means that the features need to be traded off. So the > market/user-base will decide what it wants to use that field for. I have to tell you that I just about fell off my chair when I realized what you were saying here. I don't believe that is professionally acceptable to force users to chose between i) carrying non-IP traffic, and ii) having some important control functions available. I understand that in the real world there are constraints, so we can't necessarily 'clean sheet of paper' the answer; but at the same time, surely it is not beyond our wit to find an answer that doesn't force users into making that choice. I have some ideas on what to do here (technically), but before I launch into them I would like to hear if the WG agrees with me that this 'tradeoff' is unacceptable. Because, clearly, if the WG is happy with this, there's no point in my bringing up alternatives. Noel From farinacci@gmail.com Tue Sep 24 08:13:58 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B5911E815B; Tue, 24 Sep 2013 08:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie+kF4ptXzYf; Tue, 24 Sep 2013 08:13:57 -0700 (PDT) Received: from mail-ye0-x22c.google.com (mail-ye0-x22c.google.com [IPv6:2607:f8b0:4002:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 89E9511E8159; Tue, 24 Sep 2013 08:13:57 -0700 (PDT) Received: by mail-ye0-f172.google.com with SMTP id m12so1775588yen.3 for ; Tue, 24 Sep 2013 08:13:57 -0700 (PDT) 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=arn+nHESOyRDXeeScaUad70JZYnFAer5i45vbOiftqc=; b=x8z6ZKcPvtnOSnOqt4W/JwR8BiAKQbb6rAMKT/ontWmNg0lTrNz/nMtOzKGuYWhl/U gLXaQSH1V89JWSkLNemCGkUgkUjNeZsJoqoz5K2+ngIU0r7Teh4EkYcobPya1J/9DGnI OwAhyFQHFVc7ZPubEGda5wOtHpb47pTGs/pRgeNAFSZZfb/rF5beoXp4Z7Qunj0U3lWi jtXqepILX+x3pfFbBMXIkQTvOqnvpXXzWpKd41463tfIoVBKIOhGS177LbFVkf4sL6NI 1c4yH8fDSgbEwKrNpbMEKdGDv0Himb1Z0AD8FSoqPNbIGgIb8Y+QPs4lMRz/3cyO4+Gq kwbA== X-Received: by 10.236.89.71 with SMTP id b47mr1586544yhf.83.1380035637007; Tue, 24 Sep 2013 08:13:57 -0700 (PDT) Received: from [192.168.5.128] (ip-64-134-222-24.public.wayport.net. [64.134.222.24]) by mx.google.com with ESMTPSA id g25sm45109973yhg.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 08:13:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dino Farinacci In-Reply-To: <20130924150710.B45F118C094@mercury.lcs.mit.edu> Date: Tue, 24 Sep 2013 08:13:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <03BB71ED-C05D-4421-8A0F-930EAEB6EFAE@gmail.com> References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.1510) Cc: nvo3@ietf.org, lisp@ietf.org Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 24 Sep 2013 15:13:58 -0000 For what's it worth (and for the record), I would not tradeoff the nonce = for a protocol-ID. The data-plane features in LISP are far more = important IMO then a protocol demux field we may never need to use. Dino On Sep 24, 2013, at 8:07 AM, jnc@mercury.lcs.mit.edu (Noel Chiappa) = wrote: > {This is mostly to the LISP WG; NVO3 - which I candidly admit to = knowing > almost nothing about, but which I justt joined - may or may not care. = Sorry > this goes on for a bit, but this is important. I hope people will take = the > time to read it - it's not _that_ long.} >=20 >=20 >> From: Dino Farinacci >=20 >> the P-bit is being proposed for LISP. >=20 > For those who missed what this was all about (I sure did), there is a = new ID: >=20 > http://tools.ietf.org/html/draft-lewis-lisp-gpe-00 > "LISP Generic Protocol Extension" >=20 > As a personal ID, this ID was not automagically announced to the LISP = WG; I > only happened to just see it when I was updating the LISP bibliography = this > weekend. >=20 > May I suggest that in the future, anyone posting a personal draft = _send a > message to the WG_ - for people who are not subscibed to the full ID > announcement feed (I'm not, it's way too much traffic, 97% of which I = don't > care about); otherwise, many people will have no idea that it's there. >=20 > Even better, run the basic idea through the WG _before_ you write the = draft; > it may have a major flaw (as this one, I believe, does), or it may be = a > direction we just don't want to go (in which case there's no use = putting in > the effort to write an ID). >=20 >=20 > To briefly let people know what this is about, it allows carriage of = non-IP > packets in LISP. This, I think, is basically a very good idea. >=20 > However, the particular proposal in this ID is, IMO, very badly = flawed. It > proposes to take over the field used to carry i) the nonce (for = neighbour xTR > reachability detection), and ii) the version of the mapping entry, and = use > that field to carry the Ethertype. >=20 > Obviously, then, since one _cannot_ carry a non-IP packet without = making it > _impossible_ to perform either of these functions: if only non-IP = traffic is > being carried over a particular link, these two (important, IMO) = control > functions will be _permanently_ disabled. >=20 > I don't believe this is acceptable. >=20 >=20 >>> From: Lucy yong >=20 >>> Regarding to the protocol evolution, does this mean that >>> nonce/map-version features in LISP will be deprecated? >>> IMO: Having the same field overloaded for many differen[t] purposes >>> is not good way for the protocol evolution, it becomes messy. >=20 > Yes and no. The engineering analysis on this sort of thing is subtle. >=20 > With a limited length header, if you have several control functions = that do > not need to be applied _on every packet_, I think it's reasonable to = share a > field between them. One does have to carefully look at the functions = to > decide if they really are things that one doesn't have to do on every = packet. >=20 > The thing is that putting a separate field in for every possible = function > will make the header a lot longer, which will have an impact on = overhead > (somewhat problematic), and also MTU (even more problematic, = especially if > MTU Discovery is not working properly). >=20 > I am given to understand that a number of organizations have hardware = which > looks at the first two 32-bit words, so unfortunately making the = header longer > is not available as a _short-term_ answer. >=20 > (Although I think we're just about reaching the limits of what we can = cram > into a 2-word header, so it's probably time to start thinking about a = longer > one.) >=20 >=20 >> It means that the features need to be traded off. So the >> market/user-base will decide what it wants to use that field for. >=20 > I have to tell you that I just about fell off my chair when I realized > what you were saying here. >=20 > I don't believe that is professionally acceptable to force users to = chose > between i) carrying non-IP traffic, and ii) having some important = control > functions available. >=20 > I understand that in the real world there are constraints, so we can't > necessarily 'clean sheet of paper' the answer; but at the same time, = surely it > is not beyond our wit to find an answer that doesn't force users into = making > that choice. >=20 >=20 > I have some ideas on what to do here (technically), but before I = launch into > them I would like to hear if the WG agrees with me that this = 'tradeoff' is > unacceptable. >=20 > Because, clearly, if the WG is happy with this, there's no point in my > bringing up alternatives. >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From lucy.yong@huawei.com Tue Sep 24 08:20:27 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD3C11E8147; Tue, 24 Sep 2013 08:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghXuWQ1iGqsI; Tue, 24 Sep 2013 08:20:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C676C11E8139; Tue, 24 Sep 2013 08:20:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYE90295; Tue, 24 Sep 2013 15:20:20 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 24 Sep 2013 16:19:10 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 24 Sep 2013 16:19:55 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Tue, 24 Sep 2013 08:19:48 -0700 From: Lucy yong To: Dino Farinacci , Noel Chiappa Thread-Topic: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt Thread-Index: AQHOuTi8w5pwSVEYQ0qg6kqZJksbCJnVAG4Q Date: Tue, 24 Sep 2013 15:19:47 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D14F6@dfweml509-mbx.china.huawei.com> References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> <03BB71ED-C05D-4421-8A0F-930EAEB6EFAE@gmail.com> In-Reply-To: <03BB71ED-C05D-4421-8A0F-930EAEB6EFAE@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 24 Sep 2013 15:20:28 -0000 +1. LISP is the LISP. Lucy -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Din= o Farinacci Sent: Tuesday, September 24, 2013 10:14 AM To: Noel Chiappa Cc: nvo3@ietf.org; lisp@ietf.org Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-g= pe-00.txt For what's it worth (and for the record), I would not tradeoff the nonce fo= r a protocol-ID. The data-plane features in LISP are far more important IMO= then a protocol demux field we may never need to use. Dino On Sep 24, 2013, at 8:07 AM, jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote: > {This is mostly to the LISP WG; NVO3 - which I candidly admit to=20 > knowing almost nothing about, but which I justt joined - may or may=20 > not care. Sorry this goes on for a bit, but this is important. I hope=20 > people will take the time to read it - it's not _that_ long.} >=20 >=20 >> From: Dino Farinacci >=20 >> the P-bit is being proposed for LISP. >=20 > For those who missed what this was all about (I sure did), there is a new= ID: >=20 > http://tools.ietf.org/html/draft-lewis-lisp-gpe-00 > "LISP Generic Protocol Extension" >=20 > As a personal ID, this ID was not automagically announced to the LISP=20 > WG; I only happened to just see it when I was updating the LISP=20 > bibliography this weekend. >=20 > May I suggest that in the future, anyone posting a personal draft=20 > _send a message to the WG_ - for people who are not subscibed to the=20 > full ID announcement feed (I'm not, it's way too much traffic, 97% of=20 > which I don't care about); otherwise, many people will have no idea that = it's there. >=20 > Even better, run the basic idea through the WG _before_ you write the=20 > draft; it may have a major flaw (as this one, I believe, does), or it=20 > may be a direction we just don't want to go (in which case there's no=20 > use putting in the effort to write an ID). >=20 >=20 > To briefly let people know what this is about, it allows carriage of=20 > non-IP packets in LISP. This, I think, is basically a very good idea. >=20 > However, the particular proposal in this ID is, IMO, very badly=20 > flawed. It proposes to take over the field used to carry i) the nonce=20 > (for neighbour xTR reachability detection), and ii) the version of the=20 > mapping entry, and use that field to carry the Ethertype. >=20 > Obviously, then, since one _cannot_ carry a non-IP packet without=20 > making it _impossible_ to perform either of these functions: if only=20 > non-IP traffic is being carried over a particular link, these two=20 > (important, IMO) control functions will be _permanently_ disabled. >=20 > I don't believe this is acceptable. >=20 >=20 >>> From: Lucy yong >=20 >>> Regarding to the protocol evolution, does this mean that=20 >>> nonce/map-version features in LISP will be deprecated? >>> IMO: Having the same field overloaded for many differen[t] purposes=20 >>> is not good way for the protocol evolution, it becomes messy. >=20 > Yes and no. The engineering analysis on this sort of thing is subtle. >=20 > With a limited length header, if you have several control functions=20 > that do not need to be applied _on every packet_, I think it's=20 > reasonable to share a field between them. One does have to carefully=20 > look at the functions to decide if they really are things that one doesn'= t have to do on every packet. >=20 > The thing is that putting a separate field in for every possible=20 > function will make the header a lot longer, which will have an impact=20 > on overhead (somewhat problematic), and also MTU (even more=20 > problematic, especially if MTU Discovery is not working properly). >=20 > I am given to understand that a number of organizations have hardware=20 > which looks at the first two 32-bit words, so unfortunately making the=20 > header longer is not available as a _short-term_ answer. >=20 > (Although I think we're just about reaching the limits of what we can=20 > cram into a 2-word header, so it's probably time to start thinking=20 > about a longer > one.) >=20 >=20 >> It means that the features need to be traded off. So the=20 >> market/user-base will decide what it wants to use that field for. >=20 > I have to tell you that I just about fell off my chair when I realized=20 > what you were saying here. >=20 > I don't believe that is professionally acceptable to force users to=20 > chose between i) carrying non-IP traffic, and ii) having some=20 > important control functions available. >=20 > I understand that in the real world there are constraints, so we can't=20 > necessarily 'clean sheet of paper' the answer; but at the same time,=20 > surely it is not beyond our wit to find an answer that doesn't force=20 > users into making that choice. >=20 >=20 > I have some ideas on what to do here (technically), but before I=20 > launch into them I would like to hear if the WG agrees with me that=20 > this 'tradeoff' is unacceptable. >=20 > Because, clearly, if the WG is happy with this, there's no point in my=20 > bringing up alternatives. >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Tue Sep 24 15:34:09 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4278411E8194 for ; Tue, 24 Sep 2013 15:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3ThvF76qYUV for ; Tue, 24 Sep 2013 15:34:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C4A2711E8160 for ; Tue, 24 Sep 2013 15:34:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVV09059; Tue, 24 Sep 2013 22:33:58 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 24 Sep 2013 23:33:10 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 24 Sep 2013 23:33:55 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Tue, 24 Sep 2013 15:33:48 -0700 From: Lucy yong To: "lisp@ietf.org list" Thread-Topic: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt Thread-Index: AQHOrcn8Dqq3wHN+XEid0pUVKpjnj5m/AbvQgACUYgD//4r78IAAeYaA//+LFxCAAIfYgP//lMNQAsm7XyA= Date: Tue, 24 Sep 2013 22:33:47 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D1762@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [lisp] FW: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 24 Sep 2013 22:34:09 -0000 FYI. This reply [Lucy] did not reach to the LISP mail list before due to no= t being a subscriber. -----Original Message----- From: Lucy yong=20 Sent: Tuesday, September 10, 2013 1:19 PM To: 'Dino Farinacci' Cc: nvo3@ietf.org; Paul Quinn (paulq); lisp@ietf.org list Subject: RE: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.t= xt Copying the LISP working group mailing list. >> This implies that both gpe LISP and legacy LISP may be used in the marke= t. Is that true only IP-in-IP application need nonce feature? Mobility is i= mportant requirement for cloud applications, so gpe LISP needs to develop o= ther solution for this feature? Sorry, this is a hard sale. >=20 > If you use IP-in-IP you don't need to set the P-bit, making the nonce ava= ilable for use. Yes, there are applications where the nonce is useful. > [Lucy] Yes, I agree that the nonce is useful. But gpe LISP router will no= t support that. Why do we want to remove this in the protocol evolution?=20 Lucy, we are not removing anything. Like I said (and I don't want to contin= ually repeat myself) that the features are tradeoffs. The motivation for the change was to get VXLAN to have protocol demuxing.=20 [Lucy] For VXLAN to support protocol demuxing, no need to use P bit. We hav= e the proposal (https://datatracker.ietf.org/doc/draft-yong-l3vpn-nvgre-vxl= an-encap/). And in the spirit of keeping the packet formats for VXLAN and LISP as ident= ical as VXLAN will have it, the P-bit is being proposed for LISP. [Lucy] This logic means that if VXLAN does not need P bit, LISP does not ha= ve to have it either, right? It also indicates that you do not see the appl= ications for gpe LISP router, is that right? IMO: LISP and VXLAN have diffe= rent UDP port numbers, which is sufficient to differentiate the two. This is a proposal. The LISP working group must decide if the draft becomes= a working group document. [Lucy] People need carefully evaluation this proposal impact on LISP.=20 Regards, Lucy Dino >=20 > Lucy >=20 > Dino >=20 >>=20 >> Regards, >> Lucy >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com]=20 >> Sent: Tuesday, September 10, 2013 10:56 AM >> To: Lucy yong >> Cc: Paul Quinn (paulq); nvo3@ietf.org >> Subject: Re: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-0= 0.txt >>=20 >>> Regarding to the protocol evolution, does this mean that nonce/map-vers= ion features in LISP will be deprecated? IMO: Having the same field overloa= ded for many difference purposes is not good way for the protocol evolution= , it becomes messy. >>=20 >> No it does not mean that. It means that the features need to be traded o= ff. So the market/user-base will decide what it wants to use that field for= . >>=20 >> Dino >>=20 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From fmaino@cisco.com Wed Sep 25 11:22:50 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E810A21F83EF; Wed, 25 Sep 2013 11:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avNNugfkFFiM; Wed, 25 Sep 2013 11:22:40 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3452011E8138; Wed, 25 Sep 2013 11:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6213; q=dns/txt; s=iport; t=1380133357; x=1381342957; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QjCoLhvBxWZ8qq1E2GKKhCTI8XySNvQKol+fxhYGpS8=; b=dJtrMWJhZuxHyavMUVgo8SakT54DsOx8Zt3uUDbFzltBm5qK5Xvo36B8 YhlSiofjyEVFyteo/rFN7MpoGChjRotx55Tnds+PsZrmCspx/HaigXeO9 //sMC+KVJ/dZmz0ATVy870vc0HJrYVvjU6u0T3m3Iw8dTsrC/ty7Ukzfv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAB0pQ1KrRDoH/2dsb2JhbABbDoJ5OMEcgR8WdIIlAQEBBAEBATUvBwkBARALDgcDCRYPCQMCAQIBFTAGDQEFAgEBh3ADDg2yLQ2Jao4SgT8HhB0DiTiORIEvhQOLRYJlXxyBLA X-IronPort-AV: E=Sophos;i="4.90,979,1371081600"; d="scan'208";a="93175036" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 25 Sep 2013 18:22:36 +0000 Received: from [10.154.213.28] ([10.154.213.28]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8PIMZYI002580; Wed, 25 Sep 2013 18:22:35 GMT Message-ID: <524329EB.7050704@cisco.com> Date: Wed, 25 Sep 2013 11:22:35 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Noel Chiappa References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> In-Reply-To: <20130924150710.B45F118C094@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: nvo3@ietf.org, lisp@ietf.org Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 25 Sep 2013 18:22:50 -0000 Hi Noel, there's certainly no intention of keeping this out of the LISP WG, since this is not part of the charter we just thought an individual submission was more appropriate. We just started from the very practical consideration of the proliferation of encapsulations in the data center, and the lack of multiprotocol support in both VXLAN and LISP. From a vendor perspective having a more rationale encapsulation with multiprotocol support seems a good goal, as it simplifies the implementations and improves interoperability. Since for both VXLAN and LISP there are already HW implementations the hard part is to provide some form of backward compatibility, that would allow a deployment of HW supporting the multiprotocol format to interoperate with legacy devices. The *-gpe drafts, are a proposal to do just that. For lisp-gpe, unfortunately, it comes to the expenses of the nonce and versioning fields, that is certainly a higher cost to pay, compared with the extension of vxlan. In the judgement of the authors of the drafts this might be an acceptable compromise. That said I certainly respect your dissenting opinion. To move forward I suggest we discuss the requirements and the different points of view, and we should try to see if there's a way to achieve a larger set of goals of what lisp-gpe does today. We have a great chance to talk in person next week at the LISP interim in Herndon, where I'm sure we can do a good use of aisle time. Looking forward to meet you next week, Fabio On 9/24/13 8:07 AM, Noel Chiappa wrote: > {This is mostly to the LISP WG; NVO3 - which I candidly admit to knowing > almost nothing about, but which I justt joined - may or may not care. Sorry > this goes on for a bit, but this is important. I hope people will take the > time to read it - it's not _that_ long.} > > > > From: Dino Farinacci > > > the P-bit is being proposed for LISP. > > For those who missed what this was all about (I sure did), there is a new ID: > > http://tools.ietf.org/html/draft-lewis-lisp-gpe-00 > "LISP Generic Protocol Extension" > > As a personal ID, this ID was not automagically announced to the LISP WG; I > only happened to just see it when I was updating the LISP bibliography this > weekend. > > May I suggest that in the future, anyone posting a personal draft _send a > message to the WG_ - for people who are not subscibed to the full ID > announcement feed (I'm not, it's way too much traffic, 97% of which I don't > care about); otherwise, many people will have no idea that it's there. > > Even better, run the basic idea through the WG _before_ you write the draft; > it may have a major flaw (as this one, I believe, does), or it may be a > direction we just don't want to go (in which case there's no use putting in > the effort to write an ID). > > > To briefly let people know what this is about, it allows carriage of non-IP > packets in LISP. This, I think, is basically a very good idea. > > However, the particular proposal in this ID is, IMO, very badly flawed. It > proposes to take over the field used to carry i) the nonce (for neighbour xTR > reachability detection), and ii) the version of the mapping entry, and use > that field to carry the Ethertype. > > Obviously, then, since one _cannot_ carry a non-IP packet without making it > _impossible_ to perform either of these functions: if only non-IP traffic is > being carried over a particular link, these two (important, IMO) control > functions will be _permanently_ disabled. > > I don't believe this is acceptable. > > > >> From: Lucy yong > > >> Regarding to the protocol evolution, does this mean that > >> nonce/map-version features in LISP will be deprecated? > >> IMO: Having the same field overloaded for many differen[t] purposes > >> is not good way for the protocol evolution, it becomes messy. > > Yes and no. The engineering analysis on this sort of thing is subtle. > > With a limited length header, if you have several control functions that do > not need to be applied _on every packet_, I think it's reasonable to share a > field between them. One does have to carefully look at the functions to > decide if they really are things that one doesn't have to do on every packet. > > The thing is that putting a separate field in for every possible function > will make the header a lot longer, which will have an impact on overhead > (somewhat problematic), and also MTU (even more problematic, especially if > MTU Discovery is not working properly). > > I am given to understand that a number of organizations have hardware which > looks at the first two 32-bit words, so unfortunately making the header longer > is not available as a _short-term_ answer. > > (Although I think we're just about reaching the limits of what we can cram > into a 2-word header, so it's probably time to start thinking about a longer > one.) > > > > It means that the features need to be traded off. So the > > market/user-base will decide what it wants to use that field for. > > I have to tell you that I just about fell off my chair when I realized > what you were saying here. > > I don't believe that is professionally acceptable to force users to chose > between i) carrying non-IP traffic, and ii) having some important control > functions available. > > I understand that in the real world there are constraints, so we can't > necessarily 'clean sheet of paper' the answer; but at the same time, surely it > is not beyond our wit to find an answer that doesn't force users into making > that choice. > > > I have some ideas on what to do here (technically), but before I launch into > them I would like to hear if the WG agrees with me that this 'tradeoff' is > unacceptable. > > Because, clearly, if the WG is happy with this, there's no point in my > bringing up alternatives. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Wed Sep 25 12:03:59 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D149D21F89FF; Wed, 25 Sep 2013 12:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nOBrXYtElyY; Wed, 25 Sep 2013 12:03:58 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id BE15721F9CC8; Wed, 25 Sep 2013 12:03:55 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kl14so238618pab.11 for ; Wed, 25 Sep 2013 12:03:55 -0700 (PDT) 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=6hsMsjpGr7HbmazbxN2ukGRS5s7LvgfEtZVCIPZbeEA=; b=cH3wfIx+QsKKxfz5zcLLIY/C+L8SOuGe7XThE1OO4rXEAaD5HpNLbDVzwddZJrrgd9 f3Em1AKsEHHxdYA6iLyjN6h+38MlJbRi86UviRHMSemSRD0We3QNgk8LLPMRVSGnyl2/ voO8fu1AUrAqzKt29kqu6bN+2NbB69nx5nwS+xwuM7hxBEvysTzKEqvEHtrFlzRsTP88 Pl6pkUjGvxtL/l2eqbdtA51+h2rlGkpX6hCRUipkTTHLnJGmg9jM8t+siJhwwnzWQaSl iEnsdHiyDJ7+6PL9RxQ0+JQ1jqR237r4oZ15xzWxJSh4BwuP0D/IjHsIwNQj4KlatTyC dz/A== X-Received: by 10.68.196.138 with SMTP id im10mr11947745pbc.127.1380135835332; Wed, 25 Sep 2013 12:03:55 -0700 (PDT) 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 y5sm49349033pbs.18.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 12:03:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dino Farinacci In-Reply-To: <524329EB.7050704@cisco.com> Date: Wed, 25 Sep 2013 12:03:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> <524329EB.7050704@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.1510) Cc: nvo3@ietf.org, Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 25 Sep 2013 19:04:00 -0000 > Hi Noel, > there's certainly no intention of keeping this out of the LISP WG, = since this is not part of the charter we just thought an individual = submission was more appropriate. >=20 > We just started from the very practical consideration of the = proliferation of encapsulations in the data center, and the lack of = multiprotocol support in both VXLAN and LISP. Sorry I have to disagree. The protocols that LISP supports are *IP* = protocols and the protocols that VXLAN supports are *the rest* since it = is layer-2 solution. So this appears to be just rearranging the deck = chairs. > =46rom a vendor perspective having a more rationale encapsulation with = multiprotocol support seems a good goal, as it simplifies the = implementations and improves interoperability. We had a clear demarcation point that was workable, now we have yet = another option. So IMO this is not a simplification. > Since for both VXLAN and LISP there are already HW implementations the = hard part is to provide some form of backward compatibility, that would = allow a deployment of HW supporting the multiprotocol format to = interoperate with legacy devices. The *-gpe drafts, are a proposal to do = just that. >=20 > For lisp-gpe, unfortunately, it comes to the expenses of the nonce and = versioning fields, that is certainly a higher cost to pay, compared with = the extension of vxlan. In the judgement of the authors of the drafts = this might be an acceptable compromise. That said I certainly respect = your dissenting opinion. >=20 > To move forward I suggest we discuss the requirements and the = different points of view, and we should try to see if there's a way to = achieve a larger set of goals of what lisp-gpe does today. >=20 > We have a great chance to talk in person next week at the LISP interim = in Herndon, where I'm sure we can do a good use of aisle time. >=20 > Looking forward to meet you next week, > Fabio I hope we can use private time to discuss this and not working group = time, since the reason we are having an interim meeting is to close on = the architecture draft(s). Dino >=20 >=20 >=20 >=20 >=20 >=20 > On 9/24/13 8:07 AM, Noel Chiappa wrote: >> {This is mostly to the LISP WG; NVO3 - which I candidly admit to = knowing >> almost nothing about, but which I justt joined - may or may not care. = Sorry >> this goes on for a bit, but this is important. I hope people will = take the >> time to read it - it's not _that_ long.} >>=20 >>=20 >> > From: Dino Farinacci >>=20 >> > the P-bit is being proposed for LISP. >>=20 >> For those who missed what this was all about (I sure did), there is a = new ID: >>=20 >> http://tools.ietf.org/html/draft-lewis-lisp-gpe-00 >> "LISP Generic Protocol Extension" >>=20 >> As a personal ID, this ID was not automagically announced to the LISP = WG; I >> only happened to just see it when I was updating the LISP = bibliography this >> weekend. >>=20 >> May I suggest that in the future, anyone posting a personal draft = _send a >> message to the WG_ - for people who are not subscibed to the full ID >> announcement feed (I'm not, it's way too much traffic, 97% of which I = don't >> care about); otherwise, many people will have no idea that it's = there. >>=20 >> Even better, run the basic idea through the WG _before_ you write the = draft; >> it may have a major flaw (as this one, I believe, does), or it may be = a >> direction we just don't want to go (in which case there's no use = putting in >> the effort to write an ID). >>=20 >>=20 >> To briefly let people know what this is about, it allows carriage of = non-IP >> packets in LISP. This, I think, is basically a very good idea. >>=20 >> However, the particular proposal in this ID is, IMO, very badly = flawed. It >> proposes to take over the field used to carry i) the nonce (for = neighbour xTR >> reachability detection), and ii) the version of the mapping entry, = and use >> that field to carry the Ethertype. >>=20 >> Obviously, then, since one _cannot_ carry a non-IP packet without = making it >> _impossible_ to perform either of these functions: if only non-IP = traffic is >> being carried over a particular link, these two (important, IMO) = control >> functions will be _permanently_ disabled. >>=20 >> I don't believe this is acceptable. >>=20 >>=20 >> >> From: Lucy yong >>=20 >> >> Regarding to the protocol evolution, does this mean that >> >> nonce/map-version features in LISP will be deprecated? >> >> IMO: Having the same field overloaded for many differen[t] = purposes >> >> is not good way for the protocol evolution, it becomes messy. >>=20 >> Yes and no. The engineering analysis on this sort of thing is subtle. >>=20 >> With a limited length header, if you have several control functions = that do >> not need to be applied _on every packet_, I think it's reasonable to = share a >> field between them. One does have to carefully look at the functions = to >> decide if they really are things that one doesn't have to do on every = packet. >>=20 >> The thing is that putting a separate field in for every possible = function >> will make the header a lot longer, which will have an impact on = overhead >> (somewhat problematic), and also MTU (even more problematic, = especially if >> MTU Discovery is not working properly). >>=20 >> I am given to understand that a number of organizations have hardware = which >> looks at the first two 32-bit words, so unfortunately making the = header longer >> is not available as a _short-term_ answer. >>=20 >> (Although I think we're just about reaching the limits of what we can = cram >> into a 2-word header, so it's probably time to start thinking about a = longer >> one.) >>=20 >>=20 >> > It means that the features need to be traded off. So the >> > market/user-base will decide what it wants to use that field = for. >>=20 >> I have to tell you that I just about fell off my chair when I = realized >> what you were saying here. >>=20 >> I don't believe that is professionally acceptable to force users to = chose >> between i) carrying non-IP traffic, and ii) having some important = control >> functions available. >>=20 >> I understand that in the real world there are constraints, so we = can't >> necessarily 'clean sheet of paper' the answer; but at the same time, = surely it >> is not beyond our wit to find an answer that doesn't force users into = making >> that choice. >>=20 >>=20 >> I have some ideas on what to do here (technically), but before I = launch into >> them I would like to hear if the WG agrees with me that this = 'tradeoff' is >> unacceptable. >>=20 >> Because, clearly, if the WG is happy with this, there's no point in = my >> bringing up alternatives. >>=20 >> Noel >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Wed Sep 25 12:37:53 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9031711E80E4; Wed, 25 Sep 2013 12:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5IBhEKn5huq; Wed, 25 Sep 2013 12:37:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEA411E80EC; Wed, 25 Sep 2013 12:37:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYG05409; Wed, 25 Sep 2013 19:37:32 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 25 Sep 2013 20:36:36 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 25 Sep 2013 20:37:29 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Wed, 25 Sep 2013 12:37:23 -0700 From: Lucy yong To: Fabio Maino , Noel Chiappa Thread-Topic: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt Thread-Index: AQHOuTfN+lCsrcFypU2cSNY1dmy325nXO1KA//+albA= Date: Wed, 25 Sep 2013 19:37:22 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D1A4C@dfweml509-mbx.china.huawei.com> References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> <524329EB.7050704@cisco.com> In-Reply-To: <524329EB.7050704@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 25 Sep 2013 19:37:53 -0000 Please see my reply inline [lucy]. -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Fab= io Maino Sent: Wednesday, September 25, 2013 1:23 PM To: Noel Chiappa Cc: nvo3@ietf.org; lisp@ietf.org Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-g= pe-00.txt Hi Noel, there's certainly no intention of keeping this out of the LISP WG, since th= is is not part of the charter we just thought an individual submission was = more appropriate. We just started from the very practical consideration of the proliferation = of encapsulations in the data center, and the lack of multiprotocol support= in both VXLAN and LISP. From a vendor perspective having a more rationale encapsulation with multi= protocol support seems a good goal, as it simplifies the implementations an= d improves interoperability. [Lucy] disagree. This certainly makes LISP more complex and harder to inter= work. The lisp-gpe draft has many holes on the interworking. Since for both VXLAN and LISP there are already HW implementations the hard= part is to provide some form of backward compatibility, that would allow a= deployment of HW supporting the multiprotocol format to interoperate with = legacy devices. The *-gpe drafts, are a proposal to do just that. For lisp-gpe, unfortunately, it comes to the expenses of the nonce and vers= ioning fields, that is certainly a higher cost to pay, compared with the ex= tension of vxlan. In the judgement of the authors of the drafts this might = be an acceptable compromise. That said I certainly respect your dissenting = opinion. [Lucy] Although VXLAN encapsulation had intention to align with LISP at beg= inning, if expanding it to support multiprotocol, it means the separation b= etween two because LISP does not have goal. In fact, VXLAN and LISP already= uses different UDP port number, it is sufficient to separate them. Lisp-gp= e proposal will result a bad LISP protocol. Hope that the WG give a cautiou= s consideration. Lucy To move forward I suggest we discuss the requirements and the different poi= nts of view, and we should try to see if there's a way to achieve a larger = set of goals of what lisp-gpe does today. We have a great chance to talk in person next week at the LISP interim in H= erndon, where I'm sure we can do a good use of aisle time. Looking forward to meet you next week, Fabio On 9/24/13 8:07 AM, Noel Chiappa wrote: > {This is mostly to the LISP WG; NVO3 - which I candidly admit to=20 > knowing almost nothing about, but which I justt joined - may or may=20 > not care. Sorry this goes on for a bit, but this is important. I hope=20 > people will take the time to read it - it's not _that_ long.} > > > > From: Dino Farinacci > > > the P-bit is being proposed for LISP. > > For those who missed what this was all about (I sure did), there is a new= ID: > > http://tools.ietf.org/html/draft-lewis-lisp-gpe-00 > "LISP Generic Protocol Extension" > > As a personal ID, this ID was not automagically announced to the LISP=20 > WG; I only happened to just see it when I was updating the LISP=20 > bibliography this weekend. > > May I suggest that in the future, anyone posting a personal draft=20 > _send a message to the WG_ - for people who are not subscibed to the=20 > full ID announcement feed (I'm not, it's way too much traffic, 97% of=20 > which I don't care about); otherwise, many people will have no idea that = it's there. > > Even better, run the basic idea through the WG _before_ you write the=20 > draft; it may have a major flaw (as this one, I believe, does), or it=20 > may be a direction we just don't want to go (in which case there's no=20 > use putting in the effort to write an ID). > > > To briefly let people know what this is about, it allows carriage of=20 > non-IP packets in LISP. This, I think, is basically a very good idea. > > However, the particular proposal in this ID is, IMO, very badly=20 > flawed. It proposes to take over the field used to carry i) the nonce=20 > (for neighbour xTR reachability detection), and ii) the version of the=20 > mapping entry, and use that field to carry the Ethertype. > > Obviously, then, since one _cannot_ carry a non-IP packet without=20 > making it _impossible_ to perform either of these functions: if only=20 > non-IP traffic is being carried over a particular link, these two=20 > (important, IMO) control functions will be _permanently_ disabled. > > I don't believe this is acceptable. > > > >> From: Lucy yong > > >> Regarding to the protocol evolution, does this mean that > >> nonce/map-version features in LISP will be deprecated? > >> IMO: Having the same field overloaded for many differen[t] purpos= es > >> is not good way for the protocol evolution, it becomes messy. > > Yes and no. The engineering analysis on this sort of thing is subtle. > > With a limited length header, if you have several control functions=20 > that do not need to be applied _on every packet_, I think it's=20 > reasonable to share a field between them. One does have to carefully=20 > look at the functions to decide if they really are things that one doesn'= t have to do on every packet. > > The thing is that putting a separate field in for every possible=20 > function will make the header a lot longer, which will have an impact=20 > on overhead (somewhat problematic), and also MTU (even more=20 > problematic, especially if MTU Discovery is not working properly). > > I am given to understand that a number of organizations have hardware=20 > which looks at the first two 32-bit words, so unfortunately making the=20 > header longer is not available as a _short-term_ answer. > > (Although I think we're just about reaching the limits of what we can=20 > cram into a 2-word header, so it's probably time to start thinking=20 > about a longer > one.) > > > > It means that the features need to be traded off. So the > > market/user-base will decide what it wants to use that field for. > > I have to tell you that I just about fell off my chair when I realized=20 > what you were saying here. > > I don't believe that is professionally acceptable to force users to=20 > chose between i) carrying non-IP traffic, and ii) having some=20 > important control functions available. > > I understand that in the real world there are constraints, so we can't=20 > necessarily 'clean sheet of paper' the answer; but at the same time,=20 > surely it is not beyond our wit to find an answer that doesn't force=20 > users into making that choice. > > > I have some ideas on what to do here (technically), but before I=20 > launch into them I would like to hear if the WG agrees with me that=20 > this 'tradeoff' is unacceptable. > > Because, clearly, if the WG is happy with this, there's no point in my=20 > bringing up alternatives. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From jnc@mercury.lcs.mit.edu Wed Sep 25 13:41:20 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3B121F9AE6; Wed, 25 Sep 2013 13:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRysBL34-Je5; Wed, 25 Sep 2013 13:41:15 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 253A521F8F61; Wed, 25 Sep 2013 13:41:12 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 051AB18C188; Wed, 25 Sep 2013 16:41:08 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130925204108.051AB18C188@mercury.lcs.mit.edu> Date: Wed, 25 Sep 2013 16:41:08 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: nvo3@ietf.org, jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 25 Sep 2013 20:41:20 -0000 > From: Fabio Maino > We just started from .. the lack of multiprotocol support I don't really have a 'dog in that hunt' (i.e. a preference, for those who aren't familiar with that US idiom). I can see how it might be useful, but it's not like I will die of apoplexy if we don't add it. > For lisp-gpe, unfortunately, it comes to the expenses of the nonce and > versioning fields, that is certainly a higher cost to pay But I don't think that it _is_ an un-avoidable tradeoff. As I alluded to in my prior post, I believe a slightly different change to the encapsulation is feasible, one which retains almost all the existing functionality, and adds multi-protocol support. My suggestion (based on some discussions with people, to find out what the real-world constraints on changes are), and thinking about the various functions and fields of the header, is to multiplex the LSB along with the nonce and version in the field on the right of the first header word, freeing up the 8-bit LSB field in the second header word (this is assuming the Instance field is present, which I think it will likely be) to use for a protocol type - in every packet. I won't go into the analysis of flag bits and settings, but having looked at 6830 carefully, I believe they can be made to work in an upwardly compatible way. My position is that we don't _have_ to have the LSB in _every_ packet, any more than we _have_ to have the nonce or version in _every_ packet. Exactly what the 'right' mix is of the various functions (e.g. 'check the mapping version every 10th data packet', etc), is something we'd probably want to work out from experience. Yes, this solution is not optimal - e.g. we have to have a translation between 16-bit Ethertype and an 8-bit protocol type - but it's _much_ better, IMO, than the existing proposal - where we have to chose _between_ multi-protocol support, and those important control functions. > we should try to see if there's a way to achieve a larger set of goals > of what lisp-gpe does today. To repeat something I said elsewhere, I think we're getting close to the limit of how many pounds we can fit in the particular 5-pound sack of the double-word header. (For those who aren't familiar with this expression, Google '5 pound sack'.) Given that there are hardware implications for a longer header (which I think we're likely to need at some point), we might want to go ahead and specify a longer header, _without using it for anything for the moment_. Once hardware support has made it into the pipeline, we can start to use it. But unless we specify it _before_ we need it, we will not be able to use it when we _do_ need it! Hence my suggestion that we specify it now, without using it for anything. Noel From fmaino@cisco.com Wed Sep 25 21:54:21 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BD921F8947; Wed, 25 Sep 2013 21:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnSxAwA5NLrJ; Wed, 25 Sep 2013 21:54:16 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6880021F9E52; Wed, 25 Sep 2013 21:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7218; q=dns/txt; s=iport; t=1380171254; x=1381380854; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Pt4ISSTVnMPvq4VasoFm4QGtqyv6SalKoY4Psb42qD4=; b=HdQCWgJcBhw2UuJHwkKJL572iZW9hheaj+urHegL5FkBauQsC5Y+q3YX rlCuNoLXxvEhJnt3S4Z8BiSTZcanGdw3yxcTOMm+Ktjj3WcH/CwG34x9V gkZ1kUfYHyytk8HfgWNcJ6WkVVjNo+CN9E4uf81Hty919/5dp2w+Sz5gk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHq9Q1KrRDoG/2dsb2JhbABbgwc4wS+BHxZ0giUBAQEDAQEBATUvBwkBARALEgMDCRYPCQMCAQIBFSIOBg0BBQIBAReHWQMJBQ2yYA2Jao4SgT8HhB4DiTiORIEvhQOLRYNEHIEs X-IronPort-AV: E=Sophos;i="4.90,982,1371081600"; d="scan'208";a="89928777" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 26 Sep 2013 04:54:13 +0000 Received: from [10.21.70.174] ([10.21.70.174]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8Q4sCO4027124; Thu, 26 Sep 2013 04:54:12 GMT Message-ID: <5243BDF4.8030209@cisco.com> Date: Wed, 25 Sep 2013 21:54:12 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dino Farinacci References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> <524329EB.7050704@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: nvo3@ietf.org, Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 26 Sep 2013 04:54:21 -0000 On 9/25/13 12:03 PM, Dino Farinacci wrote: >> Hi Noel, >> there's certainly no intention of keeping this out of the LISP WG, since this is not part of the charter we just thought an individual submission was more appropriate. >> >> We just started from the very practical consideration of the proliferation of encapsulations in the data center, and the lack of multiprotocol support in both VXLAN and LISP. > Sorry I have to disagree. The protocols that LISP supports are *IP* protocols and the protocols that VXLAN supports are *the rest* since it is layer-2 solution. So this appears to be just rearranging the deck chairs. > >> From a vendor perspective having a more rationale encapsulation with multiprotocol support seems a good goal, as it simplifies the implementations and improves interoperability. > We had a clear demarcation point that was workable, now we have yet another option. So IMO this is not a simplification. > >> Since for both VXLAN and LISP there are already HW implementations the hard part is to provide some form of backward compatibility, that would allow a deployment of HW supporting the multiprotocol format to interoperate with legacy devices. The *-gpe drafts, are a proposal to do just that. >> >> For lisp-gpe, unfortunately, it comes to the expenses of the nonce and versioning fields, that is certainly a higher cost to pay, compared with the extension of vxlan. In the judgement of the authors of the drafts this might be an acceptable compromise. That said I certainly respect your dissenting opinion. >> >> To move forward I suggest we discuss the requirements and the different points of view, and we should try to see if there's a way to achieve a larger set of goals of what lisp-gpe does today. >> >> We have a great chance to talk in person next week at the LISP interim in Herndon, where I'm sure we can do a good use of aisle time. >> >> Looking forward to meet you next week, >> Fabio > I hope we can use private time to discuss this and not working group time, since the reason we are having an interim meeting is to close on the architecture draft(s). sure. Architecture draft(s) are the absolute priority. Fabio > > Dino > >> >> >> >> >> >> On 9/24/13 8:07 AM, Noel Chiappa wrote: >>> {This is mostly to the LISP WG; NVO3 - which I candidly admit to knowing >>> almost nothing about, but which I justt joined - may or may not care. Sorry >>> this goes on for a bit, but this is important. I hope people will take the >>> time to read it - it's not _that_ long.} >>> >>> >>> > From: Dino Farinacci >>> >>> > the P-bit is being proposed for LISP. >>> >>> For those who missed what this was all about (I sure did), there is a new ID: >>> >>> http://tools.ietf.org/html/draft-lewis-lisp-gpe-00 >>> "LISP Generic Protocol Extension" >>> >>> As a personal ID, this ID was not automagically announced to the LISP WG; I >>> only happened to just see it when I was updating the LISP bibliography this >>> weekend. >>> >>> May I suggest that in the future, anyone posting a personal draft _send a >>> message to the WG_ - for people who are not subscibed to the full ID >>> announcement feed (I'm not, it's way too much traffic, 97% of which I don't >>> care about); otherwise, many people will have no idea that it's there. >>> >>> Even better, run the basic idea through the WG _before_ you write the draft; >>> it may have a major flaw (as this one, I believe, does), or it may be a >>> direction we just don't want to go (in which case there's no use putting in >>> the effort to write an ID). >>> >>> >>> To briefly let people know what this is about, it allows carriage of non-IP >>> packets in LISP. This, I think, is basically a very good idea. >>> >>> However, the particular proposal in this ID is, IMO, very badly flawed. It >>> proposes to take over the field used to carry i) the nonce (for neighbour xTR >>> reachability detection), and ii) the version of the mapping entry, and use >>> that field to carry the Ethertype. >>> >>> Obviously, then, since one _cannot_ carry a non-IP packet without making it >>> _impossible_ to perform either of these functions: if only non-IP traffic is >>> being carried over a particular link, these two (important, IMO) control >>> functions will be _permanently_ disabled. >>> >>> I don't believe this is acceptable. >>> >>> >>> >> From: Lucy yong >>> >>> >> Regarding to the protocol evolution, does this mean that >>> >> nonce/map-version features in LISP will be deprecated? >>> >> IMO: Having the same field overloaded for many differen[t] purposes >>> >> is not good way for the protocol evolution, it becomes messy. >>> >>> Yes and no. The engineering analysis on this sort of thing is subtle. >>> >>> With a limited length header, if you have several control functions that do >>> not need to be applied _on every packet_, I think it's reasonable to share a >>> field between them. One does have to carefully look at the functions to >>> decide if they really are things that one doesn't have to do on every packet. >>> >>> The thing is that putting a separate field in for every possible function >>> will make the header a lot longer, which will have an impact on overhead >>> (somewhat problematic), and also MTU (even more problematic, especially if >>> MTU Discovery is not working properly). >>> >>> I am given to understand that a number of organizations have hardware which >>> looks at the first two 32-bit words, so unfortunately making the header longer >>> is not available as a _short-term_ answer. >>> >>> (Although I think we're just about reaching the limits of what we can cram >>> into a 2-word header, so it's probably time to start thinking about a longer >>> one.) >>> >>> >>> > It means that the features need to be traded off. So the >>> > market/user-base will decide what it wants to use that field for. >>> >>> I have to tell you that I just about fell off my chair when I realized >>> what you were saying here. >>> >>> I don't believe that is professionally acceptable to force users to chose >>> between i) carrying non-IP traffic, and ii) having some important control >>> functions available. >>> >>> I understand that in the real world there are constraints, so we can't >>> necessarily 'clean sheet of paper' the answer; but at the same time, surely it >>> is not beyond our wit to find an answer that doesn't force users into making >>> that choice. >>> >>> >>> I have some ideas on what to do here (technically), but before I launch into >>> them I would like to hear if the WG agrees with me that this 'tradeoff' is >>> unacceptable. >>> >>> Because, clearly, if the WG is happy with this, there's no point in my >>> bringing up alternatives. >>> >>> Noel >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 From rogerj@gmail.com Thu Sep 26 11:35:42 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D3821F9E54; Thu, 26 Sep 2013 11:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaN99NyC15Ns; Thu, 26 Sep 2013 11:35:37 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9010821F9DED; Thu, 26 Sep 2013 11:35:26 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm2so1706453wib.0 for ; Thu, 26 Sep 2013 11:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0NBTCXq6ivF110PLyEHlDAlzuriXFDE8s293oDeQfkE=; b=mc1X8xtB31aeWvb2GuTxNCjYdvHRflZMChjWDsGDa51wO3TmXngxeLUxwHQbrLRz3o /5hmkGflhrFW/OFMGY7qUE8MUsWMYIIZTRIqlbsgi7oCgY0d0DlrNOM1TY9Y4EDn5a7p 3sXBXAu/y+PODD7dfuVAj9mXu0fBWQ3GGJcDGH8u6B5/RNwyRaPB2J64hcsSz/sAKHAM hVBA886AmOLD5KC7l1/v4QlDHb+XWL01tXcijS2YAg+MyR5YQb0A14fD/b447Rf0eAPu VL6PuhN4WKDgnbXEWXafhJvD7BxBYNur5E3ZnUhWBsGfmqW12HOhYJw+L3HRZjxv/9OW oXWg== MIME-Version: 1.0 X-Received: by 10.180.90.197 with SMTP id by5mr28767345wib.43.1380220525682; Thu, 26 Sep 2013 11:35:25 -0700 (PDT) Received: by 10.216.213.72 with HTTP; Thu, 26 Sep 2013 11:35:25 -0700 (PDT) In-Reply-To: References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> <524329EB.7050704@cisco.com> Date: Thu, 26 Sep 2013 20:35:25 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Dino Farinacci , Fabio Maino Content-Type: text/plain; charset=ISO-8859-1 Cc: "nvo3@ietf.org" , Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 26 Sep 2013 18:35:42 -0000 On Wed, Sep 25, 2013 at 9:03 PM, Dino Farinacci wrote: >> Hi Noel, >> there's certainly no intention of keeping this out of the LISP WG, since this is not part of the charter we just thought an individual submission was more appropriate. >> >> We just started from the very practical consideration of the proliferation of encapsulations in the data center, and the lack of multiprotocol support in both VXLAN and LISP. > > Sorry I have to disagree. The protocols that LISP supports are *IP* protocols and the protocols that VXLAN supports are *the rest* since it is layer-2 solution. So this appears to be just rearranging the deck chairs. This trouble me... why do we want to mix LISP and VXLAN? What is the gain in it? I only smell complexity. L2 in L3 over L3? How will a mix of LISP and VXLAN benefit the administrators of datacenters, end-users in the end? -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no (I really start to really dislike gmails new better editor) From farinacci@gmail.com Thu Sep 26 11:58:14 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099D321E80B0; Thu, 26 Sep 2013 11:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfGInHjGxqUC; Thu, 26 Sep 2013 11:58:09 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 217AC21E8094; Thu, 26 Sep 2013 11:58:06 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so2028897ieb.9 for ; Thu, 26 Sep 2013 11:58:05 -0700 (PDT) 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=nkac/6t9kD7tNIY5tKPTv5sLwFu++du45po8yzYbRVY=; b=Yh4diY/U3Js6l3UPKmfTQBYIjH/MQ5KeFvkMt2m9xA4zk2vPQJwasAdoNV64zwXGWa NK6BWXcrV8NkbSS5PNej80n8PJyYB1BbfaZKSUr4sWTT9HpB0gRfczOFOBL/dkUhGXUF 7W0cvUL/bOY6N0U5tjk3Q1AnwDRGLuf+Uq5GbcOGceNbd4AkaO/kxi1/LaAExZEhp1Dm DZ7cl3PeCnmph/eIjFwiC6PyHa8jaV5eWEbZ4xxwY1lrm+8aCYfwJsuIJ78m3LJv2HEL 2YU+Kp4DUAOVCnen7InLwhn4OsX3Zy64RCD7nqBp5UasH/YuM0Fr7GNpQYo/ppOYXXMF pPtQ== X-Received: by 10.43.129.197 with SMTP id hj5mr2853339icc.84.1380221885615; Thu, 26 Sep 2013 11:58:05 -0700 (PDT) Received: from [172.19.131.134] ([12.130.123.252]) by mx.google.com with ESMTPSA id m1sm96505igj.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Sep 2013 11:58:05 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dino Farinacci In-Reply-To: Date: Thu, 26 Sep 2013 11:57:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <16DF95BC-8820-4318-899B-DA0AC10BF19E@gmail.com> References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> <524329EB.7050704@cisco.com> To: =?iso-8859-1?Q?Roger_J=F8rgensen?= X-Mailer: Apple Mail (2.1510) Cc: "nvo3@ietf.org" , Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 26 Sep 2013 18:58:14 -0000 > On Wed, Sep 25, 2013 at 9:03 PM, Dino Farinacci = wrote: >>> Hi Noel, >>> there's certainly no intention of keeping this out of the LISP WG, = since this is not part of the charter we just thought an individual = submission was more appropriate. >>>=20 >>> We just started from the very practical consideration of the = proliferation of encapsulations in the data center, and the lack of = multiprotocol support in both VXLAN and LISP. >>=20 >> Sorry I have to disagree. The protocols that LISP supports are *IP* = protocols and the protocols that VXLAN supports are *the rest* since it = is layer-2 solution. So this appears to be just rearranging the deck = chairs. >=20 > This trouble me... why do we want to mix LISP and VXLAN? What is the > gain in it? I only smell complexity. L2 in L3 over L3? We shouldn't but let the authors reply. If you want to carry more than = IP protocols in LISP, then you use the L2 UDP port and carry MAC = addresses in LISP. You can carry all of MAC, IPv4, and IPv6 EIDs with = one control-plane, the LISP mapping database using LISP-DDT. > How will a mix of LISP and VXLAN benefit the administrators of > datacenters, end-users in the end? The VXLAN authors have to answer that. They came afterwards (by 5 = years). Dino >=20 >=20 >=20 > --=20 >=20 > Roger Jorgensen | ROJO9-RIPE > rogerj@gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger@jorgensen.no >=20 > (I really start to really dislike gmails new better editor) From lucy.yong@huawei.com Thu Sep 26 12:43:57 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E19D21F9B58; Thu, 26 Sep 2013 12:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10fZIas9beG6; Thu, 26 Sep 2013 12:43:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3061C21F92B9; Thu, 26 Sep 2013 12:43:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVX01730; Thu, 26 Sep 2013 19:43:35 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 20:42:43 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 20:43:33 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Thu, 26 Sep 2013 12:43:30 -0700 From: Lucy yong To: Dino Farinacci , =?iso-8859-1?Q?Roger_J=F8rgensen?= Thread-Topic: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt Thread-Index: AQHOuuo9w5pwSVEYQ0qg6kqZJksbCJnYaD9Q Date: Thu, 26 Sep 2013 19:43:30 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D1E85@dfweml509-mbx.china.huawei.com> References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> <524329EB.7050704@cisco.com> <16DF95BC-8820-4318-899B-DA0AC10BF19E@gmail.com> In-Reply-To: <16DF95BC-8820-4318-899B-DA0AC10BF19E@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.68] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 26 Sep 2013 19:43:57 -0000 Please see inline. -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Din= o Farinacci Sent: Thursday, September 26, 2013 1:57 PM To: Roger J=F8rgensen Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-g= pe-00.txt > On Wed, Sep 25, 2013 at 9:03 PM, Dino Farinacci wro= te: >>> Hi Noel, >>> there's certainly no intention of keeping this out of the LISP WG, sinc= e this is not part of the charter we just thought an individual submission = was more appropriate. >>>=20 >>> We just started from the very practical consideration of the proliferat= ion of encapsulations in the data center, and the lack of multiprotocol sup= port in both VXLAN and LISP. >>=20 >> Sorry I have to disagree. The protocols that LISP supports are *IP* prot= ocols and the protocols that VXLAN supports are *the rest* since it is laye= r-2 solution. So this appears to be just rearranging the deck chairs. >=20 > This trouble me... why do we want to mix LISP and VXLAN? What is the=20 > gain in it? I only smell complexity. L2 in L3 over L3? We shouldn't but let the authors reply. If you want to carry more than IP p= rotocols in LISP, then you use the L2 UDP port and carry MAC addresses in L= ISP. You can carry all of MAC, IPv4, and IPv6 EIDs with one control-plane, = the LISP mapping database using LISP-DDT. [Lucy] Agree. This is one way to implement L2 or L3 overlay by using LISP p= rotocol. However, Overlay virtual networks that use VXLAN encapsulation may= be implemented in other way too, e.g. SDN controller, not LISP protocol. T= herefore, there is a desire to extend VXLAN encapsulation to support multip= le protocols beside L2 only and make it a generic overlay encapsulation sch= ematics to support an overlay application. BTW: IMO: using UDP port to indicate payload type is not elegant design, bu= t acceptable for history reason only. Lucy =20 > How will a mix of LISP and VXLAN benefit the administrators of=20 > datacenters, end-users in the end? The VXLAN authors have to answer that. They came afterwards (by 5 years). Dino >=20 >=20 >=20 > -- >=20 > Roger Jorgensen | ROJO9-RIPE > rogerj@gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger@jorgensen.no >=20 > (I really start to really dislike gmails new better editor) _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Thu Sep 26 12:52:53 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7842621F9D95; Thu, 26 Sep 2013 12:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl+o2bXm9GxX; Thu, 26 Sep 2013 12:52:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C638C21F9D96; Thu, 26 Sep 2013 12:52:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVX02093; Thu, 26 Sep 2013 19:52:44 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 20:50:43 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 20:51:38 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Thu, 26 Sep 2013 12:51:28 -0700 From: Lucy yong To: Lucy yong , Dino Farinacci , =?iso-8859-1?Q?Roger_J=F8rgensen?= Thread-Topic: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt Thread-Index: AQHOuuo9w5pwSVEYQ0qg6kqZJksbCJnYaD9QgAAFGhA= Date: Thu, 26 Sep 2013 19:51:27 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D1EBC@dfweml509-mbx.china.huawei.com> References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> <524329EB.7050704@cisco.com> <16DF95BC-8820-4318-899B-DA0AC10BF19E@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.68] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 26 Sep 2013 19:52:54 -0000 Dino, Current VXLAN format is much simpler format compared to LISP format. To use= it with LISP protocol, do you need to modify VXLAN format to support LISP = features? Regards, Lucy -----Original Message----- From: Lucy yong=20 Sent: Thursday, September 26, 2013 2:44 PM To: 'Dino Farinacci'; Roger J=F8rgensen Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org Subject: RE: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-g= pe-00.txt Please see inline. -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Din= o Farinacci Sent: Thursday, September 26, 2013 1:57 PM To: Roger J=F8rgensen Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-g= pe-00.txt > On Wed, Sep 25, 2013 at 9:03 PM, Dino Farinacci wro= te: >>> Hi Noel, >>> there's certainly no intention of keeping this out of the LISP WG, sinc= e this is not part of the charter we just thought an individual submission = was more appropriate. >>>=20 >>> We just started from the very practical consideration of the proliferat= ion of encapsulations in the data center, and the lack of multiprotocol sup= port in both VXLAN and LISP. >>=20 >> Sorry I have to disagree. The protocols that LISP supports are *IP* prot= ocols and the protocols that VXLAN supports are *the rest* since it is laye= r-2 solution. So this appears to be just rearranging the deck chairs. >=20 > This trouble me... why do we want to mix LISP and VXLAN? What is the=20 > gain in it? I only smell complexity. L2 in L3 over L3? We shouldn't but let the authors reply. If you want to carry more than IP p= rotocols in LISP, then you use the L2 UDP port and carry MAC addresses in L= ISP. You can carry all of MAC, IPv4, and IPv6 EIDs with one control-plane, = the LISP mapping database using LISP-DDT. [Lucy] Agree. This is one way to implement L2 or L3 overlay by using LISP p= rotocol. However, Overlay virtual networks that use VXLAN encapsulation may= be implemented in other way too, e.g. SDN controller, not LISP protocol. T= herefore, there is a desire to extend VXLAN encapsulation to support multip= le protocols beside L2 only and make it a generic overlay encapsulation sch= ematics to support an overlay application. BTW: IMO: using UDP port to indicate payload type is not elegant design, bu= t acceptable for history reason only. Lucy =20 > How will a mix of LISP and VXLAN benefit the administrators of=20 > datacenters, end-users in the end? The VXLAN authors have to answer that. They came afterwards (by 5 years). Dino >=20 >=20 >=20 > -- >=20 > Roger Jorgensen | ROJO9-RIPE > rogerj@gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger@jorgensen.no >=20 > (I really start to really dislike gmails new better editor) _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From farinacci@gmail.com Thu Sep 26 13:34:41 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC3521E80B0; Thu, 26 Sep 2013 13:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmXkjjqNtT+9; Thu, 26 Sep 2013 13:34:37 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 80C1621F9DCA; Thu, 26 Sep 2013 13:34:37 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id aq17so2127445iec.41 for ; Thu, 26 Sep 2013 13:34:37 -0700 (PDT) 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=JfawmIpYLDzOYpJ5fIaiETPi6UMrxRpmrFsivyXoqtQ=; b=CmuLSKFy5IpMOq3siKOwRXk1tCaP4IhTJmKc+YvKD1a+CDlhF+IrmHXW9a0QQ8kibT U8Uw4f7QabLnZLuZjG0wqnd7CPu7hKvd5H8kiWDsAHbuYN60ZYGk+IbCpjTWgLV7NPnL FnDeF9Q4bAOFjQn0bYV9a1FG5LJxXvGUaknYM2EUmAAbwNvtqnlI3A6YL4EmvofI4WAN 5do7ARz5/va91i3aoKb2AiCn7ZjqNzAT/93JW7rdpphgHMth1me0wW2+e5+3WzmuABHK 4nbSWXJK2JqNKBvdmtd1PK2NNWyDKrVHxQhGnzBXhx+wUSf223Ma8EUWACD16687m08K rwQQ== X-Received: by 10.42.108.138 with SMTP id h10mr2465925icp.87.1380227675847; Thu, 26 Sep 2013 13:34:35 -0700 (PDT) Received: from [172.19.131.134] ([12.130.123.252]) by mx.google.com with ESMTPSA id hv5sm428656igb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Sep 2013 13:34:35 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dino Farinacci In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452D1EBC@dfweml509-mbx.china.huawei.com> Date: Thu, 26 Sep 2013 13:34:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> <524329EB.7050704@cisco.com> <16DF95BC-8820-4318-899B-DA0AC10BF19E@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D452D1EBC@dfweml509-mbx.china.huawei.com> To: Lucy yong X-Mailer: Apple Mail (2.1510) Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "nvo3@ietf.org" , Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 26 Sep 2013 20:34:41 -0000 > Dino, >=20 > Current VXLAN format is much simpler format compared to LISP format. = To use it with LISP protocol, do you need to modify VXLAN format to = support LISP features? Lucy, the format is exactly the same. If you choose to not implement the = LISP data plane features and disable the flags, then it is exactly the = same implementation as LISP.=20 However ... VXLAN is actually harder because if you get a cache miss, you have to = look in another table to find a group address to encapsulate to. So if = you take a closer look under the cover, it is arguably harder. It = requires a hardware implementation to build a different lookup memory or = partition one memory to do two different types of lookups. Dino >=20 > Regards, > Lucy >=20 > -----Original Message----- > From: Lucy yong=20 > Sent: Thursday, September 26, 2013 2:44 PM > To: 'Dino Farinacci'; Roger J=F8rgensen > Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org > Subject: RE: [nvo3] [lisp] New Version Notification for = draft-quinn-vxlan-gpe-00.txt >=20 > Please see inline. >=20 > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf = Of Dino Farinacci > Sent: Thursday, September 26, 2013 1:57 PM > To: Roger J=F8rgensen > Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org > Subject: Re: [nvo3] [lisp] New Version Notification for = draft-quinn-vxlan-gpe-00.txt >=20 >> On Wed, Sep 25, 2013 at 9:03 PM, Dino Farinacci = wrote: >>>> Hi Noel, >>>> there's certainly no intention of keeping this out of the LISP WG, = since this is not part of the charter we just thought an individual = submission was more appropriate. >>>>=20 >>>> We just started from the very practical consideration of the = proliferation of encapsulations in the data center, and the lack of = multiprotocol support in both VXLAN and LISP. >>>=20 >>> Sorry I have to disagree. The protocols that LISP supports are *IP* = protocols and the protocols that VXLAN supports are *the rest* since it = is layer-2 solution. So this appears to be just rearranging the deck = chairs. >>=20 >> This trouble me... why do we want to mix LISP and VXLAN? What is the=20= >> gain in it? I only smell complexity. L2 in L3 over L3? >=20 > We shouldn't but let the authors reply. If you want to carry more than = IP protocols in LISP, then you use the L2 UDP port and carry MAC = addresses in LISP. You can carry all of MAC, IPv4, and IPv6 EIDs with = one control-plane, the LISP mapping database using LISP-DDT. >=20 > [Lucy] Agree. This is one way to implement L2 or L3 overlay by using = LISP protocol. However, Overlay virtual networks that use VXLAN = encapsulation may be implemented in other way too, e.g. SDN controller, = not LISP protocol. Therefore, there is a desire to extend VXLAN = encapsulation to support multiple protocols beside L2 only and make it a = generic overlay encapsulation schematics to support an overlay = application. >=20 > BTW: IMO: using UDP port to indicate payload type is not elegant = design, but acceptable for history reason only. >=20 > Lucy =20 >=20 >> How will a mix of LISP and VXLAN benefit the administrators of=20 >> datacenters, end-users in the end? >=20 > The VXLAN authors have to answer that. They came afterwards (by 5 = years). >=20 > Dino >=20 >>=20 >>=20 >>=20 >> -- >>=20 >> Roger Jorgensen | ROJO9-RIPE >> rogerj@gmail.com | - IPv6 is The Key! >> http://www.jorgensen.no | roger@jorgensen.no >>=20 >> (I really start to really dislike gmails new better editor) >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Thu Sep 26 14:06:52 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C40A21E80B5; Thu, 26 Sep 2013 14:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkAA13nTc4nb; Thu, 26 Sep 2013 14:06:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 089F421E8085; Thu, 26 Sep 2013 14:06:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYH84410; Thu, 26 Sep 2013 21:06:28 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 22:05:32 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 22:06:27 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Thu, 26 Sep 2013 14:06:23 -0700 From: Lucy yong To: Dino Farinacci Thread-Topic: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt Thread-Index: AQHOuvfXOEzzW7npoUKyOBoxO9YOZJnYgl2w Date: Thu, 26 Sep 2013 21:06:22 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D1F16@dfweml509-mbx.china.huawei.com> References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> <524329EB.7050704@cisco.com> <16DF95BC-8820-4318-899B-DA0AC10BF19E@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D452D1EBC@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.68] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "nvo3@ietf.org" , Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 26 Sep 2013 21:06:53 -0000 -----Original Message----- From: Dino Farinacci [mailto:farinacci@gmail.com]=20 Sent: Thursday, September 26, 2013 3:35 PM To: Lucy yong Cc: Roger J=F8rgensen; Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.= org Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-g= pe-00.txt > Dino, >=20 > Current VXLAN format is much simpler format compared to LISP format. To u= se it with LISP protocol, do you need to modify VXLAN format to support LIS= P features? Lucy, the format is exactly the same. If you choose to not implement the LI= SP data plane features and disable the flags, then it is exactly the same i= mplementation as LISP.=20 However ... VXLAN is actually harder because if you get a cache miss, you have to look = in another table to find a group address to encapsulate to. So if you take = a closer look under the cover, it is arguably harder. It requires a hardwar= e implementation to build a different lookup memory or partition one memory= to do two different types of lookups. [Lucy] I get it. Thank you for the explanation. It tells me that it is bett= er not going that way. Lucy Dino >=20 > Regards, > Lucy >=20 > -----Original Message----- > From: Lucy yong > Sent: Thursday, September 26, 2013 2:44 PM > To: 'Dino Farinacci'; Roger J=F8rgensen > Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org > Subject: RE: [nvo3] [lisp] New Version Notification for=20 > draft-quinn-vxlan-gpe-00.txt >=20 > Please see inline. >=20 > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf=20 > Of Dino Farinacci > Sent: Thursday, September 26, 2013 1:57 PM > To: Roger J=F8rgensen > Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org > Subject: Re: [nvo3] [lisp] New Version Notification for=20 > draft-quinn-vxlan-gpe-00.txt >=20 >> On Wed, Sep 25, 2013 at 9:03 PM, Dino Farinacci wr= ote: >>>> Hi Noel, >>>> there's certainly no intention of keeping this out of the LISP WG, sin= ce this is not part of the charter we just thought an individual submission= was more appropriate. >>>>=20 >>>> We just started from the very practical consideration of the prolifera= tion of encapsulations in the data center, and the lack of multiprotocol su= pport in both VXLAN and LISP. >>>=20 >>> Sorry I have to disagree. The protocols that LISP supports are *IP* pro= tocols and the protocols that VXLAN supports are *the rest* since it is lay= er-2 solution. So this appears to be just rearranging the deck chairs. >>=20 >> This trouble me... why do we want to mix LISP and VXLAN? What is the=20 >> gain in it? I only smell complexity. L2 in L3 over L3? >=20 > We shouldn't but let the authors reply. If you want to carry more than IP= protocols in LISP, then you use the L2 UDP port and carry MAC addresses in= LISP. You can carry all of MAC, IPv4, and IPv6 EIDs with one control-plane= , the LISP mapping database using LISP-DDT. >=20 > [Lucy] Agree. This is one way to implement L2 or L3 overlay by using LISP= protocol. However, Overlay virtual networks that use VXLAN encapsulation m= ay be implemented in other way too, e.g. SDN controller, not LISP protocol.= Therefore, there is a desire to extend VXLAN encapsulation to support mult= iple protocols beside L2 only and make it a generic overlay encapsulation s= chematics to support an overlay application. >=20 > BTW: IMO: using UDP port to indicate payload type is not elegant design, = but acceptable for history reason only. >=20 > Lucy >=20 >> How will a mix of LISP and VXLAN benefit the administrators of=20 >> datacenters, end-users in the end? >=20 > The VXLAN authors have to answer that. They came afterwards (by 5 years). >=20 > Dino >=20 >>=20 >>=20 >>=20 >> -- >>=20 >> Roger Jorgensen | ROJO9-RIPE >> rogerj@gmail.com | - IPv6 is The Key! >> http://www.jorgensen.no | roger@jorgensen.no >>=20 >> (I really start to really dislike gmails new better editor) >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From yhertogh@cisco.com Fri Sep 27 06:14:17 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720F721F9C6C; Fri, 27 Sep 2013 06:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKnFYkliK95L; Fri, 27 Sep 2013 06:14:08 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 515B921F9BD3; Fri, 27 Sep 2013 06:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3875; q=dns/txt; s=iport; t=1380287646; x=1381497246; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cuNkuu+qY8OaMjF3DP9VP7ZGqgDwbT5p4s6tIz8VK3o=; b=mN1fclNgSrLQgqmujRpE5C1++vXoXZJKiAofuEK2Hp4Cklaffkar2LmD VR4nQ20JMhDapEqPUqLaitV4Ll5kcQUC6YJwFAGVVDAGptHjNsUZS8soG ZwdbtYyj1uutR3qPjiPtgjcw2aqq4eBn2ZR5DwkpJIiP729yhrdC4jIcW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAO2DRVKtJV2Y/2dsb2JhbABZgwc4UsBLgR4WdIIlAQEBBAEBAWkCCAECDAYBCBEEAQELHSgGCxQJCAIEAQ0FCBOHWQMPDLAsDYlqjGaCOjEHBoMXgQEDiQGNE44thTSDJIIq X-IronPort-AV: E=Sophos;i="4.90,992,1371081600"; d="scan'208";a="265280559" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 27 Sep 2013 13:14:05 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8RDE56h029406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 13:14:05 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.217]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 08:14:04 -0500 From: "Yves Hertoghs (yhertogh)" To: Lucy yong , Dino Farinacci , =?iso-8859-1?Q?Roger_J=F8rgensen?= Thread-Topic: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt Thread-Index: AQHOu4NwapU07WW4V0uvpEvaR861fg== Date: Fri, 27 Sep 2013 13:14:04 +0000 Message-ID: <1FB05356C8766F4E9C16732EDC663C090D2AF36C@xmb-aln-x09.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452D1EBC@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.55.169.141] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5F8F4F9D8BC2994F811F008B6BC952CE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 27 Sep 2013 08:08:36 -0700 Cc: "nvo3@ietf.org" , Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 27 Sep 2013 13:14:17 -0000 Lucy, inline On 26/09/13 21:51, "Lucy yong" wrote: >Dino, > >Current VXLAN format is much simpler format compared to LISP format. To >use it with LISP protocol, do you need to modify VXLAN format to support >LISP features? > >Regards, >Lucy > >-----Original Message----- >From: Lucy yong=20 >Sent: Thursday, September 26, 2013 2:44 PM >To: 'Dino Farinacci'; Roger J=F8rgensen >Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org >Subject: RE: [nvo3] [lisp] New Version Notification for >draft-quinn-vxlan-gpe-00.txt > >Please see inline. > >-----Original Message----- >From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of >Dino Farinacci >Sent: Thursday, September 26, 2013 1:57 PM >To: Roger J=F8rgensen >Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org >Subject: Re: [nvo3] [lisp] New Version Notification for >draft-quinn-vxlan-gpe-00.txt > >> On Wed, Sep 25, 2013 at 9:03 PM, Dino Farinacci >>wrote: >>>> Hi Noel, >>>> there's certainly no intention of keeping this out of the LISP WG, >>>>since this is not part of the charter we just thought an individual >>>>submission was more appropriate. >>>>=20 >>>> We just started from the very practical consideration of the >>>>proliferation of encapsulations in the data center, and the lack of >>>>multiprotocol support in both VXLAN and LISP. >>>=20 >>> Sorry I have to disagree. The protocols that LISP supports are *IP* >>>protocols and the protocols that VXLAN supports are *the rest* since it >>>is layer-2 solution. So this appears to be just rearranging the deck >>>chairs. >>=20 >> This trouble me... why do we want to mix LISP and VXLAN? What is the >> gain in it? I only smell complexity. L2 in L3 over L3? > >We shouldn't but let the authors reply. If you want to carry more than IP >protocols in LISP, then you use the L2 UDP port and carry MAC addresses >in LISP. You can carry all of MAC, IPv4, and IPv6 EIDs with one >control-plane, the LISP mapping database using LISP-DDT. > >[Lucy] Agree. This is one way to implement L2 or L3 overlay by using LISP >protocol. However, Overlay virtual networks that use VXLAN encapsulation >may be implemented in other way too, e.g. SDN controller, not LISP >protocol. Therefore, there is a desire to extend VXLAN encapsulation to >support multiple protocols beside L2 only and make it a generic overlay >encapsulation schematics to support an overlay application. The NVO3 WG has a consensus (I believe) that the functions of mapping overlay addresses to underlay addresses (NVE to NVA, or NVE to NVE control plane), and the function that actually keeps that mapping information (NVA control plane) should be kept separate. In that way, an SDN northbound interface on the NVA solves that problem for you. More-over this allows one to choose its own NVE-to-NVA CP and NVE-NVE data plane/controlplane, while the SDN northbound model stays the same. > >BTW: IMO: using UDP port to indicate payload type is not elegant design, >but acceptable for history reason only. Why ? > >Lucy =20 > >> How will a mix of LISP and VXLAN benefit the administrators of >> datacenters, end-users in the end? > >The VXLAN authors have to answer that. They came afterwards (by 5 years). > >Dino > >>=20 >>=20 >>=20 >> -- >>=20 >> Roger Jorgensen | ROJO9-RIPE >> rogerj@gmail.com | - IPv6 is The Key! >> http://www.jorgensen.no | roger@jorgensen.no >>=20 >> (I really start to really dislike gmails new better editor) > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From jmh@joelhalpern.com Fri Sep 27 08:16:18 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D32A11E815F for ; Fri, 27 Sep 2013 08:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm7VHbxzQaLg for ; Fri, 27 Sep 2013 08:16:13 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id AE61411E814D for ; Fri, 27 Sep 2013 08:16:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id EF5D91C0896 for ; Fri, 27 Sep 2013 08:16:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2490E1C088E for ; Fri, 27 Sep 2013 08:16:09 -0700 (PDT) Message-ID: <5245A13A.3010704@joelhalpern.com> Date: Fri, 27 Sep 2013 11:16:10 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "lisp@ietf.org" References: <523C887B.308@cisco.com> In-Reply-To: <523C887B.308@cisco.com> X-Forwarded-Message-Id: <523C887B.308@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [lisp] Fwd: Re: LISP Interim X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 27 Sep 2013 15:16:18 -0000 Reminder, the LISP interim is on Thursday and Friday, October 3 and 4. Very rough agenda, sketched as a type, not yet reviewed with co-chair: Webex setup, Introduction and Agenda Bash - 10:00 Oct 3 Start Discussing LISP{ Introduction Document - 10:15 ToC, then Section by section and paragraph by paragraph Lunch Break - 1200 - 1330 Continue Intro review Complete Intro and Break - 1700 Resume at 0900 on October 4. Discuss LISP Threats document Discuss LISP Perspective document Lunch break - 1200 - 1330 Continue LISP Perpective document Discuss direction of WG and work modes Discuss LISP LCAF document Finish by 1600 Sorry I can not tell webex folks even roughly when the times will break between documents. Yours, Joel -------- Original Message -------- Subject: Re: LISP Interim Date: Fri, 20 Sep 2013 10:40:11 -0700 From: Fabio Maino To: Joel M. Halpern CC: Terry Manderson Hi there, once in the lobby people can call me at 408 332 9024, and I'll pick them up. I'll have temporary badge ready for those that RSVPd. Webex info for thursday and friday: THURSDAY ======= Topic: LISP WG Interim Date: Thursday, October 3, 2013 Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 202 554 736 Meeting Password: lisp Host Key: 378028 (use this to reclaim host privileges) ------------------------------------------------------- To start the online meeting ------------------------------------------------------- 1. Go to https://cisco.webex.com/cisco/j.php?ED=235837812&UID=484339687&PW=NZjRjNzE5YjQ2&RT=MiM0 2. Log in to your account. 3. Click "Start Now". 4. Follow the instructions that appear on your screen. FRIDAY ===== Topic: LISP WG Interim Date: Friday, October 4, 2013 Time: 5:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 206 145 606 Meeting Password: lisp Host Key: 264402 (use this to reclaim host privileges) ------------------------------------------------------- To start the online meeting ------------------------------------------------------- 1. Go to https://cisco.webex.com/cisco/j.php?ED=235837932&UID=484339687&PW=NNzljOTBmNTAz&RT=MiM0 2. Log in to your account. 3. Click "Start Now". 4. Follow the instructions that appear on your screen. ---------------------------------------------------------------- ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/cisco/mc 2. On the left navigation bar, click "Support". To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://cisco.webex.com/cisco/j.php?ED=235837812&UID=484339687&ICS=MS&LD=1&RD=2&SHA2=AAAAAu9x/ImnHNvzEl1jC5P6RJAfxAzL5qMtneiDDO/ymndP&ST=1 To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://cisco.webex.com/cisco/systemdiagnosis.php. http://www.webex.com On 9/19/13 10:56 AM, Joel M. Halpern wrote: > Thanks again for hosting the LISP interim. > A couple of more specific questions: > 1) Who should we ask for, or what room, when we get there on October > 3? You? > > And can you provide us with the webex details so we can circulate > those to the list? > > Thank you, > Joel From farinacci@gmail.com Fri Sep 27 08:57:27 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F281411E810A for ; Fri, 27 Sep 2013 08:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.997 X-Spam-Level: ** X-Spam-Status: No, score=2.997 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pws9vktGL3aC for ; Fri, 27 Sep 2013 08:57:12 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 47AC011E8162 for ; Fri, 27 Sep 2013 08:56:49 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id wp18so3307468obc.36 for ; Fri, 27 Sep 2013 08:56:48 -0700 (PDT) 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=IBj/oQu+tsi8BJg0yMyNeK8hiquTWuY7GPy/lDui6Og=; b=UfQNHuP0umPIIUv0LDgR4UiNN1yyGWUjTtKYqXFi8C91HWvnF1dkbKa9JIaTGk0rwU R/dwTW0FXXAkJS2+C3ENlIwkRNxjJHX2lYreeHPIp2GlQSjJRBV6QHKecJhvzr0TiC1E 7QLHPACnGpQbR7tw/JRmjofPQaoITCj9KjfSST/phGau/D1GhkMNQkPUGuwXIRD1ltN/ glop33GrkOMVm0nwVr6g7u27PAb4gcqxmYCRAr5B0lA5zW897ULJGovlMxYgOqL9ID7d 9argQE1fwEjbHthAo7J9/PG0MaOjNWeW/bPsR/9koVv1Om0IpUP9fL9Ye36MbBFrE3Jg 1K7g== X-Received: by 10.60.115.10 with SMTP id jk10mr1034065oeb.74.1380297408695; Fri, 27 Sep 2013 08:56:48 -0700 (PDT) Received: from [10.38.108.95] (mobile-198-228-193-036.mycingular.net. [198.228.193.36]) by mx.google.com with ESMTPSA id nw5sm11010718obc.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 08:56:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11A470a) In-Reply-To: <5245A13A.3010704@joelhalpern.com> Date: Fri, 27 Sep 2013 11:56:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <56E4CDDF-F254-477A-831B-A8AD11956080@gmail.com> References: <523C887B.308@cisco.com> <5245A13A.3010704@joelhalpern.com> To: "Joel M. Halpern" Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: Re: LISP Interim X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 27 Sep 2013 15:57:28 -0000 Joel - can you send the address of the location. Thanks. =20 Dino > On Sep 27, 2013, at 11:16 AM, "Joel M. Halpern" wrot= e: >=20 > Reminder, the LISP interim is on Thursday and Friday, October 3 and 4. >=20 > Very rough agenda, sketched as a type, not yet reviewed with co-chair: >=20 > Webex setup, Introduction and Agenda Bash - 10:00 Oct 3 > Start Discussing LISP{ Introduction Document - 10:15 > ToC, then Section by section and paragraph by paragraph >=20 > Lunch Break - 1200 - 1330 >=20 > Continue Intro review >=20 > Complete Intro and Break - 1700 >=20 > Resume at 0900 on October 4. > Discuss LISP Threats document > Discuss LISP Perspective document >=20 > Lunch break - 1200 - 1330 >=20 > Continue LISP Perpective document >=20 > Discuss direction of WG and work modes >=20 > Discuss LISP LCAF document >=20 > Finish by 1600 >=20 > Sorry I can not tell webex folks even roughly when the times will break be= tween documents. >=20 > Yours, > Joel >=20 >=20 > -------- Original Message -------- > Subject: Re: LISP Interim > Date: Fri, 20 Sep 2013 10:40:11 -0700 > From: Fabio Maino > To: Joel M. Halpern > CC: Terry Manderson >=20 > Hi there, > once in the lobby people can call me at 408 332 9024, and I'll pick them > up. I'll have temporary badge ready for those that RSVPd. >=20 > Webex info for thursday and friday: >=20 > THURSDAY > =3D=3D=3D=3D=3D=3D=3D > Topic: LISP WG Interim > Date: Thursday, October 3, 2013 > Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) > Meeting Number: 202 554 736 > Meeting Password: lisp > Host Key: 378028 (use this to reclaim host privileges) >=20 > ------------------------------------------------------- > To start the online meeting > ------------------------------------------------------- > 1. Go to > https://cisco.webex.com/cisco/j.php?ED=3D235837812&UID=3D484339687&PW=3DNZ= jRjNzE5YjQ2&RT=3DMiM0 > 2. Log in to your account. > 3. Click "Start Now". > 4. Follow the instructions that appear on your screen. >=20 >=20 >=20 >=20 > FRIDAY > =3D=3D=3D=3D=3D > Topic: LISP WG Interim > Date: Friday, October 4, 2013 > Time: 5:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) > Meeting Number: 206 145 606 > Meeting Password: lisp > Host Key: 264402 (use this to reclaim host privileges) >=20 > ------------------------------------------------------- > To start the online meeting > ------------------------------------------------------- > 1. Go to > https://cisco.webex.com/cisco/j.php?ED=3D235837932&UID=3D484339687&PW=3DNN= zljOTBmNTAz&RT=3DMiM0 > 2. Log in to your account. > 3. Click "Start Now". > 4. Follow the instructions that appear on your screen. >=20 >=20 >=20 >=20 >=20 > ---------------------------------------------------------------- > ALERT =E2=80=93 PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN= THE > (408) OR (919) AREA CODES > ---------------------------------------------------------------- > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 > Dialing the WebEx toll free numbers from within 408 or 919 area codes is > not enabled (non-Cisco phones). =E2=80=9C If you dial the toll-free number= s > within the 408 or 919 area codes you will be instructed to hang up and > dial the local access number.=E2=80=9D Please use the call-back option whe= never > possible and otherwise dial local numbers only. The affected toll free > numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) > 349-3520 for the RTP area. >=20 > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or > Access Code followed by the # sign. >=20 > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 >=20 > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >=20 > India: +91.80.4350.1111 Germany: +49.619.6773.9002 >=20 > Japan: +81.3.5763.9394 China: +86.10.8515.5666 >=20 > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://cisco.webex.com/cisco/mc > 2. On the left navigation bar, click "Support". > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://cisco.webex.com/cisco/j.php?ED=3D235837812&UID=3D484339687&ICS=3DM= S&LD=3D1&RD=3D2&SHA2=3DAAAAAu9x/ImnHNvzEl1jC5P6RJAfxAzL5qMtneiDDO/ymndP&ST=3D= 1 >=20 > To check whether you have the appropriate players installed for UCF > (Universal Communications Format) rich media files, go to > https://cisco.webex.com/cisco/systemdiagnosis.php. >=20 > http://www.webex.com >=20 >=20 >=20 >=20 >=20 >=20 >> On 9/19/13 10:56 AM, Joel M. Halpern wrote: >> Thanks again for hosting the LISP interim. >> A couple of more specific questions: >> 1) Who should we ask for, or what room, when we get there on October >> 3? You? >>=20 >> And can you provide us with the webex details so we can circulate >> those to the list? >>=20 >> Thank you, >> Joel >=20 >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From fmaino@cisco.com Fri Sep 27 09:00:14 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE7321F92B9 for ; Fri, 27 Sep 2013 09:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF51Jumb1sdH for ; Fri, 27 Sep 2013 09:00:01 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42821F9D52 for ; Fri, 27 Sep 2013 09:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5961; q=dns/txt; s=iport; t=1380297601; x=1381507201; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PeNRbXj03ZbkZgowhi60zEx4KLwmPkHDSQHi5mjsGBw=; b=QHYfJefN1Of40Y6RxOQq+iPzpCstawI8K1Ec124a0Cl5XFXpYXad/4Eg VycSMoZdZH9Zop1mfs0W8fB2TMX3wgqG2LTGDoMw/AHdmgtQI81q9LN2q pUJ0Z0QnUT4vvymrj+tLXknVXuMn4SuMQ3ATn7iIdgtYft21MnYFKiCRM o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAKqqRVKrRDoI/2dsb2JhbABAFwODBziDe70igRwWdIIlAQEBBAEBARsFDwEFEA0RCAoBDAQLEQMBAgECAgULAQMHBQYCAgkDAgECARUoBwEDAw0BBQIBAYgBDTanLoQlEY1ygSmMensjEAcGBAcHglKBNgOJOY5GgS+FA4tGglJyHIEsCRcEgRc X-IronPort-AV: E=Sophos;i="4.90,994,1371081600"; d="scan'208";a="93313703" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 27 Sep 2013 15:59:57 +0000 Received: from [10.21.112.134] (sjc-vpn2-134.cisco.com [10.21.112.134]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8RFxufm018215; Fri, 27 Sep 2013 15:59:56 GMT Message-ID: <5245AB7C.8060708@cisco.com> Date: Fri, 27 Sep 2013 08:59:56 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dino Farinacci References: <523C887B.308@cisco.com> <5245A13A.3010704@joelhalpern.com> <56E4CDDF-F254-477A-831B-A8AD11956080@gmail.com> In-Reply-To: <56E4CDDF-F254-477A-831B-A8AD11956080@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: Re: LISP Interim X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 27 Sep 2013 16:00:14 -0000 The meeting will be held at the Cisco facilities located at: 13600 Dulles Technology Drive Herndon, Virginia 20171 When you get in the lobby call me at 408 332 9024 and I'll pick you up. Fabio On 9/27/13 8:56 AM, Dino Farinacci wrote: > Joel - can you send the address of the location. Thanks. > > Dino > >> On Sep 27, 2013, at 11:16 AM, "Joel M. Halpern" wrote: >> >> Reminder, the LISP interim is on Thursday and Friday, October 3 and 4. >> >> Very rough agenda, sketched as a type, not yet reviewed with co-chair: >> >> Webex setup, Introduction and Agenda Bash - 10:00 Oct 3 >> Start Discussing LISP{ Introduction Document - 10:15 >> ToC, then Section by section and paragraph by paragraph >> >> Lunch Break - 1200 - 1330 >> >> Continue Intro review >> >> Complete Intro and Break - 1700 >> >> Resume at 0900 on October 4. >> Discuss LISP Threats document >> Discuss LISP Perspective document >> >> Lunch break - 1200 - 1330 >> >> Continue LISP Perpective document >> >> Discuss direction of WG and work modes >> >> Discuss LISP LCAF document >> >> Finish by 1600 >> >> Sorry I can not tell webex folks even roughly when the times will break between documents. >> >> Yours, >> Joel >> >> >> -------- Original Message -------- >> Subject: Re: LISP Interim >> Date: Fri, 20 Sep 2013 10:40:11 -0700 >> From: Fabio Maino >> To: Joel M. Halpern >> CC: Terry Manderson >> >> Hi there, >> once in the lobby people can call me at 408 332 9024, and I'll pick them >> up. I'll have temporary badge ready for those that RSVPd. >> >> Webex info for thursday and friday: >> >> THURSDAY >> ======= >> Topic: LISP WG Interim >> Date: Thursday, October 3, 2013 >> Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) >> Meeting Number: 202 554 736 >> Meeting Password: lisp >> Host Key: 378028 (use this to reclaim host privileges) >> >> ------------------------------------------------------- >> To start the online meeting >> ------------------------------------------------------- >> 1. Go to >> https://cisco.webex.com/cisco/j.php?ED=235837812&UID=484339687&PW=NZjRjNzE5YjQ2&RT=MiM0 >> 2. Log in to your account. >> 3. Click "Start Now". >> 4. Follow the instructions that appear on your screen. >> >> >> >> >> FRIDAY >> ===== >> Topic: LISP WG Interim >> Date: Friday, October 4, 2013 >> Time: 5:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) >> Meeting Number: 206 145 606 >> Meeting Password: lisp >> Host Key: 264402 (use this to reclaim host privileges) >> >> ------------------------------------------------------- >> To start the online meeting >> ------------------------------------------------------- >> 1. Go to >> https://cisco.webex.com/cisco/j.php?ED=235837932&UID=484339687&PW=NNzljOTBmNTAz&RT=MiM0 >> 2. Log in to your account. >> 3. Click "Start Now". >> 4. Follow the instructions that appear on your screen. >> >> >> >> >> >> ---------------------------------------------------------------- >> ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE >> (408) OR (919) AREA CODES >> ---------------------------------------------------------------- >> Please dial the local access number for your area from the list below: >> - San Jose/Milpitas (408) area: 525-6800 >> - RTP (919) area: 392-3330 >> Dialing the WebEx toll free numbers from within 408 or 919 area codes is >> not enabled (non-Cisco phones). “ If you dial the toll-free numbers >> within the 408 or 919 area codes you will be instructed to hang up and >> dial the local access number.†Please use the call-back option whenever >> possible and otherwise dial local numbers only. The affected toll free >> numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) >> 349-3520 for the RTP area. >> >> ------------------------------------------------------- >> To join the teleconference only >> ------------------------------------------------------- >> 1. Dial into Cisco WebEx (view all Global Access Numbers at >> http://cisco.com/en/US/about/doing_business/conferencing/index.html >> 2. Follow the prompts to enter the Meeting Number (listed above) or >> Access Code followed by the # sign. >> >> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 >> >> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >> >> India: +91.80.4350.1111 Germany: +49.619.6773.9002 >> >> Japan: +81.3.5763.9394 China: +86.10.8515.5666 >> >> ------------------------------------------------------- >> For assistance >> ------------------------------------------------------- >> 1. Go to https://cisco.webex.com/cisco/mc >> 2. On the left navigation bar, click "Support". >> To add this meeting to your calendar program (for example Microsoft >> Outlook), click this link: >> https://cisco.webex.com/cisco/j.php?ED=235837812&UID=484339687&ICS=MS&LD=1&RD=2&SHA2=AAAAAu9x/ImnHNvzEl1jC5P6RJAfxAzL5qMtneiDDO/ymndP&ST=1 >> >> To check whether you have the appropriate players installed for UCF >> (Universal Communications Format) rich media files, go to >> https://cisco.webex.com/cisco/systemdiagnosis.php. >> >> http://www.webex.com >> >> >> >> >> >> >>> On 9/19/13 10:56 AM, Joel M. Halpern wrote: >>> Thanks again for hosting the LISP interim. >>> A couple of more specific questions: >>> 1) Who should we ask for, or what room, when we get there on October >>> 3? You? >>> >>> And can you provide us with the webex details so we can circulate >>> those to the list? >>> >>> Thank you, >>> Joel >> >> >> >> _______________________________________________ >> 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 fmaino@cisco.com Fri Sep 27 09:10:08 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFCA11E8101 for ; Fri, 27 Sep 2013 09:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.899 X-Spam-Level: X-Spam-Status: No, score=-9.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hpmBpYHgTL1 for ; Fri, 27 Sep 2013 09:10:03 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0A711E8162 for ; Fri, 27 Sep 2013 09:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6926; q=dns/txt; s=iport; t=1380298195; x=1381507795; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=M7YUni+UnnPf5yTJhX8eYX0TCEc4Qr2d79pzRD1gA2k=; b=KLXUCiQ58VJGTh80qu2YaqFR1hL457X9FHBJs3mzBghDonsGKpRx2Bxq 6HNDGB+Q50Yx1geo8zWoDX6Cvf64Or1D7Xt4OwMZW3SCJAGmyq1wVWHgg Iej7EiWgGG1lZqiZIl6TI5DRie7f2nK8gibcq2KuBXQtSBDsp6L5KhHNC Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFALesRVKrRDoI/2dsb2JhbABBFwODBziDe70igRwWdIIlAQEBBAEBARsFDwEFEA0RAgYKAQwECxEDAQIBAgIFCwEDBwUGAgIJAwIBAgEVKAcBAxABBQIBAYgBDTanHYQlEY1ygSmMensjEAcGBAcHglKBNgOJOY5GgS+FA4tGglJyHIEsCRcEgRc X-IronPort-AV: E=Sophos;i="4.90,994,1371081600"; d="scan'208";a="93314497" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 27 Sep 2013 16:09:45 +0000 Received: from [10.21.112.134] (sjc-vpn2-134.cisco.com [10.21.112.134]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8RG9iXf024167; Fri, 27 Sep 2013 16:09:44 GMT Message-ID: <5245ADC8.4070807@cisco.com> Date: Fri, 27 Sep 2013 09:09:44 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: lisp@ietf.org References: <523C887B.308@cisco.com> <5245A13A.3010704@joelhalpern.com> <56E4CDDF-F254-477A-831B-A8AD11956080@gmail.com> <5245AB7C.8060708@cisco.com> In-Reply-To: <5245AB7C.8060708@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [lisp] Fwd: Re: LISP Interim X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 27 Sep 2013 16:10:08 -0000 Here is a detailed pointer to Building 6 Wilson, where the conference room is located: https://maps.google.com/maps?q=38.955236,-77.414279+(HERNDON+6+WILSON)&t=h&iwloc=A&hl=en&ll=38.955236,-77.414279&spn=0.005,0.005 For those staying at the Hyatt Place, I think it's walking distance: https://maps.google.com/maps?saddr=hyatt+place&daddr=38.955236,-77.414279+(HERNDON+6+WILSON)&hl=en&sll=38.955786,-77.416956&sspn=0.005698,0.011362&geocode=Ff1xUgIdmqhi-yGytDcE4yx4wykV3hgpnUe2iTGytDcE4yx4ww%3BFeRoUgIdecBi-w&t=h&dirflg=w&mra=prev&z=17 Fabio On 9/27/13 8:59 AM, Fabio Maino wrote: > The meeting will be held at the Cisco facilities located at: > 13600 Dulles Technology Drive > Herndon, Virginia 20171 > > When you get in the lobby call me at 408 332 9024 and I'll pick you up. > > Fabio > > > On 9/27/13 8:56 AM, Dino Farinacci wrote: >> Joel - can you send the address of the location. Thanks. >> >> Dino >> >>> On Sep 27, 2013, at 11:16 AM, "Joel M. Halpern" >>> wrote: >>> >>> Reminder, the LISP interim is on Thursday and Friday, October 3 and 4. >>> >>> Very rough agenda, sketched as a type, not yet reviewed with co-chair: >>> >>> Webex setup, Introduction and Agenda Bash - 10:00 Oct 3 >>> Start Discussing LISP{ Introduction Document - 10:15 >>> ToC, then Section by section and paragraph by paragraph >>> >>> Lunch Break - 1200 - 1330 >>> >>> Continue Intro review >>> >>> Complete Intro and Break - 1700 >>> >>> Resume at 0900 on October 4. >>> Discuss LISP Threats document >>> Discuss LISP Perspective document >>> >>> Lunch break - 1200 - 1330 >>> >>> Continue LISP Perpective document >>> >>> Discuss direction of WG and work modes >>> >>> Discuss LISP LCAF document >>> >>> Finish by 1600 >>> >>> Sorry I can not tell webex folks even roughly when the times will >>> break between documents. >>> >>> Yours, >>> Joel >>> >>> >>> -------- Original Message -------- >>> Subject: Re: LISP Interim >>> Date: Fri, 20 Sep 2013 10:40:11 -0700 >>> From: Fabio Maino >>> To: Joel M. Halpern >>> CC: Terry Manderson >>> >>> Hi there, >>> once in the lobby people can call me at 408 332 9024, and I'll pick >>> them >>> up. I'll have temporary badge ready for those that RSVPd. >>> >>> Webex info for thursday and friday: >>> >>> THURSDAY >>> ======= >>> Topic: LISP WG Interim >>> Date: Thursday, October 3, 2013 >>> Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) >>> Meeting Number: 202 554 736 >>> Meeting Password: lisp >>> Host Key: 378028 (use this to reclaim host privileges) >>> >>> ------------------------------------------------------- >>> To start the online meeting >>> ------------------------------------------------------- >>> 1. Go to >>> https://cisco.webex.com/cisco/j.php?ED=235837812&UID=484339687&PW=NZjRjNzE5YjQ2&RT=MiM0 >>> >>> 2. Log in to your account. >>> 3. Click "Start Now". >>> 4. Follow the instructions that appear on your screen. >>> >>> >>> >>> >>> FRIDAY >>> ===== >>> Topic: LISP WG Interim >>> Date: Friday, October 4, 2013 >>> Time: 5:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) >>> Meeting Number: 206 145 606 >>> Meeting Password: lisp >>> Host Key: 264402 (use this to reclaim host privileges) >>> >>> ------------------------------------------------------- >>> To start the online meeting >>> ------------------------------------------------------- >>> 1. Go to >>> https://cisco.webex.com/cisco/j.php?ED=235837932&UID=484339687&PW=NNzljOTBmNTAz&RT=MiM0 >>> >>> 2. Log in to your account. >>> 3. Click "Start Now". >>> 4. Follow the instructions that appear on your screen. >>> >>> >>> >>> >>> >>> ---------------------------------------------------------------- >>> ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE >>> (408) OR (919) AREA CODES >>> ---------------------------------------------------------------- >>> Please dial the local access number for your area from the list below: >>> - San Jose/Milpitas (408) area: 525-6800 >>> - RTP (919) area: 392-3330 >>> Dialing the WebEx toll free numbers from within 408 or 919 area >>> codes is >>> not enabled (non-Cisco phones). “ If you dial the toll-free numbers >>> within the 408 or 919 area codes you will be instructed to hang up and >>> dial the local access number.†Please use the call-back option whenever >>> possible and otherwise dial local numbers only. The affected toll free >>> numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) >>> 349-3520 for the RTP area. >>> >>> ------------------------------------------------------- >>> To join the teleconference only >>> ------------------------------------------------------- >>> 1. Dial into Cisco WebEx (view all Global Access Numbers at >>> http://cisco.com/en/US/about/doing_business/conferencing/index.html >>> 2. Follow the prompts to enter the Meeting Number (listed above) or >>> Access Code followed by the # sign. >>> >>> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 >>> >>> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >>> >>> India: +91.80.4350.1111 Germany: +49.619.6773.9002 >>> >>> Japan: +81.3.5763.9394 China: +86.10.8515.5666 >>> >>> ------------------------------------------------------- >>> For assistance >>> ------------------------------------------------------- >>> 1. Go to https://cisco.webex.com/cisco/mc >>> 2. On the left navigation bar, click "Support". >>> To add this meeting to your calendar program (for example Microsoft >>> Outlook), click this link: >>> https://cisco.webex.com/cisco/j.php?ED=235837812&UID=484339687&ICS=MS&LD=1&RD=2&SHA2=AAAAAu9x/ImnHNvzEl1jC5P6RJAfxAzL5qMtneiDDO/ymndP&ST=1 >>> >>> >>> To check whether you have the appropriate players installed for UCF >>> (Universal Communications Format) rich media files, go to >>> https://cisco.webex.com/cisco/systemdiagnosis.php. >>> >>> http://www.webex.com >>> >>> >>> >>> >>> >>> >>>> On 9/19/13 10:56 AM, Joel M. Halpern wrote: >>>> Thanks again for hosting the LISP interim. >>>> A couple of more specific questions: >>>> 1) Who should we ask for, or what room, when we get there on October >>>> 3? You? >>>> >>>> And can you provide us with the webex details so we can circulate >>>> those to the list? >>>> >>>> Thank you, >>>> Joel >>> >>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From lucy.yong@huawei.com Fri Sep 27 10:58:30 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9539F21F969F; Fri, 27 Sep 2013 10:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDIom+8uPSna; Fri, 27 Sep 2013 10:58:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DE1BD1F0D21; Fri, 27 Sep 2013 10:58:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYI81166; Fri, 27 Sep 2013 17:58:18 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 18:57:18 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 18:58:16 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Fri, 27 Sep 2013 10:58:11 -0700 From: Lucy yong To: "Yves Hertoghs (yhertogh)" , Dino Farinacci , =?iso-8859-1?Q?Roger_J=F8rgensen?= Thread-Topic: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt Thread-Index: AQHOu4OBosJgQUYJ2Um95ZR3cSt9a5nZ0etg Date: Fri, 27 Sep 2013 17:58:10 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D23A3@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452D1EBC@dfweml509-mbx.china.huawei.com> <1FB05356C8766F4E9C16732EDC663C090D2AF36C@xmb-aln-x09.cisco.com> In-Reply-To: <1FB05356C8766F4E9C16732EDC663C090D2AF36C@xmb-aln-x09.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.136] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 27 Sep 2013 17:58:31 -0000 Hi Yves, -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Yve= s Hertoghs (yhertogh) Sent: Friday, September 27, 2013 8:14 AM To: Lucy yong; Dino Farinacci; Roger J=F8rgensen Cc: Fabio Maino (fmaino); nvo3@ietf.org; Noel Chiappa; lisp@ietf.org Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-g= pe-00.txt Lucy, inline On 26/09/13 21:51, "Lucy yong" wrote: >Dino, > >Current VXLAN format is much simpler format compared to LISP format. To=20 >use it with LISP protocol, do you need to modify VXLAN format to=20 >support LISP features? > >Regards, >Lucy > >-----Original Message----- >From: Lucy yong >Sent: Thursday, September 26, 2013 2:44 PM >To: 'Dino Farinacci'; Roger J=F8rgensen >Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org >Subject: RE: [nvo3] [lisp] New Version Notification for=20 >draft-quinn-vxlan-gpe-00.txt > >Please see inline. > >-----Original Message----- >From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of=20 >Dino Farinacci >Sent: Thursday, September 26, 2013 1:57 PM >To: Roger J=F8rgensen >Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org >Subject: Re: [nvo3] [lisp] New Version Notification for=20 >draft-quinn-vxlan-gpe-00.txt > >> On Wed, Sep 25, 2013 at 9:03 PM, Dino Farinacci >>wrote: >>>> Hi Noel, >>>> there's certainly no intention of keeping this out of the LISP WG,=20 >>>>since this is not part of the charter we just thought an individual=20 >>>>submission was more appropriate. >>>>=20 >>>> We just started from the very practical consideration of the=20 >>>>proliferation of encapsulations in the data center, and the lack of=20 >>>>multiprotocol support in both VXLAN and LISP. >>>=20 >>> Sorry I have to disagree. The protocols that LISP supports are *IP*=20 >>>protocols and the protocols that VXLAN supports are *the rest* since=20 >>>it is layer-2 solution. So this appears to be just rearranging the=20 >>>deck chairs. >>=20 >> This trouble me... why do we want to mix LISP and VXLAN? What is the=20 >> gain in it? I only smell complexity. L2 in L3 over L3? > >We shouldn't but let the authors reply. If you want to carry more than=20 >IP protocols in LISP, then you use the L2 UDP port and carry MAC=20 >addresses in LISP. You can carry all of MAC, IPv4, and IPv6 EIDs with=20 >one control-plane, the LISP mapping database using LISP-DDT. > >[Lucy] Agree. This is one way to implement L2 or L3 overlay by using=20 >LISP protocol. However, Overlay virtual networks that use VXLAN=20 >encapsulation may be implemented in other way too, e.g. SDN controller,=20 >not LISP protocol. Therefore, there is a desire to extend VXLAN=20 >encapsulation to support multiple protocols beside L2 only and make it=20 >a generic overlay encapsulation schematics to support an overlay applicati= on. The NVO3 WG has a consensus (I believe) that the functions of mapping overl= ay addresses to underlay addresses (NVE to NVA, or NVE to NVE control plane= ), and the function that actually keeps that mapping information (NVA contr= ol plane) should be kept separate. In that way, an SDN northbound interfac= e on the NVA solves that problem for you. More-over this allows one to cho= ose its own NVE-to-NVA CP and NVE-NVE data plane/controlplane, while the SD= N northbound model stays the same. [Lucy] SDN controller in my text is about NVA. Nothing to do with SDN north= bound interface. We may cross each other's view. Yes, the nvo3 architecture= /framework specifies the model and these components. That model allows NVE = and NVA to be separated and have a protocol in between to convey the mappin= g information. The WG does not confine a protocol solution yet. That is my = point.=20 > >BTW: IMO: using UDP port to indicate payload type is not elegant=20 >design, but acceptable for history reason only. Why ? [Lucy] TCP/UDP port is used for demultiplexing transport connection or iden= tifying a service. Demultiplex payload type does not fit into neither purpo= se and consumes the port numbers. Please take a look. http://datatracker.ie= tf.org/doc/draft-ietf-tsvwg-port-use/ Regards, Lucy > >Lucy > >> How will a mix of LISP and VXLAN benefit the administrators of=20 >> datacenters, end-users in the end? > >The VXLAN authors have to answer that. They came afterwards (by 5 years). > >Dino > >>=20 >>=20 >>=20 >> -- >>=20 >> Roger Jorgensen | ROJO9-RIPE >> rogerj@gmail.com | - IPv6 is The Key! >> http://www.jorgensen.no | roger@jorgensen.no >>=20 >> (I really start to really dislike gmails new better editor) > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From jnc@mercury.lcs.mit.edu Fri Sep 27 19:17:10 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6971321E8094 for ; Fri, 27 Sep 2013 19:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G46Ibjp9wBgZ for ; Fri, 27 Sep 2013 19:17:01 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7A86821F996A for ; Fri, 27 Sep 2013 19:17:01 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 97E4618C10A; Fri, 27 Sep 2013 22:16:58 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130928021658.97E4618C10A@mercury.lcs.mit.edu> Date: Fri, 27 Sep 2013 22:16:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments to draft-ietf-lisp-introduction-02 (tranche #2) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 28 Sep 2013 02:17:10 -0000 > Noel, here are my comments. After a (unfortunately long) diversion into multicast (from one of your comments), here is the second tranche of replies to your comments. As before, I did not _always_ agree with your comments, and the ones where I did not, I have attempted to explain my reasoning for disagreeing. (Ones I agreed with I have edited out, to keep the size down.) Noel ---- >> The data plane functions in ITRs include ... >> [[S2: Anything else?]] > Well, possibly doing some control functions are storing some state. Like > echo-nonces, or adding to counters for per RLOC/per-EID packet counters. The low-level housekeeping stuff (like counters) is too detailed to be mentioned at this early stage (and in any case, it's not really a procotol thing, so I'm not sure I should mention it at all - although I suppose those counters are in the MIB, now that I think about it? As for the piggybacking (sucks teeth..) again, probably too early to mention that. There is a whole sub-section later (9.3. "Header Control Channel") which covers it in some detail. >> checking for the reachability and liveness of their neighbour ETRs; and >> checking for outdated mappings and requesting updates. > Remove "neighbour". ETRs are anything but close to the ITRs. At the 'LISP packet switch' level, they are neighbours. See the section "Another Packet-Switching Layer" in the Perspectives document. Two BGP neighbours attached to an ATM network were still referred to as 'neighbours', even though there might have actually been a number of ATM packet switches etween them, right? By definition, _at the LISP layer_, an ITR has as a 'LISP neighbour' the ETR it is sending packet to... >> In the ETR, control plane functions include >> [[S3: Missing anything here? ...]] > Yes, missing a big part. Registering their mappings to the mapping > system. That is what ETRs do in the control plane. And they also process > Map-Requests and send Map-Replies. Err, it says "interacting with the mapping sub-system ... and answering requests for mappings"!! Which is just those two functions you just listed? I have added a few words about what the first entails, but I don't want to expand on it too much (remember how you told me not to be repetitive :-), and this is covered in great detail in section 10.1, "The Mapping System Interface". > This is too detail You're behind the curve :-), I had already decided to move a lot of it: http://www.ietf.org/mail-archive/web/lisp/current/msg04635.html > the data may change in the future to obsolete the numbers provided > above. I did worry about that (and in fact referred to it directly "Obviously, these studies are all snapshots of a particular point in time, and as the Internet continues its life-cycle they will increasingly become out-dated."), but I felt that I needed to be a bit more concrete than 'Oh, it will work fine'; after all, how many people are actually going to track down the paper and slog through 10 pages or so _more stuff_ it to see what it says? Anyway, I'll see if on the next pass through I can trim it down and balance (as everying in this blasted document) on the fine edge between 'not enough' and 'too much'. > There will be a lot more research so citing just these 4 will make this > document incomplete. We don't want that. Yes, but the demand caching of mappings is the thing that gets the most FUD about the entire design. I feel there have to be some hard data put right out front to show that this has been studied in some detail, and that there is actual empirical data to show that it will work. And I can only cite what's available _when the document_ was written - we cannot wait for more work to be done! > I think you should summarize what properties were considered and what > high-level conclusions were made. Easy to say! But I have tried to boil this section down considerably, and tried to say something about the conclusions (more than just simply 'it will work', which is in some sense the highest level conclusion that was reached). >> 6.2.2. Interface to the Mapping System > Earlier in this commentary, I suggested "API". Like I said, to me "API" means "programming interface", and I'm thinking in somewhat more general terms. >> Similarly, the client interface to the indexing system from an ETR's >> point of view is through devices called Map Servers (MSs - admittedly a >> poorly chosen term, since their primary function is not to respond to >> queries, but it's too late to change it now). > I would strike the text in the parens. They are serving registrations so > the term would be good as anything else. Hmm. It took me a long time to get used to the terminology: I kept thinking that a server was something that the clients of the system would go to for information, and of course MS's don't generally do this (they are neither the machines that the ITRs go to, nor the machines that give mappings to the ITRS - they're just the penultimate leaves in the delegation tree). I have changed the wording, perhaps it's better now? >> ETRs send registration control messages (Map-Register packets) to an >> MS, which makes the information about the mappings which the ETR >> indicates it is authoritative for available to the indexing system. The >> MS formulates a reply control message (the Map-Notify packet), > Change "Map-Notify" to "Map-Reply". Huh? I'm talking about _registration_ here. Map-Notify is the acknowledgement to a Map-Register, no? Map-Replies are in response to Map-Requests, right? >> robustness, any particular node in the DDT delegation tree may be >> instantiated in more than one redundant physical server machines. >> Obviously, all the servers which instantiate a particular node in the >> tree have to have identical data about that node. > Don't use "server" here because it could imply or mislead the reader to > think "Map-Servers". I think the best noun is "DDT-nodes" or describe > from a parent node's reference and call them child nodes as you did in > the uprevious paragraph. I am trying to draw a distinction between the _delegation tree_ (which is abstract), and its instantiation as data in a set of servers. This _exactly_ parallels DNS, which has a similar distinction. (Although I find DNS's somewhat confusing, with zones and all, and the ability to have more than oneA level in a zone - if I am remembering that correctly!) Anyway, I'm happy to switch to a different word for 'server', but it can't be 'node' - I am already using that to refer to the nodes in the abstract delegation hierachy. >> This case follows the processing of a typical user packet (for >> instance, a normal TCP data or acknowledgment packet associated with an >> already-open TCP connection) as it makes its way from the original >> source host to the ultimate destination. > A TCP Syn or data packet has no special difference at the network layer. > So why do you have to say this? Because I want to emphasize that this description applies to a packet which is _not_ the first packet exchanged, since _that_ packet might provoke a mapping cache miss, and reload - a more complex situation, and one which is covered in a separate description, below. I have added a few words to make this clear. >> When the packet has made its way through the local site to an ITR >> (which is also a border router for the site) > The ITR does not need to be a border router for the site. It could be > directly connected to a source, or even a PE router. So just strike the > text in the parens. But in this _example_ it is. But you are correct that the wording is inappropriate, so I have modified it. >> (Typically, like many ARP implementations, the original user packet >> will have been discarded, not cached waiting for the mapping to be >> nfound. When the host retransmits the packet, the mapping will be >> there, and the packet will be forwarded.) > I would strike the text in the parens. And add a short paragraph > indicating the packet could be dropped, queued, or sent natively. Where > the latter means it would flow toward a PITR. I seem to recall a discussion in which I was informed that queueing packets while waiting for the mapping to arrive was unlikely to be a viable strategy; there are just too many ways to Lose.Big doing that. Since I'm trying to show what will happen to a _typical_ packet, I think this is the one to focus on. But I will mention the other possibilities, improve the text about dropping, and put it all in a new para. >> [[E3: Should we given the detail on at least on DDT step?]] > I think you missed explaining that if a Map-Request is not going to a > Map-Server that intermediate DDT-nodes return referrals. That's now covered as a result of the re-write above. > And when you explain that you should indicate that they provide keys for > the children so subsequent Map-Referrals can be verified. My sense is that that's too much detail for this 'Examples' section, which is here to provide people with a rough picture of how typical packets get handled. I will mention that in the detailed section on DDT, though. And there is an entire section, "Security of the DDT Indexing Sub-system", which covers DDT's security in more detail. >> The UDP checksum is zero because the inner packet usually already has a >> end-end checksum, and the outer checksum adds no value. [Saltzer] In >> most exising hardware, computing such a checksum (and checking it >> at the other end) would also present an intolerable load, for no >> benefit. > I am feeling this is too much detail. Why does someone who wants an > intro need to know the detail about a checksum? Well, now we're into the part of the document that starts to go into more detail. Yes, this is more 'design insight' than strictly an introductory description, but... this is supposed to be an architecture document, right? And there isn't a natural place to put it in the perspective document, which focuses on larger issues; this is a very localized, small, one. >> Note that lack of a response is not necessarily _proof_ that something >> has gone wrong - but it stronly suggests that something has, so other >> actions (e.g. a switch to an alternative ETR, if one is listed; a >> direct probe; etc) are advised. > Change to ".. a direct RLOC probe". Sorry, I don't see the benefit of that? The text is clear that the ETR is being probed? If there was some kind of probe that was particularly advised, I could see listing it, but I fail to see how mentioning "RLOC" helps. OK, enough for now. Another tranche 'soon' (probably tomorrow). Noel From jnc@mercury.lcs.mit.edu Sat Sep 28 09:25:44 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5685121F9E7E for ; Sat, 28 Sep 2013 09:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDGRHR3yJbxm for ; Sat, 28 Sep 2013 09:25:39 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id CF16321F9DCB for ; Sat, 28 Sep 2013 09:25:38 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DF3AE18C1B0; Sat, 28 Sep 2013 12:25:35 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130928162535.DF3AE18C1B0@mercury.lcs.mit.edu> Date: Sat, 28 Sep 2013 12:25:35 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments to draft-ietf-lisp-introduction-02 (tranche #3) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 28 Sep 2013 16:25:44 -0000 > Noel, here are my comments. Here is the third (and final) tranche of replies to your comments. As before, I did not _always_ agree yadda-yadda-yadda. Noel ---- >> The probing mechanism is rather heavy-weight and expensive > You said it was simple but then you say heavy-weight. Those are not incompatible? (Levelling an entire city with an H-bomb to get rid of some snipers is a simple, but heavy-weight method of dealing with the problem... :-) I looked at this for a while, trying to see how to say that differently, but I can't come up with anything better than what's there already? (I looked in a thesaurus, but all the words I saw that seemed plausible were no better.) > What you want to say is if the map-cache is large, a lot of messages > will be required to be sent. To make it scale, you have to spread the > sending of RLOC-probes over time. Which then affects the down detection > convergence. That is probably worth pointing out, done. >> However, it has the advantages of providing information quickly (a >> single RTT), and being a simple, direct robust way of doing so. > And note that Echo Noncing in the data-plane can be faster assuming > bidirectional traffic. I think what you meant there was not that an Echo Nonce is faster (since both require a minimum of an RTT), but that _unless likely unreasonable amounts of RLOC Probing control traffic are used_, Echo Nonce will, on average, provide faster notice of loss of reachability? That is also worth pointing out, done. >> Mappings might also be discarded before the TTL expires, depending on >> what strategies the ITR is using to maintain its cache > And the RLOC-set can change before the map-cache entry times out. You mean, the {EID->RLOC} mapping might change? (You're not, for instance, talking about the LSB bits?) True, but I don't understand the relevance at this point in the document. There is an earlier section, "Mapping Versioning", which talks about that circumstance, and the mechanism to detect it, in detail? >> Very briefly, the ITR provided a One-Time Key with its query; this key >> is used by both the MS (to verify the EID block that it has delegated >> to the ETR), and indirectly by the ETR (to verify the mapping that it >> is returning to the ITR). > The ETR uses the MS's OTK to sign the block. The ETR does not know the > ITRs OTK and doesn't verify anything. The ITR verifies the signed > Map-Reply by generating the MS OTK from its OTK (like the MS does) and > uses the MS OTK to verify the signature, since that was the same key the ETR > used. First, yes, 'verify' is the wrong word; I have changed them to 'sign' (and tweaked the wording for the MS slightly). As to the rest, I'm not trying to give the full details of the mechanism in that text (note the "Very briefly"); I'm just trying to summarize _what_ it does, not _how_. And it does say that the ETR uses the ITR's OTK "indirectly". >> [[X3: Spec is unclear about who reassembles; says "fragments are >> reassembled at the destination host" but also "reassembly can >> happen at the ETR" - I would have thought the latter was very >> undesirable, for all the obvious reasons, unless the dest cannot >> reassemble?]] > Right because if a core router fragments, it is fragmenting a packet > destined to the ETR. Ah, right: I forgot there might be two kinds of fragmentation (at the ITR, and by routers on the path between the ITR and ETR). Does the latter actually happen, or are all LISP-encapsulated packets sent with DF on? In other words, are ETRs actually supposed to be prepared to reassemble fragmented packets which they receive? >> To recap, the mapping system is split into an indexing sub-system, >> which keeps track of where all the mappings are kept, and the mappings >> themselves, the authoritative copies of which are always held by ETRs. >> [[M0: Should we mention, somewhere, the cases where they aren't - >> i.e. proxy map-replying?]] > I think you could have reference proxy map-replying in the DDT example. It seems to me that that point fits more logically in the section "Interface to the Mapping System", which talks about Map-Requests and Map-Replies. I have added mention of proxy map-replying there. > That way you can say that the MS either forwards the Map-Request to the > MS or proxy reply itself. The DDT detailed description (in "The DDT Indexing Sub-system") already mentions this. >> "Solicit-Map-Request" (SMR) messages are actually not another message >> type, but a sub-type of Map-Reply messages. > SMRs are Map-Requests because you want to use the long nonce as well. So > an SMR is a Map-Request that is responded to by another Map-Request with > the SMR-invoked bit set. And the nonce from the SMR is returned in the > SMR-invoked Map-Request. Sorry, my brain isn't firing on all cylinders today. Why is it important that the second Map-Req (the one with the SMR-invoked bit) use the same nonce? Is it because SMR is sent when the ETR has a new mapping, and it needs the ITR to reload the mapping? But if so, I'm not following how the nonce adds anything. All the ETR needs to know is that i) the ITR tried to update the mapping (and the second Map-Request tells it that, without either the nonce or the SMR-invoked), and ii) that the ITR successfully received the Map-Reply - and I don't see how any of this does that? > Also note an RLOC can be a multi-tuple encoding meaning it can return, > for example, a Geo-Tag, or ELP or a RLE (replication list entry for > multicast). I don't want to say too much about n-tuple RLOCs, because those are all 'work in progress', and this document is (mostly) supposed to describe LISP as it is. (I have made an exception about DDT because ALT is already obsolescent.) I did consider alluding to n-tuple RLOCs as 'improvements in progress', in a different place, higher up the document (which would be the appropriate location for such an observation), but I decided not to, because it just opens up too big a can of worms. Right at the moment that section's really simple and straight-forward, EIDs identify the hosts, RLOCs where they are, yadda-yadda, and I have to put in a * and say 'Well, except when RLOCs are lists', it's just too hairy. Look, don't get me wrong, I think n-tuple RLOCs are cool and powerful, but... >> Map-Notify messages have the exact same contents as Map-Register >> messages; they are purely acknowledgements. > They are not just acknowledgements. They are used to tell the old > RLOC-set that new RLOCs have been registered. In an extension that is not documented in anything which is available to the IETF... :-( :-) But I will allude to their extension for other uses. >> The interaction between MRs and DDT servers is not complex; the MR >> sends the DDT server a Map-Request control message (which looks >> almost exactly like the Map-Request which an ITR sends to an MR). > Don't need to say the text in the parens. I don't particularly see the harm in it, but OK. > And again use "DDT node" and not "DDT server". See previous comment (in tranche #2) about DDT "node" and "server". >> If the latter, the MR then interacts with that MS, and usually the >> block's ETR(s) as well, to cause a mapping to be sent to the ITR which >> queried the MR for it. > This is the place to put the public key description in and how the MR > will verify a Map-Referral. There is an entire section "Security of the DDT Indexing Sub-system", which covers that (although maybe it should have a bit more detail than it does). I will put in a forward reference to it. >> 10.2.1. Map-Referral Messages >> Map-Referral messages look almost identical to Map-Reply messages >> (which is felt to be an advantage by some people, although having a >> more generic record-based format would probably be better in the >> long run, as ample experience with DNS has shown), except that the >> RLOCs potentially name either i) other DDT nodes (children in the >> delegation tree), or ii) terminal MSs. > There is no need to have this section I think. I think it's good to have all the message types show up in the TOC, for people who want a quick reference. And pointing out how the data returned may differ is, I think, also useful. > And don't criticize the architecture you are describing. ;-) I will take out the comment. But the design is still bad, and I will oppose it in the WG, and (if necessary) at the IESG, and IETF last call. >> 10.3. Reliability via Replication >> Everywhere throughout the mapping system, robustness to operational >> failures is obtained by replicating data in multiple instances of >> any particular node (of whatever type). Map-Resolvers, Map-Servers, >> DDT nodes, ETRs - all of them can be replicated, and the protocol >> supports this replication. >> .. >> There are generally no mechanisms specified yet to ensure coherence >> between multiple copies of any particular data item, etc - this is >> currently a manual responsibility. If and when LISP protocol adoption >> proceeds, an automated layer to perform this functionality can 'easily' >> be layered on top of the existing mechanisms. > I do not understand what you mean here. Re-reading it, it seems pretty clear to me? I will add some examples in the second paragraph (e.g. the copies of delegation data for a particular block of namespace, in two DDT sibling servers), but I don't see how else to make this plainer. > And therefore, why it is even necessary to have multiple copies. We _already_ have multiple copies of many kinds of data (e.g. the mappings in ETRs). This replication, and the ensurance of the coherence thereof, is all entirely manual at the moment. >> The client interface provides only a single model, using the >> 'canonical' public-private key system > There isn't any client interface. There is just the Map-Referrals that > the DDT-nodes use. That _is_ the client interface. > Just indicate that a parent will provide the public key of the children > so when the children sign a Map-Referral, the MR can verify it. I had already improved this text somewhat, along the lines you indicate, after a comment above. >> [[M4: Any more?]] > There are examples in the TE draft. That will have to go in the 'Improvements' ID, I'm afraid. (That ID - long story, I'll send a message to the WG about it.) >> [[M5: Perhaps this belongs in "Scalability"?]] > Yes, put all scalability in one place. Hmmm. If we're going to do that, _and be consistent_, we'd have to move a bunch of other stuff too. For instance, the cache scalability stuff in the "Major Functional Subsystems" section ought to be moved, too. Let's talk about this at the interim. >> [[M6: What about potential caching in MRs?]] > Don't document it because you will set an expectation and readers won't > find it in any of the RFCs. Should I apply this principle uniformly? ;-) But I agree that this should not be mentioned here. >> If an ITR is holding an outdated cached mapping, it may send packets to >> an ETR which is no longer an ETR for that EID. >> ... >> ETRs can easily detect cases where this happpens, after they have >> un-wrapped a user data packet; >> [[F4: The LISP spec is not clear (at least, on a quick reading) on >> whether ETRs should check for this > They need state from the mapping system that tells them an EID-prefix > has moved. That is what tells an ETR is is the wrong one. Huh? The ETR has to have all its mappings - it is, after all, authoritative for them!!! So if a packet for 1.2.3.4 arrives at an ETR, and the ETR's only mapping currently is for 1.2.77/24, it can tell instantly that it is _not_ a valid ETR for that packet. The only question is 'do all ETRs check for this'? >> 12.3. Erroneous Mappings >> Again, this 'should not happen', but a good system should deal with >> it. However, in practise, should this happen, it will produce one >> of the prior two cases (the wrong ETR, or something that is not an >> ETR), and will be handled as described there. >> [[F8: I suppose if one ETR is handing out bad mappings, it might be >> nice to be able to bypass it. This probably falls under 'Future >> Work', though.]] > This section sounds like a requirement and not a description of what can > happen. Say what? Human errors 'can't happen'? Of course they can. > I think it should be removed. I'm trying to cover all the potential cases here. >> 12.5. Neighbour Reachability > I think this section is redundant with the previous. If you think there > are salient points in it, then move them to the prior parapgraph. Sorry, but I think i) most of the content in this section is not redundant, and ii) I think it is important to distinguish between liveness and reachability. >> 13. On-Going Improvements Due to a variety of factors, I have split off this entire section as a new document; I'll deal with comments on these later. Noel From jnc@mercury.lcs.mit.edu Sat Sep 28 09:34:37 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1219F21F9A61 for ; Sat, 28 Sep 2013 09:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-0QTxR0MxB1 for ; Sat, 28 Sep 2013 09:34:32 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id E0C4621F9A37 for ; Sat, 28 Sep 2013 09:34:31 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 970DB18C1B0; Sat, 28 Sep 2013 12:34:31 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130928163431.970DB18C1B0@mercury.lcs.mit.edu> Date: Sat, 28 Sep 2013 12:34:31 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments to draft-ietf-lisp-introduction-02 (tranche #3) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 28 Sep 2013 16:34:37 -0000 > I did consider alluding to n-tuple RLOCs as 'improvements in progress', > in a different place, higher up the document (which would be the > appropriate location for such an observation), but I decided not to, > because it just opens up too big a can of worms. Right at the moment > that section's really simple and straight-forward, EIDs identify the > hosts, RLOCs where they are, yadda-yadda, and I have to put in a * and > say 'Well, except when RLOCs are lists', it's just too hairy. So I lied. It turns out I do mention n-tuple RLOCs in the current version; they are in "Mapping System". Noel From jnc@mercury.lcs.mit.edu Sun Sep 29 14:17:43 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1231F21F9B86 for ; Sun, 29 Sep 2013 14:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.787 X-Spam-Level: X-Spam-Status: No, score=-5.787 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYSzQCjpOKet for ; Sun, 29 Sep 2013 14:17:38 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id E093221F9DCB for ; Sun, 29 Sep 2013 14:17:26 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 19B8418C192; Sun, 29 Sep 2013 17:17:26 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130929211726.19B8418C192@mercury.lcs.mit.edu> Date: Sun, 29 Sep 2013 17:17:26 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 21:17:43 -0000 {Digging back through my mail folder to fold in all the comments people sent me; sorry I didn't respond earlier, but your words were not lost as biton radiation... :-} >> From: Michiel Blokzijl (mblokzij) [mailto:mblokzij@cisco.com] >> I think there's nothing wrong with discussing it in general, I just >> thought that typically you'd explain the protocol first, and then the >> limitations when the reader has a bit more of an understanding of the >> protocol ... I thought section 4 might be a potential starting point >> for people who want to find out what LISP is about without reading all >> of the background material. Basically, it was meant more as a >> structural/ordering comment. > From: Ronald Bonica > To date, a major shortcoming in the LISP document set is that explains > protocol machinery in great detail, but never really explains: > - What problem it is trying it solve > - Whether the protocol machinery offered is both necessary and sufficient to solve the problem > the purpose of the introduction and architectural perspective documents Architectural introduction and perspective, actually... :-) > Given that LISP's primary claim was to separate locator semantics from > identifier semantics, it is very appropriate that Noel should introduce > this discussion very early in the document. Guys, I have read carefully what you both had to say, and you both have good points; and I have looked again at the text in light of those points, The text as it stands has to balance a couple of powerful forces. One is the need to be accurate. The other is not to get into long digressions that divert the reader. I thought the existing text did that pretty well, but I've taken another look at it. I have toyed with the text some, seeing if I could improve it (e.g. I tried adding the phrase "but both design analysis and experience have shown it to be 'good enough'" at the end), but most of what I did just made it worse. I did wind up re-arranging it slightly, and making minor changes to the wording, so that it still contains the caveat, but it's not quite as jarring to the flow as it was before. Noel From jnc@mercury.lcs.mit.edu Sun Sep 29 19:23:10 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C2921F9DC9 for ; Sun, 29 Sep 2013 19:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.642 X-Spam-Level: X-Spam-Status: No, score=-5.642 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s65FElwTkMTT for ; Sun, 29 Sep 2013 19:23:05 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 94F9021F9D62 for ; Sun, 29 Sep 2013 19:23:05 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B07D118C099; Sun, 29 Sep 2013 22:23:00 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130930022300.B07D118C099@mercury.lcs.mit.edu> Date: Sun, 29 Sep 2013 22:23:00 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 (tranche #1) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 30 Sep 2013 02:23:10 -0000 Michiel, thanks for the comments. Most of them produced significant improvements in the document. Sorry it's taken me a while to get to them! This is the first part; I will finish it off tomorrow. Noel -------- > From: "Michiel Blokzijl (mblokzij)" > General comments: - I'd consider moving some of the "other attempts > failed to recognise X.." bits into their own section, or possibly into > another document. I think these somewhat fall into the category of "LISP > in the context of the history of the internet" :) I can easily believe that (such things would in fact fit better in the 'Perspective' document), but I'm too burned out to trawl through the entire document and find the things that fall into that class. There will be a final draft 'soon', and if you read that, please bring these to my attention. [Later: I found one, the griping about lack of separate naming for interfaces and stacks.] > After reading more of this document, I think it starts to sound more > like "A survey on LISP"? I'm not sure quite what you mean by this, how a 'survey' might differ from an 'introduction' or an 'overview' (and which of the three this thing ought to be). > I hope my comments don't come across as overly negative.. Not to worry. If I think you're wrong, I'll say so! :-) >> LISP separates the functions of location and identity of nodes (a >> nebulous term, deliberately chosen for use in this document precisely >> because its definition is not fixed - you will not go far wrong if you >> think of a node as being something like a host), which are currently >> intermingled in IPvN addresses. (This document uses the meaning for >> 'address' proposed in [Atkinson], i.e. a name with mixed location and >> identity semantics.) > So in RFC6115 nodes were defined as either routers or hosts (section > 1.2, 1.). What else are you thinking about? I have an entry for 'node' in the Glossary now. > I think the bracketed bit just confuses readers, and I think it can be > removed. Assuming you mean the first one (about nodes), it is now elsewhere. > I'm not sure whether location and identity are 'functions' of IPvN > addresses, rather than, say, properties. Are you saying that the > location is a function that takes as input an IP address and produces as > output.. a location description? I guess you could look at it in that > way. Well, 'function' in a more general sense ('the function of the steering wheel is to control the direction of the front wheels'), but yes, 'property' is probably a better word - or it would be, if I hadn't removed 'function' already in the earlier changes to this section... :-) >> In LISP, nodes have both a 'locator' (a name which says _where_ in the >> network's connectivity structure the node is), called an 'RLOC' (short >> for 'routing locator'), and an 'identifier' (a name which serves only to >> provide a persistent handle for the node), called an 'EID' (short for >> 'endpoint identifier'). > Style comment: I think it's better to spell acronyms out the first time > they're being used, and then provide the abbreviation in brackets. I'm going to leave it the way it is, as the terms "RLOC" and "EID" are universal, and it therefore seems odd to me to have them in parens. >> A node may have more than one RLOC, or its RLOC may change over time >> (e.g. if the node is mobile), but it would normally always keep the >> same EID. > A node may also have more than 1 EID, e.g. one for v4 and one (or more) > for v6. Maybe it's worthwhile saying "EID(s)", or is that confusing? Since the average node will have only one, yes! >> Technically, one should probably say that ideally, the EID names the >> node (or rather, its end-end communication stack, if one wants to be as >> forward-looking as possible), and the RLOC(s) name interface(s). (At >> the moment, in reality, the situation is somewhat more complex, as will >> be explained elsewhere (in [Perspective], Section >> "Namespaces-EIDs-Residual".) > I think both of the sentences in brackets are confusing, and don't aid > the reader much. The RLOCs naming the interfaces applies only to a small > subset of devices in the LISP EID (address) space, namely the (P)xTRs, > for the hosts in a LISP site the RLOCs name their xTRs' interfaces. I see your point (although it does say "the RLOC(s) name interface(s)", not 'the node's interface(s)' :-). I have re-arranged all this text substantially, to try and improve it. I do think it's important to make that point that ideally, we should have the two different classes of names different classes of objects; this is a long-standing lack of clarify in the existing Internet architecture, and it would be good fix this too, as well as the lack of L/I separation. >> This second distinction, of _what_ is named by the two classes of name, >> is necessary both to enable some of the capabilities that LISP provides >> (e.g the ability to seamlessly support multiple interfaces, to >> different networks), and is also a further enhancement to the >> architecture. Faailing to clearly recognize both interfaces and >> communication stacks as distinctly separate classes of things is >> another failing of the existing Internet architecture (again, one >> inherited from the previous generation of networking). > I think it would be better to talk about use-cases later in the document > (I'm referring to the seamless multihoming). That's just an example, to aid in comprehension. But I have totally re-organized all this too. > I'm sure you guys know more about this, but I don't think that > interfaces and communication stacks are completely separate "classes of > things" Read RFC-1498 and http://www.chiappa.net/~jnc/tech/endpoints.txt. > After all, L2 is a part of the communication stack, and that's to some > degree bound to interfaces. "Stack" is used as an alternative term for 'endpoint' (AKA "fate-sharing region"). I have clarified this in the text too. >> A novelty in LISP is that it uses existing IPvN addresses (initially, >> at least) for both of these kinds of names, thereby minimizing the >> deployment cost, as well as providing the ability to easily interact >> with unmodified hosts and routers. > Good - not sure 'novelty' is the right word though. That's because it was a novelty to me: the basic concept of something like LISP has been around for a long time (that was the Nimrod deployment plan), but having IPvN addresses as both inputs _and_ outputs was the novel insight, from my point of view. > Maybe say something like.. "In order to minimise deployment costs, LISP > supports existing IPvN addresses for both of these kinds of names, as > well as other future address family types. The former facilitates the > interaction with unmodified hosts and routers." I have re-organized this text too. > The first few paragraphs of this section take the reader from the > abstract concept of 'intercepting' and 'augmenting' packets to the > actual encapsulation process in multiple stages. I think this makes the > whole process sound more mysterious than it actually is, but it's > probably OK. I looked at this, and thought about it for a bit, but my concern is that if I immediately jump into the concrete details people will only think of it in low-level engineering terms. I know a lot of people habiturally think at this level, but I'd like to at least try and get them to see things in a higher-level way. I did tweak it a tiny bit, in an attempt to make it less mystical. >> The LISP device near the original source (the Ingress Tunnel Router, or >> 'ITR') uses the information originally in the packet about the identity >> of its ultimate destination, i.e. the destination address, which in >> LISP is the EID of the ultimate destination. It uses the destination >> EID to look up the current location (the RLOC) of that EID. > I'd try and simplify the sentence a little bit, the destination bit is > quite repetitive. True, done. >> The lookup is performed through a 'mapping system', which is the heart >> of LISP: it is a distributed directory of mappings from EIDs to RLOCS. >> The destination RLOC will be (initially at least) the address of the >> LISP device near the ultimate destination (the Egress Tunnel Router, or >> 'ETR'). > This is inconsistent with what ["Basic Approach"] says about what RLOCs > should ideally be. "Basic Approach" has been reorganized as a result of earlier comments. >> {{Is it worth distinguishing between 'mapping' and 'binding'? Should >> the document pick one term, and stick with it?}} > To be honest, I'm not sure what the difference is. I looked at RFC6830, > and it only uses the word binding in 2 places 6830 is irrelevant. I'm using 'binding' in the CS sense of the term. See RFC-1498. > I'd prefer to know the difference between the two before giving an > opinion 'Binding' is the formal computer-science term. 'Mapping' is the term used in LISP. (Although, to be technical, 'binding' refers to the association between a name, and an object. This association may be inherent [e.g. memory loctions, disk blocks] or constructed [e.g. a file name], which involves a 'directory', if I am recalling the jargon correctly. And I guess I have just answered my quetion: the things in LISP aren't really 'bindings' in the computer science sense of the word.) > I think it would be better to stick with 'mapping system', which was > used in the previous paragraph, rather than using the term 'mapping > database'. I carefully define, and throughout the document try and carefully distinguish between the 'mapping database' (the collection of mappings'), and the 'mapping system' - the entire system of MR's, indexing subsystem (DDT), etc - which allows clients to retrieve mappings. I may have some places where I didn't use the right term, but if so, I'd like to fix them. I have added some text here to define the second, and the difference between them. >> Extensive studies, including large-scale simulations driven by lengthy >> recordings of actual traffic at several major sites, have been >> performed to verify that this 'pull and cache' approach is viable, in >> practical engineering terms. > This is interesting. I'm not sure if I'd put it into a "further reading" > section though. But to talk about this in detail here would require a lengthy diversion into details, de-railing the rolling out of the 'big picture' of the entire system. Much as I would love to, I can't (in a linear document) talk about everything in full detail at once. > I probably would've summarised the first two paragraphs [of > "Interworking With Non-LISP-Capable Endpoints"] into a sentence and > merged it with the last one: I did look at this, but it doesn't clearly make a number of points which are in the original text, and which I think are important to convey. So I have left this as it is. > I would also provide references to the two approaches you introduced here. Done. > ["Security in LISP"] > I would provide the brief overview first, and then say "for more > details, go to.." Well, but I wanted to flag for them, _before they read the section_, that this is only a high-level gloss on the topic... and having done that, it seemed like a good place to stick the reference. I mean, otherwise, I have to have a whole sentence at the end, saying 'for more see xxxx'. > At the same time, I don't think that this section actually says anything > at all about LISP security, beyond telling the reader that it's been > considered, and that there's a tradeoff between security and > deployability. It only talks about security in general. Well, yes. LISP Security is an incredibly complex topic, with quite different mechanisms all over the place; there is simply no simple way to describe it briefly. Even a page would be a total gloss - and I don't want to spend an entire page this early in the document on a massive derail into a semi-detailed description of 5 different security mechanisms. I can probably edit this down to make the points it does in less space, though. > ["Initial Applications"] > I think the whole section focuses a little too much on the motivation to > cater for the various use-cases, and a too little on how LISP uniquely > addresses them. That's possible a worth-while thing to write somehere, but to do it here would have taken a lot more space. I'm not sure we can afford it - what's the cost/benefit of discussing this, versus the space it will take to do so? Also, this is 'Introduction to LISP', not 'Why LISP is the greatest things since sliced bread'. From jnc@mercury.lcs.mit.edu Mon Sep 30 11:42:14 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC03621F994A for ; Mon, 30 Sep 2013 11:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2SseIWP21Dt for ; Mon, 30 Sep 2013 11:42:10 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 917A421F9B60 for ; Mon, 30 Sep 2013 11:42:09 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7BB9B18C109; Mon, 30 Sep 2013 14:42:06 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130930184206.7BB9B18C109@mercury.lcs.mit.edu> Date: Mon, 30 Sep 2013 14:42:06 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 (tranche #2) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 30 Sep 2013 18:42:14 -0000 OK, here's the rest. Usual caveats apply (thing I agreed with aren't mentioned, etc). Noel -------- > ["Multi-Homing"] > I think it'd be nice if this section explained at least briefly how LISP > actually helps with multi homing (priority & weights). I think those are more important for Traffic Engineering, no? I mean, if you care _which_ ETRs traffic flow through, then you need those fields - but caring which ETR traffic comes in through is by definition TE, no? > ["Traffic Engineering"] > I think the first two sections are somewhat repetitive in terms of > explaining that the internet was not designed with TE in mind. Well, the content is not actually repetitous, since the second one talks about how TE is really functionally a routing thing. And I would have said that the second is probably excess non-relevant detail, except that the para after that goes on to talk about how doing TE with LISP is slightly 'hammer-nail', and I think that needs the preceeding paragraph to make sense. > I actually went and looked in section 6.2. The only bit that refers to > TE is this: > ... > If it's just this one sentence, maybe it's worth stating that the > priorities and weights can be used for [ingress] TE? Well, you have a point about the thinness of what's said at the location of the forward pointer, but alas I don't think I have a better place to point to - details of applications of LISP are, for better or worse, outside the scope of this document: to include them all would greatly increase the size of the document. I have added a reference to the LISP-TE document. And moving that content back here isn't really in the cards either: if I moved all the content at forward references back, it would just create others. You can't have 'everything in front of everything else'. > ["IP Version Reciprocal Traversal"] > "Note that LISP 'automagically' allows intermixing of various IP > versions for packet carriage" > Are words like 'automagically' often used in RFCs? No, but it made me sad to take it out - the IETF is so humourless that it can't tolerate a tiny bit of whimsy? > I would somehow tie in that this is because LISP can use different > versions of IP (or other protocols?) for the EID and RLOC space, or is > that too technical? Well, I could have put in an allusion to that - except that that capability is not mentioned until later. Again, everything before everything else problems... :-( > ["Local Uses"] > Is it worth mentioning the words 'network virtualisation' in this > context, or is that too buzzwordy? It is pretty buzzwordy, but it's also pretty common - and also, I gather, one of the most common uses of LISP in practise - so I had already added a bit about it (although not that specific term - it just talks about "virtual networks, and virtual machine mobility"). > ["Mapping Cache Performance"] > I think this section is more appropriate for a survey than for an > introduction. The problem is that the first thing one hears from a lot of people, when talking about LISP, is 'oh, the caching won't work'. So I think we have to talk about it. I did earlier decide that this section was too long, with too much detail, and so it has been reduced in size considerably, > ["Mapping System"] > I think it would be better to use the terms 'mapping system' and mapping > database' consistently. I have tried to do this (as explained earlier), but I haven't recently done a front-> back readthrough, and so I may have missed some. I will be doing such a read-through 'soon' (as soon as I finish going through all the comments), and I'll try and catch any remaining problems at that point. If anyone sees any, of course, please let me know. >> However, the block may be (and often is) as small as a single EID. > I'm not sure if "often" is correct. I took the HTML of > http://www.lisp4.net/lisp-site/, discarded everything outside the main > table, and all lines that didn't contain a '/' (trying to keep all the > prefixes), sorted them and removed duplicates. That left me with 690 > prefixes, 141 (~20%) of which were /32 or /128 (I didn't find /32 IPv6 > addresses). I think the numbers make sense for an estimated nr of 355 > sites, as it's on average ~2 prefixes/site. ???? If I'm reading you correctly, out of 690 entries, ~20% are host entries? How is this not "often"? Not that it really matters - I can drop the "and often is" if it's an issue. > ["Interface to the Mapping System"] >> Re: (MSs - admittedly a poorly chosen term, since their primary function >> is not to respond to queries > I'd be half inclined to remove the note about it being a poorly chosen > term - maybe some day enabling proxy replies will be the recommended > deployment method? Dino mentioned this too. I dunno, the terminology _really_ confused me for a while, and it took a while to get it straight. If people really don't like it, I can remove it, though. From jnc@mercury.lcs.mit.edu Mon Sep 30 15:52:54 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0B921F99E1 for ; Mon, 30 Sep 2013 15:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzoK2i1tjMAn for ; Mon, 30 Sep 2013 15:52:50 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 523F021F90AC for ; Mon, 30 Sep 2013 15:52:50 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7645718C102; Mon, 30 Sep 2013 18:52:47 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130930225247.7645718C102@mercury.lcs.mit.edu> Date: Mon, 30 Sep 2013 18:52:47 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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, 30 Sep 2013 22:52:55 -0000 > From: "Vasileios Lakafosis (lakafosi)" > Below please find a few comments of mine. Thanks; as with others who commented, if it's not discussed, I agree with it. Some comments below. Noel --------- > General - [whole document] > - You tend to use the verb "switch" for xTRs. Is that correct/intended That's short for the generic "packet switch". I have made that clear in the glossary (doing so on the first use would have made some already much-tweaked text even more convoluted). > please choose between "user interface" or "client interface". I would go > with the second one, as the first one can bring wrong associations to a > totally new-comer. Good catch. I use the term "user data packet" a lot, to indicate user's packets; is that problematic too, or acceptable? > You do include solutions/contributions offered when describing a LISP > feature and it's real nice (given you are skipping technical details > because of brevity of doc). This is _not_ the case, though, for > sections: > - [4.5] Security > - [12.4] Liveness > Here you only discuss the necessity, rather than what they at least > offer or intend to offer. "Security" I already talked about in a reply to Michiel; basically, there are a long list of completely different, very complex mechanisms, and it's simply impossible to describe them briefly. (It would take a really large chunk of text to even briefly explain them, and that would be grossly out of place in" the "Overview" section. There are forward refs to three of them: requesting mappings can be secured (see ), as can registering of xTRs (see ); the key indexing database of the mapping system is also secured (see ) For "Neighbour Liveness", note that it says: Solving a related problem, neighbour reachability (below) subsumes handling this fault mode, however. and if you look in the "Neighbour Reachability" it does give some details of the various ways of doing that. > ["Local Uses"] > What do you mean by "application-specific data"? Err, that's a euphemism for a use-case that I was told about in confidence... :-) > ["xTRs"] > "now-normal" > I would put this in double quotes. Err, why? It's not a euphemism, it's a straight English compound adjective ('that are now normal'). > ["Indexing Sub-system"] > This section should not be so much tied to DDT. Well DDT (and the now-obsolescent ALT) are the only two that LISP is _actually being used with_ - at least, AFAIK. ALT is covered in Appendix "The ALT Mapping Indexing Sub-system", and DDT here. > It should be highlighted that _any_ database that meets the requirements > could be used. And there ware plenty of examples. And this gives > versatility to LISP. I believe the point has been previously made (in "Indexing Sub-systema") that it's easy to replace the indexing subsystem: which would allow the actual indexing sub-system to be replaced without needing to modify the clients But I'll make it a bit more explicit. > ["DDT Overview"] 5th paragraph > This seems wrong. The DDT leaf nodes _are_ MSs No, not according to the 'indexing sub-system'/'client interface-subsystem' definition; by definition, the MS's are on the _other_ side of the 'indexing subsystem interface', and thus cannot be 'DDT leaf nodes'. > 2nd paragraph "necessarily smaller" > Redundant as it cannot be larger anyways as only parts can be delegated > to children. Yes, but is there any harm in spending two words to make it explicit? It may be obvious to you, but not everyone is that clued... :-) > ["An Ordinary Packet's Processing"] > It would be helpful to add a paragraph about the reason of/benefits from > the existence of the LISP header. This is explained below, in "UDP Encapsulation Details"; I have added a forward ref, is that good enough? > ["When to Encapsulate"] > 3rd paragraph: did you intend to say "despite the fact" or "although" > instead of "because"? Ah, no? Re-reading the paragraph in question, it seems to be fairly clear? However, I have added an additional explanatory clause. > ["Map-Register and Map-Notify Messages"] and elsewhere > "and its AFI" > Why keep mentioning AFIs? Doesn't it go without saying? Perhaps, but I'd rather be explicity (it's only a couple of words), rather than having the reader wonder 'hmm, I wonder if they left off the AFI there - and if so, why'. > ["The DDT Indexing Sub-system"] > - 3rd paragraph: You may want to use "DDT nodes" everywhere (as in the > draft) instead of the term "servers". See my reply to Dino about this; a "DDT node" is an abstract node, in the namespace delegation hierarchy. A "DDT server" is an actual machine which one can send packets to. I _hope_ I have used these terms consistently in the document; if not, let me know. I will add entries in the Glossary to make them explicit. > - 6th paragraph: "{{I think this case has been mentioned already; > check.}}" yes, it has been. So, I would remove the next paragraph > "Delegations are" Huh? The following paragraph has nothing to do with the one before it: the first speaks of MS's proxy-replying on behalf of ETRs; the second is about MRs caching delegations. > ["Mobile Device Support"] > The way 13.2 is written (with all these problems outlined and no > solutions provided) gives the impression to the new-comer that mobility > does not work in LISP today, which is absolutely wrong This entire section ("Current Improvements") has been moved out of this document. I'll save this comment for when I look at it. > [whole document] > No need to introduce new paragraphs at: > - [12.4] between 3rd and 4th paragraph You were right on the first one, but this one I'm going to leave: the two paragraphs talk about distinctly different concepts, and I think it is beneficial to underline this by the use of two separate paragraphs. > [4.2] 1st paragraph > no verb in the secondary "that" clause or confusing subject ("packets") > if "switches" is the verb I think this was not actually the case, but it's OBE because that text is different now. > Structure-related comments > ["Initial Applications - Mobility"] and ["Mobile Device Support"] > - Mobility (although indeed in different enough degree of > instantiations) has been around since almost the early days of LISP > itself. As such I wold remove it from improvements and move the [13.2] > text into [5.5]. > - No reference(s) provided in current [5.5] Well, the second section is now gone (see above), and I'm thinking of temporarily (in this RFC version) supressing the first one too, as Mobility is out-of-scope for the WG, and is not covered in the existing LISP document set. This has nothing to do with my person opinion of LISP mobility - _I_ think it's neat. But... > ["Mapping Cache Performance"] > - Shouldn't this section follow mapping [6.2]? And be a subsection of > that one? No, because the the mapping cache is in the XTR. > 3rd paragraph -- Description of first effort seems too long (also > compared to the rest ones). Feel free to drop out some details if possible. Done already. :-) http://www.ietf.org/mail-archive/web/lisp/current/msg04635.html (I came to the same conclusion independently.) > ["xTRs"] first paragraph > if [9.x] are "advanced topics" then it "automatically" makes them > candidates for removal given the prior email discussion about keeping > the _Intro_ document short. But I believe [9.1], [9.8], a few details in > [9.2] are indeed (fundamental) helpful to be included in this > document. Just pointing out in case you were looking to somehow cut down > the size of the document. Well, they are 'advanced' compared to the prior coverage of xTRs (in "Major Functional Subsystems - xTRs"). Since they all cover moderately low-level engineering details, not high-level architectural things, I don't believe they are suitable for relocation to the 'Perspective' document. (Some architectural aspects already have been moved over.) And they are in the 'second half', which the Preface explicity says is not part of the 'basic introduction'... :-) > ["The Mapping System"] 1st paragraph > Here you refer to only "indexing subsystem" and the "mappings" although > you mentioned _3_ subsections above [in 6.2.1]. Already fixed to name three here too. > ["Internetworking Mechanism"] > Shouldn't [11.3], [11.4], [11.5] and [11.6] be subsections of [11.2]? Perhaps, but then the nesting would get too deep: I don't think XML2RFC puts levels past 3 into the TOC, so someone looking into the TOC for, say, PITRs and PETRs would not find them. Since there's nothing in the section after those sub-sections, I made them peers of their intro section, rather than children.